0% found this document useful (0 votes)
39 views4 pages

Week 03a-FormalModeling

Copyright
© © All Rights Reserved
We take content rights seriously. If you suspect this is your content, claim it here.
Available Formats
Download as PDF, TXT or read online on Scribd
0% found this document useful (0 votes)
39 views4 pages

Week 03a-FormalModeling

Copyright
© © All Rights Reserved
We take content rights seriously. If you suspect this is your content, claim it here.
Available Formats
Download as PDF, TXT or read online on Scribd
You are on page 1/ 4

University of Toronto Department of Computer Science University of Toronto Department of Computer Science

Lecture 17: What are Formal Methods?


Formal Modeling Methods ➜ Broad View (Leveson)
 application of discrete mathematics to software engineering
➜ Formal Modeling Techniques  involves modeling and analysis
 Definition of FM  with an underlying mathematically-precise notation
 Why use FM?
➜ Narrow View (Wing)
➜ Program Specification vs. Reqts Modeling  Use of a formal language
 a set of strings over some well-defined alphabet, with rules for distinguishing
➜ Example Formal Methods: which strings belong to the language

 RSML  Formal reasoning about formulae in the language


 E.g. formal proofs: use axioms and proof rules to demonstrate that some formula
 SCR
is in the language
 RML
 Telos ➜ For requirements modeling…
 Albert II  A notation is formal if:
 …it comes with a formal set of rules which define its syntax and semantics.
➜ Tips on formal modeling  …the rules can be used to analyse expressions to determine if they are
syntactically well-formed or to prove properties about them.

© 2001, Steve Easterbrook 1 © 2001, Steve Easterbrook 2

University of Toronto Department of Computer Science University of Toronto Department of Computer Science

Formal Methods in Software Engineering Varieties of formal analysis


➜ What to formalize? ➜ Consistency analysis and typechecking
 models of requirements knowledge (so we can reason about them)  “Is the formal model well-formed?”
 specifications of requirements (so we can document them precisely)  Assumes “well-formedness” of the model corresponds to something useful…
 Specifications of program design (so we can verify correctness)
➜ Validation:
Why
Why formalize?
formalize? Why
Why people
people don’t
don’t formalize!
formalize!  Animate the model on small examples
Removes
Removesambiguity
ambiguityandandimproves
improvesprecision
precision FormalMethods
Formal Methodstend
tendtotobe belower
lowerlevel
level  Formal challenges:
To than
thanother
othertechniques
Toverify
verifythat
thatthe
therequirements
requirementshave
have techniques
 “if the model is correct then the following property should hold...”
been met
been met They include too much detail
They include too much detail
 ‘what if’ questions:
To
Toreason
reasonabout
aboutthe
therequirements/designs
requirements/designs FormalMethods
Formal Methodsconcentrate
concentrateon on
Properties consistent,
consistent,correct
correctmodels  reasoning about the consequences of particular requirements;
Propertiescan
canbebechecked
checked models
automatically
automatically …most
…mostof ofthe
thetime
timeyour
yourmodels
modelsare
are  reasoning about the effect of possible changes
Test inconsistent,
inconsistent,incorrect,
incorrect,incomplete…
Test for consistency,explore
for consistency, explore incomplete…
consequences,
consequences,etc.
etc. People get confused about which
People get confused about which tools
are
tools ➜ Predicting behavior
To
Toanimate/execute
animate/executespecifications
specifications areappropriate:
appropriate:
specification  State exploration (E.g. through model checking)
Helps
Helpswith
withvisualization
visualizationand
andvalidation
validation specificationofofprogram
programbehaviour
behaviour
…because vs.
vs.modeling
modelingof ofrequirements  Checking application properties:
…becausewe wehave
havetotoformalize
formalizeeventually
eventually requirements
anyway formal
formalmethods
methodsadvocates
advocatesget gettoo
too  “will the system ever do the following...”
anyway
Need attached
attachedto toone
onetool!
Needto tobridge
bridgefrom
fromthetheinformal
informal tool!
world
worldtotoaaformal
formalmachine
machinedomain
domain
Formal methods require more
Formal methods require more effort
...and
effort
➜ Verifying design refinement
...andthe
thepayoff
payoffisisdeferred
deferred
 “does the design meet the requirements?”
© 2001, Steve Easterbrook 3 © 2001, Steve Easterbrook 4
University of Toronto Department of Computer Science University of Toronto Department of Computer Science

Three traditions … (1) Formal Specification Languages


Formal Specification Languages Applicable
Applicable to
to program
program design
design ➜ Three basic flavours:
 Grew out of work on program verification  closely
closelytied
tiedto
toprogram
program
 Spawned many general purpose specification languages semantics  Operational - specification is executable abstraction of the implementation
