Chapter 21

 Formal Modeling and Verification

Slide Set to accompany
Software Engineering: A Practitioner’s
Approach, 7/e
by Roger S. Pressman

Slides copyright © 1996, 2001, 2005, 2009 by Roger S. Pressman

For non-profit educational use only

May be reproduced ONLY for student use at the university level when used in conjunction
with Software Engineering: A Practitioner's Approach, 7/e. Any other reproduction or use is
prohibited without the express written permission of the author.

All copyright information MUST appear if these slides are posted on a website for student
use.

These slides are designed to accompany Software Engineering: A

Practitioner’s Approach, 7/e (McGraw-Hill 2009). Slides copyright 2009 by
Roger Pressman. 1
 Formal Modeling and
Verification
 Cleanroom software engineering and formal
methods
 Both demand a specialized specification approach and
each applies a unique verification method.
 Both are quite rigorous and neither is used widely by the
software engineering community.
 If you must build “bullet-proof” software, these
methods can help immeasurably.

These slides are designed to accompany Software Engineering: A

Practitioner’s Approach, 7/e (McGraw-Hill 2009). Slides copyright 2009 by
Roger Pressman. 2
The Cleanroom Process
Model increment#1
BoxStructure
Specification
Formal
Design
Correctness
Verification
Code
Inspection Statistical Cerfification
Requirements Use
Gathering Testing
TestPlanning

System
Engineering increment#2
BoxStructure Formal Correctness Code
Specification Design Verification Inspection Statistical Cerfification
Requirements Use
Gathering Testing
TestPlanning

increment#n
BoxStructure Formal Correctness Code
Specification Design Verification Inspection Statistical Cerfification
Requirements Use
Gathering Testing
TestPlanning

These slides are designed to accompany Software Engineering: A

Practitioner’s Approach, 7/e (McGraw-Hill 2009). Slides copyright 2009 by
Roger Pressman. 3
The Cleanroom
Strategy-IIncrement Planning—adopts the incremental strategy
Requirements Gathering—defines a description of customer level
requirements (for each increment)
Box Structure Specification—describes the functional specification
Formal Design—specifications (called “black boxes”) are iteratively
refined (with an increment) to become analogous to architectural and
procedural designs (called “state boxes” and “clear boxes,”
respectively).
Correctness Verification—verification begins with the highest level box
structure (specification) and moves toward design detail and code
using a set of “correctness questions.” If these do not demonstrate that
the specification is correct, more formal (mathematical) methods for
verification are used.
Code Generation, Inspection and Verification—the box structure
specifications, represented in a specialized language, are transmitted
into the appropriate programming language.
These slides are designed to accompany Software Engineering: A
Practitioner’s Approach, 7/e (McGraw-Hill 2009). Slides copyright 2009 by
Roger Pressman. 4
The Cleanroom
Strategy-II
Statistical Test Planning—a suite of test cases that exercise of
“probability distribution” of usage are planned and designed
Statistical Usage Testing—execute a series of tests derived from
a statistical sample (the probability distribution noted above) of
all possible program executions by all users from a targeted
population
Certification—once verification, inspection and usage testing
have been completed (and all errors are corrected) the
increment is certified as ready for integration.

These slides are designed to accompany Software Engineering: A

Practitioner’s Approach, 7/e (McGraw-Hill 2009). Slides copyright 2009 by
Roger Pressman. 5
Box Structure
Specification CB1.1.1.1

black box
clear box
BB1.1.1 SB1.1.1 CB1.1.1.2

BB1.1 BB1.1.2
CB1.1.1.3

BB1 BB1.1.3
BB1.2

state box

BB1.n

These slides are designed to accompany Software Engineering: A

Practitioner’s Approach, 7/e (McGraw-Hill 2009). Slides copyright 2009 by
Roger Pressman. 6
 Box
Structures State
T

S f:S* R R
S black box,g R

black box
state box

State
T

g12

S g11 cg1 R
g13

