1. Specification Techniques and Formal Specifications
Based on notes from Dr. Igor Potapov, University of Liverpool

2. 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)

3. 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)

4. 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

5. 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

6. 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

7. 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

8. The context of an ATM system

9. 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

10. Equipment procurement process

11. 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

12. Software design semantic model

13. 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

14. 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

15. 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

16. The Unified Modeling Language
Devised by the developers of widely used object-oriented 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

17. 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

18. 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

19. Order processing DFD

20. 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

21. 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

22. Microwave oven model
State machine model does not show flow of data within the system

23. Microwave oven stimuli

24. Finite State Automata (FSA)
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.

25. 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 transition
input events are either externally or internally generated, which may possibly trigger rules and lead to state transitions

26. 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.

27. 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.

28. This machine might be considered as a "counting" machine.
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.

29. 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.

30. 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.
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.
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.

31. 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 stimuli

32. 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.

33. The Basics
Place with token
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. P1
Arc with capacity 1 T1
Place
Transition P2

34. 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.

35. The classical Petri net model
A Petri net is a network composed of places ( ) and transitions ( ). t2 p2 t1 p1 p4 t3 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.

36. Place p3 is both an input and an output place of t1.
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.

37. 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.

38. Firing An enabled transition may fire.
Firing corresponds to consuming tokens from the input places and producing tokens for the output places. t2 t2
Firing is atomic.

39. Example

40. Non-determinism Two transitions fight for the same token: conflict.
Even if there are two tokens, there is still a conflict.

41. A collection of primitive structures that occur in real systems

42. High-level Petri nets
The classical Petri net was invented by Carl Adam Petri in 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)

43. 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.

44. Example: traffic lightrg
red
yellow
green yr gy

45. Two traffic lights rg1 red1 yellow1 green1 yr1 gy1 rg2 red2 yellow2

46. Two safe traffic lights
rg1
red1
yellow1
green1
yr1
gy1
rg2
red2
yellow2
green2
yr2
gy2
safe

47. Two safe and fair traffic lights
red1
red2
safe2
yr1
yr2
yellow1
yellow2
rg1
rg2
gy1
gy2
safe1
green1
green2

48. 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.
black
red bb rr br

49. 7 reachable states, 1 dead state.
black
red bb rr br
(3,2)
(1,3)
(3,1)
(1,2)
(3,0)
(1,1)
(1,0) rr br
bb\br
7 reachable states, 1 dead state.

50. Exercise: your life-cycle
sleeping
start
stop
active
die
dead
How many states are reachable?
Is there a dead state?

51. EC Exercise: readers and writers
begin
receive_mail
mail_box
rest
rest
type_mail
read_mail
send_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)?

52. 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

53. To explain the three extensions we use the following example of a hairdresser's saloon.
hairdresser ready to begin
client waiting
free
start
finish
waiting
busy
ready
Note how easy it is to model the situation with multiple hairdressers.

54. 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
name: Harry
age: 28
experience: 2
start
waiting
finish
busy
free
ready

55. 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.

56. Examples Extra Credit Exercise: c := a+b b := -a a + a - b b c
a >=0 | b := Ö a a b a
sqrt b
select c
if a> 0
then b:= a
else c:=a fi
Extra Credit Exercise:
calculate Ö |a+b| using these buiding blocks

57. 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.
start
waiting
finish
busy
free
ready 1 3 9
D=3
D=0

58. 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
start
finish
busy
free

59. Exercise: remove hierarchy
waiting
ready h3
start
finish
busy
free
begin
pending
end
begin
pending
end

60. 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

61. 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

62. 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 well-suited to specifying and analysing user interfaces and user interaction
Formal methods are hard to scale up to large systems

63. 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

64. 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.

65. Specification and design

66. Specification in the software process

67. 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

68. Formal specification languages

69. 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

70. 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

71. Development costs with formal specification

72. 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

73. Sub-system interfaces

74. The structure of an algebraic specification
TION NAME > (Gener
ic P ar
ameter)
sort
< name >
introduction
imports
< LIST
OF SPECIFICA
TION NAMES >
description
Inf or
mal descr
iption of the sor
t and its oper
ations
Oper
ation signatures setting out the names and the types of
the parameters to the operations defined over the sort
signature
Axioms defining the oper
ations o v
er the sor t
axioms

75. 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) |

76. Z Operation: Assign a Phone
Scenario: Someone would like a phone. (Note: Missing precondition)
|----Assign
| p? : Person; n? : Phone
|  PhoneDB |
| phone’ = phone union  { p?  n? }
| members’ = members |

77. 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!

78. 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

79. 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

80. 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

81. 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

82. 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
paint in red A B
Moving from state A to state B is a state transition

83. 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

84. Evolution of state variables
We can view any machine’s state as a dictionary of
(Name, Value)
pairs, called state variables
paint in green
paint in red A B
(Colour, Red) is a variable, where “Colour” is the name of variable, “Red” is the value

85. 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

86. Each transition operation:
Example
Diagram shows the run of a machine that models how orders might be
processed S1
Mode = “Initial”
Orders = 0
Balance = $0
Initialise
Process All Orders S3
Mode = “Final”
Balance = $500 S2
Mode = “Active”
Orders = 2
Balance = $200
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

87. 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

88. 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
input
mode
“Initial”
orders
balance $0
The Machine’s Control Logic …
if mode = “Initial”
then mode := “Active”
output
Mode
“Active”
orders 2
balance
$200
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

89. 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  S3  …
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

90. For example: mode:=“Active”
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)

91. 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 )

92. 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”

93. Example 2. Graph representation
Step 1
Step 2 S1
F= undef
Fcontents =“”
Mode = Initial S2
F= <open file 1>
Fcontents =“”
Mode = Reading S3
F= <open file 1>
Fcontents =“a”
Mode = Reading
Step 3 S4
F= undef
Fcontents =“ab”
Mode = Reading S5
F= <open file 1>
Fcontents =“ab”
Mode = Finished
Step5
Step 4

94. 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.

95. 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.