semantics
Examples:  good for rapid prototyping
 Good for specifying the behaviour of program units Examples: Larch, Z,VDM,
Larch, Z, VDM,……
 Key technologies: Type checking, Theorem proving  e.g., Lisp, Prolog, Smalltalk
 State-based - views a program as a (large) data structures whose state
Reactive System Modelling can be altered by procedure calls…
Applicable
Applicable to
to Requirements
Requirements  … using pre/post-conditions to specify the effect of procedures
 Formalizes dynamic models of system behaviour  Languages
Languagesdeveloped
developed  e.g., VDM, Z
 Good for reactive systems (e.g. real-time, specifically
specificallyfor
forRE
RE  Algebraic - views a program as a set of abstract data structures with a set
embedded control systems) Examples:
Examples:Statecharts,
Statecharts,RSML,
RSML, of operations…
 can reason about safety, liveness, performance(?) Parnas-tables,
Parnas-tables,SCR,
SCR,……  … operations are defined declaratively by giving a set of axioms
 Key technologies: Consistency checking, Model checking
 e.g., Larch, CLEAR, OBJ
Formal Conceptual Modelling
Applicable ➜ Developed for specifying programs
 For capturing real-world knowledge in RE Applicable to
to Requirements
Requirements
 Focuses on modelling domain entities, activities,  Capture
Capturekey
keyrequirements
requirements  Programs are formal, man-made objects
agents, assertions, goals,… concepts
concepts  … and can be modeled precisely in terms of input-output behaviour
 use first order predicate logic as the underlying formalism Examples:
Examples:Reqts
ReqtsApprentice,
Apprentice,  These languages are NOT appropriate for requirements modeling
RML,
RML,Telos,
Telos,Albert
AlbertII,
II,……
 Key technologies: inference engines, default reasoning,  requirements specification program specification
KBS-shells

© 2001, Steve Easterbrook 5 © 2001, Steve Easterbrook 6

University of Toronto Department of Computer Science University of Toronto Department of Computer Science

(2) Reactive System Modelling (3) Formal Conceptual Modelling


➜ Modeling how a system should behave ➜ General approach
 General approach:  model the world beyond software functions
 Model the environment as a state machine  build models of humans’ knowledge/beliefs about the world
 Model the system as a state machine  draws on techniques from AI and Knowledge Representation
 Model safety, liveness properties of the machine as temporal logic assertions  make use of abstraction & refinement as structuring primitives
 Check whether the properties hold of the system interacting with its environment
➜ Examples:
➜ Examples:
 RML - Requirements Modeling Language
 Statecharts  Developed by Greenspan & Mylopoulos in mid-1980s
 Harel’s notation for modeling large systems
 First major attempt to use knowledge representation techniques in RE
 Adds parallelism, decomposition and conditional transitions to STDs
 Object oriented language, with classes for activities, entities and assertions
 RSML  Uses First Order Predicate Language as an underlying reasoning engine
 Heimdahl & Leveson’s Requirements State Machine Language
 Adds tabular specification of complex conditions to Statecharts
 Telos
 Extends RML by creating a fully extensible ontology
 A7e approach
 meta-level classes define the ontology (the basic set is built in)
 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
 SCR
 Heitmeyer et. al. “Software Cost Reduction”  Models a set of interacting agents that perform actions that change their state
 Extends the A7e approach to include dictionaries & support tables  uses an object-oriented real-time temporal logic for reasoning
© 2001, Steve Easterbrook 7 © 2001, Steve Easterbrook 8
University of Toronto Department of Computer Science University of Toronto Department of Computer Science

Example: SCR SCR basics


Source: Adapted from Heitmeyer et. al. 1996.
Four Variable Model:
➜ Modes and Mode classes
System
 A mode class is a finite state machine, with states called system modes
 Transitions in each mode class are triggered by events
Environ- Monitored Input Input Output Controlled Environ-
software Output  Complex systems are described using a number of mode classes operating in
ment variables devices data data devices variables ment
items items
parallel

➜ System State
Dictionaries: Tables: also:  A (system) state is defined as:
Assertions,  the system is in exactly one mode from each mode class…
Monitored/Controlled Mode Transition Tables
Variables Current Powered Too Cold Temp OK Too Hot New Mode
Scenarios,  …and each variable has a unique value
Mode on
Event Tables
...
Variable Type Initial Value Units Off @T Powered - Too Cold t Temp OK- TooInactive
Current Hot New Mode
WarningFlag boolean false - Mode@T on t - - Heat

Events
OtherFlag boolean true @T @T
Off Current -
Powered - Cold
Too - t
Temp tOK AC
- Hot
Too Inactive
New Mode Modes Events


