Specification Techniques
and
Formal Specifications
System models are abstract descriptions of
systems whose requirements are being analysed
Objectives
 To explain why specification modelling techniques
help discover problems in system requirements
 To describe
– Behavioural modelling (FSM, Petri-nets),
– Data modelling and
– Object modelling (Unified Modeling Language,
UML)
Formal Specification - Techniques for the
unambiguous specification of software
Objectives:
 To explain why formal specification techniques
help discover problems in system requirements
 To describe the use of
– algebraic techniques (for interface specification) and
– model-based techniques(for behavioural
specification)
System modelling
 System modelling helps the analyst to understand the
functionality of the system and models are used to
communicate with customers
 Different models present the system from different
perspectives
– External perspective showing the system’s context or
environment
– Behavioural perspective showing the behaviour of the
system
– Structural perspective showing the system or data
architecture
System models weaknesses
 They do not model non-functional system
requirements
 They do not usually include information about
whether a method is appropriate for a given
problem
 They may produce too much documentation
 The system models are sometimes too detailed
and difficult for users to understand
Model types
 Data processing model showing how the data is
processed at different stages
 Composition model showing how entities are
composed of other entities
 Architectural model showing principal sub-systems
 Classification model showing how entities have
common characteristics
 Stimulus/response model showing the system’s
reaction to events
1. Context models
 Context models are used to illustrate the
boundaries of a system
 Social and organisational concerns may affect
the decision on where to position system
boundaries
 Architectural models show the a system and its
relationship with other systems
The context of an ATM system
Security
system
Branch
accounting
system
Account
database
Auto-teller
system
Branch
counter
system
Usage
database
Maintenance
system
Process models
 Process models show the overall process and the
processes that are supported by the system
 Data flow models may be used to show the
processes and the flow of information from one
process to another
Equipment procurement process
Delivery
note
Specify
equipment
requir ed
Equipment
spec.
Validate
specification
Equipment
spec.
Supplier
database
Checked
spec.
Supplier list
Find
suppliers
Accept
delivery of
equipment
Get cost
estimates
Spec. +
supplier +
estima te
Choose
supplier
Order
notification
Order
details +
Blank order
form
Place
equipment
order
Checked and
signed order form
Delivery
note
Check
delivered
items
Installation
instructions
Install
equipment
Installation
acceptance
Accept
delivered
equipment
Equipment
details
Equipment
database
Semantic data models
 Used to describe the logical structure of data
processed by the system
 Entity-relation-attribute model sets out the
entities in the system, the relationships between
these entities and the entity attributes
 Widely used in database design. Can readily be
implemented using relational databases
 No specific notation provided in the UML but
objects and associations can be used
Software design semantic model
Design
1
name
description
C-date
M-date
is-a
has-nodes
1
has-links
1
n
n
1
Node
has-links
1
name
type
2
Link
n
1
links
1
name
type
1
has-labels
has-labels
Label
n
name
text
icon
n
Data dictionary entries
Data dictionaries are lists of all of the names used
in the system models.
Descriptions of the entities, relationships and
attributes are also included
Name
Description
1:N relation between entities of type Node or
has-labels
Link and entities of type Label.
Holds structured or unstructured information
Label
about nodes or links. Labels are represented by
an icon (which can be a transparent box) and
associated text.
A 1:1 relation between design entities
Link
represented as nodes. Links are typed and may
be named.
Each label has a name which identifies the type
name (label) of label. The name must be unique within the
set of label types used in a design.
Each node has a name which must be unique
name (node) within a design. The name may be up to 64
characters long.
Type
Date
Relation
5.10.1998
Entity
8.12.1998
Relation
8.12.1998
Attribute
8.12.1998
Attribute
15.11.1998
Object models
 Object models describe the system in terms
of object classes
 An object class is an abstraction over a set of
objects with common attributes and the services
(operations) provided by each object
 Various object models may be produced
– Inheritance models
– Aggregation models
– Interaction models
Object models
 Natural ways of reflecting the real-world
entities manipulated by the system
 More abstract entities are more difficult to
model using this approach
 Object class identification is recognised as a
difficult process requiring a deep understanding
of the application domain
 Object classes reflecting domain entities are
reusable across systems
The Unified Modeling Language
 Devised by the developers of widely used objectoriented analysis and design methods
 Has become an effective standard for object-oriented
modelling
 Notation
