Specifications and formal program development “in-the-large” What are specifications for? For the system user: specification captures the properties of the system the user can rely on. For the system developer: specification captures all the requirements the system must fulfil. Andrzej Tarlecki: Semantics & Verification - 261 -
Specification engineering Specification development: establishing desirable system properties and then designing a specification to capture them. Specification validation: checking if the specification does indeed capture the expected system properties. − prototyping and testing − theorem proving Andrzej Tarlecki: Semantics & Verification - 262 -
Formal specifications Model-oriented approach: give a specific model — a system is correct if it displays the same behaviour. Property-oriented approach: give a list of the properties required — a system is correct if it satisfies all of them. In either case, start by determining the logical system to work with. . . We will (pretend to) work in the standard algebraic framework BUT: everything carries over to more complex, and more realistic logical systems, capturing the semantics of more realistic programming paradigms. Institutions! more about this elsewhere: Andrzej Tarlecki: Semantics & Verification - 263 -
Specification languages ✓ ✏ ☛ ✟ Quite a few around. . . Choose one. ✡ ✠ ✒ ✑ Of course, you should be choosing Casl :-) Make even realistic large specification understandable! Key idea: STRUCTURE Use it to: • build, understand and prove properties of specifications • (though not necessarily to implement them) Andrzej Tarlecki: Semantics & Verification - 264 -
Programmer’s task Given a requirements specification produce a module that correctly implements it Given a requirements specification SP build a program P such that SP ❀ P ✬ ✩ ★ ✥ A formal definition of is a given by the semantics SP ❀ P ✧ ✦ ✫ ✪ (of the specification formalism and of the programming language) Andrzej Tarlecki: Semantics & Verification - 265 -
Recall the analogy: module interface ❀ signature module ❀ algebra module specification ❀ class of algebras Specification semantics Given a specification SP : • signature of SP : Sig [ SP ] • models of SP : Mod [ SP ] ⊆ Alg ( Sig [ SP ]) Specification equivalence : SP 1 ≡ SP 2 means Sig [ SP 1 ] = Sig [ SP 2 ] and Mod [ SP 1 ] = Mod [ SP 2 ] Specification consequences : SP | = ϕ means M | = ϕ for all M ∈ Mod [ SP ] Andrzej Tarlecki: Semantics & Verification - 266 -
Basic specifications � Σ , Φ � • Sig [ � Σ , Φ � ] = Σ • Mod [ � Σ , Φ � ] = Mod (Φ) Keep them small. . . Nothing to add, I think. Andrzej Tarlecki: Semantics & Verification - 267 -
Structured specifications Built by combining, extending and modifying simpler specifications Specification-building operations For instance: union: to combine constraints imposed by various specifications translation: to rename and introduce new components hiding: to hide interpretation of auxiliary components Three typical, elementary, but quite flexible sbo ’s Andrzej Tarlecki: Semantics & Verification - 268 -
Programmer’s task Informally: Given a requirements specification produce a module that correctly implements it Semantically: Given a requirements specification SP build a model M ∈ Alg ( Sig [ SP ]) such that M ∈ Mod [ SP ] Andrzej Tarlecki: Semantics & Verification - 269 -
Key idea SP ❀ M Never in a single jump! Rather: proceed step by step, adding gradually more and more detail and incorporating more and more design and implementation decisions, until a specification is obtained that is easy to implement directly Andrzej Tarlecki: Semantics & Verification - 270 -
Development process: SP 0 ñ ò SP 1 ñ ò · · · ñ ò SP n ñ ñ ñ ensuring: SP 0 ñ ò SP 1 ñ ò · · · ñ ò SP n SP n ❀ M ñ ñ ñ SP 0 ❀ M Andrzej Tarlecki: Semantics & Verification - 271 -
Simple implementations linked with such implementations ò SP ′ SP ñ ñ Proof obligation Means: Sig [ SP ′ ] = Sig [ SP ] and Mod [ SP ′ ] ⊆ Mod [ SP ] So: • preserve the static interface (by preserving the signature) • incorporate further details (by narrowing the class of models) Andrzej Tarlecki: Semantics & Verification - 272 -
Composability SP ′ ñ ò SP ′ ò SP ′′ SP ñ ñ ñ ò SP ′′ SP ñ ñ Easy consequence: ò · · · ñ M ∈ Mod [ SP n ] SP 0 ñ ò SP 1 ñ ò SP n ñ ñ ñ M ∈ Mod [ SP 0 ] Andrzej Tarlecki: Semantics & Verification - 273 -
For instance spec StringKey = String and Nat then opn hash : String → Nat spec StringKey nil = String and Nat then opn hash : String → Nat axioms hash ( nil ) = 0 spec StringKey a z = String and Nat then opn hash : String → Nat axioms hash ( nil ) = 0 hash ( a ) = 1 . . . hash ( z ) = 26 THEN StringKey ñ ò StringKey nil ñ ò StringKey a z ñ ñ Andrzej Tarlecki: Semantics & Verification - 274 -
. . . and then, for instance spec StringKeyCode = String and Nat then opns hash : String → Nat str2nat : String → Nat axioms str2nat ( nil ) = 0 str2nat ( a ) = 1 . . . str2nat ( z ) = 26 str2nat ( str 1 � str 2 ) = str2nat ( str 1 ) + str2nat ( str 2 ) hash ( str ) = str2nat ( str ) mod 15485857 hide str2nat THEN StringKey ñ ò StringKey nil ñ ò StringKey a z ñ ò StringKeyCode ñ ñ ñ . . . and the “code” in StringKeyCode defines a program/model for StringKey Andrzej Tarlecki: Semantics & Verification - 275 -
Another example spec Stack of String = String then sort Stack opns empty : Stack ; push : String × Stack → Stack ; top : Stack → String ; pop : Stack → Stack axioms top ( push ( str , S )) = str pop ( push ( str , S )) = S Andrzej Tarlecki: Semantics & Verification - 276 -
spec Array of String = String and Nat then sort Array opns newarr : Array ; put : Array × Nat × String → Array ; get : Array × Nat → String axioms get ( newarr , i ) = nil get ( put ( a, i, str ) , i ) = str i � = j = ⇒ get ( put ( a, j, str ) , i ) = get ( a, i ) Andrzej Tarlecki: Semantics & Verification - 277 -
spec Stack from Array = { Array of String then sort Stack = Array × Nat opns empty : Stack ; push : String × Stack → Stack ; top : Stack → String ; pop : Stack → Stack ; axioms empty = ( newarr , 0) push ( str , ( a, i )) = ( put ( a, str , i + 1) , i + 1) i > 0 = ⇒ top (( a, i )) = get ( a, i ) top (( a, 0)) = nil i > 0 = ⇒ pop (( a, i )) = ( put ( a, i, nil ) , i − 1) pop (( a, 0)) = ( a, 0) ) - : } reveal String , Stack , empty , push , top , pop e u r t y THEN l t n e i c Stack of String ñ ò Stack from Array ffi ñ u s Andrzej Tarlecki: Semantics & Verification - 278 -
Extra twist In practice, some parts will get fixed on the way: ✬ ✩ ✬ ✩ ✗ ✔ ✖ ✕ SP ′ SP ′ SP ′ ò · · · ñ · · · κ n • ñ ñ ò ñ ñ ò ñ ñ ñ ò ✫ ✪ 0 1 2 ✫ ✪ κ 2 κ 2 κ 1 κ 1 κ 1 Keep them apart from whatever is really left for implementation: ✬ ✩ ✬ ✩ ✗ ✔ ✖ ✕ SP ′ SP ′ SP ′ ò . . . • SP ′ n = EMPTY ñ ñ ñ ò ñ ñ ñ ò ñ ñ ñ ñ ñ ñ ò κ 1 ✫ ✪ κ 2 κ 3 κ n 0 1 2 ✫ ✪ Andrzej Tarlecki: Semantics & Verification - 279 -
Constructor implementations linked with such implementations Proof obligation ò SP ′ SP ñ ñ κ Means: κ ( Mod [ SP ′ ]) ⊆ Mod [ SP ] where κ : Alg ( Sig [ SP ′ ]) → Alg ( Sig [ SP ]) is a constructor : Intuitively: parameterised program ( generic module , SML functor ) Semantically: function between model classes putting aside: partiality , persistency . . . Andrzej Tarlecki: Semantics & Verification - 280 -
For instance constructor K ( A : Sig [ Array of String ]): Sig [ Stack of String ] open A type Stack = Array × Nat val empty = ( newarr , 0) fun push ( str , ( a, i )) = ( put ( a, str , i + 1) , i + 1) fun top (( a, i )) = if i > 0 then get ( a, i ) else nil fun pop (( a, i )) = if i > 0 then ( put ( a, i, nil ) , i − 1) else ( a, i ) end sufficiently true :-) THEN Stack of String ò Array of String ñ ñ ñ K Andrzej Tarlecki: Semantics & Verification - 281 -
Composability revisited ò SP ′ SP ′ ò SP ′′ SP ñ ñ ñ ñ ñ κ κ ′ ò SP ′′ SP ñ ñ ñ ñ ñ κ ′ ; κ Easy consequence: SP 0 ò SP 1 ò · · · ò SP n = EMPTY ñ ñ ñ ñ ñ ñ ñ ñ ñ κ 1 κ 2 κ n κ 1 ( κ 2 ( . . . κ n ( empty ) . . . )) ∈ Mod [ SP 0 ] Methodological issues: • top-down vs. bottom-up vs. middle-out development? • modular decomposition (designing modular structure) Andrzej Tarlecki: Semantics & Verification - 282 -
WARNING Specification structure may change during the development process! Separate means are necessary to design the final modular structure of the program under development Andrzej Tarlecki: Semantics & Verification - 283 -
Branching implementation steps SP 1 . . SP ñ κ . ñ ò SP n This involves a “ linking procedure ” ( n -argument constructor, parameterised program) κ : Alg ( Sig [ SP 1 ]) × · · · × Alg ( Sig [ SP n ]) → Alg ( Sig [ SP ]) We require: M 1 ∈ Mod [ SP 1 ] · · · M n ∈ Mod [ SP n ] κ ( M 1 , . . . , M n ) ∈ Mod [ SP ] Proof obligation linked with such design steps Andrzej Tarlecki: Semantics & Verification - 284 -
Recommend
More recommend
