slide 11.1 object-oriented and classical software...
TRANSCRIPT
Slide 11.1
© The McGraw-Hill Companies, 2007
Object-Oriented andClassical Software
Engineering
Seventh Edition, WCB/McGraw-Hill, 2007
Stephen R. [email protected]
Slide 11.2
© The McGraw-Hill Companies, 2007
CHAPTER 11
CLASSICAL ANALYSIS
Slide 11.3
© The McGraw-Hill Companies, 2007
Overview
The specification document Informal specifications Structured systems analysis Structured systems analysis: The MSG
Foundation case study Other semiformal techniques Entity-relationship modeling Finite state machines Petri nets Z
Slide 11.4
© The McGraw-Hill Companies, 2007
Overview (contd)
Other formal techniques Comparison of classical analysis techniques Testing during classical analysis CASE tools for classical analysis Metrics for classical analysis Software project management plan: The MSG
Foundation case study Challenges of classical analysis
Slide 11.5
© The McGraw-Hill Companies, 2007
The Specification Document Must Be
Informal enough for the clientThe client is generally not a computer specialist
Formal enough for the developersIt is the sole source of information for drawing up the
design
These two requirements are mutually contradictory
Slide 11.6
© The McGraw-Hill Companies, 2007
11.1 The Specification Document
The specification document is a contract betweenthe client and the developers
Typical constraintsDeadlineParallel runningPortabilityReliabilityRapid response time
For real-time softwareHard real-time constraints must be satisfied
Slide 11.7
© The McGraw-Hill Companies, 2007
Specification Document (contd)
Acceptance criteriaIt is vital to spell out a series of tests
If the product passes the tests, it is deemed havesatisfied its specifications
Some acceptance criteria are restatements ofconstraints
Slide 11.8
© The McGraw-Hill Companies, 2007
Solution Strategy
A general approach to building the product
Find strategies without worrying about constraintsThen modify the strategies in the light of the constraints,
if necessary
Keep a written record of all discarded strategies,and why they were discardedTo protect the analysis teamTo prevent unwise new “solutions” during postdelivery
maintenance
Slide 11.9
© The McGraw-Hill Companies, 2007
11.2 Informal Specifications
Informal specifications are written in a naturallanguageExamples: English, Mandarin, Kiswahili, Hindi
Example“If the sales for the current month are below the targetsales, then a report is to be printed, unless thedifference between target sales and actual sales is lessthan half of the difference between target sales andactual sales in the previous month, or if the differencebetween target sales and actual sales for the currentmonth is under 5%”
Slide 11.10
© The McGraw-Hill Companies, 2007
The Meaning of This Specification
The sales target for January was $100,000, butactual sales were only $64,000 (36% below target)Print the report
The sales target for February was $120,000, theactual sales were only $100,000 (16.7% belowtarget)The percentage difference for February (16.7%) is less
than half of the previous month’s percentage difference(36%), so do not print the report
Slide 11.11
© The McGraw-Hill Companies, 2007
The Meaning of This Specification (contd)
The sales target for March was $100,000, theactual sales were $98,000 (2% below target)The percentage difference is under 5%, so do not print
the report
Slide 11.12
© The McGraw-Hill Companies, 2007
But the Specifications Do Not Say This
“[D]ifference between target sales and actualsales”There is no mention of percentage difference in the
specifications
The difference in January was $36,000, thedifference in February was $20,000Not less than half of $36,000, so the report is printed
“[D]ifference … [of] 5%”Again, no mention of percentage
Slide 11.13
© The McGraw-Hill Companies, 2007
But the Specifications Do Not Say This (contd)
Ambiguity—should the last clause read“percentage difference … [of] 5%” or “difference …[of] $5,000” or something else entirely?
The style is poorThe specifications should state when the report should
be printed …… Rather than when it should not be printed
Slide 11.14
© The McGraw-Hill Companies, 2007
Informal Specifications (contd)
ClaimThis cannot arise with professional specifications writers
RefutationText processing case study
Slide 11.15
© The McGraw-Hill Companies, 2007
11.2.1 Correctness Proof Case Study
Naur text-processing problemGiven a text consisting of words separated by blank orby newline characters, convert it to line-by-line form inaccordance with the following rules:(1) line breaks must be made only where the given textcontains a blank or newline;(2) each line is filled as far as possible, as long as(3) no line will contain more than maxpos characters
Slide 11.16
© The McGraw-Hill Companies, 2007
Episode 1
1969 — Naur Paper
Naur constructed a procedure (25 lines of Algol60), and informally proved its correctness
Slide 11.17
© The McGraw-Hill Companies, 2007
Episode 2
1970 — Reviewer in Computing ReviewsThe first word of the first line is preceded by a blank
unless the first word is exactly maxpos characters long
Slide 11.18
© The McGraw-Hill Companies, 2007
Episode 3
1971 — London found 3 more faultsIncluding: The procedure does not terminate unless a
word longer than maxpos characters is encountered
Slide 11.19
© The McGraw-Hill Companies, 2007
Episode 4
1975 — Goodenough and Gerhart found 3 furtherfaultsIncluding: The last word will not be output unless it is
followed by a blank or newline
Goodenough and Gerhart then produced a newset of specifications, about four times longer thanNaur’s
Slide 11.20
© The McGraw-Hill Companies, 2007
Episode 5
1985 — Meyer detected 12 faults in Goodenoughand Gerhart’s specifications
Slide 11.21
© The McGraw-Hill Companies, 2007
Episode 5
Goodenough and Gerhart’s specificationsWere constructed with the greatest of careWere constructed to correct Naur’s specificationsWent through two versions, carefully refereedWere written by experts in specifications,With as much time as they needed,For a product about 30 lines long
So, what chance do we have of writing fault-freespecifications for a real product?
Slide 11.22
© The McGraw-Hill Companies, 2007
Episode 6
1989 — Schach found a fault in Meyer’sspecificationsItem (2) of Naur’s original requirement (“each line is
filled as far as possible”) is not satisfied
Slide 11.23
© The McGraw-Hill Companies, 2007
Informal Specifications (contd)
ConclusionNatural language is not a good way to specify a product
Slide 11.24
© The McGraw-Hill Companies, 2007
11.3 Structured Systems Analysis
Three popular graphical specification methods of1970sDeMarcoGane and SarsenYourdon
All are equivalent
All are equally good
Slide 11.25
© The McGraw-Hill Companies, 2007
11.3 Structured Systems Analysis (contd)
Many U.S. corporations use them for commercialproducts
Gane and Sarsen’s method is taught herebecause it is so widely used
Slide 11.26
© The McGraw-Hill Companies, 2007
11.3.1 Sally’s Software Shop Mini Case Study
Sally’s Software Shop buys software from varioussuppliers and sells it to the public. Popularsoftware packages are kept in stock, but the restmust be ordered as required. Institutions andcorporations are given credit facilities, as are somemembers of the public. Sally’s Software Shop isdoing well, with a monthly turnover of 300packages at an average retail cost of $250 each.Despite her business success, Sally has beenadvised to computerize. Should she?
Slide 11.27
© The McGraw-Hill Companies, 2007
Sally’s Software Shop Mini Case Study (contd)
A better questionWhat business functions should she computerize
Accounts payable Accounts receivable Inventory
Still betterHow? Batch, or online? In-house or outsourcing?
Slide 11.28
© The McGraw-Hill Companies, 2007
Sally’s Software Shop Mini Case Study (contd)
The fundamental issueWhat 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
Slide 11.29
© The McGraw-Hill Companies, 2007
Sally’s Software Shop Mini Case Study (contd)
We assume: Sally wishes to computerize “in orderto make more money”We need to perform cost–benefit analysis for each
section of her business
Slide 11.30
© The McGraw-Hill Companies, 2007
Sally’s Software Shop Mini Case Study (contd)
The danger of many standard approachesFirst produce the solution, then find out what the
problem is!
Gane and Sarsen’s methodNine-step methodStepwise refinement is used in many steps
Slide 11.31
© The McGraw-Hill Companies, 2007
Sally’s Software Shop Mini Case Study (contd)
The data flowdiagram (DFD)shows the logicaldata flow“What happens, not
how it happens”
Symbols:
Figure 11.1
Slide 11.32
© The McGraw-Hill Companies, 2007
Step 1. Draw the DFD
First refinementInfinite number of possible interpretations
Figure 11.2
Slide 11.33
© The McGraw-Hill Companies, 2007
Step 1 (contd)
Second refinementPENDING ORDERS is scanned daily
Figure11.3
Slide 11.34
© The McGraw-Hill Companies, 2007
Step 1 (contd)
Portion ofthirdrefinement
Figure 11.4
Slide 11.35
© The McGraw-Hill Companies, 2007
Step 1 (contd)
The final DFD is largerBut it is easily understood by the client
When dealing with larger DFDsSet up a hierarchy of DFDsA box becomes a DFD at a lower level
Slide 11.36
© The McGraw-Hill Companies, 2007
Step 2. Decide What Parts to Computerize and How
It depends on how much client is prepared tospend
Large volumes, tight controlsBatch
Small volumes, in-house microcomputerOnline
Cost/benefit analysis
Slide 11.37
© The McGraw-Hill Companies, 2007
Step 3. Determine the Details of the Data Flows
Determine the data items for each data flow
Refine each flow stepwiseExample;
order:
order_identification
customer_details
package_details
We need a data dictionary for larger products
Slide 11.38
© The McGraw-Hill Companies, 2007
Sample Data Dictionary Entries
Figure 11.5
Slide 11.39
© The McGraw-Hill Companies, 2007
Step 4. Define the Logic of the Processes
We have process give educational discountSally must explain the discount she gives to educational
institutions 10% on up to 4 packages 15% on 5 or more
Slide 11.40
© The McGraw-Hill Companies, 2007
Step 4 . Define the Logic of the Processes (contd)
Translate this into a decision tree
Figure 11.6
Slide 11.41
© The McGraw-Hill Companies, 2007
Step 4. Define the Logic of the Processes (contd)
The advantage of a decision treeMissing items are quickly apparent
Figure 11.7
Slide 11.42
© The McGraw-Hill Companies, 2007
Step 5. Define the Data Stores
Define the exact contents and representation(format)COBOL: specify to pic levelAda: specify digits or delta
Slide 11.43
© The McGraw-Hill Companies, 2007
Step 5. Define the Data Stores (contd)
Specify where immediate access is requiredData immediate-access diagram (DIAD)
Figure 11.8
Slide 11.44
© The McGraw-Hill Companies, 2007
Step 6. Define the Physical Resources
For each file, specifyFile nameOrganization (sequential, indexed, etc.)Storage mediumBlocking factorRecords (to field level)Table information, if a DBMS is to be used
Slide 11.45
© The McGraw-Hill Companies, 2007
Step 7. Determine Input/Output Specifications
SpecifyInput formsInput screensPrinted output
Slide 11.46
© The McGraw-Hill Companies, 2007
Step 8. Determine the Sizing
Obtain the numerical data needed in Step 9 todetermine the hardware requirementsVolume of input (daily or hourly)Size, frequency, deadline of each printed reportSize, number of records passing between CPU and
mass storageSize of each file
Slide 11.47
© The McGraw-Hill Companies, 2007
Step 9. Determine the Hardware Requirements
Mass storage requirements
Mass storage for back-up
Input needs
Output devices
Is the existing hardware adequate?If not, recommend whether to buy or lease additional
hardware
Slide 11.48
© The McGraw-Hill Companies, 2007
However
Response times cannot be determined
The number of I/O channels can only be guessed
CPU size and timing can only be guessed
Nevertheless, no other method provides thesedata for arbitrary products
Slide 11.49
© The McGraw-Hill Companies, 2007
Overall
The method of Gane and Sarsen/De Marco/Yourdon has resulted in major improvements inthe software industry
Slide 11.50
© The McGraw-Hill Companies, 2007
11.4 Structured Systems Analysis: The MSG Foundation Case Study
Figure 11.9
Data flowdiagram
Slide 11.51
© The McGraw-Hill Companies, 2007
Structured Systems Analysis: The MSG Foundation Case Study (contd)
As reflected in the DFD, the user can performthree different types of operations:
1. Update investment data, mortgage data, oroperating expenses data:The USER enters an update_requestTo update investment data, process
perform_selected_update solicits theupdated_investment_details from the USER, and sendsthen to the INVESTMENT_DATA store of data
Updating mortgage data or expenses data is similar
Slide 11.52
© The McGraw-Hill Companies, 2007
Structured Systems Analysis: The MSG Foundation Case Study (contd)
2. Print a listing of investments or mortgages:To print a list of investments, the USER enters an
investment_report_request. Processgenerate_listing_of_investments then obtains investmentdata from store INVESTMENT_DATA, formats the report, andthen prints the report
Printing a listing of mortgages is similar
Slide 11.53
© The McGraw-Hill Companies, 2007
Structured Systems Analysis: The MSG Foundation Case Study (contd)
3. Print a report showing available funds formortgages for the week:The USER enters a funds_availability_report_request.To determine how much money is available for
mortgages for the current week, processcompute_availability_of_funds_and_generate_funds_report
then obtains (see next slide):
Slide 11.54
© The McGraw-Hill Companies, 2007
Structured Systems Analysis: The MSG Foundation Case Study (contd)
investment_details from store INVESTMENT_DATA andcomputes the expected total annual return oninvestments
mortgage_details from store MORTGAGE_DATA and computesthe expected income for the week, expected mortgagepayments for the week, and expected grants for theweek
annual_operating_expenses from store EXPENSES_DATA andcomputes the expected annual operating expense
Slide 11.55
© The McGraw-Hill Companies, 2007
Structured Systems Analysis: The MSG Foundation Case Study (contd)
Process compute_availability_of_funds_and_generate_funds_report then uses these results tocompute available_funds_for_week, and format andprint the report
Slide 11.56
© The McGraw-Hill Companies, 2007
11.5 Other Semiformal Techniques
Semiformal (graphical) techniques for classicalanalysis includePSL/PSASADTSREM
Slide 11.57
© The McGraw-Hill Companies, 2007
11.6 Entity-Relationship Modeling
Semi-formal techniqueWidely used for specifying databasesExample:
Figure 11.10
Slide 11.58
© The McGraw-Hill Companies, 2007
Entity-Relationship Diagrams (contd)
Many-to-many relationship
Figure 11.11
Slide 11.59
© The McGraw-Hill Companies, 2007
Entity-Relationship Diagrams (contd)
More complex entity-relationship diagrams
Figure 11.12
Slide 11.60
© The McGraw-Hill Companies, 2007
11.7 Finite State Machines
Case studyA safe has a combination lock that can be in one ofthree positions, labeled 1, 2, and 3. The dial can beturned left or right (L or R). Thus there are sixpossible dial movements, namely 1L, 1R, 2L, 2R, 3L, and3R. The combination to the safe is 1L, 3R, 2L; any otherdial movement will cause the alarm to go off
Figure 11.13
Slide 11.61
© The McGraw-Hill Companies, 2007
Finite State Machines (contd)
The set of states J is {Safe Locked, A, B, Safe Unlocked,Sound Alarm}
The set of inputs K is {1L, 1R, 2L, 2R, 3L, 3R}
The transition function T is on the next slide
The initial state J is Safe Locked
The set of final states J is {Safe Unlocked, Sound Alarm}
Slide 11.62
© The McGraw-Hill Companies, 2007
Figure 11.14
Finite State Machines (contd)
Transition table
Slide 11.63
© The McGraw-Hill Companies, 2007
Extended Finite State Machines
FSM transition rules have the formcurrent state [menu] and event [option selected] ⇒ new state
Extend the standard FSM by adding globalpredicates
Transition rules then take the formcurrent state and event and predicate ⇒ new state
Slide 11.64
© The McGraw-Hill Companies, 2007
11.7.1 Finite State Machines: The Elevator Problem Case Study
A product is to be installed to control n elevators in abuilding with m floors. The problem concerns the logicrequired to move elevators between floors according to thefollowing constraints:1. Each elevator has a set of m buttons, one for each floor.These illuminate when pressed and cause the elevator tovisit the corresponding floor. The illumination is canceledwhen the corresponding floor is visited by the elevator2. Each floor, except the first and the top floor, has twobuttons, one to request an up-elevator, one to request adown-elevator. These buttons illuminate when pressed.The illumination is canceled when an elevator visits thefloor, then moves in the desired direction3. If an elevator has no requests, it remains at its currentfloor with its doors closed
Slide 11.65
© The McGraw-Hill Companies, 2007
Finite State Machines: The Elevator Problem Case Study (contd)
There are two sets of buttons
Elevator buttonsIn each elevator, one for each floor
Floor buttonsTwo on each floor, one for up-elevator, one for down-
elevator
Slide 11.66
© The McGraw-Hill Companies, 2007
Elevator Buttons
EB (e, f):Elevator Button in elevator e pressed to request floor f
Slide 11.67
© The McGraw-Hill Companies, 2007
Elevator Buttons (contd)
Two statesEBON (e, f): Elevator Button (e,f) ONEBOFF (e,f): Elevator Button (e,f) OFF
If an elevator button is on and the elevator arrives atfloor f, then the elevator button is turned off
If the elevator button is off and the elevator button ispressed, then the elevator button comes on
Figure11.15
Slide 11.68
© The McGraw-Hill Companies, 2007
Elevator Buttons (contd)
Two eventsEBP (e,f): Elevator Button (e,f) PressedEHAF (e,f): Elevator e Has Arrived at Floor f
Global predicateV (e,f): Elevator e is Visiting (stopped at) floor f
Transition RulesEBOFF (e,f) and EBP (e,f) and not V (e,f) ⇒ EBON (e,f)EBON (e,f) and EHAF (e,f) ⇒ EBOFF (e,f)
Slide 11.69
© The McGraw-Hill Companies, 2007
Floor Buttons
FB (d, f):Floor Button on floor f that requests elevator traveling in
direction d
Slide 11.70
© The McGraw-Hill Companies, 2007
StatesFBON (d, f): Floor Button (d, f) ONFBOFF (d, f): Floor Button (d, f) OFF
If the floor button is on and an elevator arrives at floor f,traveling in the correct direction d, then the floor button isturned off
If the floor button is off and the floor button is pressed,then the floor button comes on
Floor Buttons (contd)
Figure 11.16
Slide 11.71
© The McGraw-Hill Companies, 2007
Floor Buttons (contd)
EventsFBP (d, f): Floor Button (d, f) PressedEHAF (1..n, f): Elevator 1 or … or n Has Arrived at Floor f
PredicateS (d, e, f): Elevator e is visiting floor f
Direction of motion is up (d = U), down (d = D), or norequests are pending (d = N)
Transition rulesFBOFF (d, f) and FBP (d, f) and not S (d, 1..n, f) ⇒ FBON (d, f)FBON (d, f) and EHAF (1..n, f) and S (d, 1..n, f) ⇒ FBOFF (d, f),
d = U or D
Slide 11.72
© The McGraw-Hill Companies, 2007
Finite State Machines: The Elevator Problem Case Study (contd)
The state of the elevator consists of componentsubstates, including:Elevator slowingElevator stoppingDoor openingDoor open with timer runningDoor closing after a timeout
Slide 11.73
© The McGraw-Hill Companies, 2007
Elevator Problem: FSM (contd)
We assume that the elevator controller moves theelevator through the substates
Three elevator statesM (d, e, f): Moving in direction d (floor f is next)S (d, e, f): Stopped (d-bound) at floor fW (e,f): Waiting at floor f (door closed)
For simplicity, the three stopped states S (U, e, f),S (N, e, f), and S (D, e, f) are grouped into one largerstate
Slide 11.74
© The McGraw-Hill Companies, 2007
State Transition Diagram for Elevator
Figure 11.17
Slide 11.75
© The McGraw-Hill Companies, 2007
Elevator Problem: FSM (contd)
EventsDC (e,f): Door Closed for elevator e, floor fST (e,f): Sensor Triggered as elevator e nears floor fRL: Request Logged (button pressed)
Transition RulesIf the elevator e is in state S (d, e, f) (stopped, d-bound, atfloor f), and the doors close, then elevator e will moveup, down, or go into the 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)
Slide 11.76
© The McGraw-Hill Companies, 2007
Finite State Machines (contd)
The power of an FSM to specify complex systems
There is no need for complex preconditions andpostconditions
Specifications take the simple formcurrent state and event and predicate ⇒ next state
Slide 11.77
© The McGraw-Hill Companies, 2007
Finite State Machines (contd)
Using an FSM, a specification isEasy to write downEasy to validateEasy to convert into a designEasy to convert into code automaticallyMore precise than graphical methodsAlmost as easy to understandEasy to maintain
HoweverTiming considerations are not handled
Slide 11.78
© The McGraw-Hill Companies, 2007
Finite State Machines (contd)
Statecharts are a real-time extension of FSMsCASE tool: Rhapsody
Slide 11.79
© The McGraw-Hill Companies, 2007
11.8 Petri Nets
A major difficulty with specifying real-time systemsis timingSynchronization problemsRace conditionsDeadlock
Often a consequence of poor specifications
Slide 11.80
© The McGraw-Hill Companies, 2007
Petri Nets (contd)
Petri netsA powerful technique for specifying systems that have
potential problems with interrelations
A Petri net consists of four parts:A set of places P
A set of transitions T
An input function I
An output function O
Slide 11.81
© The McGraw-Hill Companies, 2007
Petri Nets (contd)
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}
Figure 11.18
Slide 11.82
© The McGraw-Hill Companies, 2007
Petri Nets (contd)
More formally, a Petri net is a 4-tuple C = (P, T, I, O)
P = {p1, p2,…,pn} is a finite set of places, n ≥ 0T = {t1, t2,…,tm} is a finite set of transitions, m ≥ 0, with P and T
disjoint I : T → P∞ is the input function, a mapping from transitions
to bags of placesO : T → P∞ is the output function, a mapping from
transitions to bags of places(A bag is a generalization of a set that allows for
multiple instances of elements, as in the example on theprevious slide)
A marking of a Petri net is an assignment of tokens tothat Petri net
Slide 11.83
© The McGraw-Hill Companies, 2007
Petri Nets (contd)
Four tokens: one in p1, two in p2, none in p3, and onein p4
Represented by the vector (1,2,0,1)
Figure 11.19
Slide 11.84
© The McGraw-Hill Companies, 2007
Petri Nets (contd)
A transition is enabled if each of its input placeshas as many tokens in it as there are arcs fromthe place to that transition
Slide 11.85
© The McGraw-Hill Companies, 2007
Petri Nets (contd)
Transition t1 is enabled (ready to fire)If t1 fires, one token is removed from p2 and one from p4,
and one new token is placed in p1
Transition t2 is also enabled
Important:The number of tokens is not conserved
Slide 11.86
© The McGraw-Hill Companies, 2007
Petri Nets (contd)
Petri nets are indeterminateSuppose t1 fires
The resulting marking is (2,1,0,0)
Figure 11.20
Slide 11.87
© The McGraw-Hill Companies, 2007
Petri Nets (contd)
Now only t2 is enabledIt fires
The marking is now (2,0,2,0)
Figure 11.21
Slide 11.88
© The McGraw-Hill Companies, 2007
Petri Nets (contd)
More formally, a marking M of a Petri netC = (P, T, I, O)
is a function from the set of places P to the non-negative integers
M : P → {0, 1, 2, …}
A marked Petri net is then a 5-tuple (P, T, I, O, M )
Slide 11.89
© The McGraw-Hill Companies, 2007
Petri Nets (contd)
Inhibitor arcsAn inhibitor arc is marked by a small circle, not an
arrowhead
Transition t1 is enabledFigure 11.22
Slide 11.90
© The McGraw-Hill Companies, 2007
Petri Nets (contd)
In general, a transition is enabled if there is atleast one token on each (normal) input arc, and notokens on any inhibitor input arcs
Figure 11.22
Slide 11.91
© The McGraw-Hill Companies, 2007
11.8.1 Petri Nets: The Elevator Problem Case Study
A product is to be installed to control n elevators ina building with m floors
Each floor is represented by a place Ff, 1 ≤ f ≤ m
An elevator is represented by a token
A token in Ff denotes that an elevator is at floor Ff
Slide 11.92
© The McGraw-Hill Companies, 2007
Petri Nets: The Elevator Problem Case Study (contd)
First constraint:1. Each elevator has a set of m buttons, one for eachfloor. These illuminate when pressed and cause theelevator to visit the corresponding floor. Theillumination is canceled when the corresponding floor isvisited by an elevator
The elevator button for floor f is represented byplace EBf, 1 ≤ f ≤ m
A token in EBf denotes that the elevator button forfloor f is illuminated
Slide 11.93
© The McGraw-Hill Companies, 2007
Petri Nets: The Elevator Problem Case Study (contd)
A button must be illuminated the first time thebutton is pressed and subsequent button pressesmust be ignored
Slide 11.94
© The McGraw-Hill Companies, 2007
Petri Nets: The Elevator Problem Case Study (contd)
If button EBf is not illuminated, no token is in placeand transition EBf pressed is enabledThe transition fires, a new token is placed in EBf
Now, no matter how many times the button ispressed, transition EBf pressed cannot be enabled
Figure 11.23
Slide 11.95
© The McGraw-Hill Companies, 2007
Petri Nets: The Elevator Problem Case Study (contd)
When the elevator reaches floor g
A token is in place Fg
Transition Elevator in action is enabled, and then fires
The tokens in EBf and Fg are removedThis turns off the light in button EBf
A new token appears in Ff
This brings the elevator from floor g to floor f
Slide 11.96
© The McGraw-Hill Companies, 2007
Petri Nets: The Elevator Problem Case Study (contd)
Motion from floor g to floor f cannot take placeinstantaneouslyWe need timed Petri nets
Slide 11.97
© The McGraw-Hill Companies, 2007
Petri Nets: The Elevator Problem Case Study (contd)
Second constraint:2. Each floor, except the first and the top floor, hastwo buttons, one to request an up-elevator, one torequest a down-elevator. These buttons illuminatewhen pressed. The illumination is canceled when theelevator visits the floor, and then moves in desireddirection
Floor buttons are represented by places FBuf and FBd
f
Slide 11.98
© The McGraw-Hill Companies, 2007
Petri Nets: The Elevator Problem Case Study (contd)
Figure 11.24
Slide 11.99
© The McGraw-Hill Companies, 2007
Petri Nets: The Elevator Problem Case Study (contd)
The Petri net in the previous slide models thesituation when an elevator reaches floor f fromfloor g with one or both buttons illuminated
If both buttons are illuminated, only one is turnedoff
A more complex model is needed to ensure thatthe correct light is turned off
Slide 11.100
© The McGraw-Hill Companies, 2007
Petri Nets: The Elevator Problem Case Study (contd)
Third constraint:C3. If an elevator has no requests, it remains at itscurrent floor with its doors closed
If there are no requests, no Elevator in action transitionis enabled
Slide 11.101
© The McGraw-Hill Companies, 2007
Petri Nets: The Elevator Problem Case Study (contd)
Petri nets can also be used for design
Petri nets possess the expressive powernecessary for specifying synchronization aspectsof real-time systems
Slide 11.102
© The McGraw-Hill Companies, 2007
11.9 Z
Z (pronounced “zed”) is a formal specificationlanguage
There is a high squiggle factor
Slide 11.103
© The McGraw-Hill Companies, 2007
11.9.1 Z: The Elevator Problem Case Study
A Z specification consists of four sections:1. Given sets, data types, and constants2. State definition3. Initial state4. Operations
Slide 11.104
© The McGraw-Hill Companies, 2007
1. Given sets
Given sets are sets that need not be defined indetail
Names appear in brackets
Here we need the set of all buttons
The specification therefore begins [Button]
Slide 11.105
© The McGraw-Hill Companies, 2007
2. State Definition
Z specification consists of a number of schemataA schema consists of a group of variable declarations,
plusA list of predicates that constrain the values of variables
Figure 11.25
Slide 11.106
© The McGraw-Hill Companies, 2007
Z: The Elevator Problem Case Study (contd)
In this problem there are four subsets of Button
The floor buttonsThe elevator buttonsbuttons (the set of all buttons in the elevator problem)pushed (the set of buttons that have been pushed)
Slide 11.107
© The McGraw-Hill Companies, 2007
Schema Button_State
Figure 11.26
Slide 11.108
© The McGraw-Hill Companies, 2007
3. Initial State
The state when the system is first turned on
Button_Init ^= [Button_State' | pushed' = ∅]
(The caret ^ should be on top of the first equals sign =.Unfortunately, this is hard to type in PowerPoint!)
Slide 11.109
© The McGraw-Hill Companies, 2007
4. Operations
A button pushed for the first time is turned on, andadded to set pushed
Without the third precondition, the results would beunspecified
Figure 11.27
Slide 11.110
© The McGraw-Hill Companies, 2007
Z: The Elevator Problem Case Study (contd)
If an elevator arrives at a floor, the correspondingbutton(s) must be turned off
The solution does not distinguish between up anddown floor buttons
Figure 11.28
Slide 11.111
© The McGraw-Hill Companies, 2007
11.9.2 Analysis of Z
Z is the most widely used formal specificationlanguage
It has been used to specifyCICS (part)An oscilloscopeA CASE toolMany large-scale projects (especially in Europe)
Slide 11.112
© The McGraw-Hill Companies, 2007
Analysis of Z (contd)
Difficulties in using ZThe large and complex set of symbolsTraining in mathematics is needed
Slide 11.113
© The McGraw-Hill Companies, 2007
Analysis of Z (contd)
Reasons for the great success of ZIt is easy to find faults in Z specificationsThe specifier must be extremely preciseWe can prove correctness (we do not have to)Only high-school math needed to read ZZ decreases development timeA “translation” of a Z specification into English (or
another natural language) is clearer than an informalspecification
Slide 11.114
© The McGraw-Hill Companies, 2007
11.10 Other Formal Techniques
AnnaFor Ada
Gist, RefineKnowledge-based
VDMUses denotational semantics
CSPCSP specifications are executableLike Z, CSP has a high squiggle factor
Slide 11.115
© The McGraw-Hill Companies, 2007
11.11 Comparison of Classical Analysis Techniques
Formal methods arePowerful, butDifficult to learn and use
Informal methods haveLittle power, but areEasy to learn and use
There is therefore a trade-off Ease of use versus power
Slide 11.116
© The McGraw-Hill Companies, 2007
Comparison of Classical Analysis Techniques (contd)
Figure 11.29
Slide 11.117
© The McGraw-Hill Companies, 2007
Newer Methods
Many are untested in practice
There are risks involvedTraining costsAdjustment from the classroom to an actual projectCASE tools may not work properly
However, possible gains may be huge
Slide 11.118
© The McGraw-Hill Companies, 2007
Which Analysis Technique Should Be Used?
It depends on theProjectDevelopment teamManagement teamMyriad other factors
It is unwise to ignore the latest developments
Slide 11.119
© The McGraw-Hill Companies, 2007
11.12 Testing during Classical Analysis
Specification inspectionAided by fault checklist
Results of Doolan [1992]2 million lines of FORTRAN1 hour of inspecting saved 30 hours of execution-based
testing
Slide 11.120
© The McGraw-Hill Companies, 2007
11.13 CASE Tools for Classical Analysis
A graphical tool is exceedingly useful
So is a data dictionaryIntegrate them
An analysis technique without CASE tools tosupport it will failThe SREM experience
Slide 11.121
© The McGraw-Hill Companies, 2007
CASE Tools for Classical Analysis (contd)
Typical toolsAnalyst/DesignerSoftware through PicturesSystem Architect
Slide 11.122
© The McGraw-Hill Companies, 2007
11.14 Metrics for CASE Tools
Five fundamental metrics
QualityFault statisticsThe number, type of each faultThe rate of fault detection
Metrics for “predicting” the size of a target productTotal number of items in the data dictionaryThe number of items of each typeProcesses vs. modules
Slide 11.123
© The McGraw-Hill Companies, 2007
11.15 Software Project Management Plan: The MSG Foundation Case Study
The Software Project Management Plan is given inAppendix F
Slide 11.124
© The McGraw-Hill Companies, 2007
11.16 Challenges of Classical Analysis
A specification document must beInformal enough for the client; butFormal enough for the development team
Analysis (“what”) should not cross the boundaryinto design (“how”)
Do not try to assign modules to process boxes ofDFDs until the classical design phase