– Object classes are rectangles with the name at the top,
attributes in the middle section and operations in the bottom
section
– Relationships between object classes (known as associations)
are shown as lines linking objects
– Inheritance is referred to as generalisation and is shown
‘upwards’ rather than ‘downwards’ in a hierarchy
Behavioural models
 Behavioural models are used to describe the
overall behaviour of a system
 Two types of behavioural model
– Data processing models that show how data is
processed as it moves through the system
– State machine models that show the systems
response to events
 Both of these models are required for a
description of the system’s behaviour
Data Flow Diagrams
 Data flow diagrams are used to model the
system’s data processing
 These show the processing steps as data flows
through a system
 IMPORTANT part of many analysis methods
 Simple and intuitive notation that customers
can understand
 Show end-to-end processing of data
Order processing DFD
Or der
details +
blank
order form
Signed
order form
Completed
order form
Complete
order form
Valida te
order
Signed
order form
Send to
supplier
Record
order
Order
details
Signed
order form
Checked and
signed order
+ order
notification
Adjust
available
budget
Order
amount
+ account
details
Orders
file
Budget
file
Data flow diagrams
 DFDs model the system from a functional
perspective
 Tracking and documenting how the data
associated with a process is helpful to develop an
overall understanding of the system
 Data flow diagrams may also be used in showing
the data exchange between a system and other
systems in its environment
State machine models
 State Machine models the behaviour of the system in
response to external and internal events
 They show the system’s responses to stimuli so are
often used for modelling real-time systems
 State machine models show system states as nodes
and events as arcs between these nodes. When an
event occurs, the system moves from one state to
another
 Statecharts are an integral part of the UML
Microwave oven model
Full
power
Timer
Waiting
do: display
time
Half
power
State machine model
does not show flow of
data within the system
Full power
do: set power
= 600
Number
Full
power
Half
power
Door
closed
Timer
Door
open
Half power
do: set power
= 300
Operation
do: operate
oven
Set time
do: get number
exit: set time
Door
closed
Disabled
do: display
'Waiting'
Cancel
Start
Enabled
do: display
'Ready'
Door
open
Waiting
do: display
time
Microwave oven stimuli
Stimulus
Half power
Full power
Timer
Number
Door open
Door closed
Start
Cancel
Description
The user has pressed the half power button
The user has pressed the full power button
The user has pressed one of the timer buttons
The user has pressed a numeric key
The oven door switch is not closed
The oven door switch is closed
The user has pressed the start button
The user has pressed the cancel button
Finite state machines
Finite State Machines (FSM), also known as
Finite State Automata (FSA)
are models of the behaviours of a system or a
complex object, with a limited number of defined
conditions or modes, where mode transitions
change with circumstance.
Finite state machines - Definition
A model of computation consisting of
–
–
–
–
a set of states,
a start state,
an input alphabet, and
a transition function that maps input symbols and current
states to a next state

Computation begins in the start state with an input string. It
changes to new states depending on the transition function.
–
–
–
states define behaviour and may produce actions
state transitions are movement from one state to another
rules or conditions must be met to allow a state
–
input events are either externally or internally generated,
transition
which may possibly trigger rules and lead to state transitions
Variants of FSMs
 There are many variants, for instance,
– machines having actions (outputs) associated
with transitions (Mealy machine) or states
(Moore machine),
– multiple start states,
– transitions conditioned on no input symbol (a
null) or more than one transition for a given
symbol and state (nondeterministic finite
state machine),
– one or more states designated as accepting
states (recognizer), etc.
Finite State Machines with Output (Mealy
and Moore Machines)
 Finite automata are like computers in that they
receive input and process the input by changing
states. The only output that we have seen finite
automata produce so far is a yes/no at the end of
processing.
 We will now look at two models of finite
automata that produce more output than a yes/no.
Moore machine
 Basically a Moore machine is just
a FA with two extras.
1. It has TWO alphabets, an input and output alphabet.
2. It has an output letter associated with each state. The
machine writes the appropriate output letter as it enters each
state.
This machine might be
considered as a
"counting" machine.
The output produced by the machine contains a 1 for each
occurrence of the substring aab found in the input string.
Mealy machine
 Mealy Machines are exactly as powerful as Moore
machines
– (we can implement any Mealy machine using a Moore machine, and
vice versa).
 However, Mealy machines move the output function
