Sie sind auf Seite 1von 100

Slide 11.

Object-Oriented and
Classical Software
Engineering
Fifth Edition, WCB/McGraw-Hill, 2002

Stephen R. Schach
srs@vuse.vanderbilt.edu

© The McGraw-Hill Companies, 2002


CHAPTER 11 Slide 11.2

SPECIFICATION
PHASE

© The McGraw-Hill Companies, 2002


Overview Slide 11.3

● The specification document


● Informal specifications
● Structured systems analysis
● Other semiformal techniques
● Entity-relationship modeling
● Finite state machines
● Petri nets
● Other formal techniques

© The McGraw-Hill Companies, 2002


Overview (contd) Slide 11.4

● Comparison of specification techniques


● Testing during the specification phase
● CASE tools for the specification phase
● Metrics for the specification phase
● Air Gourmet Case Study: structured
systems analysis
● Air Gourmet Case Study: software
project management plan
● Challenges of the specifications phase

© The McGraw-Hill Companies, 2002


Specification Phase Slide 11.5

● Specification document must be


– Informal enough for client
– Formal enough for developers
– Free of omissions, contradictions, ambiguities

© The McGraw-Hill Companies, 2002


Specification Document Slide 11.6

● Constraints
– Cost
– Time
– Parallel running
– Portability
– Reliability
– Rapid response time

© The McGraw-Hill Companies, 2002


Specification Document (contd) Slide 11.7

● Acceptance criteria
– Vital to spell out series of tests
– Product passes tests, deemed to satisfy specifications
– Some are restatements of constraints

© The McGraw-Hill Companies, 2002


Solution Strategy Slide 11.8

● General approach to building the product


● Find strategies without worrying about
constraints
● Modify strategies in the light of constraints, if
necessary
● Keep a written record of all discarded
strategies, and why they were discarded
– To protect the specification team
– To prevent unwise new “solutions” during the
maintenance phase

© The McGraw-Hill Companies, 2002


Informal Specifications Slide 11.9

● 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%”

© The McGraw-Hill Companies, 2002


Meaning of Specification Slide 11.10

● Sales target for January was $100,000, actual


sales were only $64,000 (36% below target)
– Print report

● Sales target for February was $120,000, actual


sales were only $100,000 (16.7% below target)
– Percentage difference for February (16.7%) less than
half of previous month’s percentage difference (36%),
do not print report

● Sales target for March was $100,000, actual sales


were $98,000 (2% below target)
– Percentage difference < 5%, do not print
© The McGraw-Hill Companies, 2002
But Specifications Do Not Say This Slide 11.11

● “[D]ifference between target sales and actual


sales”
– There is no mention of percentage difference
● Difference in January was $36,000, difference in
February was $20,000
– Not less than half of $36,000, so report is printed
● “[D]ifference … [of] 5%”
– Again, no mention of percentage
● Ambiguity—should the last clause read
“percentage difference … [of] 5%” or “difference …
[of] $5,000” or something else entirely?
● Style is poor
© The McGraw-Hill Companies, 2002
Informal Specifications (contd) Slide 11.12

● Claim
– This cannot arise with professional specifications writers
● Refutation
– Text Processing case study

© The McGraw-Hill Companies, 2002


Episode 1 Slide 11.13

● 1969 — Naur Paper


Given a text consisting of words separated by blank 
or by nl (new line) characters, convert it to line-by-
line form in accordance with following rules:
(1) line breaks must be made only where given text
has blank or nl ;
(2) each line is filled as far as possible, as long as
(3) no line will contain more than maxpos characters
● Naur constructed a procedure (25 lines of Algol
60), and informally proved its correctness

© The McGraw-Hill Companies, 2002


Episode 2 Slide 11.14

● 1970 — Reviewer in Computing Reviews


– First word of first line is preceded by a blank unless the
first word is exactly maxpos characters long

© The McGraw-Hill Companies, 2002


Episode 3 Slide 11.15

● 1971 — London found 3 more faults


– Including: procedure does not terminate unless a word
longer than maxpos characters is encountered

© The McGraw-Hill Companies, 2002


Episode 4 Slide 11.16

● 1975 — Goodenough and Gerhart found 3 further


faults
– Including—last word will not be output unless it is
followed by blank or nl
● Goodenough and Gerhart then produced new set
of specifications, about four times longer than
Naur’s

