University of Toronto
Department of Computer Science
➜
involves modeling and analysis
with an underlying mathematically-precise notation
Why use FM?
➜
Program Specification vs. Reqts Modeling
➜
Example Formal Methods:
➜
Narrow View (Wing)
Use of a formal language
a set of strings over some well-defined alphabet, with rules for distinguishing
which strings belong to the language
Formal reasoning about formulae in the language
RSML
E.g. formal proofs: use axioms and proof rules to demonstrate that some formula
is in the language
SCR
RML
➜
Telos
Albert II
For requirements modeling…
A notation is formal if:
…it comes with a formal set of rules which define its syntax and semantics.
…the rules can be used to analyse expressions to determine if they are
syntactically well-formed or to prove properties about them.
Tips on formal modeling
© 2001, Steve Easterbrook
University of Toronto
Broad View (Leveson)
application of discrete mathematics to software engineering
Formal Modeling Techniques
Definition of FM
➜
1
© 2001, Steve Easterbrook
Department of Computer Science
➜
models of requirements knowledge (so we can reason about them)
specifications of requirements (so we can document them precisely)
Specifications of program design (so we can verify correctness)
Removes
Removesambiguity
ambiguityand
andimproves
improvesprecision
precision
To
Toverify
verifythat
thatthe
therequirements
requirementshave
have
been
met
been met
To
Toreason
reasonabout
aboutthe
therequirements/designs
requirements/designs
Properties
Propertiescan
canbe
bechecked
checked
automatically
automatically
Test
for
consistency,
Test for consistency,explore
explore
consequences,
consequences,etc.
etc.
To
Toanimate/execute
animate/executespecifications
specifications
Helps
Helpswith
withvisualization
visualizationand
andvalidation
validation
…because
…becausewe
wehave
haveto
toformalize
formalizeeventually
eventually
anyway
anyway
Need
Needto
tobridge
bridgefrom
fromthe
theinformal
informal
world
worldto
toaaformal
formalmachine
machinedomain
domain
© 2001, Steve Easterbrook
Department of Computer Science
Varieties of formal analysis
What to formalize?
Why
Why formalize?
formalize?
2
University of Toronto
Formal Methods in Software Engineering
➜
Department of Computer Science
What are Formal Methods?
Lecture 17:
Formal Modeling Methods
➜
University of Toronto
Consistency analysis and typechecking
“Is the formal model well-formed?”
Assumes “well-formedness” of the model corresponds to something useful…
➜
Why
Why people
people don’t
don’t formalize!
formalize!
Validation:
Animate the model on small examples
Formal challenges:
Formal
FormalMethods
Methodstend
tendto
tobe
belower
lowerlevel
level
than
thanother
othertechniques
techniques
They
include
too
much
detail
They include too much detail
Formal
FormalMethods
Methodsconcentrate
concentrateon
on
consistent,
consistent,correct
correctmodels
models
…most
…mostof
ofthe
thetime
timeyour
yourmodels
modelsare
are
inconsistent,
inconsistent,incorrect,
incorrect,incomplete…
incomplete…
People
get
confused
about
which
tools
People get confused about which tools
are
areappropriate:
appropriate:
specification
specificationof
ofprogram
programbehaviour
behaviour
vs.
vs.modeling
modelingof
ofrequirements
requirements
formal
formalmethods
methodsadvocates
advocatesget
gettoo
too
attached
attachedto
toone
onetool!
tool!
Formal
methods
require
more
effort
Formal methods require more effort
...and
...andthe
thepayoff
payoffisisdeferred
deferred
“if the model is correct then the following property should hold...”
‘what if’ questions:
reasoning about the consequences of particular requirements;
reasoning about the effect of possible changes
➜
Predicting behavior
State exploration (E.g. through model checking)
Checking application properties:
“will the system ever do the following...”
➜
Verifying design refinement
“does the design meet the requirements?”
3
© 2001, Steve Easterbrook
4
Department of Computer Science
University of Toronto
Three traditions …
Formal Specification Languages
Grew out of work on program verification
Spawned many general purpose specification languages
Good for specifying the behaviour of program units
Key technologies: Type checking, Theorem proving
Reactive System Modelling
Formalizes dynamic models of system behaviour
Good for reactive systems (e.g. real-time,
embedded control systems)
can reason about safety, liveness, performance(?)
Key technologies: Consistency checking, Model checking
Formal Conceptual Modelling
For capturing real-world knowledge in RE
Focuses on modelling domain entities, activities,
agents, assertions, goals,…
use first order predicate logic as the underlying formalism
Key technologies: inference engines, default reasoning,
KBS-shells
(1) Formal Specification Languages
Applicable
Applicable to
to program
program design
design
➜
closely
closelytied
tiedto
toprogram
program
semantics
semantics
Examples:
Larch,
Z,
Examples: Larch, Z,VDM,
VDM,……
good for rapid prototyping
e.g., Lisp, Prolog, Smalltalk
State-based - views a program as a (large) data structures whose state
can be altered by procedure calls…
… using pre/post-conditions to specify the effect of procedures
e.g., VDM, Z
Languages
Languagesdeveloped
developed
specifically
specificallyfor
forRE
RE
Examples:
Examples:Statecharts,
Statecharts,RSML,
RSML,
Parnas-tables,
Parnas-tables,SCR,
SCR,……
Algebraic - views a program as a set of abstract data structures with a set
of operations…
… operations are defined declaratively by giving a set of axioms
e.g., Larch, CLEAR, OBJ
➜
Applicable
Applicable to
to Requirements
Requirements
… and can be modeled precisely in terms of input-output behaviour
These languages are NOT appropriate for requirements modeling
requirements specification
Department of Computer Science
University of Toronto
➜
➜
General approach
build models of humans’ knowledge/beliefs about the world
draws on techniques from AI and Knowledge Representation
the environment as a state machine
the system as a state machine
safety, liveness properties of the machine as temporal logic assertions
whether the properties hold of the system interacting with its environment
make use of abstraction & refinement as structuring primitives
➜
Examples:
Examples:
RML - Requirements Modeling Language
Statecharts
Harel’s notation for modeling large systems
Adds parallelism, decomposition and conditional transitions to STDs
RSML
Heimdahl & Leveson’s Requirements State Machine Language
Adds tabular specification of complex conditions to Statecharts
Developed by Greenspan & Mylopoulos in mid-1980s
First major attempt to use knowledge representation techniques in RE
Object oriented language, with classes for activities, entities and assertions
Uses First Order Predicate Language as an underlying reasoning engine
Telos
Extends RML by creating a fully extensible ontology
meta-level classes define the ontology (the basic set is built in)
A7e approach
Major project led by Parnas to formalize A7e aircraft requirements spec
Uses tables to specify transition relations & outputs
Albert II
developed by Dubois & du Bois in the mid-1990s
Models a set of interacting agents that perform actions that change their state
uses an object-oriented real-time temporal logic for reasoning
SCR
Heitmeyer et. al. “Software Cost Reduction”
Extends the A7e approach to include dictionaries & support tables
© 2001, Steve Easterbrook
Department of Computer Science
model the world beyond software functions
General approach:
Model
Model
Model
Check
6
(3) Formal Conceptual Modelling
Modeling how a system should behave
program specification
© 2001, Steve Easterbrook
(2) Reactive System Modelling
➜
Developed for specifying programs
Programs are formal, man-made objects
Capture
Capturekey
keyrequirements
requirements
concepts
concepts
Examples:
Examples:Reqts
ReqtsApprentice,
Apprentice,
RML,
RML,Telos,
Telos,Albert
AlbertII,
II,……
5
University of Toronto
Three basic flavours:
Operational - specification is executable abstraction of the implementation
Applicable
Applicable to
to Requirements
Requirements
© 2001, Steve Easterbrook
Department of Computer Science
University of Toronto
7
© 2001, Steve Easterbrook
8
Department of Computer Science
University of Toronto
Example: SCR
SCR basics
Source: Adapted from Heitmeyer et. al. 1996.
Four Variable Model:
➜
System
ment
variables
items
Transitions in each mode class are triggered by events
Controlled Environment
variables
items
Complex systems are described using a number of mode classes operating in
parallel
➜
Dictionaries:
Monitored/Controlled
Variables
Variable
WarningFlag
OtherFlag
Fudgelevel
Waterlevel
temperature
BlipCounter
TimeNow
AirBrakeAcc
Type
boolean
boolean
enumerated
real
real
integer
real
real
Initial Value
false
true
one
0.0
0.0
0
100.0
0.0
Units
-
m
degrees C
miles
sec
m/sec
Types
Type
WarningLevel
BaseType
enumerated
Values
low,med,high
Units
-
Temperature
Waterlevel
Flag
integer
integer
enumerated
-100..100
0..100
on, off
degrees C
meters
-
Constants
Constant
LowTemp
HighTemp
MaxTimeOut
ReferenceSafetyLevel
TempMargin
Type
integer
integer
integer
safetytype
integer
Value
15
23
300
low
5
Modes and Mode classes
A mode class is a finite state machine, with states called system modes
Input Input
Output
software Output
devices data
data devices
Environ- Monitored
Tables:
Mode Transition Tables
Current Powered Too Cold Temp OK Too Hot New Mode
Mode
on
Off
@T Powered - Too Cold t Temp OK- TooInactive
Current
Hot New Mode
Heat
Mode@T on t
@T @T
tOK AC
Off Current
- Cold
t
- Hot
Inactive
Powered
Too
Temp
Too
New Mode
Inactive Mode
@F @TonOff
t
Heat
@T
Heat
@T@T
- - - tt - ACInactive
Off AC
Inactive @F@T- t - -@T
- - OffHeat
Heat
@F
Off
- @T@T - - -- t Heat
AC
Inactive
- @F- -@T
- -@T
Inactive
- ACOff
AC Heat @F @F - Off
- @T- -- - OffHeat
Inactive
- -- -@T @T - - @T Inactive
AC
Timeout
@F@F
- - - - NoOff
Failure
Heat
- f f @T
@T - ACFailure
Inactive
AC
@F
Off
@T
Inactive
Event Tables
Modes
Events
NoFailure
@T(INMODE)
never
Modes
Events
SensorFail
@T(reset=on) @T(INMODE)
NoFailure
@T(INMODE)
never
Timeout
never
Modes always
Events
Blah
@T(thingy)
@T(other)
ACFailure, HeatFailure
never @T(INMODE)
@T(INMODE) never
NoFailure
Doodah
never
always
Warning light
=
Off
On
Blah
@T(thingy)
@T(other)
ACFailure, HeatFailure
never
@T(INMODE)
Doodah
never
always
Heater =
Off
On
ACFailure, HeatFailure
never
@T(INMODE)
ACpower =
Off
System State
A (system) state is defined as:
also:
Assertions,
Scenarios,
...
the system is in exactly one mode from each mode class…
…and each variable has a unique value
➜
Events
An event occurs when any system entity changes value
An input event occurs when an input variable changes value
Single input assumption - only one input event can occur at once
Notation: @T(c) means “c changed from false to true”
On
Condition Tables
Modes
NoFailure
ACFailure Modes
HeatFailure
NoFailure
Warning light =
Units
degrees C
degrees C
millisec
degrees C
Events
true
false
temp > temp0 temp
<= temp0
Events
false false waterlevel =low
true
Off
On
ACFailure, HeatFailure
true
false
Buzzer =
Off
On
A conditioned event is an event with a predicate
@T(c) WHEN d means: “c became true when c was false and d was true”
SCR Specification
© 2001, Steve Easterbrook
9
Department of Computer Science
University of Toronto
© 2001, Steve Easterbrook
SCR Tables
Source: Adapted from Heitmeyer et. al. 1996.
Mode Class Tables
Mode transition table:
Current
Mode
Off
A complex system will have many different modes classes
Each mode class has a mode table showing the conditions that cause transitions
between modes
A mode table defines a partial function from modes and events to modes
Event Tables
Inactive
An event table defines how a term or controlled variable changes in
response to input events
Defines a partial function from modes and events to variable values
➜
Heat
Condition Tables
A condition table defines the value of a term or controlled variable under
every possible condition
AC
Defines a total function from modes and conditions to variable values
© 2001, Steve Easterbrook
Department of Computer Science
Example: Temp Control System
Define the set of modes (states) that the software can be in.
➜
10
University of Toronto
Source: Adapted from Heitmeyer et. al. 1996.
➜
Department of Computer Science
University of Toronto
11
Powered
on
@T
@T
@T
@F
@F
@F
-
© 2001, Steve Easterbrook
Too Cold
Temp OK
Too Hot
t
@T
-
t
@T
@T
t
@T
-
New Mode
Inactive
Heat
AC
Off
Heat
AC
Off
Inactive
Off
Inactive
12
Department of Computer Science
University of Toronto
University of Toronto
Failure modes
Using Formal Methods
Source: Adapted from Heitmeyer et. al. 1996.
Mode transition table:
Current
Mode
➜
Powered Cold Too Warm
on
Heater Cold
AC
NoFailure
HeatFailure
ACFailure
t
t
t
t
@T
@F
-
t
t
-
@T
@F
Department of Computer Science
Too
Hot
t
t
Selective use of Formal Methods
Amount of formality can vary
New
Mode
Need not build complete formal models
Apply to the most critical pieces
Apply where existing analysis techniques are weak
HeatFailure
ACFailure
NoFailure
NoFailure
Need not formally analyze every system property
E.g. check safety properties only
Need not apply FM in every phase of development
E.g. use for modeling requirements, but don’t formalize the system design
Can choose what level of abstraction (amount of detail) to model
Event table:
Modes
NoFailure
ACFailure, HeatFailure
Warning light =
➜
@T(INMODE)
never
never
@T(INMODE)
Off
On
© 2001, Steve Easterbrook
Have become popular as a means of getting the technology transferred
Two approaches
Lightweight use of FMs - selectively apply FMs for partial modeling
Lightweight FMs - new methods that allow unevaluated predicates
13
Department of Computer Science
University of Toronto
References
van Vliet, H. “Software Engineering: Principles and Practice (2nd Edition)” Wiley,
1999.
van Vliet gives a good introduction to formal methods in chapter 15. In particular, sections 15.1 and
15.5 are worth reading, to give a feel for the current state of the art, and the problems that hinder
the use of formal methods in practice. van Vliet describes a completely different set of formal modeling
techniques from those covered in this lecture – he concentrates on methods that can be used for
program design models, rather than requirements models.
Heitmeyer, C. L., Jeffords, R. D., & Labaw, B. G. (1996). Automated
Consistency Checking of Requirements Specifications. ACM Transactions on
Software Engineering and Methodology, 5(3), 231-261.
Describes SCR in detail.
© 2001, Steve Easterbrook
Lightweight Formal Methods
15
© 2001, Steve Easterbrook
14