from the state to the transition. This turns out to be
easier to deal with in practice, making Mealy machines
more practical.
A Mealy machine produces output on a
transition instead of on entry into a state.
Transitions are labelled i/o where
– i is a character in the input alphabet and
– o is a character in the output alphabet.
The following Mealy machine takes the one's
complement of its binary input. In other words, it
flips each digit from a 0 to a 1 or from a 1 to a 0.
 Mealy machine are complete in the sense that there is a
transition for each character in the input alphabet leaving
every state.
 There are no accept states in a Mealy machine because it
is not a language recogniser, it is an output producer. Its
output will be the same length as its input.
Statecharts
 Allow the decomposition of a model into sub-models (see a figure)
 A brief description of the actions is included following the ‘do’ in
each state
 Can be complemented by tables describing the states and the
Operation
stimuli
Time
Checking
do: check
status
Turntable
fault
Cook
do: run
generator
OK
Emitter
fault
Timeout
Done
do: buzzer on
for 5 secs.
Alarm
do: display
event
Door
open
Disabled
Cancel
Waiting
Petri Nets Model
 Petri Nets were developed originally by Carl
Adam Petri, and were the subject of his dissertation in
1962.
 Since then, Petri Nets and their concepts have been
extended, developed, and applied in a variety of
areas.
 While the mathematical properties of Petri Nets are
interesting and useful, the beginner will find that a
good approach is to learn to model systems by
constructing them graphically.
The Basics
 A Petri Net is a collection of
directed arcs connecting places
and transitions.
 Places may hold tokens.
 The state or marking of a net is
its assignment of tokens to
places.
Place
P2
Place with
token
P1
Arc with capacity 1
T1
Transition
Capacity
 Arcs have capacity 1 by default; if other than 1, the
capacity is marked on the arc.
 Places have infinite capacity by default.
 Transitions have no capacity, and cannot store tokens
at all.
 Arcs can only connect places to transitions and vice
versa.
 A few other features and considerations will be added
as we need them.
The classical Petri net model
A Petri net is a network composed of places ( ) and
transitions ( ).
t2
t1
p2
p1
t3
p4
p3
Connections are directed and between a place and a transition.
Tokens ( ) are the dynamic objects.
The state of a Petri net is determined by the distribution of
tokens over the places.
p1
p4
t1
p2
p3
Transition t1 has three input places (p1, p2 and p3)
and two output places (p3 and p4).
Place p3 is both an input and an output place of t1.
Enabling condition
Transitions are the active components and places and
tokens are passive.
A transition is enabled if each of the input places contains
tokens.
t1
t2
Transition t1 is not enabled, transition t2 is enabled.
Firing
An enabled transition may fire.
Firing corresponds to consuming tokens from the input
places and producing tokens for the output places.
t2
Firing is atomic.
t2
Example
Non-determinism
t1
t2
Two transitions fight for the same token: conflict.
Even if there are two tokens, there is still a
conflict.
A collection of primitive structures that
occur in real systems
High-level Petri nets
 The classical Petri net was invented by Carl
Adam Petri in 1962. Since then a lot of research
has been conducted (>10,000 publications).
 Since the 80-ties the practical use is increasing
because of the introduction of high-level Petri
nets and the availability of many tools.
 High-level Petri nets are Petri nets extended
