Lecture 17: Formal Modeling Methods What are Formal Methods ...

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


Broad View (Leveson) application of discrete mathematics to software engineering

Formal Modeling Techniques Definition of FM

➜

1



➜

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



Varieties of formal analysis

What to formalize?

Why Why formalize? formalize?

2


Formal Methods in Software Engineering ➜


What are Formal Methods?

Lecture 17: Formal Modeling Methods ➜


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


4



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



➜

➜

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



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


(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


Three basic flavours: Operational - specification is executable abstraction of the implementation

Applicable Applicable to to Requirements Requirements




7


8



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