High Quality Software

1. High Quality Software For the purpose of this lecture we define high quality software as that software that ranks very highly on measures of software product quality. Some of these we remember were: Functionality Reliability Usability, and Maintainability

2. It was also demonstrated in the previous lectures that the ability to rank high on these quality attributes was related to the defect content of the product; albeit the relationship was complex and ill-defined. We also stated that there were two approaches to management of defect in a product, defect prevention, and defect identification and removal. In this lecture we mainly deal with the former of the two, techniques that are used to prevent introduction of defects. In doing so we concentrate on techniques inspired by the exactness of a mathematical syntax. We will also look at development processes that are aimed at the production of high quality (low defect) software.

3. Formal Methods: As stated before we can use the language of mathematics to specify our requirements (this is called Formal Specification). Specifying a set of requirements formally has the potential to increase precision and consistency and to reduce introduction of defects We can then use this formal specification (which is assumed correct) as the basis for formal or informal design work. One type of formal design work is to use mathematical transformations to transform the formal specification into an equivalent form written in an executable language. This is called formal derivation. Additionally, once we have both the specification and the formal

4. derivation, we can use principles of mathematics to show that the two artifacts are equivalent. Usually by showing that every step of the derivation is mathematically robust and provably allowed. This is called formal proof construction. Program derivation and proof construction are complex activities and are well beyond the scope of this course. Therefore we shall concentrate mainly on the activity of formal specification which in itself is a useful activity, even though followed by a non-formal design stage. We shall use the formal language Object-Z (object zed) for our purpose.

5. Syntax of Object-Z: Sets and Types [X] Type X data type ::=m1|m2|…..|mn X = = Y Y stands for X Z Set of Integers N Set of natural numbers (0) N1 Set of positive integers (1) t S t is an element of set S t S t is not an element of set S S T S is contained in T

6. ST S is strictly contained in T (ST) S T S is not contained in T S T Set of intersection of S and T S T Set of the union of S and T S Powerset of S: the set of all subsets of S FS Finite powerset of S: the set of all finite subsets of S SS The distributed intersection of all sets in SS SS The distributed union of all sets in SS  Or { } The null or empty set

7. S\T Difference:elements that are in S but not in T #S Size or cardinality: number of elements in S {D|p.t} Set of t’s such that given declaration D, P holds disjoint Sq the sets in the sequence sq are disjoint sq partition S the sets in sq partition the set S Logic true, false logical constants P not P

8. PQ conjunction: “P and Q” • PQ disjunction: “P or Q” • PQ implication: “If P then Q” • PQ equivalence: : “If P then Q and if Q then P” • t=r term t is equal to term r • tr term t is not equal to term r, that is: (t=r) • Predicates: • x:T.P for all x of type T, P holds x: T.P there exists an x of type T, for which P holds

9. Relations: XY the set of ordered pairs of X’s and Y’s XY the set of relations from X to Y; = =P(XY) x R y x is related to y by R; (x,y) R dom R the domain of relation R; = ={x:X | (x:X . x R y) . x} ran R the range of a relation R; = ={y:Y | (x:X . x R y) . y} SR the relation R is domain restricted to S RS the relation R is range restricted to S R~ the inverse of R

10. Functions: X  Y the set of partial functions from X to Y = ={f:XY | (x:X | x dom f. (1y:Y.x f y))} X Y the set of total functions from X to Y = ={f: X  Y| dom f = X.f} fx or f(x) function f is applied to x

11. Sequences seq X the set of sequences with elements drawn from X = ={S:N X | dom S= 1…#S} seq1 X set of non-empty sequences of X iseq X set of non-duplicate sequences of X #S the length of sequence X < > the empty sequence <x1,…xn> the sequence of x1 through to xn

12. <x1,…xn>^<y1,…yn> concatenation = = <x1,…xn,y1,…yn> head S = = S 1 last S = = S #S tail S^S1 = = S frontS^<x> = = S where <x>= =last S rev S the sequence S in reverse order

13. Schemas: Class Schema Class Name[generic parameter] inherited classes type definitions constant definitions state schema initial state schema operation schemas history invariant

14. State Schema items: seq T #items max predicate declaration

15. Initial State Schema INIT items = = < > Operational schemas Operation name declarations predicates

16. Schema decorations: | name: T name is a constant of type T item ?: T item is an input or accepts input item !: T item is an output or holds an output item’ new state of item after change (item) the schema effects change on item

21. Cleanroom: a practical approach to high quality software Cleanroom is based on two fundamental principles: Use of formal approaches to design correct modules Use of statistical testing techniques to certify the software product The basis is that each transformation in a computer program can be thought of as a mapping from a domain set to a range set. All deterministic programs therefore may be specified through the definition of these mappings.

22. A well defined transformation must therefore: Link a set of input histories to an output. A fact that can be checked. This assists with accuracy (see lecture 7) and ensures reliability. Require that each domain element be mapped to at most one range element. This assists with consistency (see lecture 7) and ensures reliability. Be demonstrably traceable to an equivalent requirements specification statement. This assists with traceability and ensures functionality.

23. Of course a stepwise approach is required. The approach taken in Cleanroom is called the box structure method. There are three forms defined for each schema: The black box The state box, and The clear box

24. The primary process categories of Cleanroom are the: • Specification processes • Development (design and implementation) processes • Certification processes • Management processes • We shall cover each briefly.

25. The specification processes category: • This includes the processes of: • Requirements capture, • Requirements analysis, • Function specification • Usage specification • Architecture specification, and • Increment planning

26. During Requirements Capture and Requirements Analysis a users requirements definition is obtained through conventional means (e.g. interviews and construction of usecases). During the Functional Specification phase, this definition is then precisely captured in a formal language. Various services are then allocated to different increments (through the process of Increment Planning) and are scheduled for development and certification.

27. The development processes category: • This includes the processes of: • Software re-engineering • Increment design, and • Correctness verification.

28. Increment design takes an allocated increment and uses the stepwise approach of box structures to refine each increment – in progressive levels of granularity - until verifiably correct code for each lowest level is obtained. Software re-engineering is the activity of coordinating the use of existing software with the current increment. This can be in the form of reuse or integration. Correctness verification is done formally through correctness proving.

29. The Certification processes category entails: • Usage Modeling • Test Planning • Statistical Testing, and • Certification

30. Usage modeling is performed parallel to the development set of processes and aims to identify and model interactions possible with the system or a sub-system. This model then assist with the design of effective statistical test suites that test not the individual function but a sub-system or system increment. At the conclusion of testing the customer shall accept the system or provide feedback for requirements validation. Once the increment is deemed to meet all requirements it will be certified.

31. The management category of processes: • This category includes: • Project planning • Project management • Performance improvement and • Engineering change These sets of activities span the entire lifecycle.

32. Further Reading Duke, et al.; “The Object Z Specification Language”; Technical Report 91-1; May 1991; SVRC; University of Queensland; Australia; www.it.uq.edu.au Lightfoot, D.; “Formal Specification using Z”; McMillan; 1991 Prowell, S.; et al.; “Cleanroom Software Engineering: Technology and Process”; Addison-Wesley; 1998.