Chapter 5: Software Specification - PowerPoint PPT Presentation

View by Category
About This Presentation
Title:

Chapter 5: Software Specification

Description:

Chapter 5: Software Specification Prof. Steven A. Demurjian Computer Science & Engineering Department The University of Connecticut 371 Fairfield Road, Box U-4155 – PowerPoint PPT presentation

Number of Views:439
Avg rating:3.0/5.0
Slides: 178
Provided by: Steve2245
Category:

less

Write a Comment
User Comments (0)
Transcript and Presenter's Notes

Title: Chapter 5: Software Specification


1
Chapter 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)
2
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
Whats 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
Whats 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
Uses 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

6
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
Classic Information System Design
8
Data vs. Information
9
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
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
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 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.
12
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
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
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 SpecificationNo
    Focus on Implementation
  • Actual Specifications Mix of Both

15
Operational 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
16
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
  • 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?

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

19
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/sdesig
    n.html

20
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
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
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
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

24
Methodology of Information System
1. Start from the context diagram
25
Methodology of Information System
2. Proceed by refinements until you reach
elementary functions (preserve balancing)
26
A Library Example DFD
27
Refinement of Get a book
28
Patient 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.
29
A Refinement as Detailed DFD
30
Further Refinement
31
A High-Level DFD for HTSS
32
A High-Level DFD for HTSS
33
A Lower-Level DFD for HTSS
34
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
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
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
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, 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.
38
DFD Course Registration System
Context Diagram for Course Registration System
Courses other info.
Faculty
Students
Registration Process
Class schedule
Class list
Registrar
Registrar
39
DFD 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
40
DFD 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
41
Evaluating 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?

42
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

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
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 Eventsfor State Changes

44
Classic FSM Examples
45
FSMs Can Model Real World
  • Consider a Refinement of High Pressure/High
    Temperature FSM on Previous Slide

46
FSM for HTSS
  • Totals a Customers Order

Next Coupon
Process Payment
No More Coupons
47
Classes 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
48
FSMs as Recognizers
  • FSMs as transducers - introduce set of outputs

49
FSMs as recognizers (contd..)
e
r
a
d
b
h
i
r
t
w
e
o
What are the strings accepted by this FSM?
50
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
Example of State Explosion
  • Consider Three Individual FSMs

52
Composition The Resulting FSM
  • Clearly, Complexity Has Increased

53
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
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
Basic Elements
P1
t1
P3
P2
Legend
Place
Transition
Directed arc
Token
56
Basic 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
57
Basic 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.
58
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.

59
State of PN
P1
t1
P3
P2
Local State P1 1 P2 0 P3
0 Overall State lt1,0,0gt
60
Petri 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)

61
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
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
Petri 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

64
Graphical Representation of PN
65
PN 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

66
After (a) either (b) or (c) may occur, then (d)
67
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
Avoiding Starvation
  • Focus on Cycle in Middle of PN

imposes alternation
69
A 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
70
A Deadlock-Free PN
  • If One Side Uses 2, it Proceeds, Else Other Side
  • Starvation is Still Possible

71
A Partial Starvation
  • Place Supplying t4 is Not Refilled with Token

72
Producer-Consumer Example
  • Individual PNs for Produce and Consume

separate nets for the subsystems
73
Producer-Consumer Example
  • Combined PNs

One net for the entire system
74
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
Assigning 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
76
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 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

77
Combining Timing and Priorities
78
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
Initial Sketch of Movement
80
Dealing with Buttons
Internal
External
81
Modeling the Entire PN
82
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
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
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
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
Example 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

87
ER Diagram for the Company Database
88
Summary 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
89
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 NameJohn
    Smith, SSN123456789, Address731 Fondren,
    Houston, TX, Sexm, Birthdate09-jan-55

90
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
Sample Entity with Attributes
Name
Address
Age
SSN
Person
Body Type
Make
Model
ID
Color
Owner
Car
92
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
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

Name
Single-valued attribute
Employee
Skills
Multi-valued attribute
Employee
94
Entities with Attribute Values
95
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
Entity 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)) . . .
97
Two Other Entity Types
98
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
The WORKS_ON Relationship
100
Relationships Examples
Orders
Bookstore Books
NAME
AGE
STUDENT
GENDER
ENROLLED_IN
SUBJECT
CLASS
COURSE_ID
MAX_ENROLLMENT
101
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 (11)
  • One to Many (1N)
  • Many to Many (MN)
  • Doesnt indicate whether one data object must
    participate in the relationship

102
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
Cardinality 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).
104
Relationship 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
105
Relationship 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.
106
E-R Diagrams
Project Name
Employee Name
Duration
Project No
Employee No
EMPLOYEE
PROJECT
WORKS ON
Responsibility
Salary
Title
NoEmp
Address
City
Apt.
Street
107
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 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