© The McGraw-Hill Companies, 2002


Case Study (contd) Slide 11.17

● 1985 — Meyer detected 12 faults in Goodenough


and Gerhart’s specifications
● Goodenough and Gerhart’s specifications
– Were constructed with the greatest of care
– Were constructed to correct Naur’s specifications
– Went through two versions, carefully refereed
– Were written by experts in specifications
– With as much time as they needed
– For a product about 30 lines long
● What chance do we have of writing fault-free
specifications for a real product?

© The McGraw-Hill Companies, 2002


Episode 5 Slide 11.18

● 1989 — Schach found fault in Meyer’s


specifications
– Item (2) of Naur’s original requirement (“each line
is filled as far as possible”) is not satisfied

© The McGraw-Hill Companies, 2002


Informal Specifications Slide 11.19

● 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

© The McGraw-Hill Companies, 2002


Structured Systems Analysis Slide 11.20

● Three popular graphical specification methods of


’70s
– DeMarco
– Gane and Sarsen
– Yourdon
● All equivalent
● All equally good
● Many U.S. corporations use them for commercial
products
● Gane and Sarsen used for object-oriented design

© The McGraw-Hill Companies, 2002


Structured Systems Analysis Case Study Slide 11.21

Sally’s Software Store 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 Store 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?
● Better question
– What sections?
● Still better
– How? Batch, or online? In-house or out-service?
© The McGraw-Hill Companies, 2002
Case Study (contd) Slide 11.22

● 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

● The danger of many standard


approaches
– First produce the solution, then find out what
the problem is!
● Gane and Sarsen’s method
– Nine-step method
– Stepwise refinement is used in many steps

© The McGraw-Hill Companies, 2002


Case Study (contd) Slide 11.24

● Data flow diagram (DFD) shows logical data flow


– “what happens, not how it happens”

© The McGraw-Hill Companies, 2002


Step 1. Draw the DFD Slide 11.25

● First refinement
● Infinite number of possible interpretations

© The McGraw-Hill Companies, 2002


Step 1 (contd) Slide 11.26

● Second refinement

pending orders scanned daily

© The McGraw-Hill Companies, 2002


Step 1 (contd) Slide 11.27

● Portion of
third
refinement

© The McGraw-Hill Companies, 2002


Step 1 (contd) Slide 11.28

● 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

● Depends on how much client is prepared to spend


● Large volumes, tight controls
– Batch
● Small volumes, in-house microcomputer
– Online
● Cost/benefit analysis

© The McGraw-Hill Companies, 2002


Step 3. Refine Data Flows Slide 11.30

● Data items for each data flow


● Refine each flow stepwise
● Refine further
● Need a data dictionary

© The McGraw-Hill Companies, 2002


Step 3. Refine Data Flows (contd) Slide 11.31

● Sample data dictionary entries


© The McGraw-Hill Companies, 2002
Step 4. Refine Logic of Processes Slide 11.32

● Have process give educational discount


– Sally must explain discount for educational institutions
– 10% on up to 4 packages, 15% on 5 or more
● Translate into decision tree

© The McGraw-Hill Companies, 2002


Step 4 (contd) Slide 11.33

● Advantage of decision tree


– Missing items are quickly apparent

● Can also use decision tables


– CASE tools for automatic translation
© The McGraw-Hill Companies, 2002
Step 5. Refine Data Stores Slide 11.34

● Define exact contents and representation (format)


– COBOL: specify to pic level
– Ada: specify digits or delta
● Specify where immediate access is required
– Data immediate access diagram (DIAD)

© The McGraw-Hill Companies, 2002


Step 6. Define Physical Resources Slide 11.35

● For each file, specify


– File name
– Organization (sequential, indexed, etc.)
– Storage medium
– Blocking factor
– Records (to field level)

© The McGraw-Hill Companies, 2002


Step 7. Determine Input/Output Specs Slide 11.36

● Specify input forms, input screens, printed output

© The McGraw-Hill Companies, 2002


Step 8. Perform Sizing Slide 11.37

● Numerical data for Step 9 to determine


hardware requirements
– Volume of input (daily or hourly)
– Size, frequency, deadline of each printed report
– Size, number of records passing between CPU
and mass storage
– Size of each file

© The McGraw-Hill Companies, 2002


Step 9. Hardware Requirements Slide 11.38

