1. ECSE 6770- Software Engineering 1 - 1 - HO 13 © HY 2010 Lecture 13 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. ECSE 6770- Software Engineering 1 - 2 - HO 13 © HY 2010 Lecture 13 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. ECSE 6770- Software Engineering 1 - 3 - HO 13 © HY 2010 Lecture 13 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. ECSE 6770- Software Engineering 1 - 4 - HO 13 © HY 2010 Lecture 13 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. ECSE 6770- Software Engineering 1 - 5 - HO 13 © HY 2010 Lecture 13 Syntax of Object-Z: Sets and Types [X]Type Xdata type ::=m 1 |m 2 |…..|m n X = = Y Y stands for XZSet of Integers NSet of natural numbers (  0) N1Set of positive integers (  1) t  St is an element of set S t  St is not an element of set S S  TS is contained in T

6. ECSE 6770- Software Engineering 1 - 6 - HO 13 © HY 2010 Lecture 13 S  TS is strictly contained in T (S  T) S  TS is not contained in T S  TSet of intersection of S and T S  TSet of the union of S and T  SPowerset of S: the set of all subsets of S FSFinite powerset of S: the set of all finite subsets of S  SSThe distributed intersection of all sets in SS  SSThe distributed union of all sets in SS  Or { }The null or empty set

7. ECSE 6770- Software Engineering 1 - 7 - HO 13 © HY 2010 Lecture 13 S\TDifference:elements that are in S but not in T #SSize or cardinality: number of elements in S {D|p.t}Set of t’s such that given declaration D, P holds disjoint Sqthe sets in the sequence sq are disjoint sq partition S the sets in sq partition the set S Logic true, falselogical constants  Pnot P

8. ECSE 6770- Software Engineering 1 - 8 - HO 13 © HY 2010 Lecture 13 P  Qconjunction: “P and Q” P  Qdisjunction: “P or Q” P  Qimplication: “If P then Q” P  Qequivalence: : “If P then Q and if Q then P” t=rterm t is equal to term r t  rterm t is not equal to term r, that is:  (t=r) Predicates:  x:T.Pfor all x of type T, P holds  x: T.Pthere exists an x of type T, for which P holds

9. ECSE 6770- Software Engineering 1 - 9 - HO 13 © HY 2010 Lecture 13 Relations: X  Ythe set of ordered pairs of X’s and Y’s X  Ythe set of relations from X to Y; = =P(X  Y) x R yx is related to y by R; (x,y)  R dom Rthe domain of relation R; = ={x:X | (  x:X. x R y). x} ran Rthe range of a relation R; = ={y:Y | (  x:X. x R y). y} S  Rthe relation R is domain restricted to S R  Sthe relation R is range restricted to S R ~ the inverse of R

10. ECSE 6770- Software Engineering 1 - 10 - HO 13 © HY 2010 Lecture 13 Functions: X  Ythe set of partial functions from X to Y = ={f:X  Y | (  x:X | x  dom f. (  1 y:Y.x f y))} X  Ythe 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. ECSE 6770- Software Engineering 1 - 11 - HO 13 © HY 2010 Lecture 13 Sequences seq Xthe set of sequences with elements drawn from X = ={S:N  X | dom S= 1…#S} seq 1 Xset of non-empty sequences of X iseq Xset of non-duplicate sequences of X #Sthe length of sequence X the empty sequence the sequence of x 1 through to x n

12. ECSE 6770- Software Engineering 1 - 12 - HO 13 © HY 2010 Lecture 13 ^ concatenation = = head S= = S 1 last S= = S #S tail S^S1= = S frontS^ = = S where = =last S rev Sthe sequence S in reverse order

13. ECSE 6770- Software Engineering 1 - 13 - HO 13 © HY 2010 Lecture 13 Schemas: Class Schema Class Name[generic parameter] inherited classes type definitions constant definitions state schema initial state schema operation schemas history invariant

14. ECSE 6770- Software Engineering 1 - 14 - HO 13 © HY 2010 Lecture 13 State Schema items: seq T #items  max declaration predicate

15. ECSE 6770- Software Engineering 1 - 15 - HO 13 © HY 2010 Lecture 13 items = = Initial State Schema INIT Operational schemas declarations predicates Operation name

16. ECSE 6770- Software Engineering 1 - 16 - HO 13 © HY 2010 Lecture 13 Schema decorations: | name: Tname is a constant of type T item ?: Titem is an input or accepts input item !: Titem is an output or holds an output item’new state of item after change  (item)the schema effects change on item

17. ECSE 6770- Software Engineering 1 - 17 - HO 13 © HY 2010 Lecture 13

18. ECSE 6770- Software Engineering 1 - 18 - HO 13 © HY 2010 Lecture 13

19. ECSE 6770- Software Engineering 1 - 19 - HO 13 © HY 2010 Lecture 13

20. ECSE 6770- Software Engineering 1 - 20 - HO 13 © HY 2010 Lecture 13

21. ECSE 6770- Software Engineering 1 - 21 - HO 13 © HY 2010 Lecture 13 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. Cleanroom: a practical approach to high quality software

22. ECSE 6770- Software Engineering 1 - 22 - HO 13 © HY 2010 Lecture 13 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. ECSE 6770- Software Engineering 1 - 23 - HO 13 © HY 2010 Lecture 13 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. ECSE 6770- Software Engineering 1 - 24 - HO 13 © HY 2010 Lecture 13 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. ECSE 6770- Software Engineering 1 - 25 - HO 13 © HY 2010 Lecture 13 The specification processes category: This includes the processes of: Requirements capture, Requirements analysis, Function specification Usage specification Architecture specification, and Increment planning

26. ECSE 6770- Software Engineering 1 - 26 - HO 13 © HY 2010 Lecture 13 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. ECSE 6770- Software Engineering 1 - 27 - HO 13 © HY 2010 Lecture 13 The development processes category: This includes the processes of: Software re-engineering Increment design, and Correctness verification.

28. ECSE 6770- Software Engineering 1 - 28 - HO 13 © HY 2010 Lecture 13 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. ECSE 6770- Software Engineering 1 - 29 - HO 13 © HY 2010 Lecture 13 The Certification processes category entails: Usage Modeling Test Planning Statistical Testing, and Certification

30. ECSE 6770- Software Engineering 1 - 30 - HO 13 © HY 2010 Lecture 13 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. ECSE 6770- Software Engineering 1 - 31 - HO 13 © HY 2010 Lecture 13 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. ECSE 6770- Software Engineering 1 - 32 - HO 13 © HY 2010 Lecture 13 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.