clear box
These slides are designed to accompany Software Engineering: A
Practitioner’s Approach, 7/e (McGraw-Hill 2009). Slides copyright 2009 by
Roger Pressman. 7
Design Refinement &
Verification
If a function f is expanded into a sequence g and h, the
correctness condition for all input to f is:
• Does g followed by h do f?
When a function f is refined into a conditional (if-then-else),
the correctness condition for all input to f is:
• Whenever condition <c> is true does g do f and
whenever <c> is false, does h do f?
When function f is refined as a loop, the correctness
conditions for all input to f is:
• Is termination guaranteed?
• Whenever <c> is true does g followed by f do f, and
whenever <c> is false, does skipping the loop still do f?

These slides are designed to accompany Software Engineering: A

Practitioner’s Approach, 7/e (McGraw-Hill 2009). Slides copyright 2009 by
Roger Pressman. 8
Advantages of Design
Verification
 It reduces verification to a finite
process.
 It lets cleanroom teams verify every
line of design and code.
 It results in a near zero defect level.
 It scales up.
 It produces better code than unit
testing.

These slides are designed to accompany Software Engineering: A

Practitioner’s Approach, 7/e (McGraw-Hill 2009). Slides copyright 2009 by
Roger Pressman. 9
Cleanroom
Testing
 statistical use testing
 tests the actual usage of the program
 determine a “usage probability
distribution”
 analyze the specification to identify a set of
stimuli
 stimuli cause software to change behavior
 create usage scenarios
 assign probability of use to each stimuli
 test cases are generated for each stimuli
according to the usage probability
distribution
These slides are designed to accompany Software Engineering: A
Practitioner’s Approach, 7/e (McGraw-Hill 2009). Slides copyright 2009 by
Roger Pressman. 10
Certificat
ion1. Usage scenarios must be created.
2. A usage profile is specified.
3. Test cases are generated from the profile.
4. Tests are executed and failure data are
recorded and analyzed.
5. Reliability is computed and certified.

These slides are designed to accompany Software Engineering: A

Practitioner’s Approach, 7/e (McGraw-Hill 2009). Slides copyright 2009 by
Roger Pressman. 11
Certification
Models
Sampling model. Software testing executes m random test
cases and is certified if no failures or a specified numbers of
failures occur. The value of m is derived mathematically to
ensure that required reliability is achieved.
Component model. A system composed of n components is
to be certified. The component model enables the analyst to
determine the probability that component i will fail prior to
completion.
Certification model. The overall reliability of the system is
projected and certified.

These slides are designed to accompany Software Engineering: A

Practitioner’s Approach, 7/e (McGraw-Hill 2009). Slides copyright 2009 by
Roger Pressman. 12
Formal
Methods  “Formal methods used in developing computer systems are mathematically
based techniques for describing system properties. Such formal methods provide
frameworks within which people can specify, develop, and verify systems in a
systematic, rather than ad hoc manner.”
The Encyclopedia of Software Engineering [Mar01]
 The Problem with conventional specs:
 contradictions
 ambiguities
 vagueness
 incompleteness
 mixed levels of abstraction

These slides are designed to accompany Software Engineering: A

Practitioner’s Approach, 7/e (McGraw-Hill 2009). Slides copyright 2009 by
Roger Pressman. 13
 Formal Specification
 Desired properties—consistency, completeness,
and lack of ambiguity—are the objectives of all
specification methods
 The formal syntax of a specification language
enables requirements or design to be interpreted
in only one way, eliminating ambiguity that often
occurs when a natural language (e.g., English) or a
graphical notation must be interpreted
 The descriptive facilities of set theory and logic
notation enable clear statement of facts
(requirements).
 Consistency is ensured by mathematically proving
that initial facts can be formally mapped (using
inference rules) into later statements within the
specification.
These slides are designed to accompany Software Engineering: A
Practitioner’s Approach, 7/e (McGraw-Hill 2009). Slides copyright 2009 by
Roger Pressman. 14
 Formal Methods
