Lectures 9,10
Formal Specifications
Software Engineering, COMP201
Slide 1
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)
To introduce Abstract State Machine Model
Software Engineering, COMP201
Slide 2
Formal methods


Formal specification is part of a more general
collection of techniques that are known as
‘formal methods’ COMP313 “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
Software Engineering, COMP201
Slide 3
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
Software Engineering, COMP201
Slide 4
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
Software Engineering, COMP201
Slide 5
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.
Software Engineering, COMP201
Slide 6
Specification and design
In creas in g co n tracto r in vol vemen t
Decreas in g cl ien t i n vo lv emen t
Requ ir em ent s
d efi ni ti on
Requ ir em ent s
s pecifi cat io n
Archi tect ur al
d es ig n
S o ftw are
s pecifi cat io n
Hi g h-lev el
d es ig n
S p eci ficat io n
Des ig n
Software Engineering, COMP201
Slide 7
Specification in the software
process
R equ irem ent s
s pecifi cat io n
Fo rm al
s pecifi cat io n
R equ irem ent s
d efi ni ti on
Hi g h-le vel
d es ig n
S y st em
m o dell in g
Ar chi tect ural
d es ig n
Software Engineering, COMP201
Slide 8
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
Software Engineering, COMP201
Slide 9
Formal specification languages
A lg e b ra ic
M o d e l-b a s e d
S e q u e n tia l
L a rc h (G u tta g , H o rn in g e t
a l., 1 9 8 5 ; G u tta g ,
H o rn in g e t a l., 1 9 9 3 ) ,
O B J (F u ta tsu g i, G o g u e n
e t a l., 1 9 8 5 )
Z (S p iv e y , 1 9 9 2 )
V D M (J o n e s, 1 9 8 0 )
B (W o rd sw o rth , 1 9 9 6 )
C o n c u rre n t
L o to s (B o lo g n e si a n d
B rin k sm a , 1 9 8 7 ) ,
C S P (H o a re , 1 9 8 5 )
P e tri N e ts (P e te rso n ,
1981)
ASML - Abstract State Machine Language
Yuri. Gurevich, Microsoft Research, 2001
Software Engineering, COMP201
Slide 10
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
Software Engineering, COMP201
Slide 11
Development costs with formal
specification
C o st
Vali dat io n
Des ig n and
Im pl em ent at io n
Vali dat io n
Des ig n and
Im pl em ent at io n
S p eci ficat io n
S p eci ficat io n
W i th ou t fo rm al
s pecifi cat io n
W i th fo rm al
s pecifi cat io n
Software Engineering, COMP201
Slide 12
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
Software Engineering, COMP201
Slide 13
Sub-system interfaces
Int erface
o bj ect s
S u b-s ys tem
A
S u b-s ys tem
B
Software Engineering, COMP201
Slide 14
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
Software Engineering, COMP201
axioms
Slide 15
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
Software Engineering, COMP201
Slide 16
OSI reference model
Model-based
specification
7
Ap
pl icat io n
Application
Ap pl icat io n
6
P resen tati on
5
S es si on
4
Trans po rt
3
Net wo rk
Net wo rk
Net wo rk
2
Dat a li nk
Dat a li nk
Data lin k
1
P hy si cal
P hy si cal
P hy si cal
P resen tati on
Algebraic
specification
S es si on
Trans po rt
C o m mu ni ca t io ns m edi um
Software Engineering, COMP201
Slide 17
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
Software Engineering, COMP201
Slide 18
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
Software Engineering, COMP201
Slide 19
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
Software Engineering, COMP201
Slide 20
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
Software Engineering, COMP201
Slide 21
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
Software Engineering, COMP201
Slide 22
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
Software Engineering, COMP201
Slide 23
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
Software Engineering, COMP201
Slide 24
Example
Diagram shows the run of a machine that models how orders might be
Initialise
Process All Orders
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
Software Engineering, COMP201
Slide 25
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
Software Engineering, COMP201
Slide 26
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
Logic
output
…
Mode
“Active”
orders
2
balance
£200
if mode = “Initial”
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
Software Engineering, COMP201
Slide 27
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
Software Engineering, COMP201
Slide 28
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)
Software Engineering, COMP201
Slide 29
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 Main() gives the top-level operational definition
of the model (Main() is like main() in Java and C )
Software Engineering, COMP201
Slide 30
The Executable Specification Language -
ASML
Compiler
asmlc [name of the program]
!!! Use D drive at the University Laboratories !!!
Example
D:\>asmlc test.asml
D:\> test.exe
D:\> test.exe >output_file.txt
Software Engineering, COMP201
Slide 31
I. Steps
A step can be
introduced
independently or
as part of
sequence of steps
in the form:
step …
step …
The general syntax for steps is
Step [label] [stopping-condition]
statement block
 a statement block consists of
indented statement that follow
 a label is an optional string,
number of identifier followed by a
colon (“:”)
 stopping condition is any these
forms:
until fixpoint
until expression
while expression
Software Engineering, COMP201
Slide 32
Stopping for fixed point
“until fixed point”
enum EnumMode
Initial
Started
Finished
var mode = Initial
var count = 0
Initial
if count < 10 then
count:= count+1
count:= 1
Main()
step until fixpoint
if mode = Initial then
mode :=Started
count:=1
if mode = Started and count < 10 then
count:= count+1
if mode = Started and count >=10 then
mode:= Finished
Software Engineering, COMP201
Started
count  10
Finished
Slide 33
Stopping for conditions
“while” & “until”
Either while or until may be used to give an explicit stopping
condition for iterated sequential steps of the machine.
while expression
var x as Integer = 1
Main()
step while x < 10
WriteLine(x)
x:= x + 1
until expression
var x as Integer = 1
Main()
step until x > 9
WriteLine(x)
x:= x + 1
Running each of these examples produces nine steps. It
will print numbers: 1,2,3,4,5,6,7,8 and 9 as output
Software Engineering, COMP201
Slide 34
Conditions
eq
ne
lt
gt
in
notin
subset
superset
subseteq
superseteq
=

