Cai

Chapter 5: Specification
Yuanfang Cai
CS751 Jan 29, 2003
Overview
Definition
5.1 The Uses of Specification
5.2 Specification Qualities
5.3 Classification of Specification Styles
5.4 Verification of Specification
5.5 Operational Specifications
5.6 Descriptive Specifications
5.7 Building and Using Specifications in Practice
Overview
Definition
Overview
Definition
5.5.1 Data Flow Diagram (DFD): Function
5.5.2 Unified Modeling Language (UML): Behavior
5.5.3 Finite State Machine (FSM): Control Flow
5.5.4 Petri Nets: Asynchronous Systems

Overview
Definition
5.6.1 Entity Relationship Diagrams
5.6.2 Logic Specification
5.6.3 Algebraic Specifications
Definition
The statement of an agreement between a producer of a
service and the consumer of the service or between an
implementer and a user
Requirement specification
Design specification
Module specification
Requirements, Specification and Design
Definition
Between end user and the system architect/developer
Definition

Between the architect and the implementers
Definition

Between the architect and the implementers
Between the implementer and the user of a module
5.1 The use of Specifications

A statement of user requirement
A statement of interface between the
machine and the controlled environment
A statement of requirements for the
implementation
A reference point during product
maintenance.
5.2 Specification Quality

Clear, unambiguous and understandable
Consistency
Complete
Internally complete
Externally complete

Formal, informal and Semiformal
Specifications
Operational and descriptive specifications
Operational specifications: desired behavior

Descriptive specifications: desired properties
5.4 Verification of Specifications

Dynamic analysis
Static analysis
Formalism and verification
Simulation
Prototype
Verify all three aspects:
Functional
Consistency
completeness

5.5.1 Data Flow diagrams
Features
Example
limitations
5.5.2 UML Diagram for Specifying Behaviors

5.5.3 Finite State Machine: Describing Control Flow
5.5.4 Pretri Nets: Specifying Asynchronous Systems
5.5.1 Data Flow Diagram: Specifying

Functions of Information Systems
Features
Describe systems as collections of functions that manipulate

data
Can be expressed by means of graphical notation
Elements:
Input device symbol
Output device symbol
Function symbol
Data flow
Data store symbol
5.5.1 DFD Example

d
(a + b) * ( c + a * d)
5.5.1 DFD limitations

The semantics of the symbol is specified
only by the identifiers chosen by the user.
Control aspects are not defined by the model
A
E
D
F
5.5.1 DFD Limitations

A
E
D
F
5.5.1 DFD Limitations

A
E
D
F

Features
Example
Limitations


Definiation
Features
Example
Limitations
5.5.3 Finite State Machines:

Describing Control Flow
Definition
A finite automata is a 5-tuple (Q, , , q0, F),
where
1.
Q is a finite set called the states,
is a finite set called the alphabet (inputs),
: Q Q is the transition function,

4.
q0 Q is the start state, and
5.
F Q is the set of accept states (final states).

Features
Formal notation
Suitable for describing systems that can be in a
finite set of states and that can go from one
state into another as a consequence of some
event, modeled by an input symbol.
Widely used: specification of control systems,
compilation, pattern matching, etc.

Example
Push switch
Off
On
Push switch

Example: Chemical plant

High-pressure alarm
High-temperature alarm
Off
On
Restart

Example: Chemical plant

Pressure signal
Normal
Temperature signal
Temperature signal
Pressure
Recovery
Successful
Unsuccessful
recovery
recovery
Successful
Unsuccessful
recovery
recovery
Temperature
Recovery
Off
Pressure signal

Limitations
Finite states: need assistance such as natural language or

accompanied by action descriptions, like:
Cooling_effort := k * (present_temperature standard temperature)
Cant describe concurrent, asynchronous systems.

consume
write
P2
P1
C2
C1
read
produce
write
write
empty
0
read
2
read
full
5.5.3 FSM: Describing Control Flow
Example continued: the Cartesian Product of the component state sets:

write
write
<0,p1,c1>
<2,p1,c1>
<1,p1,c1>
consume
consume
consume
Produce
Produce
Produce
<0,p2,c1>
<0,p1,c2>
<2,p1,c2>
<1,p1,c2>
read
read
Produce
<0,p2,c1>
<1,p2,c1>
read
Produce
Produce
read
write
consume
consume
consume
<0,p2,c2>
<1,p2,c2>
<2,p2,c2>

Limitations:
The cardinality of the state space grows dramatically:

if we have n subsystems, each with ki states, the
resulting system has a cardinality of k1*k2*Kn
FSM are essentially a synchronous model: at any

time, a global state of the system must be defined and
a single transition must occur.

Definition
Example
Features
Limitations
5.5.4 Petri Nets: Specifying

Asynchronous System
Definition
A Petri Net is a quadruple (P, T, F, W), where
1.
P is the finite set of places;
2.
T is a finite set of transitions;
3.
P T ;
4.
F { P T} { T P} is the flow relation; and
5.
W: F N {0} is the weight function, which associates
a nonzero natural value to each element of F. If no
weight value is explicitly associated with a flow
element, the default value 1 is assumed for the function

Asynchronous System
Example:
p2 is the input place of transition write
Transition
p1 is the output place of transition write
write
Produce is the enabled, so transition

produce may fire
Place
p2
p1
Token
produce

Asynchronous System
Example:
Transition
write
Produce is the enabled, so transition

produce may fire
Place
p2
p1
Token
2
produce

Asynchronous System
Example: After produce fired
Transition
write
Now, write is the enabled, so transition

write may fire
Place
p2
p1
2
produce
Token
5.5.4 PN: Specifying Asynchronous System

Example: producer and consumer
write
consume
p2
p1
c2
c1
produce
read
read
read
write
write

Example continued:
producer and consumer:
consume
c2
c1
read
Now the system is at the state

<0, p1, c1>
read
write
p1
write
p2
produce

Example continued:
consume
c2
c1
read

<0, p2, c1>
read
write
p1
write
p2
produce

Example continued:
consume
c2
c1
read

<1, p2, c1>
read
write
p1
write
p2
produce

Asynchronous System
Features
Good at describing concurrent and asynchronous
system
Limitations
Tokens are anonymous

Cant specify a selection policy
Cant resolve deadlock or starving

5.6.1 Entity Relationship (ER) Diagrams
A semiformal notation
5.6.2 Logic Specification
5.6.3 Algebraic Specifications

NAME
Entities:
a collection of items that
share common properties
AGE
STUDENT
SEX
Relations:
A set of pairs <a, b>, where
a is an element of
STUDENT and b is an
element of CLASS
Attribute:
ENROLLED_IN
SUBJECT
CLASS
COURSE_ID
MAX_ENROLLMENT

Relation Attributes:
A
A R B is one to one
A R B is one to many
A R B is many to one
A R B is many to
many
Unified Modeling Language

A general-purpose visual modeling language
that is used to specify, visualize, construct
and document the artifacts of a software
system.
Static Structure (Descriptive)
Dynamic behavior (Operational)

Static Structure (Descriptive)
Static view: class diagram

User Case View
Physical Views
Implementation view
Deployment view
Dynamic behavior (Operational)
Interaction view
Sequence diagram
Collaboration diagram
State machine view

Activity view

Static Structure (Operational)
Static View: class diagram

User Case View
Physical Views
Implementation view
Deployment view
Dynamic behavior (Descriptive)
Interaction view
Sequence diagram
State machine view

Activity view
Class
Customer
Name: String
Phone: String
Add(name,phone)
Class Diagram:
attributes
class-scope operation
1
association
*
Reservation
Date: Date
Show
generalization
Name: String
Subscription Series
Individual
Reservation
Series: integer
multiplicities
0..1
0..1
3..6
Ticket
1..*
Performance
Available: Boolean
Sell (c. Customer)
Exchange()
Seat: Sting
qualifier
Date: Date
Time: TimeOfDay
Use Case Diagram:
system
actor
buy
tickets
<<include>>
relationship
Clerk
buy
subscription
<<include>>
Kiosk
make
charges
Credit card service