Concepts
data invariant—a condition that is true

throughout the execution of the system that
contains a collection of data
 state
 Many formal languages, such as OCL (Section 28.5)
, use the notion of states as they were discussed in
Chapters 7 and 8, that is, a system can be in one of
several states, each representing an externally
observable mode of behavior.
 The Z language (Section 28.6)defines a state as the
stored data which a system accesses and alters
 operation—an action that takes place in a
system and reads or writes data to a state
 precondition defines the circumstances in which a
particular operation is valid
 postcondition defines what happens when an
operation has completed its action

These slides are designed to accompany Software Engineering: A

Practitioner’s Approach, 7/e (McGraw-Hill 2009). Slides copyright 2009 by
Roger Pressman. 15
An Example—Print
Spooler Device queues files awaiting printing

persons
LP1 ftax
LP2 newdata
LAS1
LAS2 exres

Limits Size

LP1 -> 750 newdata -> 450

LP2 -> 500 ftax -> 650
LAS1 -> 300 exres -> 50
LAS2 -> 200 persons -> 700
These slides are designed to accompany Software Engineering: A
Practitioner’s Approach, 7/e (McGraw-Hill 2009). Slides copyright 2009 by
Roger Pressman. 16
States and Data
Invariant
The state of the spooler is represented by the four components
Queues, OutputDevices, Limits, and Sizes.
The data invariant has five components:
• Each output device is associated with an upper limit of
print lines
• Each output device is associated with a possibly
nonempty queue of files awaiting printing
• Each file is associated with a size
• Each queue associated with an output device contains files
that have a size less than the upper limit of the output
device
• There will be no more than MaxDevs output devices
administered by the spooler
These slides are designed to accompany Software Engineering: A
Practitioner’s Approach, 7/e (McGraw-Hill 2009). Slides copyright 2009 by
Roger Pressman. 17
Operatio
ns An operation which adds a new output device

to the spooler together with its associated
print limit
 An operation which removes a file from the
queue associated with a particular output
device
 An operation which adds a file to the queue
associated with a particular output device
 An operation which alters the upper limit of
print lines for a particular output device
 An operation which moves a file from a queue
associated with an output device to another
queue associated with a second output device

These slides are designed to accompany Software Engineering: A

Practitioner’s Approach, 7/e (McGraw-Hill 2009). Slides copyright 2009 by
Roger Pressman. 18
Pre- &
Postconditions
For the first operation (adds a new output device to the
spooler together with its associated print limit):
Precondition: the output device name does not already exist
and that there are currently less than MaxDevs output devices
known to the spooler
Postcondition: the name of the new device is added to the
collection of existing device names, a new entry is formed for
the device with no files being associated with its queue, and
the device is associated with its print limit.

These slides are designed to accompany Software Engineering: A

Practitioner’s Approach, 7/e (McGraw-Hill 2009). Slides copyright 2009 by
Roger Pressman. 19
Mathematical
Concepts*
 sets and constructive set specification
 set operators
 logic operators
 e.g., i, j: • i > j i2 => j2
 which states that, for every pair of values in
the set of natural numbers, if i is greater
than j, then i2 is greater than j2.
 sequences

*A discussion of sets and constructive specification (slides 20 - 24) is no longer included within
SEPA, 7/e, but is included here for those who are unfamiliar with the basic concepts.

These slides are designed to accompany Software Engineering: A

Practitioner’s Approach, 7/e (McGraw-Hill 2009). Slides copyright 2009 by
Roger Pressman. 20
 Sets and Constructive
Specification
 A set is a collection of objects or
elements and is used as a
cornerstone of formal methods.
 Enumeration
• {C++, Pascal, Ada, COBOL, Java}
• #{C++, Pascal, Ada, COBOL, Java} implies
cardinality = 5
 Constructive set specification is
preferable to enumeration because it
enables a succinct definition of large sets.
• {x, y : N | x + y = 10 (x, y2)}