● DASD requirements
● Mass storage for back-up
● Input needs
● Output devices
● Is existing hardware
adequate?
● If not, recommend buy/lease

© The McGraw-Hill Companies, 2002


However Slide 11.39

● Response times cannot be determined


● 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

● The method of Gane and Sarsen/De


Marco/Yourdon has resulted in major
improvements in the software industry

© The McGraw-Hill Companies, 2002


Entity-Relationship Diagrams Slide 11.40

● Semi-formal technique
● Widely used for specifying databases
● Used for object-oriented analysis

© The McGraw-Hill Companies, 2002


Entity-Relationship Diagrams (contd) Slide 11.41

● Many-to-many relationship
● More complex entity-relationship diagrams

© The McGraw-Hill Companies, 2002


Formality versus Informality Slide 11.42

● 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.

© The McGraw-Hill Companies, 2002


Finite State Machines Slide 11.43

● 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

© The McGraw-Hill Companies, 2002


Finite State Machines (contd) Slide 11.44

● Transition table
© The McGraw-Hill Companies, 2002
Extended Finite State Machines Slide 11.45

● Extend FSM with global predicates


● Transition rules have form
state and event and predicate  ⇒  new state

© The McGraw-Hill Companies, 2002


Elevator Problem Slide 11.46

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
elevator to visit corresponding floor. Illumination is
canceled when corresponding floor is visited by elevator
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 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
© The McGraw-Hill Companies, 2002
Elevator Problem: FSM Slide 11.47

● Two sets of buttons


– Elevator buttons—in each elevator, one for each floor
– Floor buttons—two on each floor, one for up-elevator,
one for down-elevator
EB(e, f): Elevator Button in elevator e pressed to request floor f

© The McGraw-Hill Companies, 2002


Elevator Buttons (contd) Slide 11.48

● Two states
EBON(e, f): Elevator Button (e,f) ON
EBOFF(e,f): Elevator Button (e,f) OFF

– If button is on and elevator arrives at floor f, then light


turned off
– If light is off and button is pressed, then light comes on

© The McGraw-Hill Companies, 2002


Elevator Buttons (contd) Slide 11.49

● 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)

© The McGraw-Hill Companies, 2002


Floor Buttons Slide 11.50

● 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

– If floor button is on and an elevator arrives at floor f,


traveling in correct direction d, then light is turned off
– If light is off and a button is pressed, then light comes
on
© The McGraw-Hill Companies, 2002
Floor Buttons (contd) Slide 11.51

● 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

© The McGraw-Hill Companies, 2002


Elevator Problem: FSM (contd) Slide 11.52

● State of elevator consists of


component substates, including:
– Elevator slowing
– Elevator stopping
– Door opening
– Door open with timer running
– Door closing after a timeout

© The McGraw-Hill Companies, 2002


Elevator Problem: FSM (contd) Slide 11.53

● Assume elevator controller moves elevator


through substates
– Three elevator states
M(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, three stopped states S(U, e, f), S(N, e, f),
and S(D, e, f) are grouped into one larger state

© The McGraw-Hill Companies, 2002


Elevator Problem: FSM (contd) Slide 11.54

© The McGraw-Hill Companies, 2002


Elevator Problem: FSM (contd) Slide 11.55

● 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)

© The McGraw-Hill Companies, 2002


Power of FSM to Specify Complex Systems Slide 11.56

● No need for complex preconditions and


postconditions
● Specifications take the simple form
current state and event and predicate ⇒ next state

© The McGraw-Hill Companies, 2002


Power of FSM to Specify Complex Systems Slide 11.57

● Using an FSM, a specification is


– Easy to write down
– Easy to validate
– Easy to convert into design
– Easy to generate code automatically
– More precise than graphical methods
– Almost as easy to understand
– Easy to maintain
● However
– Timing considerations are not handled

© The McGraw-Hill Companies, 2002


Who Is Using FSMs? Slide 11.58

● 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

© The McGraw-Hill Companies, 2002


Petri Nets Slide 11.59

● A major difficulty with specifying real-time


systems is timing
– Synchronization problems
– Race conditions
– Deadlock
● Often a consequence of poor
specifications

© The McGraw-Hill Companies, 2002


Petri Nets (contd) Slide 11.60

● 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

© The McGraw-Hill Companies, 2002


Petri Nets (contd) Slide 11.61

● 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}

© The McGraw-Hill Companies, 2002


