SOFT 423: Software Requirementscourses.caslab.queensu.ca/.../8/2014/09/423_W5_C3.pdf · 3. Formal...

SOFT 423: Software Requirements

Week 5 Class 3

Formal Methods

SOFT 423 – Winter 2015 1

Last Class

•Writing Requirements

•Modeling Techniques


This Class

•Formal Methods


Formal Methods

•Some overlap with 422

•SA and OOA are semi-formal models •text/diagrams/tables and simple notation

•mathematically formal syntax and semantics •Z, VDM, ALLOY


Formal Methods

•Provide a means of achieving a high degree of confidence that the system will conform to its specification

•Do not guarantee correctness

•Do not provide much for software management


Formal Method Language Components

•Syntax that defines the specific notation

•Semantics that define a universe of objects that are used to describe the system

•Relations which define the rules that indicate which objects properly satisfy the specification


Formal Methods

•Formal methods are not widely used •This should probably change


Formal Methods

•Factors contributing to slow acceptance: •difficulty in understanding •some aspects of requirements cannot be formalized easily •conservative management and non-obvious payoff


Advantages of Formal Methods

•Removes Ambiguity

•Encourages greater rigour in early stages

•Possible to verify the correctness, incompleteness and inconsistency of the specification


Disadvantages of Formal Methods

•Some requirements can only be determined through empirical evaluation and prototyping •Does not address the problem of how requirements are constructed •Some formal methods do not have adequate tool support (Z vs alloy).


Formal Methods in RE [Easterbrook]

•What to formalize in RE •models of requirements knowledge

• so we can reason about them

•specifications of requirements • so can document precisely



•Why formalize in RE •remove ambiguity •provide basis for verification that requirements have been met •will have to formalize eventually

• RE is all about bridging from the informal world to a formal machine domain



•Why people don’t formalize in RE •Formal methods tend to be lower level that other analysis techniques

•force you to include too much detail •Formal Methods tend to concentrate on consistent correct models



•but most of the time your models are inconsistent, incorrect and incomplete. •Confusion over which tools are appropriate

•modeling behaviour vs modeling the requirements •Formal methods require more effort



•For requirements, a notation is formal if: •formal set of rules for syntax and semantics •rules can be used to analyze expressions for well-formedness and to prove properties


Three Traditions [Easterbrook]

1. Formal Specification Languages •grew out of work on program verification •Key Technologies: type checking and theorem proving • Examples: Z, VDM

•Poor applicability to RE • minimal abstraction, closely tied to program semantics



2. Reactive System Modeling •grew out of a need to capture dynamic models of system behaviour •focus on reactive systems

• real-time, embedded • Examples: StateCharts, RSML, SCR

•designed specifically for RE



3. Formal Conceptual Modeling •grew out of a need to capture real world knowledge •focus on modeling domain entities, activities •Examples: RML, Telos •Excellent for RE



3. Formal Conceptual Modeling •model the world beyond functional specifications • specification is prescription concentrating on desired

properties of the machine • also need to capture an understanding of application

domain • build model of human’s knowledge/belief about the

world

•first order predicate logic


Reactive System Modeling [Easterbrook]

•Model how a system should behave •model environment as a state machine •Model the system as a state machine



•Statecharts (Harel) •parallelism, decomposition & conditional transitions

•RSML •Heimdahl & Leveson •Requirements State Machine Language •Adds Tabular Specs & Complex Conditions



•Parnas Tables (A7e requirements spec) •Tables to specify transition and outputs

•Software Cost Reduction (SCR) •extends Parnas Tables to include dictionaries & support tables


Finite State Machines Reactive System Modeling – Detailed Exploration


Finite State Machines

•Model behaviour of solution system • input and state to output •do not impose a modularization on the system •relatively implementation free

•Form •set of states •change from one state to another in response

to external stimulus (trigger) •usually (but not always) deterministic



•Bray Text discusses several notations •puts outputs(actions) in rectangles


Trigger Actions

State Transition Diagram


idle

busy

dial

tone ringing cnctd

on hook

dial idle number

callee on hook

off hook

on hook on hook

on hook

callee off hook

dial busy number

start busy sig

start ring sig

connect

disconnect

disconnect

start tone

Rules and Guidelines

•transitions start and end at a state

•each transition has one associated trigger

•each transition may have one or more actions