These slides are designed to accompany Software Engineering: A

Practitioner’s Approach, 7/e (McGraw-Hill 2009). Slides copyright 2009 by
Roger Pressman. 21
 Set Operators
 A specialized set of symbology is used to
represent set and logic operations.
 Examples
• The P operator is used to indicate membership of a set.
For example, the expression
• xPX
• The operators , , and # take sets as their operands. The
predicate
• A,B
• has the value true if the members of the set A are
contained in the set B and has the value false otherwise.
 The union operator, <, takes two sets and forms a set
that contains all the elements in the set with
duplicates eliminated.
• {File1, File2, Tax, Compiler} < {NewTax, D2, D3, File2} is
the set
• {Filel, File2, Tax, Compiler, NewTax, D2, D3}

These slides are designed to accompany Software Engineering: A

Practitioner’s Approach, 7/e (McGraw-Hill 2009). Slides copyright 2009 by
Roger Pressman. 22
 Logic Operators
 Another important component of a formal method is
logic: the algebra of true and false expressions.
 Examples:
• V or
• ¬ not
• => implies
 Universal quantification is a way of making a statement
about the elements of a set that is true for every member
of the set. Universal quantification uses the symbol, . An
example of its use is
• i, j : N i > j => i2 > j2
 which states that for every pair of values in the set of
natural numbers, if i is greater than j, then i2 is greater
than j2.

These slides are designed to accompany Software Engineering: A

Practitioner’s Approach, 7/e (McGraw-Hill 2009). Slides copyright 2009 by
Roger Pressman. 23
 Sequences
 Sequences are designated using angle
brackets. For example, the preceding
sequence would normally be written as
 k Jones, Wilson, Shapiro, Estavezl
 Catenation, X, is a binary operator that forms a
sequence constructed by adding its second
operand to the end of its first operand. For
example,
• k 2, 3, 34, 1l X k12, 33, 34, 200 l = k 2, 3, 34, 1, 12, 33, 34,
200 l
 Other operators that can be applied to
sequences are head, tail, front, and last.
• head k 2, 3, 34, 1, 99, 101 l = 2
• tail k 2, 3, 34, 1, 99, 101 l = 73, 34, 1,99, 1018
• last k 2, 3, 34, 1, 99, 101 l = 101
• front k 2, 3, 34, 1, 99, 101 l = 72, 3, 34, 1, 998
These slides are designed to accompany Software Engineering: A
Practitioner’s Approach, 7/e (McGraw-Hill 2009). Slides copyright 2009 by
Roger Pressman. 24
 Formal Specification
 The block handler
 The block handler maintains a reservoir of unused
blocks and will also keep track of blocks that are
currently in use. When blocks are released from a
deleted file they are normally added to a queue of
blocks waiting to be added to the reservoir of
unused blocks.
• The state
used, free: P BLOCKS
BlockQueue: seq P BLOCKS
• Data Invariant
used > free = \
used < free = AllBlocks
i: dom BlockQueue BlockQueue i # used
i, j : dom BlockQueue i ≠ j => BlockQueue i > BlockQueue j = \
• Precondition
#BlockQueue > 0
• Postcondition
used' = used \ head BlockQueue
free’ = free < head BlockQueue
accompany Software
These slides are designed to BlockQueue' = tailEngineering:
BlockQueue A
Practitioner’s Approach, 7/e (McGraw-Hill 2009). Slides copyright 2009 by
Roger Pressman. 25
 Formal Specification
Languages
 A formal specification language is usually
composed of three primary components:
 a syntax that defines the specific notation with
which the specification is represented
 semantics to help define a "universe of objects"
[WIN90] that will be used to describe the system
 a set of relations that define the rules that
indicate which objects properly satisfy the
specification
 The syntactic domain of a formal specification
language is often based on a syntax that is
derived from standard set theory notation and
predicate calculus.
 The semantic domain of a specification