with
– color (for the modeling of attributes)
– time (for performance analysis)
– hierarchy (for the structuring of models, DFD's)
Modeling
States of a process are modeled by tokens in places and
state transitions leading from one state to another are
modeled by transitions.
 Tokens represent objects (humans, goods, machines),
information, conditions or states of objects.
 Places represent buffers, channels, geographical
locations, conditions or states.
 Transitions represent events, transformations or
transportations.
Example: traffic light
red
yr
yellow
rg
gy
green
Two traffic lights
red1
red2
yr1
yr2
yellow1
rg1
gy1
yellow2
rg2
gy2
green1
green2
Two safe traffic lights
red1
red2
safe
yr1
yr2
yellow1
rg1
gy1
yellow2
rg2
gy2
green1
green2
Two safe and fair traffic lights
red1
red2
safe2
yr1
yr2
yellow1
rg1
yellow2
gy1
rg2
gy2
safe1
green1
green2
Some definitions
 current state
The configuration of tokens over the places.
 reachable state
A state reachable form the current state by
firing a sequence of enabled transitions.
 dead state
A state where no transition is enabled.
br
red
black
rr
bb
(3,2)
br
rr
red
black
bb\br
(1,3)
(3,1)
rr
br
bb\br
rr
bb
(1,2)
(3,0)
rr
bb\br
(1,1)
br
(1,0)
 7 reachable states, 1 dead state.
Exercise: your life-cycle
sleeping
start
stop
active
die
dead
 How many states are reachable?
 Is there a dead state?
EC Exercise: readers and writers
begin
receive_mail
mail_box
rest
rest
type_mail
send_mail




read_mail
ready
How many states are reachable?
Are there any dead states?
How to model the situation with 2 writers and 3 readers?
How to model a "bounded mailbox" (buffer size =4)?
High-level Petri nets
In practice the classical Petri net is not very useful:
 The Petri net becomes too large and too complex.
 It takes too much time to model a given situation.
 It is not possible to handle time and data.
Therefore, we use high-level Petri nets, i.e. Petri nets
extended with:
 color
 time
 hierarchy
To explain the three extensions we use the
following example of a hairdresser's
hairdresser ready to begin
saloon.
free
client waiting
start
waiting
finish
busy
ready
Note how easy it is to model the situation with multiple
hairdressers.
The extension with color
A token often represents an object having all kinds
of attributes.
Therefore, each token has a value (color) with
refers to specific features of the object modeled
by the token.
name: Sally
age: 28
hairtype: BL
free
start
waiting
name: Harry
age: 28
experience: 2
finish
busy
ready
Each transition has an (in)formal
specification which specifies:
 the number of tokens to be produced,
 the values of these tokens,
 and (optionally) a precondition.
The complexity is divided over the network and
the values of tokens.
This results in a compact, manageable and natural
process description.
Examples
c := a+b
a
b := -a
+
b
a
-
b
c
a >=0 | b :=  a
a
b
select
if a> 0
then b:= a
else c:=a
fi
a
sqrt
b
c
Extra Credit Exercise:
calculate |a+b| using these buiding blocks
The extension with time
For performance analysis we need to model
durations, delays, etc.
Therefore, each token has a timestamp and
transitions determine the delay of a produced
token.
free
3
0
9
D=0
1
start
waiting
D=0
finish
D=3
busy
ready
The extension with hierarchy
 A mechanism to structure complex Petri nets
comparable to DFD's.
 A subnet is a net composed out of places,
transitions and subnets.
h1
h2
waiting
ready
h3
free
start
busy
finish
Exercise: remove hierarchy
h1
h2
waiting
ready
h3
free
begin
start
busy
pending end
finish
begin
pending end
Key points
 Modeling specification complements informal
requirements elicitation techniques.
 Model specifications can be precise and
unambiguous, but generally depend on
interpretation of inputs/output. They reduce areas
of doubt in a specification
 More formal models, such as FSM or Petri nets
forces an analysis of the system requirements at
an early stage. Correcting errors at this stage is
cheaper than modifying a system during design
Formal methods
 Formal specification is part of a more general
collection of techniques that are known as
‘formal methods’
These are all based on mathematical
representation and analysis of software
 Formal methods include
–
–
–
–
Formal specification
Specification analysis and proof
Transformational development
Program verification
Acceptance of formal methods
 Formal methods have not become mainstream software
development techniques as was once predicted
– Other software engineering techniques have been successful
at increasing system quality. Hence the need for formal
methods has been reduced
– Market changes have made time-to-market rather than
software with a low error count the key factor. Formal
methods do not reduce time to market
– The scope of formal methods is limited. They are not wellsuited to specifying and analysing user interfaces and user
interaction
– Formal methods are hard to scale up to large systems
Use of formal methods
 Their principal benefits are in reducing the number of
errors in systems so their main area of applicability is
critical systems:
–
–
–
–
Air traffic control information systems,
Railway signalling systems
Spacecraft systems
Medical control systems
 In this area, the use of formal methods is most likely to
be cost-effective
 Formal methods have limited practical applicability
Specification in the software process
 Specification and design are inextricably
mixed.
 Architectural design is essential to
structure a specification.
 Formal specifications are expressed in a
mathematical notation with precisely
defined vocabulary, syntax and semantics.
Specification and design
Increasing contractor involvement
Decreasin g client involvement
Requir ements
definition
Requir ements
specification
Architectur al
design
Software
specification
Specification
Design
High-level
design
Specification in the software process
Requirements
specification
Formal
specification
Requirements
definition
High-le vel
design
System
modelling
Ar chitectural
design
Specification techniques
 Algebraic approach
– The system is specified in terms of its
operations and their relationships
 Model-based approach
– The system is specified in terms of a state
model that is constructed using mathematical
constructs such as sets and sequences.
– Operations are defined by modifications to
the system’s state
Formal specification languages
Algebraic
Model-based
Sequential
Larch (Guttag, Horning et
al., 1985; Guttag,
Horning et al., 1993),
OBJ (Futatsugi, Goguen
et al., 1985)
Z (Spivey, 1992)
VDM (Jones, 1980)
B (Wordsworth, 1996)
Concurrent
Lotos (Bolognesi and
Brinksma, 1987),
CSP (Hoare, 1985)
Petri Nets (Peterson,
1981)
Z (“zed”) Notation
 Formal specification language
– most successful one -> easy to find faults, can prove correctness
 Requires set theory, functions, & discrete math
– also difficult to learn because of special symbols
 Z specifications consists of 4 sections
– given sets, data types, and constants
• sets that get defined in detail
– state definition
• variable declarations & predicates that constrain values
– initial state
– operations
Use of formal specification
 Formal specification involves investing more
effort in the early phases of software
development
This reduces requirements errors as it
forces a detailed analysis of the requirements
 Incompleteness and inconsistencies can be
discovered and resolved !!!
Hence, savings as made as the amount of
rework due to requirements problems is
reduced
Development costs with formal specification
Cost
Validation
Design and
Implementation
Validation
Design and
Implementation
Specification
Specification
Without formal
specification
With formal
specification
1. Interface specification
 Large systems are decomposed into subsystems with
well-defined interfaces between these subsystems
 Specification of subsystem interfaces allows
independent development of the different subsystems
 Interfaces may be defined as abstract data types or
object classes
The algebraic approach to formal specification is
particularly well-suited to interface specification
Sub-system interfaces
Interface
objects
Sub-system
A
Sub-system
B
The structure of an algebraic
specification
< SPECIFICATION NAME > (Gener ic Parameter)
sort < name >
imports < LIST OF SPECIFICATION NAMES >
Informal descr iption of the sor t and its operations
introduction
description
Operation signatures setting out the names and the types of
the parameters to the operations defined over the sort
signature
Axioms defining the operations over the sort
axioms
Specification in Z
 Scenario: We maintain a membership list
and an associated phone database.
[Person, Phone]
|----PhoneDB----------------------------------|members: P Person
(‘set of’ person)
|phones : Person  Phone
(relation)
|------------------------------------------------------|dom phones ⊆ members (invariant)
|---------------------------------------------------
Z Operation: Assign a Phone
 Scenario: Someone would like a phone.
(Note: Missing precondition)
|----Assign----------------------------------| p? : Person; n? : Phone
| D PhoneDB
|------------------------------------------------------| phone’ = phone union  { p?  n? }
| members’ = members
|---------------------------------------------------
Example
 members  {jim, sue}
 phones {(jim, 1231), (sue, 3956)}
 Assign(alice, 1231)
 Cool Z property: Can calculate minimal
preconditions!!
 Simple analysis: leave out preconditions and find
minimum constraint to maintain invariants!
Behavioural specification
 Algebraic specification can be
cumbersome when the object operations
are not independent of the object state
 Model-based specification exposes the
system state and defines the operations
in terms of changes to that state
Abstract State Machine
Language (AsmL)
 AsmL is a language for modelling the
structure and behaviour of digital systems
 AsmL can be used to faithfully capture the
abstract structure and step-wise behaviour of
any discrete systems, including very complex
ones such as:
Integrated circuits, software components, and devices that
combine both hardware and software
Abstract State
 An AsmL model is said to be abstract because it
encodes only those aspects of the system’s structure
that affect the behaviour being modelled
The goal is to use the minimum amount of detail
that accurately reproduces (or predicts) the
behaviour of the system
 Abstraction helps us reduce complex problems into
manageable units and prevents us from getting lost in
a sea of details
AsmL provides a variety of features that allow
you to describe the relevant state of a
system in a very economical, high-level way
Abstract State Machine and
Turing Machine
 An abstract state machine is a particular
kind of mathematical machine, like the
Turing machine (TM)
 But unlike a TM, ASMs may be defined a
very high level of abstraction
 An easy way to understand ASMs is to see
them as defining a succession of states that
may follow an initial state
State transitions
 The behaviour of a machine (its run) can always
be depicted as a sequence of states linked by state
transitions
paint in green
A
paint in red
B
• Moving from state A to state B is a state
transition
Configurations
 Each state is a particular “configuration” of the
machine
 The state may be simple or it may be very large,
with complex structure
 But no matter how complex the state might be,
each step of the machine’s operation can be seen
as a well-defined transition from one particular
state to another
Evolution of state variables
We can view any machine’s state as a dictionary of
(Name, Value)
pairs, called state variables
paint in green
A
paint in red
B
(Colour, Red) is a variable, where “Colour” is
the name of variable, “Red” is the value
Evolution of state variables
 Names are given by the machine’s symbolic
vocabulary
 Values are fixed elements, like numbers and
strings of characters
The run of a machine is a series of
states and state transitions that
results form applying operations
to each state in succession
Example
Diagram shows the run of a machine that models how orders might
Initialise
Process All Orders
be
processed
S1
S2
S3
Mode = “Initial”
Mode = “Active”
Mode = “Final”
Orders = 0
Orders = 2
Orders = 0
Balance = $0
Balance = $200
Balance = $500
Each transition operation:
• can be seen as the result of invoking the machine’s
control logic on the current state
• calculates the subsequence state as output
Control Logic
The machine’s control logic
behaves like a fix set of transition
rules that say how state may evolve
Typical form of the operational text is:
“ if condition then update ”
We can think of the control logic as a text that
precisely specifies, for any given state, what the
values of the machine’s variables will be in the
following step
Control Logic as a Black Box
• The machine control logic is a black box that takes as input a
state dictionary S1 and gives as output a new dictionary S2
mode
“Initial”
orders
0
balance
$0
input
The Machine’s Control
output
Logic
…
Mode
“Active”
if mode = “Initial”
orders
2
balance
$200
then mode := “Active”
 The two dictionaries S1 and S2 have the same set of
keys, but the values associated with each variable
name may differ between S1 and S2
Run of the Machine
 The run of the machine can be seen as what happens
when the control logic is applied to each state in turn
 The run starts form initial state
S1  S2  S 3  …
S1 is given to the black box yielding S2, processing S2 results in S3,
and so on …
 When no more changes to state are possible, the run is
complete
Update operations
 We use the symbol
“: =” (reads as “gets”)
to indicate the value that a name will have in the
resulting state
For example: mode:=“Active”
 Update can be seen only during the following step (this
is in contrast to Java, C, Pascal, …)
 All changes happen simultaneously, when you moving
from one step to another. Then, all updates happen at
once.(atomic transaction)
Programs
Example 1. Hello, world
Main()
step WriteLine(“hello, world!”)
ASML uses indentations to denote block structure, and blocks can
be places inside other blocks
Statement block affect the scope of variables
Whitespace includes blanks and new-line character, ASML does not
recognize tab character for indentation !!!!!!!
An operation names run() gives the top-level operational definition
of the model (Main() is like main() in Java and C )
Example 2. Reading a file
var F as File? = undef
var Fcontents as String = “”
var Mode as String = “Initial”
Main()
step until fixpoint
if Mode = “Initial” then
F :=open(“mfile.txt”)
Mode :=“Reading”
if Mode = “Reading” and length(FContents) =0 then
FContents :=fread (F,1)
if Mode = “Reading” and length(FContents) =1 then
FContents := FContents + fread (F,1)
if Mode = “Reading” and length(FContents) >1 then
WriteLine (FContents)
Mode :=“Finished”
Example 2.
Graph representation
Step 1
Step 2
S1
S2
S3
F= undef
F= <open file 1>
F= <open file 1>
Fcontents =“”
Fcontents =“”
Fcontents =“a”
Mode = Initial
Mode = Reading
Mode = Reading
Step 3
S4
S5
F= undef
F= <open file 1>
Fcontents =“ab”
Fcontents =“ab”
Mode = Reading
Step 4
Mode = Finished
Step5
Key points
 Formal system specification complements
informal specification and modeling techniques
 Formal specifications are precise and
unambiguous. They remove areas of doubt in a
specification, but still depend on interpretation of
terms, inputs and outputs.
 Formal specification forces an very details
analysis of the system requirements at an early
stage. Correcting errors at this stage is cheaper.
Key points
 Formal specification techniques are most applicable in
the development of critical systems and standards.
 Algebraic techniques are suited to interface specification
where the interface is defined as a set of object classes
 Model-based techniques model the system using sets and
functions. This simplifies some types of behavioural
specification
 Its not for the faint of heart, you’ll need some special
training to go down this path.