Fudgelevel enumerated one - Inactive Mode @F @Ton- t - - - Off
- Heat
NoFailure @T(INMODE) never
Waterlevel real 0.0 m Off - @T@T@T - - - - t- Heat
t - ACInactive Modes Events
temperature real 0.0 degrees C Inactive - @F@T- - t - - -@T AC
- - OffHeat SensorFail @T(reset=on) @T(INMODE)
BlipCounter integer 0 miles Heat @F - @T- @T - - - -- Off
- t Heat NoFailure @T(INMODE) never
AC Timeout Modes always never
Events
TimeNow real 100.0 sec -
Inactive - @F- - -@T - -- Inactive
@T - ACOff Blah @T(thingy) @T(other)
ACFailure, HeatFailure never @T(INMODE)
@T(INMODE) never

 An event occurs when any system entity changes value


AirBrakeAcc real 0.0 m/sec AC Heat @F @F - - - @T- - -- Off
- - OffHeat NoFailure
Doodah never always
- - -- - -@T @T - - Inactive
- @T Inactive
AC Warning light =
Blah Off On
@T(thingy) @T(other)
ACFailure, HeatFailure never @T(INMODE)

Types
Timeout
Heat @F@F - - - - - - NoOff Failure Doodah never always
- - f - f @T @T - ACFailure
Inactive Heater = Off On

 An input event occurs when an input variable changes value


ACFailure, HeatFailure never @T(INMODE)
AC @F - - - Off
- - @T - Inactive ACpower = Off On
Type BaseType Values Units
WarningLevel enumerated low,med,high -

 Single input assumption - only one input event can occur at once
Temperature integer -100..100 degrees C
Waterlevel integer 0..100 meters
Flag enumerated on, off -

Condition Tables  Notation: @T(c) means “c changed from false to true”


Constants Modes Events

 A conditioned event is an event with a predicate


Constant Type Value Units NoFailure true false
LowTemp integer 15 degrees C ACFailure Modes temp > temp0 temp <= temp0
Events
HighTemp integer 23 degrees C HeatFailure
NoFailure false false waterlevel =low
true
MaxTimeOut integer 300 millisec Warning light = Off On

 @T(c) WHEN d means: “c became true when c was false and d was true”
ACFailure, HeatFailure true false
ReferenceSafetyLevel safetytype low -

SCR Specification
TempMargin integer 5 degrees C Buzzer = Off On

© 2001, Steve Easterbrook 9 © 2001, Steve Easterbrook 10

University of Toronto Department of Computer Science University of Toronto Department of Computer Science

SCR Tables Example: Temp Control System


Source: Adapted from Heitmeyer et. al. 1996. Source: Adapted from Heitmeyer et. al. 1996.

➜ Mode Class Tables Mode transition table:


 Define the set of modes (states) that the software can be in.
 A complex system will have many different modes classes Current Powered Too Cold Temp OK Too Hot New Mode
 Each mode class has a mode table showing the conditions that cause transitions Mode on
between modes
Off @T - t - Inactive
 A mode table defines a partial function from modes and events to modes
@T t - - Heat
➜ Event Tables @T - - t AC
 An event table defines how a term or controlled variable changes in Inactive @F - - - Off
response to input events - @T - - Heat
 Defines a partial function from modes and events to variable values - - - @T AC
➜ Condition Tables Heat @F - - - Off
 A condition table defines the value of a term or controlled variable under - - @T - Inactive
every possible condition AC @F - - - Off
 Defines a total function from modes and conditions to variable values - - @T - Inactive

© 2001, Steve Easterbrook 11 © 2001, Steve Easterbrook 12


University of Toronto Department of Computer Science University of Toronto Department of Computer Science

Failure modes Using Formal Methods


Source: Adapted from Heitmeyer et. al. 1996.

Mode transition table: ➜ Selective use of Formal Methods


 Amount of formality can vary
Current Powered Cold Too Warm Too New
Mode on Heater Cold AC Hot Mode  Need not build complete formal models
 Apply to the most critical pieces
NoFailure t @T t - - HeatFailure
 Apply where existing analysis techniques are weak
t - - @T t ACFailure
HeatFailure t @F t - - NoFailure  Need not formally analyze every system property
 E.g. check safety properties only
ACFailure t - - @F t NoFailure
 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:
➜ Lightweight Formal Methods
Modes  Have become popular as a means of getting the technology transferred
NoFailure @T(INMODE) never  Two approaches
 Lightweight use of FMs - selectively apply FMs for partial modeling
ACFailure, HeatFailure never @T(INMODE)
 Lightweight FMs - new methods that allow unevaluated predicates
Warning light = Off On
© 2001, Steve Easterbrook 13 © 2001, Steve Easterbrook 14

University of Toronto Department of Computer Science

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 15

You might also like