<
>






Software Engineering, COMP201
Slide 35
Sequences of steps

The syntax step … step … indicates a sequence of
steps that will be performed in order
• Labels after the “step” keyword are optional
but helpful as documentation.
Software Engineering, COMP201
Slide 36
Be wary !



Be wary of introducing unnecessary steps
This can occur if two operations are really not
order-dependent but are given as two
sequential steps, regardless
It is very easy to fall into this trap, since most
people are used to the sequential structures
used by other programming languages
Software Engineering, COMP201
Slide 37
Iteration over
collections
Another common idiom for iteration is to do one step per element
in some finite collection such as a set or sequence
step foreach ident1 in expr1, ident2 in expr2 …
statement-block
Sequential, step-based
iteration is available for
sets as well as sequences,
but in the case of sets, the
order is not specified
myList = [1,2,3]
Main()
step foreach i in myList
WriteLine (i)
Software Engineering, COMP201
Slide 38
Guidelines for using steps
You choose …
Situation
operations occur in a fixed
order
each operation must be
done in order
operations must be done in
sequence, one after another
operations can be done
without order
Repeat an operation until
no more changes occur
sequence of steps
iterated steps with stopping
condition “while”,“until”
iteration over collection
“foreach”
iteration over collection
“forall”
fixed-point stopping
condition “until fixed point”
Software Engineering, COMP201
Slide 39
II. Updates “How are variables updated?”



A program defines state variables and operations
The most important concept is that state is a
dictionary of (name,value) pairs
Each name identifies an occurrence for state
variables
• Operations may propose new values for
state variables
• But effect of these changes is only visible
in subsequent step
Software Engineering, COMP201
Slide 40
The update statement
Update symbol “: =” (reads as “gets”)
var x = 0
var y = 1
Main()
step
WriteLine(“In the first step, x =” + x) // x is 0
WriteLine (“In the first step, y =” + y) // y is 1
x:=2
step
// updates occur here
WriteLine(“In the second step, x =” + x)//x is 2
WriteLine(“In the second step, y =” + y)//y is 1
Software Engineering, COMP201
Slide 41
Delayed effect of updates
Updates don’t actually occur until the step
following the one in which they are written
var x = 0
var y = 1
Main()
step
WriteLine(“In the first step, x =” + x) // x is 0
WriteLine(“In the first step, y =” + y) // y is 1
step
x:=2
WriteLine (“In the second step, x =” + x) // x is 0
step WriteLine (“In the third step, x =” + x) // x is 2
Software Engineering, COMP201
Slide 42
When updates occur


All updates given within a single step occur
simultaneously at the end of the step.
Conceptually, the updates are applied “in
between” the steps.
Swapping values
in C, Java
temp = x
x=y
y = temp
in ASML
step
x:= y
y:=x
Software Engineering, COMP201
Slide 43
Consistency of updates
•
•
•
The order within a step does not matter, but all of updates
in the step must be consistent
None of the updates given within a step may contradict
each other
If updates do contradict, then they are called
“inconsistent updates” and an error occur
Inconsistent update
step
x:=1
x:=2
Error: CLASH
in the update set
we don’t know which of the
two should take effect
Software Engineering, COMP201
Slide 44
Total and partial updates




An update of the variable can either be total or
partial
Total update is a simple replacement of variable’s
value with a new value
Partial updates apply to variables that have
structure
The left hand side of the update operation
“ X : = val ”
indicates whether the update is total or partial
Software Engineering, COMP201
Slide 45
Total update of a
set-valued variable
var Students as Set of String = {}
Main()
step
WriteLine (“The initial roster is = ” + Students)
Students := {“Bill”, “Carol”, “Ted”, “Alice”}
step
WriteLine (“The final roster is = ” + Students)
1.
2.
3.
The variable Students was, initially, an empty set
It was then updated to contain the names of the four
students
Update became visible in the second step as the finial
roster
Software Engineering, COMP201
Slide 46
Partial update of a
set-valued variable
var Students as Set of String = {}
Main()
step
WriteLine (“The initial roster is = ” + Students)
Students(“Bill”) := true
Students(“Carol”) := true
Students(“Ted”) := true
Students(“Alice”) := true
step
WriteLine (“The final roster is = ” + Students)



“ X : = val ” is update operation
If X ends with an index form, then the update is partial
If X ends with a variable name, then the update is total
Software Engineering, COMP201
Slide 47
Updating a set-valued variable
var Students as Set of String = {}
Main()
step
WriteLine (“The initial roster is = ” + Students) Students := {“Bill”, “Carol”,
“Ted”, “Alice”}
step
WriteLine (“The current roster is = ” + Students)
Students ( “Bill”) := false
// ( * )
step
WriteLine (“The final roster is = ” + Students)


Updating the set Students with updating statement (*)
removes “Bill ” from the set
The update is partial in the sense that other students may be
added to the set Students in the same step without
contradiction
Software Engineering, COMP201
Slide 48
Descargar

Formal Specification - University of Liverpool