Gaudi software process Ralph Back CREST CREST: Center for Reliable Software Technology Åbo Akademi

The Ladder:Specification and implementation Specification – customer Implementation – programmer Ladder model – cooperation between customer/specifier and implementer/programmer Implementation is done using extreme programming  with short iteration cycles  using design by contract (for internal consistency)  and extensive unit testing (checking internal consistency) Specification is done in layers  defining each layer with a new feature  deciding on the order in which the layers are introduced  checking the correctness of the implementation of each level (by functional testing)

Formalization Relationsship specification- implementation need not be one-to- one, but expressed so here for simplicity Comparing level stacks with each other, not individual levels  Spec0 ref Impl0  Spec0+Spec1 ref Impl0+Impl1  etc. In the end, by induction, we prove that Spec0+...+Spec3 ref Impl0+...+Impl3  In general, implementation and specification hierarchies do not need to be the same, it is sufficient that there is a correspondence between these two. Spec0 Spec1 Spec2 Spec3 Impl0 Impl1 Impl2 Impl3

Software evolution We construct the software by building the ladder higher and higher  Each ladder provides one release of the software system Each ladder consists of the specification and implementation stacks, together with verification that these two are related by refinement Successive ladders do not need to be related to each other in any way  May completely change the structure of the software from one ladder (release) to the next one  However, the next release has to be structured as a ladder  This means that there are identified levels in the specification and the implementation, that the consistency of each level has been checked, and that the refinement of the specification by the implementation has also been checked. This means that the specifications can change between releases, to match changing goals for the software Ladder0Ladder1Ladder2Ladder3Ladder4

Software evolution 2 Subsequent ladders can have different structures and goals Reuse part of the ladder (specification or implementation) No need to fix the overall purpose of the software in advance  Software is allowed to evolve freely  The work that has gone into building layers, establishing internal consistency and functional correctness is preserved when possible Software evolution process can be forking into independent developments with different targets.  The ladder can also fork into independent extensions Ladder0Ladder10Ladder2Ladder3Ladder4Ladder5

Ladder structure Can have independent extensions of a layer Can have joint extension of two or more layers (multiple inheritance) This allows parallel construction of independent layers It also allows different extensions to the same basic platform application 1 application 2 application 3 a pplication 4 common platform parallel extensions

Specifications and implementations Specifications and implementations are in principle expressed in the same language (unified framework) In both cases, we have UML class diagrams + behavioral specification Can use more abstract constructs in modelling (specification) and more concrete in programs (implementation) For both specifications and implementations:  we need to check for internal consistency  having an executable description is good (can simulate/test)  having an exact description is very important (cannot check anything else)  we need tools for simulation-testing-verification Also, need tools to check that implementation is correct with respect to specification  this means that the ladder is internally consistent Note that internal consistency of the ladder is what is preserved from one release to the next.

Software hierarchy ConstructRelation relation, predicate, function, truth value inclusion, equality, implication statementrefinement procedurerefinement classrefinement system (collection of classes) refinement stack (of systems)refinement ladderconsistency preserving

Ladders A ladder may be followed by another ladder that has the same functionality, but where the structure has been refactored.  There may be fewer or more layers  The functionality in the different layers may be different Terminology:  layer refer to the modules at a certain height in the hierarchy  level refers to the modules at or below a certain height in the hierarchy

The ladder may be extended sideways by more efficient implementations Spec0 Spec1 Spec2 Spec3 Impl0 Impl1 Impl2 Impl3 Optm0 Optm1 Optm2 Optm3