Copyright 1999 G.v. Bochmann ELG 7186B ch.2 1 Specifications with assumptions and guarantees (in general) extracts from course notes for ELG7186B in 1999 A system component functions within an environment of other components; the component specification must take this environment into account Normally, the properties specified for a component should (only) be satisfied when certain other properties are satisfied by the components in the environment. Examples: –operating temperature should be within a given (for a computer, or a component thereof) »electrical power supply must be given (idem) »disk must be formatted the right way (for a disk unit) »line length within some bound (test processor)

Copyright 1999 G.v. Bochmann ELG 7186B ch.2 2 Components, interfaces, architectures Example: Electricity counter –I1: electricity input (assumption: less than 100 Amps, less than 300 Volts) –I2: electricity output (guarantee: same current and voltage as at I1) –I3: read-out interface (guarantee: the value provided is equal to the energy (i.e. product of current*voltage*time) that passed through the interface I2) specified component component of environment interface E1 E2C I1 I3 I2 component of environment

Copyright 1999 G.v. Bochmann ELG 7186B ch.2 3 Specification formalism A/G Form of a specification of a component C: If the environment satisfies the assumption A C then the component C will guarantee the property G C Note: For the case that the assumption is not satisfied, the specification does not say anything about the desired behavior In first-order logic: the specification of C has the form “A C implies G C “ (or “A C => G C “ ) Assuming that the components in the environment have specifications of the same form, the properties of the example system above are those that can be derived from the specifications of all the components, that is P = (A C => G C ) and (A E1 => G E1 ) and (A E2 => G E2 ) Note: Let us hope that the assumptions made by E1 and E2 are small enough to be able to obtain interesting system properties.

Copyright 1999 G.v. Bochmann ELG 7186B ch.2 4 Conforming specializations Definition: Given two specifications S C and S C’ of two components C and C’, respectively, we say that S C’ conforms to S C if S C’ implies S C (which means that all properties specified for S C are implied by the properties specified for S C’ ). We also say in this case that S C’ is specialization of S C. Note: S C’ => S C is equivalent to (A C’ => G C’ ) => (A C => G C ) and this is equivalent to [ ( G C’ => G C ) and (A C => A C’ ) ] If X => Y we also say that X is stronger than Y or that Y is weaker than X. Therfore “S C’ conforms to S C “ is equivalent to saying that the guarantees of S C’ are stronger than those of S C and that the assumptions of S C’ are weaker than those of S C, which means [ ( G C’ => G C ) and (A C => A C’ ) ]

Copyright 1999 G.v. Bochmann ELG 7186B ch.2 5 Conforming implementations, possibilities of replacement and reuse We say that an implementation conforms to a given specification S C if the properties of the implementation imply the specified properties. Assuming that the properties of the implementation can be characterized in the same form, namely by (A I => G I ), then a conforming implementation must satisfy (A I => G I ) => (A C => G C ). –Note: this is the same form of comparison as between specifications Important fact: If S C’ conforms to S C then an implementation conforming to S C’ could be used at any place in a system where a component satisfying the specification S C is foreseen by the system specification. –Therefore the conforming specialization defined above should be used as the relation which determines, within object-oriented systems, whether a given type (or class) of object is a “specialization” (or is a “subtype” of, or “inherits” from) another type of object.

Copyright 1999 G.v. Bochmann ELG 7186B ch.2 6 Different kinds of refinement What is a “refinement”? –The system development process usually leads from an abstract specification of the requirements to detailed design specifications and finally to an implementation. Each step within this process starts with a given specification S i and leads to a “refinement” S i+1 of this specification. – Since we want that the implementation conforms to the original requirement specification, one usually asks that S i+1 should conform to S i. Therefore one needs a conforming refinement. Special classes of refinements: Reductions: S i+1 conforms to S i and G i+1 is stronger than (not equal to) G i this is usually a reduction of nondeterminism, e.g. reduction of possible outputs (or possible next states in state-nondeterministic systems); in the extreme, this may lead to blocking (no output is possible, or no transition possible) Extensions: S i+1 conforms to S i and A i+1 is weaker than (not equal to) A i S i+1 is defined for situations where S i was not defined, e.g. new allowed input and corresponding output, function defined for input values for which S i is undefined, etc. Structural refinements: see next slide

Copyright 1999 G.v. Bochmann ELG 7186B ch.2 7 Composition: Structural refinement (an example) C1 I1 I2 I3 I4 C3 C2 specified component composition : this module C consists of three components, two external interfaces and two internal interfaces C specified component specified component

Copyright 1999 G.v. Bochmann ELG 7186B ch.2 8 Composition: structural refinement (the formalism) (Abstract) specification of component C: (A C => G C ) The refinement of the component in terms of three sub- components C1, C2 and C3 is given by the specifications (A Ci => G Ci ), i = 1, 2, 3, respectively. The properties of this structural refinement are given by (A C1 => G C1 ) and (A C2 => G C2 ) and (A C3 => G C3 ) If one wants that this refinement conforms to the original specification (A C => G C ) of the component C, one has to verify that [ (A C1 => G C1 ) and (A C2 => G C2 ) and (A C3 => G C3 ) ] => (A C => G C )