Software Engineering: A Practitioner’s Approach, 

6/e

Chapter 28
Formal Methods copyright © 1996, 2001, 2005
R.S. Pressman & Associates, Inc.

For University Use Only

May be reproduced ONLY for student use at the university level
when used in conjunction with Software Engineering: A Practitioner's Approach.
Any other reproduction or use is expressly prohibited.

These courseware materials are to be used in conjunction with Software Engineering: A Practitioner’s Approach, 6/e and 
are provided with permission by R.S. Pressman & Associates, Inc., copyright © 1996, 2001, 2005 1
 Problems with 
Conventional 
Specification
 contradictions
contradictions
 ambiguities
 vagueness
 incompleteness
 mixed levels of abstraction

These courseware materials are to be used in conjunction with Software Engineering: A Practitioner’s Approach, 6/e and 
are provided with permission by R.S. Pressman & Associates, Inc., copyright © 1996, 2001, 2005 2
 Formal Specification
 Desired properties—consistency, completeness, and lack of ambiguity—are 
the objectives of all specification methods
 The formal syntax of a specification language (Section 28.4) 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 (Section 28.2) 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 courseware materials are to be used in conjunction with Software Engineering: A Practitioner’s Approach, 6/e and 
are provided with permission by R.S. Pressman & Associates, Inc., copyright © 1996, 2001, 2005 3
 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 courseware materials are to be used in conjunction with Software Engineering: A Practitioner’s Approach, 6/e and 
are provided with permission by R.S. Pressman & Associates, Inc., copyright © 1996, 2001, 2005 4
 An Example—Print Spooler
Device queues files awaiting printing

LP1 ftax persons

LP2 newdata
LAS1
LAS2 exres

Limits Size

LP1 ­> 750 newdata ­> 450
LP2 ­> 500 ftax ­> 650
LAS1 ­> 300 exres ­> 50
LAS2 ­> 200 persons ­> 700

These courseware materials are to be used in conjunction with Software Engineering: A Practitioner’s Approach, 6/e and 
are provided with permission by R.S. Pressman & Associates, Inc., copyright © 1996, 2001, 2005 5
 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 courseware materials are to be used in conjunction with Software Engineering: A Practitioner’s Approach, 6/e and 
are provided with permission by R.S. Pressman & Associates, Inc., copyright © 1996, 2001, 2005 6
 Operation

s
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 courseware materials are to be used in conjunction with Software Engineering: A Practitioner’s Approach, 6/e and 
are provided with permission by R.S. Pressman & Associates, Inc., copyright © 1996, 2001, 2005 7
 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 courseware materials are to be used in conjunction with Software Engineering: A Practitioner’s Approach, 6/e and 
are provided with permission by R.S. Pressman & Associates, Inc., copyright © 1996, 2001, 2005 8
 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

These courseware materials are to be used in conjunction with Software Engineering: A Practitioner’s Approach, 6/e and 
are provided with permission by R.S. Pressman & Associates, Inc., copyright © 1996, 2001, 2005 9
 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 courseware materials are to be used in conjunction with Software Engineering: A Practitioner’s Approach, 6/e and 
are provided with permission by R.S. Pressman & Associates, Inc., copyright © 1996, 2001, 2005 10
 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
 x P
x P X
 The operators , , and # take sets as their operands. The predicate
 A ,
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 courseware materials are to be used in conjunction with Software Engineering: A Practitioner’s Approach, 6/e and 
are provided with permission by R.S. Pressman & Associates, Inc., copyright © 1996, 2001, 2005 11
 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
: 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 courseware materials are to be used in conjunction with Software Engineering: A Practitioner’s Approach, 6/e and 
are provided with permission by R.S. Pressman & Associates, Inc., copyright © 1996, 2001, 2005 12
 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 courseware materials are to be used in conjunction with Software Engineering: A Practitioner’s Approach, 6/e and 
are provided with permission by R.S. Pressman & Associates, Inc., copyright © 1996, 2001, 2005 13
 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
: 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  
BlockQueue' = tail BlockQueue

These courseware materials are to be used in conjunction with Software Engineering: A Practitioner’s Approach, 6/e and 
are provided with permission by R.S. Pressman & Associates, Inc., copyright © 1996, 2001, 2005 14
 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 courseware materials are to be used in conjunction with Software Engineering: A Practitioner’s Approach, 6/e and 
are provided with permission by R.S. Pressman & Associates, Inc., copyright © 1996, 2001, 2005 15
 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 courseware materials are to be used in conjunction with Software Engineering: A Practitioner’s Approach, 6/e and 
are provided with permission by R.S. Pressman & Associates, Inc., copyright © 1996, 2001, 2005 16
 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 courseware materials are to be used in conjunction with Software Engineering: A Practitioner’s Approach, 6/e and 
are provided with permission by R.S. Pressman & Associates, Inc., copyright © 1996, 2001, 2005 17
 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 courseware materials are to be used in conjunction with Software Engineering: A Practitioner’s Approach, 6/e and 
are provided with permission by R.S. Pressman & Associates, Inc., copyright © 1996, 2001, 2005 18
 BlockHandler in OCL
 No block will be marked as both unused and used.
   context BlockHandler inv:
  context  BlockHandler inv:
     (self.used­>intersection(self.free)) ­>isEmpty()
    (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:
  context  BlockHandler inv:
     blockQueue­>forAll(aBlockSet | used­>includesAll(aBlockSet ))
    blockQueue­>forAll(aBlockSet | used­>includesAll(aBlockSet ))
 No elements of the queue will contain the same block numbers.
   context BlockHandler 
  context inv::
 BlockHandler inv
     blockQueue­>forAll(blockSet1, blockSet2 |
    blockQueue­>forAll(blockSet1, blockSet2 |
       blockSet1 <> blockSet2 implies
      blockSet1 <> blockSet2 implies
       blockSet1.elements.number­>excludesAll(blockSet2.elements.number))
      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 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 
  context inv::
 BlockHandler inv
     allBlocks = used­>union(free)
    allBlocks = used­>union(free)
 The collection of unused blocks will have no duplicate block numbers.
   context BlockHandler 
  context inv::
 BlockHandler inv
     free­>isUnique(aBlock | aBlock.number)
    free­>isUnique(aBlock | aBlock.number)
 The collection of used blocks will have no duplicate block numbers.
   context BlockHandler 
  context inv::
 BlockHandler inv
     used­>isUnique(aBlock | aBlock.number)

These courseware materials are to be used in conjunction with Software Engineering: A Practitioner’s Approach, 6/e and 
are provided with permission by R.S. Pressman & Associates, Inc., copyright © 1996, 2001, 2005 19
 The Z Language

 organized into schemas
 defines variables
 establishes relationships between variables
 the analog for a “module” in conventional languages
 notation described in Table 28.2

These courseware materials are to be used in conjunction with Software Engineering: A Practitioner’s Approach, 6/e and 
are provided with permission by R.S. Pressman & Associates, Inc., copyright © 1996, 2001, 2005 20
 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 28.6.2 for further expansion of the specification

These courseware materials are to be used in conjunction with Software Engineering: A Practitioner’s Approach, 6/e and 
are provided with permission by R.S. Pressman & Associates, Inc., copyright © 1996, 2001, 2005 21