ecse 6770- software engineering 1 - 1 - ho 13 © hy 2010 lecture 13 high quality software for the...
TRANSCRIPT
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
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.
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
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.
ECSE 6770- Software Engineering 1
- 5 -HO 13
© HY 2010
Lecture 13
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
ECSE 6770- Software Engineering 1
- 6 -HO 13
© HY 2010
Lecture 13
ST S is strictly contained in T (ST)
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
ECSE 6770- Software Engineering 1
- 7 -HO 13
© HY 2010
Lecture 13
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
ECSE 6770- Software Engineering 1
- 8 -HO 13
© HY 2010
Lecture 13
PQ conjunction: “P and Q”
PQ disjunction: “P or Q”
PQ implication: “If P then Q”
PQ equivalence: : “If P then Q and if Q then P”
t=r term t is equal to term r
tr 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
ECSE 6770- Software Engineering 1
- 9 -HO 13
© HY 2010
Lecture 13
Relations:
XY the set of ordered pairs of X’s and Y’s
XY the set of relations from X to Y; = =P(XY)
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}
SR the relation R is domain restricted to S
RS the relation R is range restricted to S
R~ the inverse of R
ECSE 6770- Software Engineering 1
- 10 -HO 13
© HY 2010
Lecture 13
Functions:
X Y the set of partial functions from X to Y
= ={f:XY | (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
ECSE 6770- Software Engineering 1
- 11 -HO 13
© HY 2010
Lecture 13
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
ECSE 6770- Software Engineering 1
- 12 -HO 13
© HY 2010
Lecture 13
<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
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
ECSE 6770- Software Engineering 1
- 14 -HO 13
© HY 2010
Lecture 13
State Schema
items: seq T
#items max
declaration predicate
ECSE 6770- Software Engineering 1
- 15 -HO 13
© HY 2010
Lecture 13
items = = < >
Initial State Schema
INIT
Operational schemas
declarations
predicates
Operation name
ECSE 6770- Software Engineering 1
- 16 -HO 13
© HY 2010
Lecture 13
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
ECSE 6770- Software Engineering 1
- 17 -HO 13
© HY 2010
Lecture 13
ECSE 6770- Software Engineering 1
- 18 -HO 13
© HY 2010
Lecture 13
ECSE 6770- Software Engineering 1
- 19 -HO 13
© HY 2010
Lecture 13
ECSE 6770- Software Engineering 1
- 20 -HO 13
© HY 2010
Lecture 13
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
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.
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
ECSE 6770- Software Engineering 1
- 24 -HO 13
© HY 2010
Lecture 13
The primary process categories of Cleanroom are the:
Specification processesDevelopment (design and implementation) processesCertification processesManagement processes
We shall cover each briefly.
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
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.
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.
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.
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
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.
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.
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.