Title: Chapter 5: Software Specification
1Chapter 5 Software Specification
Prof. Steven A. Demurjian Computer Science
Engineering Department The University of
Connecticut 371 Fairfield Road, Box
U-4155 Storrs, CT 06269-4155
steve_at_engr.uconn.edu http//www.engr.uconn.edu/st
eve (860) 486 4818 (860) 486 3719 (office)
2Overview 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
3Whats 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)
4Whats 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
5Uses of Specification
- Statement of Users Needs
- Statement of Interface Between Machine and
Controlled Environment - Critical Issues
- Users 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
6Uses 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
7Classic Information System Design
8Data vs. Information
9Specification 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
10Clear, 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.
11Precise, 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 three copies
must be forwarded through three different
physical channels. The receiver accepts the
message on the basis of a two-out-of-three
voting policy.
12Consistent
- 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.
13Specification 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)
14Specification 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 SpecificationNo
Focus on Implementation - Actual Specifications Mix of Both
15Operational Specification Example
- Consider a geometric figure E
E can be drawn as follows 1. Select two points
P1 and P2 on a plane 2. Get a string of a certain
length and fix its ends to P1 and P2 3. Position
a pencil as shown in next figure 4. Move the pen
clockwise, keeping the string tightly stretched,
until you reach the point where you started
drawing
16Verification 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
- Whats 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?
17Operational 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
18Verification 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.
19Data 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/sdesig
n.html
20DFDs 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.
21Data 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.
22DFDs 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
23DFDs 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
24Methodology of Information System
1. Start from the context diagram
25Methodology of Information System
2. Proceed by refinements until you reach
elementary functions (preserve balancing)
26A Library Example DFD
27Refinement of Get a book
28Patient 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.
29A Refinement as Detailed DFD
30Further Refinement
31A High-Level DFD for HTSS
32A High-Level DFD for HTSS
33A Lower-Level DFD for HTSS
34DFDs 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
35DFDs 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?
36DFDs 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
37DFD 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, then the student is
enrolled in those courses, and the class
schedule is 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
classroom of an appropriate capacity can be
allocated depending on the number of students
enrolled.
38DFD Course Registration System
Context Diagram for Course Registration System
Courses other info.
Faculty
Students
Registration Process
Class schedule
Class list
Registrar
Registrar
39DFD Course Registration System
Level 1 DFD
Students
Individual Course Registration Information
Courses Other info.
2. Compile Distribute Information
1. Enroll Students
Registrar
Registrar
Schedules
Class Lists
Students
Faculty
Note External entity Students is replicated to
avoid crossing lines
40DFD Course Registration System
Level 2 DFD
Courses Other info.
Student Records
Course Prereqs
1.1 Obtain Student Preferences
1.2 Check Eligibility
List of Preferences
Eligible Students
1.3 Enroll Students in Classes
Individual course registration information
41Evaluating DFDs
- Easy to Read, but
- Informal Semantics
- How Does One Define Leaf Functions?
- Inherent Ambiguities in Flow
- Consider the DFD (Functions) Below
- Are Outputs from A, B, C
- all needed Before D isEnabled?
- What if Only A and B Present?
- Do A, B, and C have to beReceived in a
Particular Order? - Outputs for E and F are
- produced at the same time?
42Evaluating 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
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
43Finite 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 Eventsfor State Changes
44Classic FSM Examples
45FSMs Can Model Real World
- Consider a Refinement of High Pressure/High
Temperature FSM on Previous Slide
46FSM for HTSS
Next Coupon
Process Payment
No More Coupons
47Classes of FSMs
- Deterministic/Nondeterministic
- FSMs as Recognizers - Introduce Final States
- FSMs
- Used for Lexical Analysis in Compilers
- Realize Regular Expressions in Automata
q0 is an initial state qf is a final state
48FSMs as Recognizers
- FSMs as transducers - introduce set of outputs
49FSMs as recognizers (contd..)
e
r
a
d
b
h
i
r
t
w
e
o
What are the strings accepted by this FSM?
50FSM 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 )
51Example of State Explosion
- Consider Three Individual FSMs
52Composition The Resulting FSM
- Clearly, Complexity Has Increased
53FSMs 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
54Petri 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
55Basic Elements
P1
t1
P3
P2
Legend
Place
Transition
Directed arc
Token
56Basic Elements
P1
t1
P3
P2
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
57Basic Elements
P1
2
t1
P3
P2
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.
58Static 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.
59State of PN
P1
t1
P3
P2
Local State P1 1 P2 0 P3
0 Overall State lt1,0,0gt
60Petri Nets
- Petri Nets are Another Graphical Formalism for
Systems Specification Consisting of - Finite Set of Places (Circles Pis)
- Finite set of Transitions (Horizontal Lines
tjs) - Finite Set of Arrows Connecting Places to
Transitions and Transitions to Places - Tokens (Dots)
61Petri 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
62Modeling 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
63Petri Nets
- A Petri Net is Defined as a Quadruple (P,T,F,W)
withP places T transitions (P, T are finite)
F flow relation (F ? P?T ? T?P )
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
64Graphical Representation of PN
65PN Semantics Dynamic Evolution
- Transition t is Enabled iff
- ?p ? t's Input Places, M(p) ? W(ltp,tgt)
- 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(ltp,tgt)Consume a Token - If p is an Output Place M'(p) M(p)
W(ltt,pgt)Produce a Token - If p is both an Input and an Output Place
M'(p) M(p) - W(ltp,tgt) W(ltt,pgt)Consume and
Produce a Token
66After (a) either (b) or (c) may occur, then (d)
67Modeling 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
68Avoiding Starvation
- Focus on Cycle in Middle of PN
imposes alternation
69A Conflict-Free PN
- Always a Token Available in Place R for Both
Sides to Utilize - R Reloaded with 2 Tokens at
Each Step
this net can deadlock! consider
70A Deadlock-Free PN
- If One Side Uses 2, it Proceeds, Else Other Side
- Starvation is Still Possible
71A Partial Starvation
- Place Supplying t4 is Not Refilled with Token
72Producer-Consumer Example
- Individual PNs for Produce and Consume
separate nets for the subsystems
73Producer-Consumer Example
One net for the entire system
74Petri 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
75Assigning Values to Tokens
- Transitions have Predicates and Functions
- Predicate Refers to Values of Tokens in Inputs
- Functions Define Values of Tokens for Outputs
Predicate P2 gt 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 lt3,7gt would produce the
value 10 in P4. t2 can then fire using lt4, 4gt
76Other 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 lttmin, tmaxgt 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
77Combining Timing and Priorities
78Overview 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
79Initial Sketch of Movement
80Dealing with Buttons
Internal
External
81Modeling the Entire PN
82Summary 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
83Entity 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.
84Entities, 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.
85Example 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
86Example COMPANY Database
- Store Each Employees 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
87ER Diagram for the Company Database
88Summary of ER-Diagram Notation
- Meaning
- 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 1N FOR E1E2 IN R
- STRUCTURAL CONSTRAINT (min, max) ON PARTICIPATION
OF E IN R
Symbol
R
E2
N
N
R
E1
E2
(min,max)
R
E
89ER 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 NameJohn
Smith, SSN123456789, Address731 Fondren,
Houston, TX, Sexm, Birthdate09-jan-55
90Three 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)
91Sample Entity with Attributes
Name
Address
Age
SSN
Person
Body Type
Make
Model
ID
Color
Owner
Car
92Identifier 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
93Single-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
Name
Single-valued attribute
Employee
Skills
Multi-valued attribute
Employee
94Entities with Attribute Values
95Entity 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
96Entity Type CAR with Attributes
CAR Registration(RegistrationNumber, State),
V_ID, Make, Model, Year, (Color)
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)) . . .
97Two Other Entity Types
98Relationships 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
99The WORKS_ON Relationship
100Relationships Examples
Orders
Bookstore Books
NAME
AGE
STUDENT
GENDER
ENROLLED_IN
SUBJECT
CLASS
COURSE_ID
MAX_ENROLLMENT
101Relationships
- 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 (11)
- One to Many (1N)
- Many to Many (MN)
- Doesnt indicate whether one data object must
participate in the relationship
102Relationships 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
103Cardinality Modality Notation
Modality 0, if relationship is
optional Modality 1, if relationship is
mandatory
E2
E1
R
(min,max)
(min,max)
Modality Cardinality 0 Partial
1 One 1 Mandatory M
More than one
Places
R
Customer
Order
(1,1)
(0,M)
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).
104Relationship cardinalities
1
1
A R B is one to one
R
A
B
1
m
A R B is one to many (one A, many B)
A
R
B
n
1
A R B is many to one (one B, many A)
R
A
B
m
n
A R B is many to many (many A B)
R
A
B
105Relationship cardinalities Example
1
m
Parts
Suppliers
A
R
B
n
1
Parts
Suppliers
R
A
B
n
m
Parts
Suppliers
R
A
B
A supplier supplies many parts. A part is
supplied by many suppliers Parts are supplied by
suppliers.
106E-R Diagrams
Project Name
Employee Name
Duration
Project No
Employee No
EMPLOYEE
PROJECT
WORKS ON
Responsibility
Salary
Title
NoEmp
Address
City
Apt.
Street
107Weak 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 Dependents
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
108ER 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
- ????????
109Constraints 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)
110One-to-many(1N) or Many-to-one (N1)
EMPLOYEE
WORKS_FOR
DEPARTMENT
e1 ? e2 ? e3 ? e4 ? e5 ? e6 ? e7 ?
? d1 ? d2 ? d3
r1 r2 r3 r4 r5 r6 r7
111MANY-TO-MANY(MN)
r1 r2 r3 r4 r5 r6 r7
e1 ? e2 ? e3 ? e4 ? e5 ? e6 ? e7 ?
? d1 ? d2 ? d3
r8
r9
112One-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
Project Name
Employee Name
Duration
Project No
Employee No
1
1
EMPLOYEE
PROJECT
WORKS ON
Responsibility
Salary
Title
113One-to-One WORKS_ON Relationship
WORKS_ON Relationship Instances
EMPLOYEE Set
PROJECT Set
114Many-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
Project Name
Employee Name
Duration
Project No
Employee No
N
1
EMPLOYEE
PROJECT
WORKS ON
Responsibility
Salary
Title
115One-to-Many WORKS_ON Relationship
116Many-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 ProjectsEach
Project Can Employ Many Employees
Project Name
Employee Name
Duration
Project No
Employee No
N
M
EMPLOYEE
PROJECT
WORKS ON
Responsibility
Salary
Title
117Many-to-Many WORKS_ON Relationship
118Structural Constraints
- Structural Constraints on a Relationship are One
Way to Express the Semantics of a Relationship - Cardinality Ratio (of a Binary Relationship)
11, 1N, N1, or MN - 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
119Relationships 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
120Unary Relationship
Is_Manager_Of
Employee
Is_Composed_Of
Assembly Part
121Binary Relationships
Most relationships fall in this category
Teaches
Faculty
Course
Manages
Manager
Project
122Ternary Relationships
Relationships that exist between three entities
Warehouse
Vendor
Product
Ships
123Ternary Relationships
124Ternary Relationships
125Ternary vs. Binary Relationships
126Ternary Relationships - Instances
SUPPLIER
SUPPLY
PROJECT
s1 ? s2 ?
? j1 ? j2 ? j3
r1 r2 r3 r4 r5 r6 r7
PART
p1 ? p2 ? p3 ?
127Modified Earlier Example
128Another ER Diagram - Bank Example
129From 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
- Lets see Examples
130Two Versions of a Student Relation
131Relation 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
ENO
ENAME
TITLE
SAL
EMP
PROJ
WORKS
132Relation Instances
133A Complete Schema with Keys ...
Keys Allow us to Establish Links Between
Relations
What is This Similar to in ER?
134 and Corresponding DB Tables
Which Represent Tuples/Instances of Each Relation
A S C null W B null null
1 4 5 5
135 with Remaining DB Tables
136Referential Integrity Constraints
- 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, A2 , ..., An) is Said to
Reference a Tuple T2 in R2 if FK? A1, A2 ,
..., An such that T1fk T2pk
137Examples
WORKS
ENO
PNO
RESP
DUR
E9 P3 Engineer 30
138Referential Integrity Constraints
- A Referential Integrity Constraint Can Be
Displayed in a Relational Database Schema as a
Directed Arc From R1.FK to R2.PK
EMP
PROJ
ENO ENAME TITLE
PNO PNAME BUDGET
ENO PNO RESP DUR
WORK
WORKENO is a subset of EMPENO
WORKPNO is a subset of PROJPNO
139Another Example Referential Integrity
What Do these Arrows Represent in ER Diagram?
140What 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.
141Specialization/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
EMPLOYEE
EMPLOYEE
?
?
Condo
Expense Act.
MANAGER
MANAGER
142Generalization
- Abstracting the Common Properties of Two or More
Entities to Produce a Higher-level Entity
Project
Region
Specialty
SALESPERSON
Office
Car
Office
143Generalization
EMPLOYEE
?
d
SALESPERSON
Project
Office
Specialty
Office
Car
Region
144Constraints
- disjoint, total
- disjoint, partial
- overlapping, total
- overlapping, partial
M_date
?
Manufactured_Part
BatchNo
Part
o
?
DrawingNo
Purchased_Part
Description
PartNo
SupplierName
ListPrice
145Total and Partial Disjoint
Hourly Rate
EMPLOYEE
HOURLY_EMP
?
?
?
?
?
SALARIED_EMP
ENGINEER
SECRETARY
SALESPERSON
Salary
Project
Office
Specialty
Office
Car
Region
146Total Overlapping
Part No
PART
?
?
PURCHASED_PART
MANUFACTURED_PART
Batch No
Price
Drawing No
147HTSS ER Diagram Example
148HTSS ER Diagram Example
149Finding 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
150ER 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 number of
students enrolled, while each student can
register for a number of courses. A course is
taught by a single instructor. Each instructor
teaches only 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.
151ER Diagrams Example
Enrolled_In
Student
Course
Advised_by
Taught_by
Instructor
152Example 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
153Example COMPANY Database
- Store Each Employees 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
154ER Diagram for the Company Database
155UML 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.
156UML Use-Case Diagrams
- Define Functions on Basis of Actors and Actions
157UML Sequence Diagrams
- Describe Object Interactions by Exchanging
Messages
158UML Sequence Diagrams
- Describe Object Interactions by Exchanging
Messages
159UML Collaboration Diagrams
- Object Interactions and Their Ordering
160UML Statechart Diagrams
- Akin to Finite State Machine
161Activity Diagram
162Mathematical-Based Specifications
- Queueing and Simulation Models
- Predict and Simulate System Behavior
- CSE3504
- Declarative Specifications
- Logic Specifications
- Algebraic Specifications
- CSE4102 Programming Languages
- We Briefly Highlight
163An 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
L
L
L
164Simulation Model
To the Host
1,4,6
1,2,3,4,6,7
From the Host
2,3,4,5,6
From other Backends
To other Backends
2,3,5
8
165Simulation Program - Simscript
PREAMBLE THIS IS A SIMSCRIPT MODEL OF A
SINGLE SERVER QUEUE. IN THIS MODEL, THERE IS
ONLY ONE PROCESS CALLED CUSTOMER WHO INITIATES
THE PROCESSING NORMALLY MODE IS
UNDEFINED PROCESSES INCLUDE CUSTOMER RESOURCES
INCLUDE SERVER ACCUMLATE UTIL.SERVER AS THE
AVERAGE OF N.X.SERVER ACCUMULATE AVE.QUEUE.LENGTH
AS THE AVERAGE OF N.Q.SERVER ACCUMULATE
MAX.QUEUE.LENGTH AS THE MAXIMUM OF
N.Q.SERVER DEFINE NO.OF.ARRIVALS AND
MAX.NO.ARRIVALS AS INTEGER VARIABLES END MAIN PRI
NT 1 LINE THUS INPUT NUMBER MAXIMUM NUMBER OF
ARRIVALS READ MAX.NO.ARRIVALS CREATE EVERY
SERVER(1) LET U.SERVERER(1)1 ACTIVATE A CUSTOMER
IN EXPONENTIAL.F(10.0,1) MINUTES START
SIMULATION PRINT 4 LINES WITH TIME.V2460,
UTIL.SERVER(1), AVE.QUERY.LENGTH(1) AND
MAX.QUERY.LENGTH(1) THUS CLOCK TIME .
MINUTES THE UTILIZATION OF THE SEVER WAS
. THE AVERAGE LENGTH OF THE QUEUE WAS
. THE MAXIMIMUM LENGTH OF THE QUEUE WAS
END
166Simulation Program - Continued
PROCESS CUSTOMER ADD 1 TO NO.OF-ARRIVALS IF
NO.OF.ARRIVALS lt MAX.NO.ARRIVALS ACTIVATE A
CUSTOMER IN EXPONENTIAL.F(10.0,1)
MINUTES ALWAYS REQUEST 1 UNIT OF SEVER() WORK
EXPONENTIAL.F(8.0,2) MINUTES RELINQUISH 1 UNIT OF
SERVER(1) END EXECUTION/OUTPUT OF SIMULATION
PROGRAM INPUT NUMBER MAXIMUM NUMBER OF
ARRIVALS II.5gt 100 CLOCK TIME 100008.36
MINUTES THE UTILIZATION OF THE SEVER WAS .80 THE
AVERAGE LENGTH OF THE QUEUE WAS 2.65 THE
MAXIMIMUM LENGTH OF THE QUEUE WAS 12
167Requirements 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
168Recall Different Views Data Flow
169Recall Different Views Control Flow
170Interplay 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?
171Interplay of Specification Techniques
172Interplay of Specification Techniques
173Building 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)
- Whats in a Specification?
- Diverge to Web Page for Additional Presentation
- Accompanying Document
174What 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 - Bu