Gaudi software process

Ralph BackCREST

CR

ES

T:

Cen

ter fo

r Relia

ble

Softw

are

Tech

nolo

gy

Åb

o A

kad

em

i

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

Ladder0 Ladder1 Ladder2 Ladder3 Ladder4

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

Ladder0 Ladder10 Ladder2 Ladder3 Ladder4 Ladder5

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 application 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

Construct Relation

relation, predicate, function, truth value

inclusion, equality, implication

statement refinement

procedure refinement

class refinement

system (collection of classes)

refinement

stack (of systems) refinement

ladder consistency 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