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

SOFT 423 – Winter 2015 2

This Class

•Formal Methods

SOFT 423 – Winter 2015 3

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

SOFT 423 – Winter 2015 4

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

SOFT 423 – Winter 2015 5

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

SOFT 423 – Winter 2015 6

Formal Methods

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

SOFT 423 – Winter 2015 7

Formal Methods

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

SOFT 423 – Winter 2015 8

Advantages of Formal Methods

•Removes Ambiguity

•Encourages greater rigour in early stages

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

SOFT 423 – Winter 2015 9

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).

SOFT 423 – Winter 2015 10

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

SOFT 423 – Winter 2015 11

Formal Methods in RE [Easterbrook]

•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

SOFT 423 – Winter 2015 12

Formal Methods in RE [Easterbrook]

•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

SOFT 423 – Winter 2015 13

Formal Methods in RE [Easterbrook]

•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

SOFT 423 – Winter 2015 14

Formal Methods in RE [Easterbrook]

•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

SOFT 423 – Winter 2015 15

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

SOFT 423 – Winter 2015 16

Three Traditions [Easterbrook]

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

SOFT 423 – Winter 2015 17

Three Traditions [Easterbrook]

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

SOFT 423 – Winter 2015 18

Three Traditions [Easterbrook]

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

SOFT 423 – Winter 2015 19

Reactive System Modeling [Easterbrook]

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

SOFT 423 – Winter 2015 20

Reactive System Modeling [Easterbrook]

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

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

SOFT 423 – Winter 2015 21

Reactive System Modeling [Easterbrook]

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

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

SOFT 423 – Winter 2015 22

Finite State Machines Reactive System Modeling – Detailed Exploration

SOFT 423 – Winter 2015 23

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

SOFT 423 – Winter 2015 24

Finite State Machines

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

SOFT 423 – Winter 2015 25

Trigger Actions

State Transition Diagram

SOFT 423 – Winter 2015 26

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

SOFT 423 – Winter 2015 27

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

SOFT 423 – Winter 2015 28

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

SOFT 423 – Winter 2015 29

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

SOFT 423 – Winter 2015 30

Other Issues

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

SOFT 423 – Winter 2015 31

Other Issues

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

SOFT 423 – Winter 2015 32

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

SOFT 423 – Winter 2015 33

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

SOFT 423 – Winter 2015 34

State Transition Diagram – with Timer

SOFT 423 – Winter 2015 35

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

SOFT 423 – Winter 2015 36

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

SOFT 423 – Winter 2015 37

Concurrency Examples

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

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

SOFT 423 – Winter 2015 38

Finite State Machines

•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

SOFT 423 – Winter 2015 39

State Transition Matrices

•State diagrams may become very complex and difficult to understand

SOFT 423 – Winter 2015 40

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

SOFT 423 – Winter 2015 41

Example State Transition Diagram

SOFT 423 – Winter 2015 42

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]

SOFT 423 – Winter 2015 43

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

SOFT 423 – Winter 2015 44

Test 2

SOFT 423 – Winter 2015 45

Test 2 Details

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

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

•No lecture after class

SOFT 423 – Winter 2015 46

Test 2 Details

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

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

SOFT 423 – Winter 2015 47

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

SOFT 423 – Winter 2015 48

Test 2 Details

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

• State Transition Diagrams • State Transition Matrices

•Statecharts (Monday)

SOFT 423 – Winter 2015 49

Next Class

•Statecharts

•Introduce Assignment 2

SOFT 423 – Winter 2015 50