Use case
survey
sales
Supervisor

Static Structure (Operational)
Static View: class diagram

User Case View
Physical Views
Implementation view
Deployment view
Dynamic behavior (Descriptive)
Interaction view
Sequence diagram
State machine view

Activity view
Sequence Diagram
Active object
credit card service
box office
Kiosk
Request (count, performance)

Show availability (seat-list)
lifeline (active)
Select(seats)
Demand payment(cost)
Insert card(card number)
message
charge(card number,cost))
authorized
Print tickets (performance,

seats)
Eject card
Collaboration
Diagram:
active object
Kiosk
1:request (count, performance)
link
4: offer(seat-list)
5:buy(seats)
8:confirm (seats, cost)
ticketseller
3: seat-list := lock(count)
6: claim (seats)
7: unlock(seat-list)
<<local>>db
transient link
message
2: db := findDB(performance)
performanceGuide
passive object
Db: performanceDB
multi object
Db: performanceDB
State chart Diagram

Assign to subscription
Initial state
Time out
Available
lock
state
Locked
buy
Sold
unlock
transition
exchange
Trigger event
Activity Diagram
Pick show
activity
schedule show
fork
publicize show
Hire
artists
Buy scripts
and music
Sell tickets
Build
sets
Design
lighting
Completion
transition
rehearse
Dress rehearsal
join
perform
Make
costumes
Questions?

Cai

Uploaded by

Document Information

Original Description:

Original Title

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

Cai

Uploaded by

Copyright:

Available Formats

Chapter 5: Specification

5.6 Descriptive Specifications

Requirements, Specification and Design

Between end user and the system architect/developer

Requirements, Specification and Design

Between end user and the system architect/developer

Requirements, Specification and Design

Between end user and the system architect/developer

Between the implementer and the user of a module

Requirements, Specification and Design

5.1 The use of Specifications

5.2 Specification Quality

5.3 Classification of Specification Styles

Operational specifications: desired behavior

5.4 Verification of Specifications

Verify all three aspects:

5.5 Operational Specifications

5.5.2 UML Diagram for Specifying Behaviors

5.5.1 Data Flow Diagram: Specifying

Describe systems as collections of functions that manipulate

Output device symbol

5.5.1 DFD Example

5.5.1 DFD limitations

5.5.1 DFD Limitations

5.5.1 DFD Limitations

5.5 Operational Specifications

5.5.3 Finite State Machine: Describing Control Flow

5.5 Operational Specifications

5.5.4 Pretri Nets: Specifying Asynchronous Systems

5.5.3 Finite State Machines:

is a finite set called the alphabet (inputs),

: Q Q is the transition function,

5.5.3 Finite State Machines:

5.5.3 Finite State Machines:

5.5.3 Finite State Machines:

Example: Chemical plant

5.5.3 Finite State Machines:

Example: Chemical plant

5.5.3 Finite State Machines:

Finite states: need assistance such as natural language or

Cant describe concurrent, asynchronous systems.

5.5.3 FSM: Describing Control Flow

Example continued: the Cartesian Product of the component state sets:

5.5.3 Finite State Machines:

The cardinality of the state space grows dramatically:

FSM are essentially a synchronous model: at any

5.5 Operational Specifications

5.5.4 Petri Nets: Specifying

5.5.4 Petri Nets: Specifying

p1 is the output place of transition write

Produce is the enabled, so transition

5.5.4 Petri Nets: Specifying

p1 is the output place of transition write

Produce is the enabled, so transition

5.5.4 Petri Nets: Specifying

p1 is the output place of transition write

Now, write is the enabled, so transition

5.5.4 PN: Specifying Asynchronous System

5.5.4 PN: Specifying Asynchronous System

Now the system is at the state

5.5.4 PN: Specifying Asynchronous System

Now the system is at the state