Petri Nets (contd) Slide 11.62

● 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 ≥ 0
● is a finite set of transitions, m ≥ 0, with P
T = {t1, t2,…,tm}
and T disjoint
● I : T → P∞ is input function, mapping from transitions to
bags of places
● O : T → P∞ is output function, mapping from transitions
to bags of places
● (A bag is a generalization of sets which allows for
multiple instances of element in bag, as in example
above)
● Marking of a Petri net is an assignment of tokens to
that Petri net
© The McGraw-Hill Companies, 2002
Petri Nets (contd) Slide 11.63

● Four tokens, one in p1, two in p2, none in


p3, and one in p4
– Represented by vector (1,2,0,1)
● Transition is enabled if each of its input
places has as many tokens in it as there
arcs from the place to that transition
© The McGraw-Hill Companies, 2002
Petri Nets (contd) Slide 11.64

● 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
● Important: Number of tokens is not conserved
● Transition t2 is also enabled

© The McGraw-Hill Companies, 2002


Petri Nets (contd) Slide 11.65

● Petri nets are indeterminate


– Suppose t1 fires

● Resulting marking is (2,1,0,0)

© The McGraw-Hill Companies, 2002


Petri Nets (contd) Slide 11.66

● Now only t2 is
enabled
– It fires

● Marking is now
(2,0,2,0)

© The McGraw-Hill Companies, 2002


Petri Nets (contd) Slide 11.67

● More formally, a marking M of a Petri net


C = (P, T, I, O) is a function from the set of places P
to the non-negative integers N
M:P→N
● A marked Petri net is then 5-tuple (P, T, I, O, M )

© The McGraw-Hill Companies, 2002


Petri Nets (contd) Slide 11.68

● 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

● Product is to be installed to control n


elevators in a building with m floors
– Each floor represented by place Ff, 1 ≤ f ≤ m
– Elevator represented by token
– Token in Ff denotes that an elevator is at floor Ff

© The McGraw-Hill Companies, 2002


Elevator Problem: Petri Net (contd) Slide 11.70

● 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

© The McGraw-Hill Companies, 2002


Elevator Problem: Petri Net (contd) Slide 11.71

● A button must be illuminated the first time button


is pressed and subsequent button presses must
be ignored

● If button EBf is not illuminated, no token in place


and transition EBf pressed is enabled
– Transition fires, new token is placed in EBf
● Now, no matter how many times button is
pressed, transition EBf pressed cannot be enabled
© The McGraw-Hill Companies, 2002
Elevator Problem: Petri Net (contd) Slide 11.72

● When elevator reaches floor g, token is in place Fg,


transition Elevator in action is enabled, and then
fires
– Tokens in EBf and Fg removed
– This turns off light in button EBf
– New token appears in Ff
– This brings elevator from floor g to floor f

© The McGraw-Hill Companies, 2002


Elevator Problem: Petri Net (contd) Slide 11.73

● Motion from floor g to floor f


cannot take place instantaneously
– Timed Petri nets

© The McGraw-Hill Companies, 2002


Elevator Problem: Petri Net (contd) Slide 11.74

● 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

© The McGraw-Hill Companies, 2002


Elevator Problem: Petri Net (contd) Slide 11.75

© The McGraw-Hill Companies, 2002


Elevator Problem: Petri Net (contd) Slide 11.76

● The situation when an elevator reaches floor f


from floor g with one or both buttons illuminated
– If both buttons are illuminated, only one is turned off
– (A more complex model is needed to ensure that the
correct light is turned off)

© The McGraw-Hill Companies, 2002


Elevator Problem: Petri Net (contd) Slide 11.77

● 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

© The McGraw-Hill Companies, 2002


Petri Nets (contd) Slide 11.78

● Petri nets can also be used for design


● Petri nets possess the expressive power
necessary for specifying timing aspects of
real-time systems

© The McGraw-Hill Companies, 2002


Z (“zed”) Slide 11.79

● Formal specification language


● High squiggle factor
● Z specification consists of four sections:
– 1. Given sets, data types, and constants
– 2. State definition
– 3. Initial state
– 4. Operations

© The McGraw-Hill Companies, 2002


Elevator Problem: Z Slide 11.80

● 1. Given Sets

● Sets that need not be defined in detail


– Names appear in brackets
– Here we need the set of all buttons
– Specification begins
[Button]

