1 CSE 2102 Chapter 5: Software Chapter 5: Software Specification Specification Prof. Steven A. Demurjian Computer Science & Engineering Department The University of Connecticut 371 Fairfield Road, Box U-4155 Storrs, CT 06269-4155 [email protected]http://www.engr.uconn.edu/ ~steve (860) 486 – 4818 (860) 486 – 3719 (office)
177
Embed
1 CSE 2102 CSE 2102 Chapter 5: Software Specification Prof. Steven A. Demurjian Computer Science & Engineering Department The University of Connecticut.
This document is posted to help you gain knowledge. Please leave a comment to let me know what you think about it! Share it to your friends and learn new things together.
Inconsistencies May be Impossible to Implement Complexity May Lead to Inconsistency Inconsistencies Lead to Incorrect Implementation
Completeness Internally Complete: Specification Defines any
new Concept or Terminology that it Uses W.r.t. Requirements; All Requirements Should be
Contained within Specification How Does the Achievement of Software Qualities
Affect the Attainment of Specification Qualities? Incremental: Both Spec Process and Document built
over Time
10
CSE
2102
CSE
2102
Clear, Unambiguous, Understandable Specification Fragment for a Word-Processor Can an Area be Scattered, or Must it be Contiguous?
Selecting is the process of designating areas of the document that you want to work on. Most editing and formatting actions require two steps: first you select what you want to work on, such as text or graphics; then you initiate the appropriate action.
11
CSE
2102
CSE
2102
Precise, Unambiguous, Clear Consider a Real-Time Safety-Critical System Can a message be accepted as soon as we receive 2
out of 3 identical copies of message or do we need to wait for receipt of the 3rd?
The message must be triplicated. The threecopies must be forwarded through three
different physical channels. The receiver accepts the message on the basis of a
two-out-of-three voting policy.
12
CSE
2102
CSE
2102
Consistent Specification Fragment for a Word-Processor What if the length of a word exceeds the length of the
line? What should the action of the editor be?
The whole text should be kept in lines of equal length. The length is specified by the user. Unless the user gives an
explicit hyphenation command, a carriage return should occur only
at the end of a word.
13
CSE
2102
CSE
2102
Specification Styles Informal: Natural Language, Spec by Visio/PPT,
Figures, Tables, etc. Formal: Notation with precise Syntax/Semantics
Advantages: May Allow Formal Verification May Support Automatic Processing (Code Gen) Allows Use of Mathematical Models May be Used to Generate Test Cases (Chapter 6)
Disadvantages: Formal Specifications Not Widely Used Hard to Justify Economic Gain Training Issues for Personnel
Semi-Formal: No Precise Semantics (TDN/GDN)
14
CSE
2102
CSE
2102
Specification Styles Operational
Describes Desired Behavior of System Usually Provides a Model of System Behavior Verified by Prototyping
Descriptive Describes Desired Properties of System Declarative Specification Usually Uses Mathematical Equations More Abstract than Operation Specification
No Focus on Implementation Actual Specifications – Mix of Both…
15
CSE
2102
CSE
2102
Operational Specification Example Consider a geometric figure E:
E can be drawn as follows:1. Select two points P1 and P2 on a plane2. Get a string of a certain length and fix its ends
to P1 and P23. Position a pencil as shown in next figure4. Move the pen clockwise, keeping the string
tightly stretched, until you reach the point where you started drawing
P P 1 2
16
CSE
2102
CSE
2102
Verification of Specifications Two Approaches:
“Observe” Dynamic Behavior of Specified System (Simulation, Prototyping, “Testing” specs)
Analyze Properties of the Specified System Both Depend on Formality of Specification Analogy with Traditional Engineering
Physical Model of a Bridge Build An Actual Model Test it out in Wind Tunnel
Mathematical Model of a Bridge What’s Reality of Bridge Building?
Guarantee of Success w.r.t. Weight, Weather, etc. Are there Similar Guarantees in Software? What Software Applications Need Such Guarantees?
17
CSE
2102
CSE
2102
Operational Specifications Allow the Behavior of a System to be Defined Many Complementary Techniques
Data Flow Diagrams UML Diagrams
Operational Specifications Provide Means to Model System from Alternative Perspectives Perspectives Must be Consistent with One Another Some Techniques Target End-User/Customer Others are More Software Engineering Intensive Key Issue: All Diagrams Must be Consistent in
Terminology to Yield Strong Result
18
CSE
2102
CSE
2102
Verification of Specifications “Observe” dynamic behavior of the specified system:
Simulation, prototyping, testing specifications Analyze system properties, by analyzing results or
outputs of the system Both the techniques depend on the formality of
specifications Also have to verify completeness and consistency
May be done mathematically or mechanically For example, queuing models.
18
19
CSE
2102
CSE
2102
Data Flow Diagrams (DFDs) A Semi-Formal Operational Specification System Viewed as Collection of Data Manipulated by
“Functions” Data can be Persistent - Stored in Data Repositories Input State to Represent Trigger of Data Flow Output State(s) to Represent Result of Data Flow Data can Flow from Input to Function to/from
Repositories to Output DFDs have a Graphical Notation
Tools are Commercially Available www.qsee-technologies.com/multi-case.htm www.aisintl.com/case/products/PowerDesigner/sdesign.html
20
CSE
2102
CSE
2102
DFDs: Structured Analysis and Design Structured Analysis/Structured Design (SA/SD) most
popular analysis and design method since the 1970s. Sophisticated function-oriented analysis and design
methods. Created in 1970s, has evolved and been refined by
many people since then: Newer and older versions are in use. Extensions for special domains (for example, real-
time systems) are widely used. Supported by many CASE tools. Documented in many popular books. Influenced many other design methods.
21
CSE
2102
CSE
2102
Data Flow Diagrams Provide a semantic bridge between users and system
developers. Logical representation of WHAT a system does, rather
than physical models showing HOW it does it Hierarchical, showing systems at any level of detail Jargonless, allowing user understanding and reviewing Basis of Structured Analysis/Structured Design
methodology.
22
CSE
2102
CSE
2102
DFDs: Objectives Avoiding the cost of:
User/developer misunderstanding of a system, resulting in a need to redo systems or in not using the system
Having to start documentation from scratch when the physical system changes since the logical system, WHAT gets done, often remains the same when the technology changes
Systems inefficiencies because a system gets “computerized” before it gets “systematized”
Being unable to evaluate system project boundaries or degree of automation, resulting in a project of inappropriate scope
23
CSE
2102
CSE
2102
DFDs Employ a Graphical Notation What are Main Modeling Constructs?
Bubbles Represent Functions Arcs (Arrows) Data Flows Open Boxes Represent Persistent Store Closed Boxes Represent I/O Interaction
Note: DFDs can not Represent Sequential Steps
The function symbol
The data flow symbol
The data store symbol
The input device symbol
The output device symbol
24
CSE
2102
CSE
2102
Methodology of Information SystemMethodology of Information System
... ...
Input 1
Input2
Input n
Output1
Output2
Outputm
information
system
1. Start from the “context” diagram
25
CSE
2102
CSE
2102
Methodology of Information SystemMethodology of Information System
A
A1
A3
A2
A4
A5
A6
A7
B1
B2
B3B4
Ag
IO
I
O
H
K
J
M
N
P Q
R
S
K
T
K1
K2
K3
K4
M
N
2. Proceed by refinements until you reach “elementary” functions (preserve
balancing)
26
CSE
2102
CSE
2102
A Library Example DFDA Library Example DFD
Shelves
List of Authors
List of titles
List of topics
Title and author of requested book; name of the user
Get a book
Book
List of books borrowed
Book title; user name
Topic request by the user
Search by topics
Book request by the user
Book reception
TopicList of titles referring to the topic
Book
Author
Title
Display of the list of titles
Topic
Title
27
CSE
2102
CSE
2102
Refinement of “Get a book”Refinement of “Get a book”
Shelves
List of Authors
List of titles
Title and author of requested book; name of the user
Book
List of books borrowed
Book title; user name
Book request by the user
Book reception
Book
Author
TitleFind book position
<shelf#, book#>
Get the book
28
CSE
2102
CSE
2102
Patient Monitoring SystemsPatient Monitoring Systems
The purpose is to monitor the patients’ vital factors--blood,pressure, temperature, …--reading them at specified frequencies
from analog devices and storing readings in a DB. If readings fall outside the range specified for patient or device fails an alarm
must be sent to a nurse. The system also provides reports.
Patient
Nurse
PatientMonitoring
Nurse
Persistent data
Report
AlarmDataClinical
ReportRequest
Recent data
Data for report
29
CSE
2102
CSE
2102
A Refinement as Detailed DFDA Refinement as Detailed DFD
Nurse
Nurse
Patient archive
ReportRequest
Limits for patient
MonitoringCentral
Limits
Updatearchive
GenerateReport
Data forReport
RecentData
Formatted data
Alarm
PatientClinicalDataMonitoring
Local
Patient data
Report
30
CSE
2102
CSE
2102
Further RefinementFurther Refinement
Limits
Formatted data alarm
dataPatient
decode
Check
violations limit
Temperature
Pulse
Pressure
Result
Pressure, pulse…
Format
data clockDate Time
producemessage
31
CSE
2102
CSE
2102
A High-Level DFD for HTSSA High-Level DFD for HTSS
32
CSE
2102
CSE
2102
A High-Level DFD for HTSSA High-Level DFD for HTSS
33
CSE
2102
CSE
2102
A Lower-Level DFD for HTSSA Lower-Level DFD for HTSS
34
CSE
2102
CSE
2102
DFDs: Levels DFDs can be drawn at multiple levels, each level
represents a refinement of diagram at next higher level Topmost level of DFD is called the Context diagram Context diagram:
Entire system is shown as a single process Communication of the system with external
entities is shown by data flows Every system has one context diagram
Level 1 DFD: Main functional areas of the system Every system has only one level 1 DFD Beyond Level 1 DFD there are a series of lower
level diagrams
35
CSE
2102
CSE
2102
DFDs: Levels Level 2 DFD:
Explodes each process in Level 1 diagram into lower level DFDs
Rule of thumb: Between 3 and 9 processes in a DFD
Each process in a Level 2 DFD can be further exploded to form a Level 3 DFD and so on… Lines coming into and leaving the process node
must be present in the lower level DFD Process of successive refinement is called top-down
expansion Usually not advisable to go beyond Level 3 DFD When to stop expanding?
36
CSE
2102
CSE
2102
DFDs: Hints for Construction Read the problem description to I
Identify and underline “candidate” processes (usually verbs)
Describing some way in which data manipulated Reread the text to identify input-output data flows for
each process Do the same for external entities and data stores All data flows must be labeled, label identifies the data
Do not use verbs such as employee sends invoice All external entities, processes, and data stores should
be properly numbered
37
CSE
2102
CSE
2102
DFD: Course Registration System DFD: Course Registration System
Consider a course registration system. When a student provides a prioritized list of courses and other information to the system, this
information is transformed into a list of preferences. The list of preferences is used to verify the eligibility of the students
using the student records and the course prerequisites. If the student is eligible to register for the courses he/she desires, thenthe student is enrolled in those courses, and the class scheduleis communicated back to the student. In addition, the system
also compiles the list of students enrolled in each class using the registration information for each student. This list is then given to
the faculty. The list is also forwarded to the registrar so that a classroomof an appropriate capacity can be allocated depending on the number of
students enrolled.
38
CSE
2102
CSE
2102
DFD: Course Registration SystemDFD: Course Registration System
Registrar
Faculty Students
Class list
Courses & other info.
Class schedule
Context Diagram for Course Registration System
Registrar
RegistrationProcess
39
CSE
2102
CSE
2102
DFD: Course Registration SystemDFD: Course Registration System
Registrar
1. Enroll Students
2. Compile &Distribute
Information
Students
FacultyStudents
Courses &Other info.
Individual CourseRegistrationInformation
SchedulesClass Lists
Level 1 DFD
Note: External entity Students is replicated to avoid crossing lines
Registrar
40
CSE
2102
CSE
2102
DFD: Course Registration SystemDFD: Course Registration System
Level 2 DFD
1.1 Obtain Student
Preferences
1.2 CheckEligibility
Student Records Course Prereqs
1.3 Enroll Studentsin Classes
Courses &Other info.
List ofPreferences
Eligible Students
Individual course registration information
41
CSE
2102
CSE
2102
Evaluating DFDs Easy to Read, but … Informal Semantics
How Does One Define Leaf Functions? Inherent Ambiguities in Flow
Consider the DFD (Functions) Below:
A
C
E
B
F
D
• Are Outputs from A, B, Call needed Before D isEnabled?
• What if Only A and B Present?• Do A, B, and C have to be
Received in a Particular Order?• Outputs for E and F are
produced at the same time?
42
CSE
2102
CSE
2102
Evaluating DFDs Clearly, Control Information is Absent
DFDs are a Semi-Formal Notation DFDs by Visio and PPT Excellent Vehicle for Presenting to End-User Not Standalone – Need Complementary
Diagram(s) to Fully Specify System Capabilities
BA
Possible interpretations:(a) A produces datum, waits until B consumes it(b)B can read the datum many times without
consuming it(c) a pipe is inserted between A and B
43
CSE
2102
CSE
2102
Finite State Machines (FSMs) Utilized to Specify control flow aspects An FSM Consists of:
A finite set of states (nodes), Q; A finite set of inputs (labels), I; A transition function d : Q x I Q
(d can be a partial function) FSMs are Well Suited to
Represent Systems with Multiple Known States Well-Defined Events
for State Changes
a a
b
bc
q
q
q
q
1
20
3
44
CSE
2102
CSE
2102
Classic FSM Examples
On Off
Push switch
Push switch
On Off
High-pressure alarm
High-temperature alarm
Restart
45
CSE
2102
CSE
2102
FSM’s Can Model Real World Consider a Refinement of High Pressure/High
Temperature FSM on Previous Slide
Pressure signal Temperature signal
Successful recovery
Unsuccessful recovery
OffNormal
Pressure action
OffNormal
Pressure action
Temperature signalTemperature action
Successful recovery
Unsuccessful recovery
Pressure signal
46
CSE
2102
CSE
2102
FSM for HTSS Totals a Customer’s Order
ProcessPayment
No More Coupons
Next Coupon
47
CSE
2102
CSE
2102
Classes of FSMs Deterministic/Nondeterministic FSMs as Recognizers - Introduce Final States FSMs
Used for Lexical Analysis in Compilers Realize Regular Expressions in Automata
q
q q q q
q q
q
b
e g i
n
e
n
d
0
1 2 3 4
5 6
fq0 is an initial state
qf is a final state
48
CSE
2102
CSE
2102
FSMs as Recognizers FSMs as transducers - introduce set of outputs
q <letter>
<letter>
_
<digit>
q q
<letter> Legend: is an abbreviation for a set of arrows
labeled a, b,..., z, A,..., Z, respectively
is an abbreviation for a set of arrows labeled 0, 1,..., 9, respectively <digit>
0 1 2
<letter>
<digit>
49
CSE
2102
CSE
2102
FSMs as recognizers (contd..)FSMs as recognizers (contd..)
q1 q2 q3 q4
q5 q6 q7 q8
qfq0
br e a
d
h
w r i
ot
e
What are the strings accepted by this FSM?
50
CSE
2102
CSE
2102
FSM Usage and Limitation FSMs are Simple and Widely Used
Control Systems, Compilation Pattern Matching, Hardware Design
Most Software Applications can be Modeled via FSMs In Practice, FSMs are Good for Sample or Portions of
System – Problems Can Arise: Model Different Portions of Application Compose FSMs for Entire System View Finite Memory Yields State Explosion
Suppose n FSMs with k1, k2, … kn states
Composition is a FSM with k1 * k2 *… * kn.
This growth is exponential with the number of FSMs, not linear (we would like it to be k1 + k2 +… + kn )
51
CSE
2102
CSE
2102
Example of State Explosion: Consider Three Individual FSMs:
Producer
p1
c2
Storage
1
produce
deposit
get
consume
deposit
get get
deposit
p2
Consumer
c1
20
52
CSE
2102
CSE
2102
Composition: The Resulting FSM Clearly, Complexity Has Increased
<0, p ,c >
<0, p ,c >
consume
produce
consume
produce
consume
produce
consume
produce
produce produce
consume consume
write
read
write
read
read
write read
write
1
1 2
<0, p , c >
1
2 2
<1, p ,c >
<0, p ,c >
1 1
<1, p ,c>
<1, p ,c >
<1, p ,c >
2 1
1 2
1
2
2 2 <2, p ,c > 2 2
<2, p ,c > 1 2
<2, p ,c > 2 1
<2, p ,c > 1 1
53
CSE
2102
CSE
2102
FSMs Summary Simple and widely used:
Control systems & Compilation Pattern matching & Hardware design
Most software can be modeled using FSMs FSMs may become complex:
Approximate requirements Switch models Enrich the model (predicates for transitions)
FSMs can be composed to create new FSMs Combine arcs where necessary Cardinality may grow (state explosion problem)
FSMs Equate to Statechart Diagrams in UML
54
CSE
2102
CSE
2102
Petri Nets Introduced by C. Adams Petri in 1960 Widely used in the modeling and analysis of computer
systems Basic elements:
Places Transitions Directed arcs Tokens
55
CSE
2102
CSE
2102
Basic ElementsBasic Elements
Legend:PlaceTransitionDirected arc
P1
P2
P3
t1
Token
56
CSE
2102
CSE
2102
Basic ElementsBasic Elements
P1
P2
P3
t1
Input place: Directed arc from a place to a transition Place is an input place to the transition
P1 is an input place to transition t1
Output place: Directed arc from a transition to a place Place is an output place of the transition
P3 is an output place of transition t1
57
CSE
2102
CSE
2102
Basic ElementsBasic Elements
P1
P2
P3
t12
Weighted connection: - Multiple arcs between a place and a transition. - Represented as a single arc, labeled with a natural
number called weight.Weight of the connection between P1 and t1 is 2. Default weight is 1.
58
CSE
2102
CSE
2102
Static Structure Net structure:
Static part of the system. Marking:
Overall state on the structure. Distribution of tokens among the places Marked place: Place with one or more tokens Umarked place: Place with no tokens Local state: Number of tokens in a place Overall state: Number of tokens in each place.
58
59
CSE
2102
CSE
2102
59
State of PNState of PN
P1
P2
P3
t1
Local State: P1 – 1 P2 – 0 P3 – 0
Overall State: <1,0,0>
60
CSE
2102
CSE
2102
Petri Nets Petri Nets are Another Graphical Formalism for
System’s Specification Consisting of: Finite Set of Places (Circles – Pi’s) Finite set of Transitions (Horizontal Lines – tj’s) Finite Set of Arrows Connecting Places to
Transitions and Transitions to Places Tokens (Dots)
61
CSE
2102
CSE
2102
Petri Nets – Other Concepts Marking: Assigning Non-Negative Integers to Places
Which Represent Tokens in the Network State: Petri Net with Marking Enabled: Transition if all of its Incoming Places have
at Least One Token Fire: Transition Consumes Token from Incoming
Places and Produces Token for Outgoing Places Firing Sequence: Sequence of Transition Firings for
Execution of PN (t1, t3, t2, t5, …) PNs are Non-Deterministic
Any Enabled TransitionMay Fire
Neither When Nor Which Fires is Specified by Model
62
CSE
2102
CSE
2102
Modeling with Petri nets Places Represent Distributed States Transitions Represent Actions Or Events That May
Occur When System is in a Certain State They Can Occur as Certain Conditions Hold on the
States Forks and Joins Modeled
Fork: Transition from 1 Input to N Outputs Join: Transition fron N Inputs to 1 Output
63
CSE
2102
CSE
2102
Petri Nets A Petri Net is Defined as a Quadruple (P,T,F,W) with:
P: places T: transitions (P, T are finite) F: flow relation (F {PT} {TP} ) W: weight function (W: F N – {0} )Properties:(1) P T = Ø(2) P T Ø(3)F (P T) (T P)(4) W: F N-{0}
Default Value of Weight Function W is 1 State Defined by Marking: M: P N
64
CSE
2102
CSE
2102
places
transitions flows
marking
3 weight
P
P
P
t
tP
t
1
3
1
3
4
6
5
P
P
P
2
5
7
t
t
t
2
4
6
Graphical Representation of PN
65
CSE
2102
CSE
2102
PN Semantics: Dynamic Evolution Transition t is Enabled iff
p t's Input Places, M(p) W(<p,t>) Transition t Fires: Produces a New Marking M’ in
Places that are Either t's Input or Output or Both If p is an Input Place: M'(p) = M(p) - W(<p,t>)
Consume a Token If p is an Output Place: M'(p) = M(p) + W(<t,p>)
Produce a Token If p is both an Input and an Output Place:
M'(p) = M(p) - W(<p,t>) + W(<t,p>)Consume and Produce a Token
66
CSE
2102
CSE
2102
After (a) either (b) or (c) may occur, then (d)
P
P
P
t
tP
t
1
3
1
3
4
6
5
P
P
P
2
5
7
t
t
t
2
4
6
P
P
P
t
tP
t
1
3
1
3
4
6
5
P
P
P
2
5
7
t
t
t
2
4
6
P
P
P
t
tP
t
1
3
1
3
4
6
5
P
P
P
2
5
7
t
t
t
2
4
6
P
P
P
t
tP
t
1
3
1
3
4
6
5
P
P
2
5
7
t
t
t
2
4
6
P
(a) (b)
(c) (d)
67
CSE
2102
CSE
2102
Modeling Concurrent Systems Concurrency: Two Transitions are Enabled to Fire in
Given State, and the Firing of One Does Nor Prevent the Other From Firing See t1 and t2 in Case (a)
Conflict: Two Transitions are Enabled to Fire in Given State, But the Firing of One Prevents the Other From Firing See T3 and T4 in Case (d) Place P3 Models Shared Resource Between Two
Processes No Policy Exists to Resolve Conflicts (Known as
Unfair Scheduling) A Process May Never Get a Resource (Starvation) Deadlock: A Marking Where no Transition May be
Enabled
68
CSE
2102
CSE
2102
Avoiding Starvation Focus on Cycle in Middle of PN
P P
P
P P
t t
t t
P P
t t
1
1 2
3
4
5
6
7
4
2
3
6
5
imposes alternation
69
CSE
2102
CSE
2102
A Conflict-Free PN Always a Token Available in Place R for Both Sides to
Utilize - R Reloaded with 2 Tokens at Each Step
R
P P
t t
t'
t"
t
t'
t"
t
1
1
3
3
2
2
4
4
56
2 2
this net candeadlock!consider
'42
'31 t,t , t,t
70
CSE
2102
CSE
2102
A Deadlock-Free PN If One Side Uses 2, it Proceeds, Else Other Side Starvation is Still Possible
R
P P
t t
t'
t"
t
t'
t"
t
1
1
3
3
2
2
4
4
56
2 2
2 2
71
CSE
2102
CSE
2102
A Partial Starvation Place Supplying t4 is Not Refilled with Token
t
t
1
3
t
t
2
4
72
CSE
2102
CSE
2102
Producer-Consumer Example Individual PNs for Produce and Consume
P P
write
produce
C
C
consume
0 1 2
read read
write write
read
1
1
2
2
separate netsfor the subsystems
73
CSE
2102
CSE
2102
Producer-Consumer Example Combined PNs
C1C2
consume
0 1 2
read
writewrite
read
P1 P2produce
One net for theentire system
74
CSE
2102
CSE
2102
Petri Net Limitations Petri Nets are Limited in Their Modeling Capability
As Presented, Non-Deterministic No Way to Prioritorize Among All Eligible Active
Transitions that Can Fire There are a Number of Capabilities that Would be
Very Useful in Modeling System Behavior Adding Predicates and Functions that are Used to
Evaluate Conditions Under Which a Transition Fire and its Results
Instituting Priority to Decide When to Fire Among Multiple Transitions that are Eligible
Incorporating Timing to Constrain When a Transition can Fire
75
CSE
2102
CSE
2102
Assigning Values to Tokens
Transitions have Predicates and Functions Predicate Refers to Values of Tokens in Inputs Functions Define Values of Tokens for Outputs
PP
P
PP
34
71 4
t t1 2
45
12
3Predicate P2 > P1
and function P4 := P2 + P1
associated with t1
Predicate P3 = P2 and functions
P4 := P3 P2 and P5 := P2 + P3 are associated with t2
The firing of t1 by using <3,7> would produce the value 10 in P4. t2 can then fire using <4, 4>
76
CSE
2102
CSE
2102
Other PN Extensions Specifying Priorities
Function Pri from Transitions to Natural Numbers: pri: T N
When Several Transitions are Enabled, Only Ones with Maximum Priority are Allowed to Fire
If Multiple Active, choose Non-deterministically Timing
Pair of Constants <tmin, tmax> associated with each Transition – If Transition Enabled Must wait for at least tmin to elapse before it can Fire Must Fire before tmax has elapsed, unless it is Disabled
by the Firing of another Transition before tmax
77
CSE
2102
CSE
2102
Combining Timing and Priorities
P P P
t t t
tmin = 1 tmax = 4
tmin = 2 tmax = 3
tmin = 0 tmax = 5
priority = priority = priority = 1 3 2
P
1
1 2
2
3
3
4
78
CSE
2102
CSE
2102
Overview of a PN Example PNs can be Used for Very Complex Applications Consider
An N Elevator System to be Installed in a Building with M Floors
Natural Language Specifications Contain Several Ambiguities
Formal Specification Using PNs Removes Ambiguities
How is a Solution Constructed? Employ Modules Each Encapsulating Fragments of PNs Each Captures Certain System Components
79
CSE
2102
CSE
2102
Initial Sketch of MovementInitial Sketch of Movement
Elevator at floor j
Elevator at floor j + 1
Pushing internal button for floor j + 1
Button illumination
Transfer from floor j to j+1
80
CSE
2102
CSE
2102
Dealing with ButtonsDealing with Buttons
InternalInternal
ExternalExternal
Set
x..x Reset
ti'
Fj
Fj'
On Off
UPj
81
CSE
2102
CSE
2102 Fj+1 UFj+1
Fj"
t Fj'
UPh
On
On
DOWNh
ILBh
DOWNj+1
On
On
On
On
ILBj+1
Fj
t1 t2 t3 t4 t5 t6
t7
t8
t9 t10
t11 t12
UPj+1
Modeling the Entire PNModeling the Entire PN
82
CSE
2102
CSE
2102
Summary of Operational Specifications DFDs describe flow of data but not control FSMs describe control flow and data usage, but are
synchronous and may grow complex Easy to interpret.
Petri nets describe asynchronous and concurrent systems Can have values, priorities, and times Non deterministic
83
CSE
2102
CSE
2102
Entity Relationship Diagrams ER Model Concepts
Entities and Attributes Entity Types, Value Sets, and Key Attributes Relationships and Relationship Types Weak Entity Types Roles and Attributes in Relationship Types
Relationships of Higher Degree Skip Extended Entity-Relationship (EER) Model Notation is based on :
R. Elmasri and S.B. Navathe, “ Fundamentals of Database Systems,” Ed. 3., Addison Wesley, 2000, Chapters 3 and 4.
84
CSE
2102
CSE
2102
Entities, Types, and Instances A person, place, concept, or thing which is represented
in the system. Examples:
A report or display A telephone call An event (an alarm) A person An organization (Accounting) A place (warehouse)
Entity type: A definition for a collection of entity “instances” that share
the same properties. Employee(ID, Name, SS#,… Birthdate,….)
Entity instance: A physical data, a concrete occurrence of a given entity
type (1234, John Smith,…. 08/31/1972,..) (5678,Marie Joe,…. 07/31/1968,..)
Compare this with class and object in OO paradigm.
85
CSE
2102
CSE
2102
Example COMPANY Database Requirements of the Company (Oversimplified for
Illustrative Purposes) Company is Organized into Departments
Each Department has a Name, Number and an Employee Who Manages the Department
We Track of the Start Date of the Department Manager Each Department Controls a Number of Projects
Each Project has a Name, Number and is Located at a Single Location
86
CSE
2102
CSE
2102
Example COMPANY Database Store Each Employee’s Social Security Number,
Address, Salary, Sex, and Birthdate Each Employee Works for One Department but May
Work on Several Projects We Track of the Number of Hours Per Week that an
Employee Currently Works on Each Project We Track of the Direct Supervisor of Each Employee
Each Employee May have a Number of Dependents For Each Dependent, We Track of their Name, Sex,
Birthdate, and Relationship to Employee
87
CSE
2102
CSE
2102
ER Diagram for the Company DatabaseER Diagram for the Company Database
88
CSE
2102
CSE
2102
Summary of ER-Diagram NotationSummary of ER-Diagram NotationMeaning
ENTITY TYPE
WEAK ENTITY TYPE
RELATIONSHIP TYPE
IDENTIFYING RELATIONSHIP TYPE
ATTRIBUTE
KEY ATTRIBUTE
MULTIVALUED ATTRIBUTE
COMPOSITE ATTRIBUTE
DERIVED ATTRIBUTE
TOTAL PARTICIPATION OF E2 IN R
CARDINALITY RATIO 1:N FOR E1:E2 IN R
STRUCTURAL CONSTRAINT (min, max) ON PARTICIPATION OF E IN R
Symbol
E1 R E2
E1 RN E2
R(min,max)
E
N
89
CSE
2102
CSE
2102
ER Model Concepts: Entities and Attributes Entities - Specific Objects or Things in the Mini-world
that are Represented in the Database EMPLOYEE John Smith Research DEPARTMENT Productx PROJECT
Attributes are Properties Used to Describe an Entitye.g., an EMPLOYEE Entity may have a Name, SSN, Address, Sex, Birthdate
A Specific Entity (Instance) has a Value for Each of its Attributes Specific Employee Entity May Have Name=‘John
Relationship cardinalities: ExampleRelationship cardinalities: Example
A R B
A R B
A R B
Parts Suppliers
Parts Suppliers
Parts Suppliers
1 n
m 1
m n
A supplier supplies many parts.A part is supplied by many suppliers
Parts are supplied by suppliers.
106
CSE
2102
CSE
2102
E-R Diagrams
EMPLOYEE PROJECT
Responsibility
Duration
Budget
ProjectName
Project NoEmployee No EmployeeName
SalaryTitle
WORKS ON
Address
CityApt. #
Street #
NoEmp
Location
107
CSE
2102
CSE
2102
Weak Entity Types Entity that Does Not have a Key Attribute Weak Entity Must Participate in an Identifying
Relationship Type with an Owner or Identifying Entity Type
Entities are Identified by the Combination of: A Partial Key of the Weak Entity Type Particular Entity they Are Related to in the
Identifying Entity Type Example:
A DEPENDENT Entity is Identified by Dependent’s First Name and Birthdate, and the EMPLOYEE That the Dependent is Related to
DEPENDENT is a Weak Entity Type With EMPLOYEE as its Identifying Entity Type Via the Identifying Relationship Type DEPENDENT_OF
108
CSE
2102
CSE
2102
ER Model and Data Abstraction Abstraction Classification
Aggregation
Identification Generalization
ER Model Concept Entity Type - a
Grouping of Member Entities
Relationship Type - a Grouping of Member Relationships
Relationship Type is an Aggregation of (Over) Its Participating Entity Types
Weak Entity Type and Attribute Key
????????
109
CSE
2102
CSE
2102
Constraints on Aggregation Cardinality Constraints on Relationship Types
AKA Ratio Constraints Maximum Cardinality
One-to-One One-to-Many Many-to-Many
Minimum Cardinality (AKA Participation or Existence Dependency Constraints) Zero (Optional Participation, Not Existence-Dependent) One or More (Mandatory, Existence-Dependent)
110
CSE
2102
CSE
2102
e1
e2
e3
e4
e5
e6
e7
EMPLOYEE
r1
r2
r3
r4
r5
r6
r7
WORKS_FOR
d1
d2
d3
DEPARTMENT
One-to-many(1:N) or Many-to-one (N:1)One-to-many(1:N) or Many-to-one (N:1)
111
CSE
2102
CSE
2102
e1
e2
e3
e4
e5
e6
e7
r1
r2
r3
r4
r5
r6
r7
d1
d2
d3
r8
r9
MANY-TO-MANY(M:N)MANY-TO-MANY(M:N)
112
CSE
2102
CSE
2102
EMPLOYEE PROJECT
Responsibility
Duration
Budget
ProjectName
Project NoEmployee No EmployeeName
SalaryTitle
WORKS ON1 1
One-to-One Relationship Each Instance of One Entity Class E1 Can Be
Associated with Exactly One Instance of Another Entity Class E2 and Vice Versa.
Example: Each Employee Can Work in Exactly One Project
Underlined Attributes are Relation Keys which Uniquely Distinguish Among Tuples (Rows)
Tabular Form
132
CSE
2102
CSE
2102
Relation Instances
ENO ENAME TITLE
E1 J. Doe Elect. Eng.E2 M. Smith Syst. Anal.E3 A. Lee Mech. Eng.E4 J. Miller ProgrammerE5 B. Casey Syst. Anal.E6 L. Chu Elect. Eng.E7 R. Davis Mech. Eng.E8 J. Jones Syst. Anal.
E1 J. Doe Elect. Eng.E2 M. Smith Syst. Anal.E3 A. Lee Mech. Eng.E4 J. Miller ProgrammerE5 B. Casey Syst. Anal.E6 L. Chu Elect. Eng.E7 R. Davis Mech. Eng.E8 J. Jones Syst. Anal.
A Referential Integrity Constraint Can Be Displayed in a Relational Database Schema as a Directed Arc From R1.FK to R2.PK
139
CSE
2102
CSE
2102
Another Example: Referential IntegrityAnother Example: Referential Integrity
What Do theseArrows Represent
in ER Diagram?
140
CSE
2102
CSE
2102
What are Problems with ER Notation? Historically, ER Model 1st Proposed in 1976
P. Chen, ''The Entity-Relationship Model - Toward a Unified View of Data,'' ACM Trans. on Database Systems, Vol. 1, No. 1, March 1976.
However, ER Model in this Original Form Did Not Support the Generalization Abstraction (Inheritance)
In Databases, Inheritance 1st Proposed in 1977 J. Smith and D. Smith, ''Database Abstractions:
Aggregation and Generalization,'' ACM Trans. on Database Systems, Vol. 2, No. 2, June 1977.
Thus, Extended ER Evolved through 1980s with the Focus on “Semantic Data Models”
M. Hammer and D. McLeod, ''Database Descriptions with SDM: A Semantic Data Model,'' ACM Trans. on Database Systems, Vol. 6, No. 3, Sept. 1981.
141
CSE
2102
CSE
2102
Specialization/Attribute Inheritance An Entity Type E1 is a Specialization of
another Entity Type E2 if E1 has the Same Properties of E2 and Perhaps Even More.
E1 IS-A E2
MANAGER
EMPLOYEE
EMPLOYEE
Employee No EmployeeName
Salary
Title Address
MANAGER
Employee No EmployeeName
Salary
Title Address
Expense Act. Condo
142
CSE
2102
CSE
2102
Generalization Abstracting the Common Properties of Two
or More Entities to Produce a “Higher-level” Entity
ENGINEER SECRETARY SALESPERSON
Employee NoEmployee Name
SalaryTitle
Address
Employee NoEmployee Name
SalaryTitle
Address
Employee NoEmployee Name
SalaryTitle
Address
ProjectOffice Office
SpecialtyCarRegion
EMPLOYEE Employee NoEmployee Name
SalaryTitle
Address
143
CSE
2102
CSE
2102
Generalization
ENGINEER SECRETARY SALESPERSON
EMPLOYEE
Employee No EmployeeName
Salary
Title Address
Project Office Specialty Office CarRegion
d
144
CSE
2102
CSE
2102
Constraints
disjoint, totaldisjoint, total
disjoint, partialdisjoint, partiald
d
o
o
overlapping, total
overlapping, partial
Part
Manufactured_Part
Purchased_Part
o
PartNo Description
SupplierName ListPrice
BatchNo
M_date
DrawingNo
145
CSE
2102
CSE
2102
Total and Partial Disjoint
EMPLOYEE
Employee No EmployeeName
Salary
Title Address
SECRETARYENGINEER
Project Office Specialty Office
SALESPERSON
CarRegion
dd
HOURLY_EMP
SALARIED_EMP
Hourly Rate
Salary
146
CSE
2102
CSE
2102
Total Overlapping
PART
Part No PartName
QTY
WGT
o
MANUFACTURED_PART PURCHASED_PART
Batch No Drawing No Price
147
CSE
2102
CSE
2102
HTSS ER Diagram Example
148
CSE
2102
CSE
2102
HTSS ER Diagram Example
149
CSE
2102
CSE
2102
Finding entities and relationships Identify the system information:
User interviews Paper and screen documents Previous system documentation
Identify entities: Heuristics Analysis of English grammar Entity-
Relationships
150
CSE
2102
CSE
2102
ER Diagrams: ExampleER Diagrams: Example
Consider a course registration and student advising system. This system maintains information regarding the courses offered each semester as
well as the advisors assigned to each student. Each course has a numberof students enrolled, while each student can register for a number of
courses. A course is taught by a single instructor. Each instructor teachesonly one course per semester. In addition, an instructor is responsible
for advising several students. Each student is assigned a single advisor. Draw an ER diagram for the course registration and student advising
system.
151
CSE
2102
CSE
2102
ER Diagrams: ExampleER Diagrams: Example
Course Student
Instructor
Taught_by Advised_by
Enrolled_In
152
CSE
2102
CSE
2102
Example COMPANY Database Requirements of the Company (Oversimplified for
Illustrative Purposes) Company is Organized into Departments
Each Department has a Name, Number and an Employee Who Manages the Department
We Track of the Start Date of the Department Manager Each Department Controls a Number of Projects
Each Project has a Name, Number and is Located at a Single Location
153
CSE
2102
CSE
2102
Example COMPANY Database Store Each Employee’s Social Security Number,
Address, Salary, Sex, and Birthdate Each Employee Works for One Department but May
Work on Several Projects We Track of the Number of Hours Per Week that an
Employee Currently Works on Each Project We Track of the Direct Supervisor of Each Employee
Each Employee May have a Number of Dependents For Each Dependent, We Track of their Name, Sex,
Birthdate, and Relationship to Employee
154
CSE
2102
CSE
2102
ER Diagram for the Company DatabaseER Diagram for the Company Database
155
CSE
2102
CSE
2102
UML Diagrams UML is a Language for Specifying, Visualizing,
Constructing, and Documenting Software Artifacts UML Formalizes the Previous Techniques (DFD, ER,
FSM, PN, etc.) into a Unified Environment What Does a Modeling Language Provide?
Model Elements: Concepts and Semantics Notation: Visual Rendering of Model Elements Guidelines: Hints and Suggestions for Using
Elements in Notation UML has 13 Different Diagrams (2.0) References and Resources
Web for UML 2.0: www.uml.org “The Unified Modeling Language Reference
Manual”, Addison-Wesley.
156
CSE
2102
CSE
2102
UML Use-Case Diagrams Define Functions on Basis of Actors and Actions
borrow book
return book
library update
librariancustomer
157
CSE
2102
CSE
2102
UML Sequence Diagrams Describe Object Interactions by Exchanging Messages
Librarian Catalogue
member card + book request membership
OK
book request
book available
book borrowed
Customer
158
CSE
2102
CSE
2102
UML Sequence Diagrams Describe Object Interactions by Exchanging Messages
159
CSE
2102
CSE
2102
UML Collaboration Diagrams Object Interactions and Their Ordering
Customer Librarian Catalogue
1: member card + book request
2: membership OK
3: book request
4: book available 5: book borrowed
160
CSE
2102
CSE
2102
UML Statechart Diagrams Akin to Finite State Machine
161
CSE
2102
CSE
2102
Activity Diagram Akin to Petri Net
162
CSE
2102
CSE
2102
Mathematical-Based Specifications Queueing and Simulation Models
Predict and Simulate System Behavior CSE3504
Declarative Specifications: Logic Specifications Algebraic Specifications CSE4102 Programming Languages
We Briefly Highlight…
163
CSE
2102
CSE
2102
An I/O Sub-Model of Disk System L: Mean Arrival Rate Mean Bulk Size T/n Variance of Bulk Size: T/n (1-1/n) Mean Bulk Size
at Each ModuleT/Mn
DriveQueu
e1
DriveQueu
e2
DriveQueu
eM
ChannelQueue
L L L
164
CSE
2102
CSE
2102
Simulation Model
Controller
Un
ibu
s
Bro
ad
cast
Bu
s
Backend
Disks
From the Host
To the Host
From other
Backends
To other Backends
1,4,6 1,2,3,4,6,7
2,3,4,5,6
2,3,5
8
165
CSE
2102
CSE
2102
Simulation Program - SimscriptPREAMBLE
‘ ‘ THIS IS A SIMSCRIPT MODEL OF A SINGLE SERVER QUEUE. IN THIS MODEL, THERE
‘ ‘ IS ONLY ONE PROCESS CALLED CUSTOMER WHO INITIATES THE PROCESSINGNORMALLY MODE IS UNDEFINEDPROCESSES INCLUDE CUSTOMERRESOURCES INCLUDE SERVERACCUMLATE UTIL.SERVER AS THE AVERAGE OF N.X.SERVERACCUMULATE AVE.QUEUE.LENGTH AS THE AVERAGE OF N.Q.SERVERACCUMULATE MAX.QUEUE.LENGTH AS THE MAXIMUM OF N.Q.SERVERDEFINE NO.OF.ARRIVALS AND MAX.NO.ARRIVALS AS INTEGER VARIABLESEND
MAINPRINT 1 LINE THUSINPUT NUMBER MAXIMUM NUMBER OF ARRIVALSREAD MAX.NO.ARRIVALSCREATE EVERY SERVER(1)LET U.SERVERER(1)=1ACTIVATE A CUSTOMER IN EXPONENTIAL.F(10.0,1) MINUTESSTART SIMULATIONPRINT 4 LINES WITH TIME.V*24*60, UTIL.SERVER(1), AVE.QUERY.LENGTH(1) AND MAX.QUERY.LENGTH(1) THUSCLOCK TIME = *******.** MINUTESTHE UTILIZATION OF THE SEVER WAS ****.**THE AVERAGE LENGTH OF THE QUEUE WAS ***.**THE MAXIMIMUM LENGTH OF THE QUEUE WAS ****END
166
CSE
2102
CSE
2102
Simulation Program - Continued
PROCESS CUSTOMERADD 1 TO NO.OF-ARRIVALSIF NO.OF.ARRIVALS < MAX.NO.ARRIVALSACTIVATE A CUSTOMER IN EXPONENTIAL.F(10.0,1) MINUTESALWAYSREQUEST 1 UNIT OF SEVER()WORK EXPONENTIAL.F(8.0,2) MINUTESRELINQUISH 1 UNIT OF SERVER(1)END
EXECUTION/OUTPUT OF SIMULATION PROGRAM:INPUT NUMBER MAXIMUM NUMBER OF ARRIVALSII.5> 100
CLOCK TIME = 100008.36 MINUTESTHE UTILIZATION OF THE SEVER WAS .80THE AVERAGE LENGTH OF THE QUEUE WAS 2.65THE MAXIMIMUM LENGTH OF THE QUEUE WAS 12
167
CSE
2102
CSE
2102
Requirements of Specification Notation All SWE Principles Must be Applied to the
Construction of a Specification Rigor and Formality as Discussed in Chapter 3 Separation of Concerns
Functional vs. Performance vs. GUI vs. DB vs. … Different Notations for Different Parts of System
DFD, ER, UML Activity, Statechart, Collaboration, etc. Different Stakeholders See Design for their Perspective
Incrementality Not All SW Requirements Understood at Start Apply to Construction of Specification Add Details and Functionality Over Time Specification Evolves Like a Design
168
CSE
2102
CSE
2102
Recall Different Views – Data FlowRecall Different Views – Data Flow
User
Formatting options
Predefined Text skeletons
Customers
Customer data (name, type of document)
Print Document
Predefined Formats
Document production
169
CSE
2102
CSE
2102
Recall Different Views – Control FlowRecall Different Views – Control Flow
Search in Customers
Get user name
Get other data from the data base
Get other relevant data from user interaction
Get appropriate text skeletons from predefined text library
Print document
Compose the document by choosing formatting options (this involves interaction with the user and access to the Formats data base)
(b)
170
CSE
2102
CSE
2102
Interplay of Specification Techniques What do DFDs have to Offer re. OO Design?
Data Stores (Classes) Arrow Labels (Parameters) Input (Method of Class) Functions (Implementation of Method of Class) Output (Return of Method of Class)
What do DFDs have to Offer re. ER Design? Data Stores (Entities) Arrow Labels (Relationships and Keys)
What about FSMs? What is Impact w.r.t. Modular or ADT/Class Design?
171
CSE
2102
CSE
2102
Interplay of Specification Techniques
172
CSE
2102
CSE
2102
Interplay of Specification Techniques
173
CSE
2102
CSE
2102
Building Modular Specifications Specification Document is Combination of Multiple
Formal and Semi-Formal Notations Bound Together with Prose Organized into Sections
Fully Formal Specs Needed for Critical Applications Formalisms Not Understood by All Mathematics Used to Verify Correctness
Tools Aid in Construction of Specification Word Processors, Visual (PPT, Visio, etc.) Analyzers (e.g., Logic) Design Tools (Together Architect/Rhapsody)
What’s in a Specification? Diverge to Web Page for Additional Presentation Accompanying Document
174
CSE
2102
CSE
2102
What Did their Specification Contain? Consulting Project in 1995 with Pitney Bowes
Investigate the Ability to Sell Postage over Internet C++/OO Windows 95/Add-on Hardware Device
Their Specification Contained Introduction: Purpose, Scope, Terms, Abbr, etc. Models of Operation: System Ops + High-Level System Functions w.r.t. Performance/Reliability,
Security/Confidentiality, Other Domain Issues Details from User Perspective: Interactions and
Behavior Details from System Perspective: The way the
System Works + Components + User Interactions Business Related Considerations: Feasibility of
Idea, Marketability, etc.
175
CSE
2102
CSE
2102
Return from “What’s in a Specification” 30 Pages of Main text Supplemental Information:
Conceptual, High Level, Detailed Designs 25 Page Object Model with Explanation 7 Pages of ER Diagrams 200 Pages of DFDs
Object Model Underestimated Requirements by Factor of 10! 15 Classes Estimated, 150 Classes Designed/Built First Very OO Project by Company
Specification Not Updated Over Time How to Write and Organize a Specification?
Jump to Specification PPT
176
CSE
2102
CSE
2102
Concluding Remarks Specifications Describe
What the Users Need from a System (Requirements Specification)
Design of a Software System (Design and Architecture Specification)
Features Offered by a System (Functional Specification)
Performance Characteristics of a System (Performance Specification)
External Behavior of a Module (Module Interface Specification)
Internal Structure of a Module (Internal Structural Specification)
177
CSE
2102
CSE
2102
Concluding Remarks Descriptions are given via Suitable Notations
There is no “Ideal” Notation Notations, Diagrams, Approach, on Application-
by-Application Basis Three Keys Issues:
Specifications must be Modular Specifications support Communication and
Interaction between Designers and Users Specification Process Itself Must be Managed
Versions of Specification (CMS) Assigning Specification Parts to D&D Team Updating Specification as Changes Occur Etc.