View
2
Download
0
Category
Preview:
Citation preview
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
Recommended