© The McGraw-Hill Companies, 2002


Elevator Problem: Z (contd) Slide 11.81

● 2. State Definition

● Z specification consists of a number of schemata


– Schema consists of group of variable declarations, plus
– List of predicates that constrain values of variables

© The McGraw-Hill Companies, 2002


Elevator Problem: Z (contd) Slide 11.82

● Four subsets of Button


– The floor buttons
– The elevator buttons
– buttons (the set of all buttons in the elevator problem)
– pushed (the set of buttons that have been pushed)

© The McGraw-Hill Companies, 2002


Elevator Problem: Z (contd) Slide 11.83

● Schema Button_State
© The McGraw-Hill Companies, 2002
Elevator Problem: Z (contd) Slide 11.84

● 3. Initial State

● State when the system is first turned on

Button_Init ≡ [Button_State' | pushed' = ∅]

– (In the above equation, the ≡ should be a = with a ^ on


top. Unfortunately, this is hard to type in PowerPoint!)

© The McGraw-Hill Companies, 2002


Elevator Problem: Z (contd) Slide 11.85

● 4. Operations

● Button pushed for first time is turned on, and


added to set pushed
● Without third precondition, results would be
unspecified
© The McGraw-Hill Companies, 2002
Elevator Problem: Z (contd) Slide 11.86

● If elevator arrives at a floor, the corresponding


button(s) must be turned off
● The solution does not distinguish between up and
down floor buttons
© The McGraw-Hill Companies, 2002
Analysis of Z Slide 11.87

● Most widely used formal specification language


– CICS (part)
– Oscilloscope
– CASE tool
– Large-scale projects (esp. Europe)

© The McGraw-Hill Companies, 2002


Analysis of Z (contd) Slide 11.88

● 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

© The McGraw-Hill Companies, 2002


Other Formal Methods Slide 11.89

● 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

● We must always choose the appropriate


specification method
● Formal methods
– Powerful
– Difficult to learn and use
● Informal methods
– Little power
– Easy to learn and use
● Trade-off
– Ease of use versus power

© The McGraw-Hill Companies, 2002


Comparison of Specification Techniques (contd) Slide 11.91

© The McGraw-Hill Companies, 2002


Newer Methods Slide 11.92

● Many are untested in practice


● Risks
– Training costs
– Adjustment from classroom to actual project
– CASE tools may not work properly
● However, possible gains may be huge

© The McGraw-Hill Companies, 2002


Which Specification Method to Use? Slide 11.93

● Depends on the
– Project
– Development team
– Management team
– Myriad other factors

● It is unwise to ignore the latest developments

© The McGraw-Hill Companies, 2002


Testing during the Specification Phase Slide 11.94

● Specification inspection
– Checklist
● Doolan [1992]
– 2 million lines of FORTRAN
– 1 hour of inspecting saved 30 hours of
execution-based testing

© The McGraw-Hill Companies, 2002


CASE Tools for the Specification Phase Slide 11.95

● Graphical tool
● Data dictionary
– Integrate them
● Specification method without CASE tools fails
– SREM

© The McGraw-Hill Companies, 2002


CASE Tools for the Specification Phase Slide 11.96

● Typical tools
– Analyst/Designer
– Software through Pictures
– System Architect

© The McGraw-Hill Companies, 2002


Metrics for the Specification Phase Slide 11.97

● Five fundamental metrics


● Quality
– Fault statistics
– Number, type of each fault
– Rate of detection
● Metrics for “predicting” size of target product
– Total number of items in data dictionary
– Number of items of each type
– Processes vs. modules

© The McGraw-Hill Companies, 2002


Air Gourmet Case Study: Structured Sys. Anal. Slide 11.98

● Data flow diagram


reflects centrality
of SPECIAL MEAL DATA
● See Appendix E
for remainder of
structured systems
analysis

© The McGraw-Hill Companies, 2002


Air Gourmet Case Study: SPMP Slide 11.99

● The Software Project Management Plan is given


in Appendix F

© The McGraw-Hill Companies, 2002


Challenges of the Specification Phase Slide 11.100

● A specification document must be


– Informal enough for the client; and
– Formal enough for the development team
● The specification phase (“what”) should not cross
the boundary into the design phase (“how”)
● Do not try to assign modules to process boxes of
DFDs until the design phase

© The McGraw-Hill Companies, 2002

Das könnte Ihnen auch gefallen