Embed Size (px)
Citation preview
SOFT 423: Software Requirements
Week 7 Class 3
More on Decision Tables and Petri Nets
Wrap Up Formal Methods
SOFT 423 – Winter 2015 1
Last Class
•Decision Tables
•Petri Nets
SOFT 423 – Winter 2015 2
This Class
•Some More Examples•Decision Tables•Petri Nets
•Wrap Up Formal Methods
SOFT 423 – Winter 2015 3
Printer Troubleshooting –Limited Entry
SOFT 423 – Winter 2015 4
Source: http://en.wikipedia.org/wiki/Decision_table#Example
Admission Prices – Limited Entry
SOFT 423 – Winter 2015 5
Source: http://hsc.csu.edu.au/ipt/project_work/3287/decision_table.jpg
Source Code Variable Actions –Limited Entry
SOFT 423 – Winter 2015 6
Source: http://dtrules.com/wiki2/images/thumb/c/cd/SimpleBalancedDecisionTable.JPG/300px-SimpleBalancedDecisionTable.JPG
Automotive Insurance –Extended Entry
SOFT 423 – Winter 2015 7
Petri Net Simulator
•http://torguet.free.fr/java/Petri.html
•Simple Demo
SOFT 423 – Winter 2015 8
Team Exercises
•Break Into Teams•1 or 2 (or gather around a laptop/tablet)•Let each person try the tool
•Attempt to Construct the following challenges
SOFT 423 – Winter 2015 9
Implement the Simple Example
SOFT 423 – Winter 2015 10
Remember the choice?
How does yours behave?
Implement a Guard
•Prove that the Guard does what it should.
SOFT 423 – Winter 2015 11
Implement the OS Scheduler
SOFT 423 – Winter 2015 12
Ready Running
Timeout IO Request
IO Complete
Wait Queue
Show Me Something Cool
•Come up with something neat, complex, visually appealing, real-life modeling, etc.
SOFT 423 – Winter 2015 13
Wrapping Up Formal Methods
SOFT 423 – Winter 2015 14
Final Comments
•Selective use of Formal Methods•amount of formality can vary•need not build complete formal models
• apply to the most critical pieces• apply where existing techniques are weak
•need not formally analyze every system property• check safety properties only??
•need not apply FM in every phase• Requirements Engineering but not design
SOFT 423 – Winter 2015 15
Final Comments
•Lightweight Formal Methods•Two approaches:
• Lightweight use of FMs (partial modeling)• Lightweight FMs - new methods that allow
unevaluated predicates
SOFT 423 – Winter 2015 16
Wrapping up Requirements Methods
SOFT 423 – Winter 2015 17
Requirements Methods: Key Points
•No such thing as an ideal requirements method•all have strengths and weaknesses
•System model can be enriched by modeling different aspects of it using modeling techniques that capture and describe those aspects best
SOFT 423 – Winter 2015 18
Requirements Methods: Key Points
•The data-flow model is based on a set of interaction functions. DFDs are composed of inputs, transforming processes and data stores and outputs
•The OOA approach assumes that systems can be modeled as a set of interacting objects.
SOFT 423 – Winter 2015 19
Requirements Methods: Key Points
•Formal methods are based on mathematical principles. They are intended to achieve a high degree of confidence that a system will conform to its specifications
SOFT 423 – Winter 2015 20
Requirements Methods: Key Points
•informal/semi-formal/formal models do not model everything
•The models are part of the requirements•have to be connected to each other
• i.e. connect a OOA model to a Statechart model
•have to be connected back to the requirements document
SOFT 423 – Winter 2015 21
Now What?
SOFT 423 – Winter 2015 22
The Big Picture
•We have looked at Elicitation•How to get information.
•Then we looked at modeling•Data Flow and Relational (SA)•Object Oriented (OOA)•Problem Domain (PDOA)
SOFT 423 – Winter 2015 23
The Big Picture
•Then we stepped back and looked at writing the document itself
•Then we looked at formal methods:•State Transition Diagrams/Statecharts•SCR•Decision Tables•Petri Nets
SOFT 423 – Winter 2015 24
The Big Picture
•Now we will move on down the line•we have all of the information we can dream of•we have accurate models (informal and formal) of the system behaviour
•Now we need to look at Specifying the requirements!
SOFT 423 – Winter 2015 25
Next Class
•Requirements Specification
SOFT 423 – Winter 2015 26
