Embed Size (px)
Citation preview
1
CSE
2102
CSE
2102
Chapter 5: Software SpecificationChapter 5: Software Specification
Prof. Steven A. DemurjianComputer Science & Engineering Department
The University of Connecticut371 Fairfield Road, Box U-4155
Storrs, CT 06269-4155
[email protected]://www.engr.uconn.edu/
~steve(860) 486 – 4818
(860) 486 – 3719 (office)
2
CSE
2102
CSE
2102
Overview of Chapter 5 What is a Specification? Operational Specifications
Data Flow Diagrams Finite State Machines (UML Statechart) Petri Nets
Diagrammatic Specifications Entity Relationship Diagrams UML Diagrams (A Quick, First Look)
Use Case, Class, Object, and Sequence Activity and State Chart Collaboration, Component, Deployment
Mathematical-Based Specifications Queueing and Simulation Models
Writing Specifications
3
CSE
2102
CSE
2102
What’s in a Specification? Specification is Broad Term that Means Definition
Used at Different Stages of Software Development For Different Purposes
Statement of Agreement (Contract) Between Producer and Consumer of a Service (Domain Uses and
Domain Experts) Implementer and User
All Desired Features Must Be Specified All Relevant Software Qualities Attained
Statement of User Requirements Major Failures Occur Due to Misunderstandings
Between Producer and User "The Hardest Single Part of Building a Software
System is Deciding Precisely What To Build" (F. Brooks – Mythical Man Month)
4
CSE
2102
CSE
2102
What’s in a Specification? Specification can be Many Different things to Many
Different Stakeholders (User, Designer, Manager, etc.) Requirements Specification:
Agreement between End User and Designers Design Specification:
Agreement between Designers and Developers Module Specification:
Agreement between SEs that Use a Module and SEs that Implement a Module re. Interface
Object-Oriented Specification: Assertion of Class’ Capability via Public Interface
Specification Involves “What” Implementation Involves “How”
5
CSE
2102
CSE
2102
Uses of Specification Statement of User’s Needs
Statement of Interface Between Machine and Controlled Environment
Critical Issues: User’s Needs May not be Understood by
Developer Need Ability to Verify Specification
Problem Faced: Serious Undesirable Effects can Result Due to
Misunderstandings Between Software Engineers and Domain Experts
6
CSE
2102
CSE
2102
Uses of Specification Statement of Implementation Requirements
Hardware, OS, Language(s), DBMS, etc. Requirement Specification
External Behavior of System Functional and Non-Function Behavior Design Spec Verified Against Requirements Spec
Design Specification Description of Software Architecture Code Must be Verified Against Design Spec
Reference Point During Product Maintenance Verify that Changes Satisfy Requirements Change in Specification Requires Adaptive
Maintenance
7
CSE
2102
CSE
2102
Classic Information System DesignClassic Information System Design
8
CSE
2102
CSE
2102
Data vs. InformationData vs. Information
9
CSE
2102
CSE
2102
Specification Qualities Clear, Unambiguous, Understandable Consistent
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
Smith’, SSN=‘123456789’, Address=‘731 Fondren, Houston, TX’, Sex=‘m’, Birthdate=‘09-jan-55’
90
CSE
2102
CSE
2102
Three Types of Attributes Simple: Single Atomic Value for the Attribute
SSN or Sex or State or Salary or ... Composite: Attribute Composed of Many Components
Address (Apt#, House#, Street, City, State, Zipcode, Country) or Name(Fname, MI, Lname)
Composition May form a Hierarchy where Some Components are Themselves Composite
Multi-Valued: Entity may have Multiple Values for That Attribute - Like an Set Type CAR {Color} or STUDENT {Previousdegrees}
Composite and Multi-valued Attributes may be Nested Arbitrarily to any Number of Levels (Rare) Previousdegrees of a STUDENT is a Composite
Multi-valued Attribute Denoted by {Previousdegrees(college, Year, Degree, Field)}
91
CSE
2102
CSE
2102
Sample Entity with AttributesSample Entity with Attributes
Car
Make Model ID#
BodyType Color Owner
Person
Name Address Age SSN
92
CSE
2102
CSE
2102
Identifier Attributes Attribute becomes “key” when we want to find an
instance of the object Example:
For the “Car” data object, the key might be “ID#” attribute
For the “Person” data object, the key might be ? Keys often must be unique, but not always
93
CSE
2102
CSE
2102
Single-Valued vs. Multi-Valued Attributes Single-valued attribute:
Only one possible value is associated with the attribute if the “entity instance” is fixed
For example, Name, SS# of entity person Multi-valued attribute:
Many possible values may be associated with the attribute even if the “entity instance” is fixed
For example, Cars owned by a person
Employee Name
Employee Skills
Single-valued attribute
Multi-valued attribute
94
CSE
2102
CSE
2102
Entities with Attribute ValuesEntities with Attribute Values
95
CSE
2102
CSE
2102
Entity Types and Key Attributes Entities with the Same Basic Attributes Are Grouped
or Typed into an Entity Type EMPLOYEE Entity Type or PROJECT Type
Attribute of Entity Type for which Each Entity Must Have a Unique Value is Called a Key Attribute SSN of EMPLOYEE, ISBN of BOOK
A Key Attribute may be Composite VIN is a Key of the CAR Entity Type
An Entity Type may have More than One Key CAR Entity Type May Have Two Keys:
VIN Vehicletagnumber (Number, State) aka License Plate
96
CSE
2102
CSE
2102
car1
((ABC 123, TEXAS), TK629, Ford Mustang, convertible, 1989, (red, black))car2
((ABC 123, NEW YORK), WP9872, Nissan Sentra, 2-door, 1992, (blue))car3
((VSY 720, TEXAS), TD729, Chrysler LeBaron, 4-door, 1993, (white, blue))
.
.
.
CARRegistration(RegistrationNumber, State), V_ID, Make, Model, Year, (Color)
Entity Type CAR with AttributesEntity Type CAR with Attributes
97
CSE
2102
CSE
2102
Two Other Entity TypesTwo Other Entity Types
98
CSE
2102
CSE
2102
Relationships and Relationship Types A Relationship Relates Two or More Distinct Entities
With a Specific Meaning EMPLOYEE John Smith Works on the Productx
PROJECT EMPLOYEE Franklin Wong Manages the
Research DEPARTMENT Relationship - Instance Level
Relationships of the Same Type are Grouped or Typed Into a Relationship Type WORKS_ON Relationship Type in Which
Employees and Projects Participate MANAGES Relationship Type in Which
Employees and Departments Participate Analogous to Reference or List in Programming
99
CSE
2102
CSE
2102
The WORKS_ON RelationshipThe WORKS_ON Relationship
100
CSE
2102
CSE
2102
Relationships: ExamplesRelationships: Examples
Bookstore BooksOrders
STUDENT
CLASS
ENROLLED_IN
NAME
GENDER
AGE
SUBJECT
COURSE_ID
MAX_ENROLLMENT
101
CSE
2102
CSE
2102
Relationships A logical association between two types of entities Consider books and bookstores:
Bookstore orders books, Bookstore displays Books Bookstore stocks books, Bookstore sells Books
Represented by a Diamond Cardinality
Occurrences of object x are related to how many occurrences of object y. One to One (1:1) One to Many (1:N) Many to Many (M:N)
Doesn’t indicate whether one data object must participate in the relationship
102
CSE
2102
CSE
2102
Relationships and Relationship Types Degree of a Relationship Type is the Number of
Participating Entity Types Both MANAGES and WORKS_ON are Binary
Relationships What is a possible Ternary Relationship?
More Than One Relationship Type Can Exist With the Same Participating Entity Types MANAGES and WORKS_FOR are Distinct
Relationships Between EMPLOYEE and DEPARTMENT Entity Types
Relationships are Directional SUPPLIES: SUPPLIER to PARTS SUPPLIERS: PARTS to SUPPLIER
103
CSE
2102
CSE
2102
Cardinality & Modality: NotationCardinality & Modality: Notation
E1 R E2(min,max) (min,max)
Modality Cardinality0 – Partial 1 – One
1 – Mandatory M – More than one
Modality = 0, if relationship is optionalModality = 1, if relationship is mandatory
Customer R Order(0,M) (1,1)
Places
A customer may place (modality 0) zero to many orders (cardinality M)
An order is placed by one and only customer (modality and cardinality 1).
104
CSE
2102
CSE
2102
Relationship cardinalitiesRelationship cardinalities
A R B
A R B
A R B
A R B
A R B is one to one
A R B is one to many (one A, many B)
A R B is many to one (one B, many A)
A R B is many to many (many A & B)
1 1
1 m
n 1
m n
105
CSE
2102
CSE
2102
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
and Each Project Employs Exactly One Employee
113
CSE
2102
CSE
2102
One-to-One WORKS_ON RelationshipOne-to-One WORKS_ON Relationship
WORKS_ONRelationship
Instances
EMPLOYEE Set PROJECT Set
114
CSE
2102
CSE
2102
EMPLOYEE PROJECT
Responsibility
Duration
Budget
ProjectName
Project NoEmployee No EmployeeName
SalaryTitle
WORKS ON1N
Many-to-One Relationship Each Instance of One Entity Class E1 can be
Associated with Zero or More Instances of Another Entity Class E2, but Each Instance of E2 can be Associated With at Most 1 Instance of E1
Example : Each Employee Can Work in Exactly One Project
Each Project Can Employ Many Engineers
115
CSE
2102
CSE
2102
One-to-Many WORKS_ON RelationshipOne-to-Many WORKS_ON Relationship
116
CSE
2102
CSE
2102
EMPLOYEE PROJECT
Responsibility
Duration
Budget
ProjectName
Project NoEmployee No EmployeeName
SalaryTitle
WORKS ONN M
Many-to-Many Relationship Each Instance of One Entity Class Can Be Associated
with Many Instances of Another Entity Class, and vice versa
Example: Each Employee Can Work in Many Projects
Each Project Can Employ Many Employees
117
CSE
2102
CSE
2102
Many-to-Many WORKS_ON RelationshipMany-to-Many WORKS_ON Relationship
118
CSE
2102
CSE
2102
Structural Constraints Structural Constraints on a Relationship are One Way
to Express the Semantics of a Relationship Cardinality Ratio (of a Binary Relationship): 1:1, 1:N,
N:1, or M:N Shown by Placing Apropos Number on the Link
Participation Constraint (on Each Entity Type): Total (Called Existence Dependency) or Partial Shown By Double Lining The Link
NOTE: Easy to Specify for Binary Relationship Types Do Not Be Misled by Obscure Notations to
Specify Above Constraints for Higher Order Relationships
119
CSE
2102
CSE
2102
Relationships of Higher Degree Relationship Types of Degree 1 Are Called Unary
Relationship of Entity with Itself Relationship Types of Degree 2 Are Called Binary Relationship Types of Degree 3 Are Called Ternary
There is a Concrete Relationship Instance that Involves all Three Entity Types
These are Not Separate Relationships! Relationship Types of Degree N Are Called N-ary
Again - Concrete n-Participation Relationship In General, an N-ary Relationship is Not Equivalent to
N Binary Relationships Rather - it is more Analogous to the Grouping of
N-Binary Relationships into a N-ary Relationship
120
CSE
2102
CSE
2102
Unary RelationshipUnary Relationship
Employee Is_Manager_Of
Assembly Part Is_Composed_Of
121
CSE
2102
CSE
2102
Binary RelationshipsBinary Relationships
Most relationships fall in this category
Faculty Course
Teaches
Manager Project
Manages
122
CSE
2102
CSE
2102
Ternary RelationshipsTernary Relationships
Relationships that exist between three entities
Vendor
Warehouse
Product
Ships
123
CSE
2102
CSE
2102
Ternary RelationshipsTernary Relationships
124
CSE
2102
CSE
2102
Ternary RelationshipsTernary Relationships
125
CSE
2102
CSE
2102
Ternary vs. Binary RelationshipsTernary vs. Binary Relationships
126
CSE
2102
CSE
2102
s1
s2
SUPPLIER
p1
p2
p3
PART
r1
r2
r3
r4
r5
r6
r7
SUPPLY
j1
j2
j3
PROJECT
Ternary Relationships - InstancesTernary Relationships - Instances
127
CSE
2102
CSE
2102
Modified Earlier ExampleModified Earlier Example
128
CSE
2102
CSE
2102
Another ER Diagram - Bank ExampleAnother ER Diagram - Bank Example
129
CSE
2102
CSE
2102
From ER Diagrams to Relational DB Tables ER Diagram is Conceptual Representation Possible to Generate Relational Database Tables
SQL Language Each Entity/Table has Two Abstractions Relational Table Defines
Class Aggregation of Class Instances
Dependencies Encoded within Table Primary and Foreign Keys Linkages Among Tables
Strive for Referenental Integrity Let’s see Examples
130
CSE
2102
CSE
2102
Two Versions of a Student RelationTwo Versions of a Student Relation
131
CSE
2102
CSE
2102
EMP
PROJ
WORKS
ENO ENAME TITLE SAL
PNO PNAME BUDGET
RESPPNOENO DUR
Relation Schemes Example
EMP(ENO, ENAME, TITLE, SAL) PROJ (PNO, PNAME, BUDGET) WORKS(ENO, PNO, RESP, DUR)
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.
EMP
ENO PNO RESP
E1 P1 Manager 12
DUR
E2 P1 Analyst 24E2 P2 Analyst 6E3 P3 Consultant 10E3 P4 Engineer 48E4 P2 Programmer 18E5 P2 Manager 24E6 P4 Manager 48E7 P3 Engineer 36
E8 P3 Manager 40
WORKS
E7 P5 Engineer 23
PROJ
PNO PNAME BUDGET
P1 Instrumentation 150000
P3 CAD/CAM 250000P2 Database Develop. 135000
P4 Maintenance 310000P5 CAD/CAM 500000
PROJ[PNO] P1P2P3P4P5
EMP[TITLE]
Elect.EngSyst. AnalMech. Eng
Programmer
133
CSE
2102
CSE
2102
A Complete Schema with Keys ...A Complete Schema with Keys ...
Keys Allow us to Establish Links Between Relations
What is ThisSimilar to in ER?
134
CSE
2102
CSE
2102
… …and Corresponding DB Tablesand Corresponding DB Tables
Which Represent Tuples/Instances of Each Relation
1455
ASCnullWBnullnull
135
CSE
2102
CSE
2102
… …with Remaining DB Tableswith Remaining DB Tables
136
CSE
2102
CSE
2102
A Constraint Involving Two Relations Used to Specify a Relationship Among Tuples in
Referencing Relation and Referenced Relation Definition: R1and R2 have a Referential Integrity
Constraint If Tuples in the Referencing Relation R1 have a Set of
Foreign Key (FK) Attributes That References Primary Key (PK) of Referenced Relation R2
A Tuple T1 in R1( A1, A
2 , ..., A
n) is Said to
Reference a Tuple T2 in R2 if FK {A1, A
2 , ...,
An} such that T1[fk] = T2[pk]
Referential Integrity ConstraintsReferential Integrity Constraints
137
CSE
2102
CSE
2102
ExamplesExamples
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.
EMPWORKS
PROJ
PNO PNAME BUDGET
P1 Instrumentation 150000
P3 CAD/CAM 250000P2 Database Develop. 135000
P4 Maintenance 310000P5 CAD/CAM 500000
ENO PNO RESP DUR
E1 P1 Manager 12E2 P1 Analyst 24E2 P2 Analyst 6E3 P3 Consultant 10E3 P4 Engineer 48E4 P2 Programmer 18E5 P2 Manager 24E6 P4 Manager 48E7 P3 Engineer 36
E8 P3 Manager 40E7 P5 Engineer 23
E9 P3 Engineer 30
138
CSE
2102
CSE
2102
ENO ENAME TITLE
ENO PNO RESP DUR
PNO PNAME BUDGET
WORK
EMP PROJ
WORK[ENO] is a subset of EMP[ENO]
WORK[PNO] is a subset of PROJ[PNO]
Referential Integrity Constraints
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.
