Specifications and formal program development in-the-large What are - - PowerPoint PPT Presentation

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. more about this elsewhere:

Institutions!

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 SP ❀ P is a given by the semantics (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: SP1 ≡ SP2 means Sig[SP1] = Sig[SP2] and Mod[SP1] = Mod[SP2] 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:

SP0 ñ ñ òSP1 ñ ñ ò· · · ñ ñ òSPn ensuring: SP0 ñ ñ òSP1 ñ ñ ò· · · ñ ñ òSPn SPn ❀ M SP0 ❀ M

Andrzej Tarlecki: Semantics & Verification

• 271 -

Simple implementations

SP ñ ñ òSP′ 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)

Proof obligation linked with such implementations

Andrzej Tarlecki: Semantics & Verification

• 272 -

Composability

SP ñ ñ òSP′ SP′ ñ ñ òSP′′ SP ñ ñ òSP′′ Easy consequence: SP0 ñ ñ òSP1 ñ ñ ò· · · ñ ñ òSPn M ∈ Mod[SPn] M ∈ Mod[SP0]

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

• pns 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

• pns 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

• pns 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 THEN s u ffi c i e n t l y t r u e :

• )

Stack of String ñ ñ òStack from Array

Andrzej Tarlecki: Semantics & Verification

• 278 -

Extra twist

In practice, some parts will get fixed on the way: ✬ ✫ ✩ ✪ SP′ ñ ñ ò κ1 ✬ ✫ ✩ ✪ SP′

1

ñ ñ ò κ1 κ2 ✗ ✖ ✔ ✕ SP′

2

ñ ñ ò· · · ñ ñ ò κ1 κ2 · · · κn

• Keep them apart from whatever is really left for implementation:

✬ ✫ ✩ ✪ SP′

κ1

ñ ñ ñ ò ✬ ✫ ✩ ✪ SP′

1 κ2

ñ ñ ñ ò ✗ ✖ ✔ ✕ SP′

2 κ3

ñ ñ ñ ò. . .

κn

ñ ñ ñ ò

• SP′

n = EMPTY

Andrzej Tarlecki: Semantics & Verification

• 279 -

Constructor implementations

SP

κ

ñ ñ òSP′ Means: κ(Mod[SP′]) ⊆ Mod[SP] where κ: Alg(Sig[SP′]) → Alg(Sig[SP]) is a constructor: Proof obligation linked with such implementations 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]

• pen 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 THEN sufficiently true :-) Stack of String

K

ñ ñ ñ òArray of String

Andrzej Tarlecki: Semantics & Verification

• 281 -

Composability revisited

SP

κ

ñ ñ òSP′ SP′

κ′

ñ ñ ñ òSP′′ SP

κ′;κ

ñ ñ ñ ñ ñ òSP′′ Easy consequence: SP0

κ1

ñ ñ ñ òSP1

κ2

ñ ñ ñ ò· · ·

κn

ñ ñ ñ òSPn = EMPTY κ1(κ2(. . . κn(empty) . . .)) ∈ Mod[SP0] 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

• f the program under development

Andrzej Tarlecki: Semantics & Verification

• 283 -

Branching implementation steps

SP ñ ñ ò κ          SP1 . . . SPn This involves a “linking procedure” (n-argument constructor, parameterised program) κ: Alg(Sig[SP1]) × · · · × Alg(Sig[SPn]) → Alg(Sig[SP]) We require: M1 ∈ Mod[SP1] · · · Mn ∈ Mod[SPn] κ(M1, . . . , Mn) ∈ Mod[SP] Proof obligation linked with such design steps

Andrzej Tarlecki: Semantics & Verification

• 284 -

Casl architectural specifications

Casl provides an explicit way to write down the design specification branching amounts to: arch spec ASP = units U1 : SP1 . . . Un : SPn result κ(U1, . . . , Un) Moreover:

• units my be generic (parameterised programs, SML functors), but always are

declared with their specifications

• Casl provides a rich collection of combinators to define κ and various additional

ways to define units

Andrzej Tarlecki: Semantics & Verification

• 285 -

Instead of conclusions

• Quite a lot of good theory around this;
• Even more bad practise . . .

Ever evading overall goal

Practical methods for software specification and development with solid foundations

Andrzej Tarlecki: Semantics & Verification

• 286 -