Date post: | 13-Jan-2016 |
Category: |
Documents |
Upload: | clifton-goodwin |
View: | 221 times |
Download: | 0 times |
Slide 11.1
© The McGraw-Hill Companies, 2007
CHAPTER 11
CLASSICAL ANALYSIS
Slide 11.2
© 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.3
© The McGraw-Hill Companies, 2007
The Specification Document Must Be
At the end of the analysis workflow – the specification document should be produced
Specification - contract Informal enough for the client
The client is generally not a computer specialist Formal enough for the developers
It is the sole source of information for drawing up the design
These two requirements are mutually contradictory
Slide 11.4
© The McGraw-Hill Companies, 2007
Specification
Specification Clientprogrammer
SoftwareEngineer
Slide 11.5
© The McGraw-Hill Companies, 2007
11.1 The Specification Document
The specification document is a contract between the client and the developers
Typical constraints on the product must be included in the specificationDeadline – for deliveryParallel running with existing productPortability – can run under different operating systemsReliabilityRapid response time
For real-time softwareHard real-time constraints must be satisfied
Slide 11.6
© The McGraw-Hill Companies, 2007
Specification Document (contd)
Acceptance criteria – how the client accept the software It is vital to spell out a series of tests
If the product passes the tests, it is deemed have satisfied its specifications
Some acceptance criteria are restatements of constraints such as the response time should be 1 sec, and system can run under Linux and WindowsXP etc
Slide 11.7
© The McGraw-Hill Companies, 2007
Acceptance constraints
As a constraintThe system must run under the windows XP
As a test conditionThe system will be tested under the windows XP
operating system
Slide 11.8
© The McGraw-Hill Companies, 2007
Exercise
Derive one acceptance test based on specification from your group’s mini-project
Slide 11.9
© The McGraw-Hill Companies, 2007
11.2 Informal Specifications
Informal specifications are written in a natural languageExamples: English, Mandarin, Kiswahili, Hindi
Example“If the sales for the current month are below the target sales, then a report is to be printed, unless the difference between target sales and actual sales is less than half of the difference between target sales and actual sales in the previous month, or if the difference between target sales and actual sales for the current month is under 5%”
Slide 11.10
© The McGraw-Hill Companies, 2007
Case study
The management of a retail chain sets a target sales figure for each shop for each month; and if a shop does not meet this target, a report is to be printed. Consider the following scenario: Suppose that the January sales target for one particular shop is $100,000 but actual sales are only $64,000, that is, 36% below target. In this case, a report must be printed. Now suppose further that the February target figure is $120,000 and the actual sales are only $100,000, 16.7% below target. Although sales are below the target figure, the % difference for February, is less than half of the previous month’s % difference; management believes that an improvement has been made, and no report is to be printed. If in March, the target is again $100,000 but the shop makes $98,000, only 2% below target. Because the % difference is small (5%), no report should be printed.
Slide 11.11
© The McGraw-Hill Companies, 2007
The Meaning of This Specification
The sales target for January was $100,000, but actual sales were only $64,000 (36% below target)Print the report
The sales target for February was $120,000, the actual sales were only $100,000 (16.7% below target)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.12
© The McGraw-Hill Companies, 2007
The Meaning of This Specification (contd)
The sales target for March was $100,000, the actual sales were $98,000 (2% below target)The percentage difference is under 5%, so do not print
the report
Slide 11.13
© The McGraw-Hill Companies, 2007
But the Specifications Do Not Say This
“[D]ifference between target sales and actual sales”There is no mention of percentage difference in the
specifications
The difference in January was $36,000, the difference 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.14
© 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 poor The specifications should state when the report should
be printed …… Rather than when it should not be printed
Slide 11.15
© The McGraw-Hill Companies, 2007
11.3 Structured Systems Analysis
Use of graphics to specify software was an important technique
Three popular graphical specification methods of 1970sDeMarcoGane and SarsenYourdon
All are equivalent All are equally good
Slide 11.16
© The McGraw-Hill Companies, 2007
11.3 Structured Systems Analysis (contd)
Many U.S. corporations use them for commercial products
Gane and Sarsen’s method is taught here because it is so widely used
Slide 11.17
© The McGraw-Hill Companies, 2007
11.3.1 Sally’s Software Shop Mini Case Study
Sally’s Software Shop buys software from various suppliers and sells it to the public. Popular software packages are kept in stock, but the rest must be ordered as required. Institutions and corporations are given credit facilities, as are some members of the public. Sally’s Software Shop is doing well, with a monthly turnover of 300 packages at an average retail cost of $250 each. Despite her business success, Sally has been advised to computerize. Should she?
Slide 11.18
© 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.19
© The McGraw-Hill Companies, 2007
Sally’s Software Shop Mini Case Study (contd)
The 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
Slide 11.20
© The McGraw-Hill Companies, 2007
Sally’s Software Shop Mini Case Study (contd)
We assume: Sally wishes to computerize “in order to make more money” We need to perform cost–benefit analysis for each
section of her business
Slide 11.21
© The McGraw-Hill Companies, 2007
Sally’s Software Shop Mini Case Study (contd)
The danger of many standard approaches First produce the solution, then find out what the
problem is! The software should run on an IBM mainframe
Gane and Sarsen’s methodNine-step method to analyze the client’s needStepwise refinement is used in many steps
Slide 11.22
© The McGraw-Hill Companies, 2007
Structured system analysis
Nine steps Step 1
Draw the data flow diagram to determine the logical data flow
What happens to the data!
Slide 11.23
© The McGraw-Hill Companies, 2007
Sally’s Software Shop Mini Case Study (contd)
The data flow diagram (DFD) shows the logical data flow “What happens, not
how it happens” After you have
determined the requirements
Only 4 symbols:
Figure 11.1
Slide 11.24
© The McGraw-Hill Companies, 2007
Data flow diagram
DFD will be huge for complex system Developed iteratively Each flow of data starts and ends either at a
source or destination or at a data store Data are transformed by processes Diagram refined by adding new flow of data or an
existing flow is refined with more details
Slide 11.25
© The McGraw-Hill Companies, 2007
Step 1. Draw the DFD
First refinement Infinite number of possible interpretationsProcess_order – worker
Figure 11.2
Slide 11.26
© The McGraw-Hill Companies, 2007
Step 1 (contd)
Second refinement PENDING ORDERS is scanned daily
Figure 11.3
Slide 11.27
© The McGraw-Hill Companies, 2007
Step 1 (contd)
Portion of third refinement
Figure 11.4
Slide 11.28
© The McGraw-Hill Companies, 2007
Exercise
Apply DFD to define operations in a libraryFor example how books are being borrowed or returned
Slide 11.29
© 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 DFDsUse proper symbol (such as a box) to represent DFD at
lower levelA box becomes a DFD at a lower level
Slide 11.30
© The McGraw-Hill Companies, 2007
Step 2. Decide What Parts to Computerize and How
It depends on how much client is prepared to spend
Large volumes of data, tight controlsBatch (collect sufficient order and then process together)
Small volumes of data, in-house microcomputerOnline
Cost/benefit analysis – to determine what to computerize
Slide 11.31
© 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 stepwise
Example;order:
order_identification
customer_details
package_details
We need a data dictionary for larger products – to keep track of all the data elements.
Slide 11.32
© The McGraw-Hill Companies, 2007
Sample Data Dictionary Entries
Figure 11.5
Slide 11.33
© 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.34
© 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.35
© The McGraw-Hill Companies, 2007
Step 5. Define the Data Stores
Define the exact contents and representation (format) Specify where immediate access is required
Data immediate-access diagram (DIAD) How the data stored can be searched – by name, by
machine and by function
Slide 11.36
© The McGraw-Hill Companies, 2007
Step 6. Define the Physical Resources
For each file, specifyFile nameOrganization of the file (sequential, indexed, etc.)Storage medium – in DVD, tape, or RAID Blocking factor – how large is a block of dataRecords (to field level)Table information, if a DBMS (Data Base Management
System) is to be used
Slide 11.37
© The McGraw-Hill Companies, 2007
Step 7. Determine Input/Output Specifications
Specify Input forms – the paper form Input screens - GUIPrinted output
Slide 11.38
© The McGraw-Hill Companies, 2007
Step 8. Determine the Sizing
Obtain the numerical data that are needed in Step 9 to determine 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.39
© The McGraw-Hill Companies, 2007
Step 9. Determine the Hardware Requirements
Mass storage requirements – to store the data Mass storage for back-up Input needs – scanner, keyboard Output devices – printer, monitor Is the existing hardware adequate?
If not, recommend whether to buy or lease additional hardware
Slide 11.40
© The McGraw-Hill Companies, 2007
Steps to perform structured systems analysis
Draw the data flow diagram Decide what sections to computerize and how
(batch processing or online) Determine the details of the data flows Define the logic of the processes Define the data stores Define the physical resources Determine the input-output specifications Perform the sizing Determine the hardware requirements
Slide 11.41
© 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 these data for arbitrary products
Slide 11.42
© The McGraw-Hill Companies, 2007
Overall
The method of Gane and Sarsen/De Marco/ Yourdon has resulted in major improvements in the software industry
Slide 11.43
© The McGraw-Hill Companies, 2007
11.4 Structured Systems Analysis: The MSG Foundation Case Study
Figure 11.9
Data flow diagram
Slide 11.44
© The McGraw-Hill Companies, 2007
Structured Systems Analysis: The MSG Foundation Case Study (contd)
As reflected in the DFD, the user can perform three different types of operations:
1. Update investment data, mortgage data, or operating expenses data:The USER enters an update_requestTo update investment data, process
perform_selected_update solicits the updated_investment_details from the USER, and sends then to the INVESTMENT_DATA store of data
Updating mortgage data or expenses data is similar
Slide 11.45
© 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. Process generate_listing_of_investments then obtains investment data from store INVESTMENT_DATA, formats the report, and then prints the report
Printing a listing of mortgages is similar
Slide 11.46
© The McGraw-Hill Companies, 2007
Structured Systems Analysis: The MSG Foundation Case Study (contd)
3. Print a report showing available funds for mortgages for the week:The USER enters a funds_availability_report_request. To determine how much money is available for
mortgages for the current week, process compute_availability_of_funds_and_generate_funds_report then obtains (see next slide):
Slide 11.47
© The McGraw-Hill Companies, 2007
Structured Systems Analysis: The MSG Foundation Case Study (contd)
investment_details from store INVESTMENT_DATA and computes the expected total annual return on investments
mortgage_details from store MORTGAGE_DATA and computes the expected income for the week, expected mortgage payments for the week, and expected grants for the week
annual_operating_expenses from store EXPENSES_DATA and computes the expected annual operating expense
Slide 11.48
© 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 to compute available_funds_for_week, and format and print the report
Slide 11.49
© The McGraw-Hill Companies, 2007
11.6 Entity-Relationship Modeling
Semi-formal techniqueWidely used for specifying databasesExample:
Figure 11.10
Slide 11.50
© The McGraw-Hill Companies, 2007
Entity-Relationship Diagrams (contd)
Many-to-many relationship
Figure 11.11
Slide 11.51
© The McGraw-Hill Companies, 2007
Entity-Relationship Diagrams (contd)
More complex entity-relationship diagrams
Figure 11.12
Slide 11.52
© The McGraw-Hill Companies, 2007
Exercise
Apply ERD to define something in a University
Slide 11.53
© The McGraw-Hill Companies, 2007
Finite state machine
Finite state machine is a formal specification technique
A system is defined by different states It is based on the
State InputTransition function Initial stateFinal state
A diagram or a table is used to describe how a state is transited to another state
Slide 11.54
© The McGraw-Hill Companies, 2007
11.7 Finite State Machines
Case studyA 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
Figure 11.13
Slide 11.55
© 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.56
© The McGraw-Hill Companies, 2007
Figure 11.14
Finite State Machines (contd)
Transition table
Slide 11.57
© The McGraw-Hill Companies, 2007
Extended Finite State Machines
FSM transition rules have the form (for a menu driven GUI)
current state [menu] and event [option selected] new state
Extend the standard FSM by adding global predicates ( a term designating a property or relation )
Predicate is something either “true” or “false” Transition rules then take the form
current state and event and predicate new state
Slide 11.58
© 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 a building with m floors. The problem concerns the logic required to move elevators between floors according to the following constraints: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 the elevator2. Each floor, except the first and the top floor, has two buttons, one to request an up-elevator, one to request a down-elevator. These buttons illuminate when pressed. The illumination is canceled when an elevator visits the floor, then moves in the desired direction 3. If an elevator has no requests, it remains at its current floor with its doors closed
Slide 11.59
© The McGraw-Hill Companies, 2007
Finite State Machines: The Elevator Problem Case Study (contd)
There are two sets of buttons
Elevator buttons In each elevator, one for each floor
Floor buttonsTwo on each floor, one for up-elevator, one for down-
elevator
Slide 11.60
© The McGraw-Hill Companies, 2007
Elevator Buttons
EB (e, f): Elevator Button in elevator e pressed to request floor f
Slide 11.61
© The McGraw-Hill Companies, 2007
Elevator Buttons (contd)
Two statesEBON (e, f): Elevator Button (e,f) ON
EBOFF (e,f): Elevator Button (e,f) OFF
If an elevator button is on and the elevator arrives at floor f, then the elevator button is turned off
If the elevator button is off and the elevator button is pressed, then the elevator button comes on
Figure11.15
Slide 11.62
© The McGraw-Hill Companies, 2007
Elevator Buttons (contd)
Two eventsEBP (e,f): Elevator Button (e,f) Pressed
EHAF (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.63
© The McGraw-Hill Companies, 2007
Floor Buttons
FB (d, f): Floor Button on floor f that requests elevator traveling in
direction dDirection “Up” or “Down”
Slide 11.64
© 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 is turned 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.65
© 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 no requests 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.66
© The McGraw-Hill Companies, 2007
Finite State Machines: The Elevator Problem Case Study (contd)
The state of the elevator consists of component substates, including:Elevator slowingElevator stoppingDoor openingDoor open with timer runningDoor closing after a timeout
Slide 11.67
© The McGraw-Hill Companies, 2007
Elevator Problem: FSM (contd)
We assume that the elevator controller moves the elevator 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 f
W (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 larger state
Slide 11.68
© The McGraw-Hill Companies, 2007
State Transition Diagram for Elevator
Figure 11.17
Slide 11.69
© The McGraw-Hill Companies, 2007
Elevator Problem: FSM (contd)
EventsDC (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 RulesIf the elevator e is in state S (d, e, f) (stopped, d-bound, at floor f), and the doors close, then elevator e will move up, 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.70
© 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 and postconditionsReading the FSM diagram can determine the conditions
Specifications take the simple form current state and event and predicate next state
Slide 11.71
© 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.72
© The McGraw-Hill Companies, 2007
Exercise
Apply FSM to design a dialing action of a mobile phone
Slide 11.73
© The McGraw-Hill Companies, 2007
Petri Net
Invented by Carl Adam Petri Currently has wide applications in computer
science in fields including performance evaluation, operating systems, and software engineering
Able to describe concurrent interrelated activities
Slide 11.74
© The McGraw-Hill Companies, 2007
Petri Nets Example
Slide 11.75
© The McGraw-Hill Companies, 2007
Petri Nets basic elements
Four partsA set of places P {p1, p2, p3, p4}A set of transitions T {t1, t2}An input function I
I(t1) = {p2, p4} i(t2) = {p2}
An output function O O(t1) = {p1} O(t2) = {p3, p3} as there are 2 arrows
Slide 11.76
© The McGraw-Hill Companies, 2007
Petri Nets
Marking – assignment of tokens to a Petri Net Token is represented by a The marking can be represented by a vector
(1,2,0,1) based on the sequence and number of tokens in the places
A transition is enabled if each of its input places has as many tokens in it as there are arcs from the place to that transition
Tokens will be moved from input places to an output when a transition is fired
Slide 11.77
© The McGraw-Hill Companies, 2007
Petri Net
Slide 11.78
© The McGraw-Hill Companies, 2007
Petri Net
Slide 11.79
© The McGraw-Hill Companies, 2007
Petri Net
Slide 11.80
© The McGraw-Hill Companies, 2007
Transition fire
T1 fires – one token would be removed from p2 an one from p4; one new token would be placed in p1
T2 fires – one token would be removed from p2, and 2 new tokens would be placed in p3
The number of tokens is not conserved Petri Nets are nondeterministic – if more than one
transition can fire, then any one of them can be fired
Slide 11.81
© The McGraw-Hill Companies, 2007
Petri Net
Inhibitor arc – marked by a small circle No token is needed on an inhibitor input arcs
Slide 11.82
© The McGraw-Hill Companies, 2007
Petri Nets example
Based on the elevator system There are n elevator and m floors Each floor is represented by a place Ff where
1<=f<=m An elevator is represented by a token A token in Ff denotes that an elevator is at floor f The elevator button for floor f is represented in the
Petri Net by place EBf
A token in EBf denotes that the elevator button for floor f is illuminated
Slide 11.83
© The McGraw-Hill Companies, 2007
Elevator problem
If the button EBf is not illuminated, due to the inhibitor arc, the transition EBf pressed is enabled and a token is in EBf
When the button is pressed again, EBf pressed will not fire because of the inhibitor arc (as there is now token in EBf)
If the elevator is to travel from floor g to floor f, transition Elevator in action is enabled because token in Fg and EBf
Token in EBf and Fg will be removed and a new token is placed in Ff
Slide 11.84
© The McGraw-Hill Companies, 2007
Petri Net example
Slide 11.85
© The McGraw-Hill Companies, 2007
Petri Net
Slide 11.86
© The McGraw-Hill Companies, 2007
11.9 Z
Z is a formal specification languageRequires knowledge in set theory, functions,
mathematics etc A Z specification consists of four sections:
1. Given sets, data types, and constants2. State definition3. Initial state4. Operations
Slide 11.87
© The McGraw-Hill Companies, 2007
1. Given sets
Given sets are sets that need not be defined in detail
Names appear in brackets
Here we need the set of all buttons
The specification therefore begins [Button]
Slide 11.88
© The McGraw-Hill Companies, 2007
2. State Definition
Z specification consists of a number of schemataA schema is an outline of a theoryA schema is used to introduce the state variablesA schema consists of a group of variable declarations,
plusDeclarations – the names and types of the entities
introduced in the schemaA list of predicates that constrain the values of variables
and relationships between the entities in declarations
Figure 11.25
Slide 11.89
© 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 buttons buttons (the set of all buttons in the elevator problem) pushed (the set of buttons that have been pushed)
Slide 11.90
© The McGraw-Hill Companies, 2007
Symbols used in Z schema
?
!
if and only if
union
change status
and
or
status not change
input
output
mapping
combining
belong
Slide 11.91
© The McGraw-Hill Companies, 2007
Schema Button_State
Figure 11.26
Slide 11.92
© 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!)
Pushed’ = the updated set
Slide 11.93
© The McGraw-Hill Companies, 2007
4. Operations
ΔButton_state – the operation changes the state A button pushed for the first time is turned on, and
added to set pushed Without the third precondition, the results would be
unspecified
Slide 11.94
© The McGraw-Hill Companies, 2007
Z: The Elevator Problem Case Study (contd)
If an elevator arrives at a floor, the corresponding button(s) must be turned off or removed from the set pushed Pushed \ {button?}
The solution does not distinguish between up and down floor buttons
Figure 11.28
Slide 11.95
© The McGraw-Hill Companies, 2007
11.9.2 Analysis of Z
Z is the most widely used formal specification language
It has been used to specifyCICS (part) – a software system of IBMAn oscilloscopeA CASE toolMany large-scale projects (especially in Europe)
Slide 11.96
© 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.97
© The McGraw-Hill Companies, 2007
Analysis of Z (contd)
Reasons for the great success of Z It 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 informal specification
Slide 11.98
© The McGraw-Hill Companies, 2007
11.10 Other Formal Techniques
Anna For Ada
Gist, RefineKnowledge-based
VDM Uses denotational semantics
CSP CSP specifications are executableLike Z, CSP has a high squiggle factor
Slide 11.99
© 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.100
© The McGraw-Hill Companies, 2007
Comparison of Classical Analysis Techniques (contd)
Figure 11.29
Slide 11.101
© 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.102
© 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.103
© The McGraw-Hill Companies, 2007
11.16 Challenges of Classical Analysis
A specification document must be Informal enough for the client; butFormal enough for the development team
Analysis (“what”) should not cross the boundary into design (“how”)
Do not try to assign modules to process boxes of DFDs until the classical design phase
Slide 11.104
© The McGraw-Hill Companies, 2007
FSM example
Use FSM to describe the operation of a lamp with a push switch.
Consider the control of a small part of a chemical plant. Temperature and pressure levels must be monitored for safety reasons. Sensors are installed to generate appropriate signals when either of these levels exceeds some predefined values. A trivial policy for managing the plant is the following: when either one of the signals is raised by the corresponding sensor, the control system shuts the plant off and raises an alarm signal; the system is restarted manually when the cause of the failure has been rectified.
Slide 11.105
© The McGraw-Hill Companies, 2007
Z example
Apply Z specification to describe part of the library system Identify the setState definition Initial stateOperation of book return