Beruflich Dokumente
Kultur Dokumente
Object-Oriented and
Classical Software
Engineering
Fifth Edition, WCB/McGraw-Hill, 2002
Stephen R. Schach
srs@vuse.vanderbilt.edu
SPECIFICATION
PHASE
● Constraints
– Cost
– Time
– Parallel running
– Portability
– Reliability
– Rapid response time
● Acceptance criteria
– Vital to spell out series of tests
– Product passes tests, deemed to satisfy specifications
– Some are restatements of constraints
● Example
“If sales for current month are below target sales,
then report is to be printed, unless difference
between target sales and actual sales is less than
half of difference between target sales and actual
sales in previous month, or if difference between
target sales and actual sales for the current month
is under 5%”
● Claim
– This cannot arise with professional specifications writers
● Refutation
– Text Processing case study
● Conclusion
– Natural language is not a good way to specify product
● Fact
– Many organizations still use natural language, especially
for commercial products
● Reasons
– Uninformed management
– Undertrained computer professionals
– Management gives in to client pressure
– Management is unwilling to invest in training
● Fundamental issue
– What is Sally’s objective in computerizing her business?
● Because she sells software?
– She needs an in-house system with sound and light
effects
● Because she uses her business to launder “hot”
money?
– She needs a product that keeps five different sets of
books, and has no audit trail
● Assume: Computerization “in order to make more
money”
– Cost/benefit analysis for each section of business
© The McGraw-Hill Companies, 2002
Case Study (contd) Slide 11.23
● First refinement
● Infinite number of possible interpretations
● Second refinement
●
pending orders scanned daily
● Portion of
third
refinement
● Final DFD
– Larger, But easily understood by client
● Larger DFDs
– Hierarchy
– Box becomes DFD at lower level
● Frequent problem
– Process P at level L, expanded at level L+1
– Correct place for sources and destinations of data for
process P is level L+1
– Clients cannot understand DFD—sources and
destinations of data for P are “missing”
● Solution
– Draw “correct” DFD, modify by moving sources and
destinations of© The
data one or more levels up
McGraw-Hill Companies, 2002
Step 2. Decide What Parts to Computerize Slide 11.29
● DASD requirements
● Mass storage for back-up
● Input needs
● Output devices
● Is existing hardware
adequate?
● If not, recommend buy/lease
● Semi-formal technique
● Widely used for specifying databases
● Used for object-oriented analysis
● Many-to-many relationship
● More complex entity-relationship diagrams
● Informal method
– English (or other natural language)
● Semiformal methods
– Gane & Sarsen/DeMarco/Yourdon
– Entity-Relationship Diagrams
– Jackson/Orr/Warnier,
– SADT, PSL/PSA, SREM, etc.
● Formal methods
– Finite State Machines
– Petri Nets
– Z
– ANNA, VDM, CSP, etc.
● Case study
A safe has a combination lock that can be in one of
three positions, labeled 1, 2, and 3. The dial can
be turned left or right (L or R). Thus there are six
possible dial movements, namely 1L, 1R, 2L, 2R,
3L, and 3R. The combination to the safe is 1L, 3R,
2L; any other dial movement will cause the alarm to
go off
● Transition table
© The McGraw-Hill Companies, 2002
Extended Finite State Machines Slide 11.45
● Two states
EBON(e, f): Elevator Button (e,f) ON
EBOFF(e,f): Elevator Button (e,f) OFF
● Two events
EBP(e,f): Elevator Button (e,f) Pressed
EAF(e,f): Elevator e Arrives at Floor f
● Global predicate
V(e,f): Elevator e is Visiting (stopped at) floor f
● Transition Rules
EBOFF(e,f) and EBP(e,f) and not V(e,f) ⇒ EBON(e,f)
EBON(e,f) and EAF(e,f) Þ EBOFF(e,f)
● Floor buttons
FB(d, f): Floor Button on floor f that requests elevator traveling in
direction d
● States
FBON(d, f): Floor Button (d, f) ON
FBOFF(d, f): Floor Button (d, f) OFF
● Events
FBP(d, f): Floor Button (d, f) Pressed
EAF(1..n, f):Elevator 1 or … or n Arrives at Floor f
● Predicate
S(d, e, f): elevator e is visiting floor f
Direction of motion is up (d = U), down (d = D), or no requests are
pending (d = N)
● Transition rules
FBOFF(d, f) and FBP(d, f) and not S(d, 1..n, f) ⇒ FBON(d, f)
FBON(d, f) and EAF(1..n, f) and S(d, 1..n, f) ⇒ FBOFF(d, f),
d = U or D
● Events
DC(e,f): Door Closed for elevator e, floor f
ST(e,f): Sensor Triggered as elevator e nears floor f
RL: Request Logged (button pressed)
● Transition Rules
If elevator e is in state S(d, e, f) (stopped, d-bound, at
floor f), and doors close, then elevator e will move up,
down, or go into wait state
DC(e,f) and S(U, e, f) ⇒ M(U, e, f+1)
DC(e,f) and S(D, e, f) ⇒ M(D, e, f-1)
DC(e,f) and S(N, e, f) ⇒ W(e,f)
● Commercial products
– Menu driven
– Various states/screens
– Automatic code generation a major plus
● System software
– Operating system
– Word processors
– Spreadsheets
● Real-time systems
– Statecharts are a real-time extension of
FSMs
» CASE tool: Rhapsody
● Petri nets
– Powerful technique for specifying
systems with potential timing problems
● A Petri net consists of four parts:
– Set of places P
– Set of transitions T
– Input function I
– Output function O
● Set of places P is
{p1, p2, p3, p4}
● Set of transitions
T is {t1, t2}
● Input functions:
I(t1) = {p2, p4}
I(t2) = {p2}
● Output functions:
O(t1) = {p1}
O(t2) = {p3, p3}
● Now only t2 is
enabled
– It fires
● Marking is now
(2,0,2,0)
● Inhibitor arcs
– Inhibitor arc is marked by small circle, not arrowhead
● Transition t1 is enabled
– In general, transition is enabled if at least one token on
each (normal) input arc, and no tokens on any inhibitor
input arcs
© The McGraw-Hill Companies, 2002
Elevator Problem: Petri Net Slide 11.69
● First constraint
1. Each elevator has a set of m buttons,
one for each floor. These illuminate when
pressed and cause the elevator to visit the
corresponding floor. The illumination is
canceled when the corresponding floor is
visited by an elevator
● Elevator button for floor f is represented
by place EBf, 1 ≤ f ≤ m
● Token in EBf denotes that the elevator
button for floor f is illuminated
● Second constraint
2. Each floor, except the first and the top floor, has 2
buttons, one to request an up-elevator, one to request a
down-elevator. These buttons illuminate when pressed.
The illumination is canceled when the elevator visits the
floor, and then moves in desired direction
● Floor buttons represented by places FBuf and FBdf
● Third constraint
C3. If an elevator has no requests, it remains at its
current floor with its doors closed
● If no requests, no Elevator in action transition is
enabled
● 1. Given Sets
● 2. State Definition
● Schema Button_State
© The McGraw-Hill Companies, 2002
Elevator Problem: Z (contd) Slide 11.84
● 3. Initial State
● 4. Operations
● Difficulties
– Symbols
– Mathematics
● Reasons for great success
– Easy to find faults in Z specification
– Specifier must be extremely precise
– Can prove correctness
– Only high-school math needed to read Z
– Decreases development time
– “Translation” clearer than informal
specification
● Anna
– Ada
● Gist, Refine
– Knowledge-based
● VDM
– Denotational semantics
● CSP
– Sequence of events
– Executable specifications
– High squiggle factor
© The McGraw-Hill Companies, 2002
Comparison of Specification Techniques Slide 11.90
● Depends on the
– Project
– Development team
– Management team
– Myriad other factors
● Specification inspection
– Checklist
● Doolan [1992]
– 2 million lines of FORTRAN
– 1 hour of inspecting saved 30 hours of
execution-based testing
● Graphical tool
● Data dictionary
– Integrate them
● Specification method without CASE tools fails
– SREM
● Typical tools
– Analyst/Designer
– Software through Pictures
– System Architect