language indicates how the language represents
system requirements.
These slides are designed to accompany Software Engineering: A
Practitioner’s Approach, 7/e (McGraw-Hill 2009). Slides copyright 2009 by
Roger Pressman. 26
 Object Constraint Language
(OCL)
 a formal notation developed so that
users of UML can add more precision
to their specifications
 All of the power of logic and discrete
mathematics is available in the
language
 However the designers of OCL
decided that only ASCII characters
(rather than conventional
mathematical notation) should be
used in OCL statements.
These slides are designed to accompany Software Engineering: A
Practitioner’s Approach, 7/e (McGraw-Hill 2009). Slides copyright 2009 by
Roger Pressman. 27
 OCL Overview
 Like an object-oriented programming
language, an OCL expression involves
operators operating on objects.
 However, the result of a complete
expression must always be a Boolean,
i.e. true or false.
 The objects can be instances of the
OCL Collection class, of which Set
and Sequence are two subclasses.
 See Table 28.1 for summary of OCL
notation
These slides are designed to accompany Software Engineering: A
Practitioner’s Approach, 7/e (McGraw-Hill 2009). Slides copyright 2009 by
Roger Pressman. 28
 BlockHandler using
UML
1

B l o c k
B l o c k S e t

e l e m e n t s

n u m b e r

* *

* b l o c k Q u e u e

f r e e
u s e d

{ o r d e r e d }

a l l B l o c k s

{ s u b s e t }

{ s u b s e t }

1 1 1

B l o c k H a n d l e r

a d d B l o c k ( )

r e m o v e B l o c k ( )

These slides are designed to accompany Software Engineering: A

Practitioner’s Approach, 7/e (McGraw-Hill 2009). Slides copyright 2009 by
Roger Pressman. 29
 BlockHandler in OCL
 No block will be marked as both unused and used.
• context BlockHandler inv:
• (self.used->intersection(self.free)) ->isEmpty()
 All the sets of blocks held in the queue will be subsets of the collection of
currently used blocks.
• context BlockHandler inv:
• blockQueue->forAll(aBlockSet | used->includesAll(aBlockSet ))
 No elements of the queue will contain the same block numbers.
• context BlockHandler inv:
• blockQueue->forAll(blockSet1, blockSet2 |
• blockSet1 <> blockSet2 implies
• blockSet1.elements.number->excludesAll(blockSet2.elements.number))
• The expression before implies is needed to ensure we ignore pairs where both
elements are the same Block.

 The collection of used blocks and blocks that are unused will be the total
collection of blocks that make up files.
• context BlockHandler inv:
• allBlocks = used->union(free)
 The collection of unused blocks will have no duplicate block numbers.
• context BlockHandler inv:
• free->isUnique(aBlock | aBlock.number)
 The collection of used blocks will have no duplicate block numbers.
• context BlockHandler inv:
• used->isUnique(aBlock | aBlock.number)
These slides are designed to accompany Software Engineering: A
Practitioner’s Approach, 7/e (McGraw-Hill 2009). Slides copyright 2009 by
Roger Pressman. 30
The Z
Language
 organized into schemas
 defines variables
 establishes relationships between
variables
 the analog for a “module” in
conventional languages
 notation described in Table 21.2

These slides are designed to accompany Software Engineering: A

Practitioner’s Approach, 7/e (McGraw-Hill 2009). Slides copyright 2009 by
Roger Pressman. 31
 BlockHandler in Z
The following example of a schema describes the state of the block
handler and the data invariant:

———BlockHandler——————————————
used, free : P BLOCKS
BlockQueue : seq P BLOCKS
———————————————————————
used > free = \
used < free = AllBlocks
i: dom BlockQueue BlockQueue i # used
i, j : dom BlockQueue i ≠ j => BlockQueue i > BlockQueue j = \
————————————————————————

See Section 21.7.2 for further expansion of the specification

These slides are designed to accompany Software Engineering: A
Practitioner’s Approach, 7/e (McGraw-Hill 2009). Slides copyright 2009 by
Roger Pressman. 32