•same trigger can be used for more than one state


Rules and Guidelines

•If state has no incoming transitions it is unreachable

•If no outgoing transitions, un-leave-able •Otherwise known as an final state

•often continuous •models a system with infrequent starts and stops


Other Issues

•Finite state machines are ‘flat’ •usually drawn to minimize crossing lines •limits complexity of model •can sometimes partition diagram into somewhat independent machines with transitions between the machines • Loss of total information, however


Other Issues

•Each state is a state of the whole system being specified •No structure

•A system is in one state at a time •requires a trigger to change state

•Good for Event Driven Systems


Other Issues

•Traditional non-determinism is of limited use in requirements •Only some domains use non-determinism


Other Issues

•Bray Text version of non-determinism is to incorporate a decision (choice) into a transition


Other Issues

•State reduction technique •extra variables (increases real state) •e.g. state machine for pop-machine, coin adds to total, is total enough? •don’t need a state for each possible current total


State Machine Timers

•Timers •allow finite state machines to react to time as well as external stimuli •model timeouts or communication delays •setting timer is an action •timer expiration is a trigger


State Transition Diagram – with Timer


idle

busy

dial tone ringing cnctd

on hook

dial idle number

callee on hook

off hook

on hook on hook

on hook

callee off

hook

dial busy number

set tmr1

on hook

tmr1

expires

Alert

start alert tone

Concurrency

•Concurrent Machines •single state is limiting and can lead to very complex diagrams •sometimes better to model as two or more separate machines that communicate •action in one machine is a trigger in another machine


Concurrency Examples

•Microwave oven •state machine for display and keyboard, concurrent state machine for cooking control and temperature probe

•Games •states for each of the NPC characters in the game


Concurrency Examples

•Communication Protocols •TCP protocol stack is modelled as two communicating state machines

•Automotive Control Systems •Emissions, injection control, ignition timing



•Mealy Machine •action is associated with transition •these are the examples shown in class

•Moore Machine •action is associated with the state

•Both are useable for specification of system and environment behaviour


State Transition Matrices

•State diagrams may become very complex and difficult to understand


State Transition Matrices

•Solution: Transition Matrices •tabular form •rows represent states •columns represent triggers •cells contain next state •Moore -> extra column for actions •Mealy -> put actions in cells with next state


Example State Transition Diagram


idle

busy

dial

tone ringing cnctd

on hook

dial idle number

callee on hook

off hook

on hook on hook

on hook

callee off hook

dial busy number

start busy sig

start ring sig

connect

disconnect

disconnect

start tone

Example State Transition Matrix

State off hook

on hook

dial busy

dial idle callee off hook

Callee on hook

1. Idle 2. [ST]

2. Dial Tone 1. 3. [SBS]

4. [SRS]

3. Busy 1.

4. Ringing 1. 5. [Con]

5. Connected 1. [DC]

2. [DC]


Actions ST = start tone SBS = start busy signal SRS = start ring signal Con = connect DC = disconnect

Diagrams vs. Matrices

•few transitions from each individual state •sparse matrix, lots of wasted space •diagrams are better (fewer arrows)

•many transitions from individual states •cluttered diagram •filled matrix •tables better


Test 2


Test 2 Details

•Wednesday, February 11, 2015 •2:30pm

•Time: 40 minutes (by request from last test)

•No lecture after class


Test 2 Details

•Cover material from W3C3 until W6C1 •Including Monday’s lecture

•Format •Similar to Test 1 •Short Answer Definition Questions •Application Questions


Test 2 Details

•Topics: •Modeling •Data Flow and Data Modeling •Structured Analysis •Data Dictionaries •Relational and ER Models •Object Oriented Analysis and Modeling •Problem Domain Oriented Analysis


Test 2 Details

•Topics: •Personas •Interactive Systems •Writing Requirements •Modeling Techniques •Formal Methods

• State Transition Diagrams • State Transition Matrices

•Statecharts (Monday)


Next Class

•Statecharts

•Introduce Assignment 2


SOFT 423: Software Requirementscourses.caslab.queensu.ca/.../8/2014/09/423_W5_C3.pdf · 3. Formal...

Documents

Transcript of SOFT 423: Software Requirementscourses.caslab.queensu.ca/.../8/2014/09/423_W5_C3.pdf · 3. Formal...