108
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
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
One-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
111
MANY-TO-MANY(MN)
r1 r2 r3 r4 r5 r6 r7
e1 ? e2 ? e3 ? e4 ? e5 ? e6 ? e7 ?
? d1 ? d2 ? d3
r8
r9
112
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

Project Name
Employee Name
Duration
Project No
Employee No
1
1
EMPLOYEE
PROJECT
WORKS ON
Responsibility
Salary
Title
113
One-to-One WORKS_ON Relationship
WORKS_ON Relationship Instances
EMPLOYEE Set
PROJECT Set
114
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

Project Name
Employee Name
Duration
Project No
Employee No
N
1
EMPLOYEE
PROJECT
WORKS ON
Responsibility
Salary
Title
115
One-to-Many WORKS_ON Relationship
116
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 ProjectsEach
    Project Can Employ Many Employees

Project Name
Employee Name
Duration
Project No
Employee No
N
M
EMPLOYEE
PROJECT
WORKS ON
Responsibility
Salary
Title
117
Many-to-Many WORKS_ON Relationship
118
Structural 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

119
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
Unary Relationship
Is_Manager_Of
Employee
Is_Composed_Of
Assembly Part
121
Binary Relationships
Most relationships fall in this category
Teaches
Faculty
Course
Manages
Manager
Project
122
Ternary Relationships
Relationships that exist between three entities
Warehouse
Vendor
Product
Ships
123
Ternary Relationships
124
Ternary Relationships
125
Ternary vs. Binary Relationships
126
Ternary Relationships - Instances
SUPPLIER
SUPPLY
PROJECT
s1 ? s2 ?
? j1 ? j2 ? j3
r1 r2 r3 r4 r5 r6 r7
PART
p1 ? p2 ? p3 ?
127
Modified Earlier Example
128
Another ER Diagram - Bank Example
129
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
  • Lets see Examples

130
Two Versions of a Student Relation
131
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

ENO
ENAME
TITLE
SAL
EMP
PROJ
WORKS
132
Relation Instances
133
A 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
136
Referential 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

137
Examples
WORKS
ENO
PNO
RESP
DUR
E9 P3 Engineer 30
138
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

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
139
Another Example Referential Integrity
What Do these Arrows Represent in ER Diagram?
140
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
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

EMPLOYEE
EMPLOYEE
?
?
Condo
Expense Act.
MANAGER
MANAGER
142
Generalization
  • Abstracting the Common Properties of Two or More
    Entities to Produce a Higher-level Entity

Project
Region
Specialty
SALESPERSON
Office
Car
Office
143
Generalization
EMPLOYEE
?
d
SALESPERSON
Project
Office
Specialty
Office
Car
Region
144
Constraints
  • disjoint, total
  • disjoint, partial
  • overlapping, total
  • overlapping, partial

M_date
?
Manufactured_Part
BatchNo
Part
o
?
DrawingNo
Purchased_Part
Description
PartNo
SupplierName
ListPrice
145
Total and Partial Disjoint
Hourly Rate
EMPLOYEE
HOURLY_EMP
?
?
?
?
?
SALARIED_EMP
ENGINEER
SECRETARY
SALESPERSON
Salary
Project
Office
Specialty
Office
Car
Region
146
Total Overlapping
Part No
PART
?
?
PURCHASED_PART
MANUFACTURED_PART
Batch No
Price
Drawing No
147
HTSS ER Diagram Example
148
HTSS ER Diagram Example
149
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
ER 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.
151
ER Diagrams Example
Enrolled_In
Student
Course
Advised_by
Taught_by
Instructor
152
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
Example 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

154
ER Diagram for the Company Database
155
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
UML Use-Case Diagrams
  • Define Functions on Basis of Actors and Actions



157
UML Sequence Diagrams
  • Describe Object Interactions by Exchanging
    Messages

158
UML Sequence Diagrams
  • Describe Object Interactions by Exchanging
    Messages

159
UML Collaboration Diagrams
  • Object Interactions and Their Ordering

160
UML Statechart Diagrams
  • Akin to Finite State Machine

161
Activity Diagram
  • Akin to Petri Net

162
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
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

L
L
L
164
Simulation 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
165
Simulation 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
166
Simulation 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
167
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
Recall Different Views Data Flow
169
Recall Different Views Control Flow
170
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
Interplay of Specification Techniques
172
Interplay of Specification Techniques
173
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)
  • Whats in a Specification?
  • Diverge to Web Page for Additional Presentation
  • Accompanying Document

174
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
  • Bu
About PowerShow.com