Скачать презентацию CSE 230 Chapter 5 Software Specification Prof Steven Скачать презентацию CSE 230 Chapter 5 Software Specification Prof Steven

19b04a0d70db1b6f950bad9df548a5b5.ppt

  • Количество слайдов: 116

CSE 230 Chapter 5: Software Specification Prof. Steven A. Demurjian Computer Science & Engineering CSE 230 Chapter 5: Software Specification Prof. Steven A. Demurjian Computer Science & Engineering Department The University of Connecticut 371 Fairfield Road, Box U-2155 Storrs, CT 06269 -2155 [email protected] uconn. edu http: //www. engr. uconn. edu/~stev e (860) 486 – 4818 (860) 486 – 3719 (office) CH 5. 1

CSE 230 Overview of Chapter 5 m m m What is a Specification? Operational CSE 230 Overview of Chapter 5 m m m What is a Specification? Operational and Diagrammatic Specifications q Data Flow Diagrams, Finite State Machines, Petri Nets, Entity Relationship Diagrams q UML Diagrams (Briefly – Revisit in Total) Mathematical-Based Specifications q Queueing and Simulation Models q Declarative Specifications Ø Logic-Based Notations Ø Algebraic Notations q Languages for Modular Specifications Ø Statecharts and Z m Specification Notations and Writing Specifications CH 5. 2

What’s in a Specification? m CSE 230 Specification is Broad Term that Means Definition What’s in a Specification? m CSE 230 Specification is Broad Term that Means Definition q Used at Different Stages of Software Development For Different Purposes q Statement of Agreement (Contract) Between Ø Producer and Consumer of A Service Ø Implementer and User All Desirable Qualities Must Be Specified Statement of User Requirements q Major Failures Occur Due to Misunderstandings Between Producer and User q "The Hardest Single Part of Building a Software System is Deciding Precisely What To Build" (F. Brooks – Mythical Man Month) q m CH 5. 3

What’s in a Specification? m CSE 230 m m m Specification can be Many What’s in a Specification? m CSE 230 m m m Specification can be Many Different things to Many Different Stakeholders (User, Designer, Manager, etc. ) Requirements Specification: q Agreement between End User and Designers Design Specification: q Agreement between Designers and Developers Module Specification: q Agreement between SEs that Use a Module and SEs that Implement a Module re. Interface Object-Oriented Specification: q Assertion of Class’ Capability via Public Interface Specification Involves “What” Implementation Involves “How” CH 5. 4

Uses of Specification m CSE 230 m m Statement of User’s Needs q Statement Uses of Specification m CSE 230 m m Statement of User’s Needs q Statement of Interface Between Machine and Controlled Environment Critical Issues: q User’s Needs May not be Understood by Developer q Need Ability to Verify Specification Problem Faced: q Serious Undesirable Effects can Result Due to Misunderstandings Between Software Engineers and Domain Experts CH 5. 5

Uses of Specification m CSE 230 Statement of Implementation Requirements q Hardware, OS, Language(s), Uses of Specification m CSE 230 Statement of Implementation Requirements q Hardware, OS, Language(s), DBMS, etc. q Requirement Specification Ø External Behavior of System Ø Functional and Non-Function Behavior Ø Design Spec Verified Against Requirements Spec q Design Specification Ø Description of Software Architecture Ø Code Must be Verified Against Design Spec m Reference Point During Product Maintenance q Verify that Changes Satisfy Requirements q Change in Specification Requires Adaptive Maintenance CH 5. 6

Classic Information System Design CSE 230 CH 5. 7 Classic Information System Design CSE 230 CH 5. 7

Data vs. Information CSE 230 CH 5. 8 Data vs. Information CSE 230 CH 5. 8

CSE 230 Specification Qualities m m m Clear, Unambiguous, Understandable Consistent q Inconsistencies May CSE 230 Specification Qualities m m m Clear, Unambiguous, Understandable Consistent q Inconsistencies May be Impossible to Implement q Complexity May Lead to Inconsistency q Inconsistencies Lead to Incorrect Implementation Completeness q Internally Complete: Specification Defines any new Concept or Terminology that it Uses q W. r. t. Requirements; All Requirements Should be Contained within Specification q Incrementality Aids Achievement of Completeness How Does the Achievement of Software Qualities Affect the Attainment of Specification Qualities? Let’s See Some Examples of These Qualities… CH 5. 9

CSE 230 Clear, Unambiguous, Understandable m m Specification Fragment for a Word-Processor Can an CSE 230 Clear, Unambiguous, Understandable m m 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. CH 5. 10

CSE 230 Precise, Unambiguous, Clear m m Consider a Real-Time Safety-Critical System Can a CSE 230 Precise, Unambiguous, Clear m m 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 3 rd? The message must be triplicated. copies must be forwarded through different physical channels. The accepts the message on the basis two-out-of-three voting policy. The three receiver of a CH 5. 11

CSE 230 Consistent m m m Specification Fragment for a Word-Processor What if the CSE 230 Consistent m m m 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. CH 5. 12

Specification Styles m CSE 230 m Informal: Natural Language, Spec by Visio/PPT, Figures, Tables, Specification Styles m CSE 230 m Informal: Natural Language, Spec by Visio/PPT, Figures, Tables, etc. Formal: Notation with precise Syntax/Semantics q 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) q Disadvantages: Ø Formal Specifications Not Widely Used Ø Hard to Justify Economic Gain Ø Training Issues for Personnel m Semi-Formal: No Precise Semantics (TDN/GDN) CH 5. 13

Specification Styles m CSE 230 m m Operational q Describes Desired Behavior of System Specification Styles m CSE 230 m m Operational q Describes Desired Behavior of System q Usually Provides a Model of System Behavior q Verified by Prototyping Descriptive q Describes Desired Properties of System q Declarative Specification q Usually Uses Mathematical Equations q More Abstract than Operation Specification No Focus on Implementation Actual Specifications – Mix of Both… CH 5. 14

CSE 230 Operational Specification Example m Consider a geometric figure E: E can be CSE 230 Operational Specification Example m Consider a geometric figure E: E can be drawn as follows: 1. Select two points P 1 and P 2 on a plane 2. Get a string of a certain length and fix its ends to P 1 and P 2 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 CH 5. 15

Verification of Specifications m CSE 230 m m Two Approaches: q “Observe” Dynamic Behavior Verification of Specifications m CSE 230 m m Two Approaches: q “Observe” Dynamic Behavior of Specified System (Simulation, Prototyping, “Testing” specs) q Analyze Properties of the Specified System Both Depend on Formality of Specification Analogy with Traditional Engineering q Physical Model of a Bridge Ø Build An Actual Model Ø Test it out in Wind Tunnel Mathematical Model of a Bridge What’s Reality of Bridge Building? q Guarantee of Success w. r. t. Weight, Weather, etc. Are there Similar Guarantees in Software? What Software Applications Need Such Guarantees? q m m m CH 5. 16

CSE 230 Operational Specifications m m m Allow the Behavior of a System to CSE 230 Operational Specifications m m m Allow the Behavior of a System to be Defined Many Complementary Techniques q Data Flow Diagrams q UML Diagrams (Briefly and Separate Lecture) q Finite State Machines q Petri Nets Operational Specifications Provide Means to Model System from Alternative Perspectives q Perspectives Must be Consistent with One Another q Some Techniques Target End-User/Customer q Others are More Software Engineering Intensive q Key Issue: All Diagrams Must be Consistent in Terminology to Yield Strong Result CH 5. 17

CSE 230 Data Flow Diagrams (DFDs) m m m m A Semi-Formal Operational Specification CSE 230 Data Flow Diagrams (DFDs) m m m m 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 q Tools are Commercially Available Ø http: //www. qsee-technologies. com/multi-case. htm Ø http: //www. aisintl. com/case/products/Power. Designer/sd esign. html CH 5. 18

DFDs Employ a Graphical Notation m CSE 230 m What are Main Modeling Constructs? DFDs Employ a Graphical Notation m CSE 230 m What are Main Modeling Constructs? q Bubbles Represent Functions q Arcs (Arrows) Data Flows q Open Boxes Represent Persistent Store q Closed Boxes Represent I/O Interaction Note: DFDs can not Represent Sequential Steps CH 5. 19

Methodology of Information System CSE 230 1. Start from the “context” diagram CH 5. Methodology of Information System CSE 230 1. Start from the “context” diagram CH 5. 20

CSE 230 Methodology of Information System 2. Proceed by refinements until you reach “elementary” CSE 230 Methodology of Information System 2. Proceed by refinements until you reach “elementary” functions (preserve balancing) CH 5. 21

A Library Example DFD CSE 230 CH 5. 22 A Library Example DFD CSE 230 CH 5. 22

Refinement of “Get a book” CSE 230 CH 5. 23 Refinement of “Get a book” CSE 230 CH 5. 23

CSE 230 Patient Monitoring Systems The purpose is to monitor the patients’ vital factors--blood, CSE 230 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. CH 5. 24

A Refinement as Detailed DFD CSE 230 CH 5. 25 A Refinement as Detailed DFD CSE 230 CH 5. 25

Further Refinement CSE 230 CH 5. 26 Further Refinement CSE 230 CH 5. 26

A High-Level DFD for HTSS CSE 230 CH 5. 27 A High-Level DFD for HTSS CSE 230 CH 5. 27

A High-Level DFD for HTSS CSE 230 CH 5. 28 A High-Level DFD for HTSS CSE 230 CH 5. 28

A Lower-Level DFD for HTSS CSE 230 CH 5. 29 A Lower-Level DFD for HTSS CSE 230 CH 5. 29

CSE 230 Evaluating DFDs m m m Easy to Read, but … Informal Semantics CSE 230 Evaluating DFDs m m m Easy to Read, but … Informal Semantics q How Does One Define Leaf Functions? q Inherent Ambiguities in Flow Consider the DFD (Functions) Below: • Are Outputs from A, B, C all needed Before D is Enabled? • What if Only A and B Present? • Do A, B, and C have to be Received in a Particular Order? • Outputs for E and F are produced at the same time? CH 5. 30

Evaluating DFDs m Clearly, Control Information is Absent CSE 230 Possible interpretations: (a) A Evaluating DFDs m Clearly, Control Information is Absent CSE 230 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 m DFDs are a Semi-Formal Notation q DFDs by Visio and PPT q Excellent Vehicle for Presenting to End-User q Not Standalone – Need Complementary Diagram(s) to Fully Specify System Capabilities CH 5. 31

CSE 230 Finite state machines (FSMs) m m m Utilized to Specify control flow CSE 230 Finite state machines (FSMs) m m m Utilized to Specify control flow aspects An FSM Consists of: q A finite set of states (nodes), Q; q A finite set of inputs (labels), I; q A transition function d : Q x I Q (d can be a partial function) FSMs are Well Suited to Represent Systems with q Multiple Known States q Well-Defined Events for State Changes CH 5. 32

Classic FSM Examples CSE 230 CH 5. 33 Classic FSM Examples CSE 230 CH 5. 33

CSE 230 FSM’s Can Model Real World m Consider a Refinement of High Pressure/High CSE 230 FSM’s Can Model Real World m Consider a Refinement of High Pressure/High Temperature FSM on Previous Slide CH 5. 34

FSM for HTSS m Totals a Customer’s Order CSE 230 Next Coupon No More FSM for HTSS m Totals a Customer’s Order CSE 230 Next Coupon No More Coupons Process Payment CH 5. 35

CSE 230 Classes of FSMs m m m Deterministic/Nondeterministic FSMs as Recognizers - Introduce CSE 230 Classes of FSMs m m m Deterministic/Nondeterministic FSMs as Recognizers - Introduce Final States FSMs q Used for Lexical Analysis in Compilers q Realize Regular Expressions in Automata q 0 is an initial state qf is a final state CH 5. 36

FSMs as Recognizers m FSMs as transducers - introduce set of outputs CSE 230 FSMs as Recognizers m FSMs as transducers - introduce set of outputs CSE 230 CH 5. 37

FSM Usage and Limitation m CSE 230 m m FSMs are Simple and Widely FSM Usage and Limitation m CSE 230 m m FSMs are Simple and Widely Used q Control Systems, Compilation q 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: q Model Different Portions of Application q Compose FSMs for Entire System View q Finite Memory Yields State Explosion Ø Suppose n FSMs with k 1, k 2, … kn states Ø Composition is a FSM with k 1 * k 2 *… * kn. Ø This growth is exponential with the number of FSMs, not linear (we would like it to be k 1 + k 2 +… + kn ) CH 5. 38

Example of State Explosion: m Consider Three Individual FSMs: CSE 230 CH 5. 39 Example of State Explosion: m Consider Three Individual FSMs: CSE 230 CH 5. 39

Composition: The Resulting FSM m Clearly, Complexity Has Increased CSE 230 CH 5. 40 Composition: The Resulting FSM m Clearly, Complexity Has Increased CSE 230 CH 5. 40

CSE 230 Petri Nets m Petri Nets are Another Graphical Formalism for System’s Specification CSE 230 Petri Nets m Petri Nets are Another Graphical Formalism for System’s Specification Consisting of: q Finite Set of Places (Circles – Pi’s) q Finite set of Transitions (Horizontal Lines – tj’s) q Finite Set of Arrows Connecting Places to Transitions and Transitions to Places q Tokens (Dots) CH 5. 41

Petri Nets – Other Concepts m CSE 230 m m m Marking: Assigning Non-Negative Petri Nets – Other Concepts m CSE 230 m m m 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 (t 1, t 3, t 2, t 5, …) PNs are Non-Deterministic q Any Enabled Transition May Fire q Neither When Nor Which Fires is Specified by Model CH 5. 42

CSE 230 Modeling with Petri nets m m Places Represent Distributed States Transitions Represent CSE 230 Modeling with Petri nets m m 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 q Fork: Transition from 1 Input to N Outputs q Join: Transition fron N Inputs to 1 Output CH 5. 43

Petri Nets m CSE 230 m m A Petri Net is Defined as a Petri Nets m CSE 230 m m A Petri Net is Defined as a Quadruple (P, T, F, W) with: P: places T: transitions (P, T are finite) F: flow relation (F {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 CH 5. 44

Graphical Representation of PN CSE 230 P P 2 1 t 1 P t Graphical Representation of PN CSE 230 P P 2 1 t 1 P t 3 P 2 P 5 4 t t P 4 3 P 7 6 t 5 t 6 CH 5. 45

PN Semantics: Dynamic Evolution m CSE 230 m Transition t is Enabled iff q PN Semantics: Dynamic Evolution m CSE 230 m Transition t is Enabled iff q p t's Input Places, M(p) W() Transition t Fires: Produces a New Marking M’ in Places that are Either t's Input or Output or Both q If p is an Input Place: M'(p) = M(p) - W() Consume a Token q If p is an Output Place: M'(p) = M(p) + W() Produce a Token q If p is both an Input and an Output Place: M'(p) = M(p) - W() + W() Consume and Produce a Token CH 5. 46

After (a) either (b) or (c) may occur, then (d) CSE 230 CH 5. After (a) either (b) or (c) may occur, then (d) CSE 230 CH 5. 47

Modeling Concurrent Systems m CSE 230 m m Concurrency: Two Transitions are Enabled to Modeling Concurrent Systems m CSE 230 m m Concurrency: Two Transitions are Enabled to Fire in Given State, and the Firing of One Does Nor Prevent the Other From Firing q See t 1 and t 2 in Case (a) Conflict: Two Transitions are Enabled to Fire in Given State, But the Firing of One Prevents the Other From Firing q See T 3 and T 4 in Case (d) q Place P 3 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 CH 5. 48

Avoiding Starvation m Focus on Cycle in Middle of PN CSE 230 imposes alternation Avoiding Starvation m Focus on Cycle in Middle of PN CSE 230 imposes alternation CH 5. 49

CSE 230 A Conflict-Free PN m Always a Token Available in Place R for CSE 230 A Conflict-Free PN m 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 CH 5. 50

CSE 230 A Deadlock-Free PN m m If One Side Uses 2, it Proceeds, CSE 230 A Deadlock-Free PN m m If One Side Uses 2, it Proceeds, Else Other Side Starvation is Still Possible CH 5. 51

A Partial Starvation m Place Supplying t 4 is Not Refilled with Token CSE A Partial Starvation m Place Supplying t 4 is Not Refilled with Token CSE 230 CH 5. 52

Producer-Consumer Example m Individual PNs for Produce and Consume CSE 230 separate nets for Producer-Consumer Example m Individual PNs for Produce and Consume CSE 230 separate nets for the subsystems CH 5. 53

Producer-Consumer Example m Combined PNs CSE 230 One net for the entire system CH Producer-Consumer Example m Combined PNs CSE 230 One net for the entire system CH 5. 54

Petri Net Limitations m CSE 230 m Petri Nets are Limited in Their Modeling Petri Net Limitations m CSE 230 m Petri Nets are Limited in Their Modeling Capability q As Presented, Non-Deterministic q No Way to Prioritorize Among All Eligible Active Transitions that Can Fire There a Number of Capabilities that Would be Very Useful in Modeling System Behavior q Adding Predicates and Functions that are Used to Evaluate Conditions Under Which a Transition Fire and its Results q Instituting Priority to Decide When to Fire Among Multiple Transitions that are Eligible q Incorporating Timing to Constrain When a Transition can Fire CH 5. 55

CSE 230 Assigning Values to Tokens m m m Transitions have Predicates and Functions CSE 230 Assigning Values to Tokens m m m Transitions have Predicates and Functions Predicate Refers to Values of Tokens in Inputs Functions Define Values of Tokens for Outputs Predicate P 2 > P 1 and function P 4 : = P 2 + P 1 associated with t 1 Predicate P 3 = P 2 and functions P 4 : = P 3 P 2 and P 5 : = P 2 + P 3 are associated with t 2 The firing of t 1 by using <3, 7> would produce the value 10 in P 4. t 2 can then fire using <4, 4> CH 5. 56

Other PN Extensions m CSE 230 Specifying Priorities q Function Pri from Transitions to Other PN Extensions m CSE 230 Specifying Priorities q Function Pri from Transitions to Natural Numbers: Ø pri: T N When Several Transitions are Enabled, Only Ones with Maximum Priority are Allowed to Fire q If Multiple Active, choose Non-deterministically Timing q Pair of Constants associated with each Transition – If Transition Enabled q m Ø 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 CH 5. 57

Combining Timing and Priorities CSE 230 CH 5. 58 Combining Timing and Priorities CSE 230 CH 5. 58

CSE 230 Overview of a PN Example m m m PNs can be Used CSE 230 Overview of a PN Example m m m PNs can be Used for Very Complex Applications Consider q An N Elevator System to be Installed in a Building with M Floors q Natural Language Specifications Contain Several Ambiguities q Formal Specification Using PNs Removes Ambiguities How is a Solution Constructed? q Employ Modules q Each Encapsulating Fragments of PNs q Each Captures Certain System Components CH 5. 59

Initial Sketch of Movement CSE 230 CH 5. 60 Initial Sketch of Movement CSE 230 CH 5. 60

Dealing with Buttons CSE 230 Internal Fj' UPj Set ti' External Fj On Off Dealing with Buttons CSE 230 Internal Fj' UPj Set ti' External Fj On Off x. . x Reset CH 5. 61

Modeling the Entire PN CSE 230 CH 5. 62 Modeling the Entire PN CSE 230 CH 5. 62

Entity Relationship Diagrams m CSE 230 m m m ER Model Concepts q Entities Entity Relationship Diagrams m CSE 230 m m m ER Model Concepts q Entities and Attributes q Entity Types, Value Sets, and Key Attributes q Relationships and Relationship Types q Weak Entity Types q Roles and Attributes in Relationship Types Relationships of Higher Degree Skip Extended Entity-Relationship (EER) Model Notation is based on : q R. Elmasri and S. B. Navathe, “ Fundamentals of Database Systems, ” Ed. 3. , Addison Wesley, 2000, Chapters 3 and 4. CH 5. 63

Summary of ER-Diagram Notation Meaning Symbol ENTITY TYPE CSE 230 WEAK ENTITY TYPE RELATIONSHIP Summary of ER-Diagram Notation Meaning Symbol ENTITY TYPE CSE 230 WEAK ENTITY TYPE RELATIONSHIP TYPE IDENTIFYING RELATIONSHIP TYPE ATTRIBUTE KEY ATTRIBUTE MULTIVALUED ATTRIBUTE COMPOSITE ATTRIBUTE DERIVED ATTRIBUTE E 1 E 2 R R R N (min, max) E 2 E TOTAL PARTICIPATION OF E 2 IN R CARDINALITY RATIO 1: N FOR E 1: E 2 IN R STRUCTURAL CONSTRAINT (min, max) ON PARTICIPATION OF E IN R CH 5. 64

CSE 230 Example COMPANY Database m Requirements of the Company (Oversimplified for Illustrative Purposes) CSE 230 Example COMPANY Database m Requirements of the Company (Oversimplified for Illustrative Purposes) q 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 q Each Department Controls a Number of Projects Ø Each Project has a Name, Number and is Located at a Single Location CH 5. 65

Example COMPANY Database (Cont. ) q CSE 230 Store Each Employee’s Social Security Number, Example COMPANY Database (Cont. ) q CSE 230 Store Each Employee’s Social Security Number, Address, Salary, Sex, and Birthdate Ø Each Employee Works for One Department but May Work on Several Projects Ø We Track of the Number of Hours Per Week that an Employee Currently Works on Each Project Ø We Track of the Direct Supervisor of Each Employee q Each Employee May have a Number of Dependents Ø For Each Dependent, We Track of their Name, Sex, Birthdate, and Relationship to Employee CH 5. 66

ER Diagram for the Company Database CSE 230 CH 5. 67 ER Diagram for the Company Database CSE 230 CH 5. 67

ER Model Concepts: Entities and Attributes m CSE 230 m m Entities - Specific ER Model Concepts: Entities and Attributes m CSE 230 m m Entities - Specific Objects or Things in the Mini-world that are Represented in the Database q EMPLOYEE John Smith q Research DEPARTMENT q Productx PROJECT Attributes are Properties Used to Describe an Entity e. g. , an EMPLOYEE Entity may have a Name, SSN, Address, Sex, Birthdate A Specific Entity (Instance) has a Value for Each of its Attributes q Specific Employee Entity May Have Name=‘John Smith’, SSN=‘ 123456789’, Address=‘ 731 Fondren, Houston, TX’, Sex=‘m’, Birthdate=‘ 09 jan-55’ CH 5. 68

Three Types of Attributes m CSE 230 m m m Simple: Single Atomic Value Three Types of Attributes m CSE 230 m m m Simple: Single Atomic Value for the Attribute q SSN or Sex or State or Salary or. . . Composite: Attribute Composed of Many Components q Address (Apt#, House#, Street, City, State, Zipcode, Country) or Name(Fname, MI, Lname) q 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 q CAR {Color} or STUDENT {Previousdegrees} Composite and Multi-valued Attributes may be Nested Arbitrarily to any Number of Levels (Rare) q Previousdegrees of a STUDENT is a Composite Multi-valued Attribute Denoted by {Previousdegrees(college, Year, Degree, Field)} CH 5. 69

Entities with Attribute Values CSE 230 CH 5. 70 Entities with Attribute Values CSE 230 CH 5. 70

Entity Types and Key Attributes m CSE 230 m m m Entities with the Entity Types and Key Attributes m CSE 230 m m m Entities with the Same Basic Attributes Are Grouped or Typed into an Entity Type q EMPLOYEE Entity Type or PROJECT Type Attribute of Entity Type for which Each Entity Must Have a Unique Value is Called a Key Attribute q SSN of EMPLOYEE, ISBN of BOOK A Key Attribute may be Composite q VIN is a Key of the CAR Entity Type An Entity Type may have More than One Key q CAR Entity Type May Have Two Keys: Ø VIN Ø Vehicletagnumber (Number, State) aka License Plate CH 5. 71

Entity Type CAR with Attributes CSE 230 CAR Registration(Registration. Number, State), V_ID, Make, Model, Entity Type CAR with Attributes CSE 230 CAR Registration(Registration. Number, State), V_ID, Make, Model, Year, (Color) car 1 ((ABC 123, TEXAS), TK 629, Ford Mustang, convertible, 1989, (red, black)) car 2 ((ABC 123, NEW YORK), WP 9872, Nissan Sentra, 2 -door, 1992, (blue)) car 3 ((VSY 720, TEXAS), TD 729, Chrysler Le. Baron, 4 -door, 1993, (white, blue)) . . . CH 5. 72

Two Other Entity Types CSE 230 CH 5. 73 Two Other Entity Types CSE 230 CH 5. 73

Relationships and Relationship Types m CSE 230 m A Relationship Relates Two or More Relationships and Relationship Types m CSE 230 m A Relationship Relates Two or More Distinct Entities With a Specific Meaning q EMPLOYEE John Smith Works on the Productx PROJECT q EMPLOYEE Franklin Wong Manages the Research DEPARTMENT q Relationship - Instance Level Relationships of the Same Type are Grouped or Typed Into a Relationship Type q WORKS_ON Relationship Type in Which Employees and Projects Participate q MANAGES Relationship Type in Which Employees and Departments Participate q Analogous to Reference or List in Programming CH 5. 74

The WORKS_ON Relationship CSE 230 CH 5. 75 The WORKS_ON Relationship CSE 230 CH 5. 75

Relationships and Relationship Types m CSE 230 m m Degree of a Relationship Type Relationships and Relationship Types m CSE 230 m m Degree of a Relationship Type is the Number of Participating Entity Types q Both MANAGES and WORKS_ON are Binary Relationships q What is a possible Ternary Relationship? More Than One Relationship Type Can Exist With the Same Participating Entity Types q MANAGES and WORKS_FOR are Distinct Relationships Between EMPLOYEE and DEPARTMENT Entity Types Relationships are Directional q SUPPLIES: SUPPLIER to PARTS q SUPPLIERS: PARTS to SUPPLIER CH 5. 76

CSE 230 E-R Diagrams Employee No Employee Name EMPLOYEE Title WORKS ON Salary Address CSE 230 E-R Diagrams Employee No Employee Name EMPLOYEE Title WORKS ON Salary Address Apt. # Duration Responsibility Project No Project Name PROJECT Budget No. Emp Location City Street # CH 5. 77

CSE 230 Weak Entity Types m m Entity that Does Not have a Key CSE 230 Weak Entity Types m m 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: q A Partial Key of the Weak Entity Type q Particular Entity they Are Related to in the Identifying Entity Type Example: q A DEPENDENT Entity is Identified by Dependent’s First Name and Birthdate, and the EMPLOYEE That the Dependent is Related to q DEPENDENT is a Weak Entity Type With EMPLOYEE as its Identifying Entity Type Via the Identifying Relationship Type DEPENDENT_OF CH 5. 78

CSE 230 ER Model and Data Abstraction m m Abstraction Classification m Aggregation m CSE 230 ER Model and Data Abstraction m m Abstraction Classification m Aggregation m m m Identification Generalization m m 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 ? ? ? ? CH 5. 79

CSE 230 Constraints on Aggregation m Cardinality Constraints on Relationship Types q AKA Ratio CSE 230 Constraints on Aggregation m Cardinality Constraints on Relationship Types q AKA Ratio Constraints q Maximum Cardinality Ø Ø Ø q One-to-One One-to-Many-to-Many Minimum Cardinality (AKA Participation or Existence Dependency Constraints) Ø Zero (Optional Participation, Not Existence-Dependent) Ø One or More (Mandatory, Existence-Dependent) CH 5. 80

CSE 230 One-to-many(1: N) or Many-to-one (N: 1) EMPLOYEE WORKS_FOR e 1 r 1 CSE 230 One-to-many(1: N) or Many-to-one (N: 1) EMPLOYEE WORKS_FOR e 1 r 1 e 2 e 3 r 2 e 4 e 5 e 6 r 5 e 7 DEPARTMENT r 6 d 1 d 2 d 3 r 4 r 7 CH 5. 81

MANY-TO-MANY(M: N) CSE 230 r 9 e 1 r 1 e 2 e 3 MANY-TO-MANY(M: N) CSE 230 r 9 e 1 r 1 e 2 e 3 r 2 e 4 d 1 d 2 d 3 r 4 e 5 e 6 r 5 e 7 r 6 r 8 r 7 CH 5. 82

One-to-One Relationship m CSE 230 m Each Instance of One Entity Class E 1 One-to-One Relationship m CSE 230 m Each Instance of One Entity Class E 1 Can Be Associated with Exactly One Instance of Another Entity Class E 2 and Vice Versa. Example: q Each Employee Can Work in Exactly One Project and Each Project Employs Exactly One Employee No Employee Name EMPLOYEE Title 1 Salary Duration WORKS ON Responsibility Project No 1 Project Name PROJECT Budget CH 5. 83

One-to-One WORKS_ON Relationship Instances CSE 230 EMPLOYEE Set PROJECT Set CH 5. 84 One-to-One WORKS_ON Relationship Instances CSE 230 EMPLOYEE Set PROJECT Set CH 5. 84

Many-to-One Relationship m CSE 230 m Each Instance of One Entity Class E 1 Many-to-One Relationship m CSE 230 m Each Instance of One Entity Class E 1 can be Associated with Zero or More Instances of Another Entity Class E 2, but Each Instance of E 2 can be Associated With at Most 1 Instance of E 1 Example : q Each Employee Can Work in Exactly One Project Each Project Can Employ Many Engineers Employee No Employee Name EMPLOYEE Title N Salary Duration WORKS ON Responsibility Project No 1 Project Name PROJECT Budget CH 5. 85

One-to-Many WORKS_ON Relationship CSE 230 CH 5. 86 One-to-Many WORKS_ON Relationship CSE 230 CH 5. 86

Many-to-Many Relationship m CSE 230 m Each Instance of One Entity Class Can Be Many-to-Many Relationship m CSE 230 m Each Instance of One Entity Class Can Be Associated with Many Instances of Another Entity Class, and vice versa Example: q Each Employee Can Work in Many Projects Each Project Can Employ Many Employees Employee No Employee Name EMPLOYEE Title N Salary Duration WORKS ON Responsibility Project No M Project Name PROJECT Budget CH 5. 87

Many-to-Many WORKS_ON Relationship CSE 230 CH 5. 88 Many-to-Many WORKS_ON Relationship CSE 230 CH 5. 88

Structural Constraints m CSE 230 m m m Structural Constraints on a Relationship are Structural Constraints m CSE 230 m m m Structural Constraints on a Relationship are One Way to Express the Semantics of a Relationship Cardinality Ratio (of a Binary Relationship): 1: 1, 1: N, N: 1, or M: N q Shown by Placing Apropos Number on the Link Participation Constraint (on Each Entity Type): q Total (Called Existence Dependency) or Partial q Shown By Double Lining The Link NOTE: q Easy to Specify for Binary Relationship Types q Do Not Be Misled by Obscure Notations to Specify Above Constraints for Higher Order Relationships CH 5. 89

CSE 230 Relationships of Higher Degree m m Relationship Types of Degree 2 Are CSE 230 Relationships of Higher Degree m m Relationship Types of Degree 2 Are Called Binary Relationship Types of Degree 3 Are Called Ternary q There is a Concrete Relationship Instance that Involves all Three Entity Types q These are Not Separate Relationships! Relationship Types of Degree N Are Called N-ary q Again - Concrete n-Participation Relationship In General, an N-ary Relationship is Not Equivalent to N Binary Relationships q Rather - it is more Analogous to the Grouping of N -Binary Relationships into a N-ary Relationship CH 5. 90

Ternary Relationships CSE 230 CH 5. 91 Ternary Relationships CSE 230 CH 5. 91

Ternary Relationships CSE 230 CH 5. 92 Ternary Relationships CSE 230 CH 5. 92

Ternary vs. Binary Relationships CSE 230 CH 5. 93 Ternary vs. Binary Relationships CSE 230 CH 5. 93

CSE 230 Ternary Relationships - Instances SUPPLIER s 1 s 2 SUPPLY r 1 CSE 230 Ternary Relationships - Instances SUPPLIER s 1 s 2 SUPPLY r 1 r 2 PROJECT j 1 j 2 r 3 PART r 4 p 1 r 5 p 2 r 6 p 3 j 3 r 7 CH 5. 94

Modified Earlier Example CSE 230 CH 5. 95 Modified Earlier Example CSE 230 CH 5. 95

Another ER Diagram - Bank Example CSE 230 CH 5. 96 Another ER Diagram - Bank Example CSE 230 CH 5. 96

What are Problems with ER Notation? m Historically, ER Model 1 st Proposed in What are Problems with ER Notation? m Historically, ER Model 1 st 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. CSE 230 m m However, ER Model in this Original Form Did Not Support the Generalization Abstraction (Inheritance) In Databases, Inheritance 1 st Proposed in 1977 Ø J. Smith and D. Smith, ''Database Abstractions: Aggregation and Generalization, '' ACM Trans. on Database Systems, Vol. 2, No. 2, June 1977. m Thus, Extended ER Evolved through 1980 s with the Focus on “Semantic Data Models” Ø M. Hammer and D. Mc. Leod, ''Database Descriptions with SDM: A Semantic Data Model, '' ACM Trans. on Database Systems, Vol. 6, No. 3, Sept. 1981. CH 5. 97

Specialization/Attribute Inheritance m CSE 230 m An Entity Type E 1 is a Specialization Specialization/Attribute Inheritance m CSE 230 m An Entity Type E 1 is a Specialization of another Entity Type E 2 if E 1 has the Same Properties of E 2 and Perhaps Even More. Salary Employee No Employee E 1 IS-A E 2 Name EMPLOYEE MANAGER Title EMPLOYEE Address Condo Expense Act. Title MANAGER Employee No Employee Name Address Salary CH 5. 98

Generalization m CSE 230 Project Office Abstracting the Common Properties of Two or More Generalization m CSE 230 Project Office Abstracting the Common Properties of Two or More Entities to Produce a “Higher-level” Entity ENGINEER Employee No Salary Employee Name Title Address Specialty Office SECRETARY Employee No Salary Employee Name Title Address EMPLOYEE SALESPERSON Region Car Employee No Salary Employee Name Title Address CH 5. 99

Generalization Employee No Title CSE 230 Employee Name EMPLOYEE Salary Address d ENGINEER Project Generalization Employee No Title CSE 230 Employee Name EMPLOYEE Salary Address d ENGINEER Project Office SECRETARY Specialty Office SALESPERSON Region Car CH 5. 100

m m disjoint, total d disjoint, partial n overlapping, total o n overlapping, partial m m disjoint, total d disjoint, partial n overlapping, total o n overlapping, partial d o M_date CSE 230 Constraints Manufactured_Part. No o Batch. No Drawing. No Purchased_Part Description Supplier. Name List. Price CH 5. 101

Total and Partial Disjoint CSE 230 Employee No Employee Name Salary Hourly Rate EMPLOYEE Total and Partial Disjoint CSE 230 Employee No Employee Name Salary Hourly Rate EMPLOYEE Title HOURLY_EMP SALARIED_EMP d d ENGINEER Salary Address Project Office SECRETARY Specialty Office SALESPERSON Region Car CH 5. 102

Total Overlapping CSE 230 Part No Part Name QTY PART WGT o MANUFACTURED_PART Batch Total Overlapping CSE 230 Part No Part Name QTY PART WGT o MANUFACTURED_PART Batch No Drawing No PURCHASED_PART Price CH 5. 103

HTSS ER Diagram Example CSE 230 CH 5. 104 HTSS ER Diagram Example CSE 230 CH 5. 104

HTSS ER Diagram Example CSE 230 CH 5. 105 HTSS ER Diagram Example CSE 230 CH 5. 105

Interplay of Specification Techniques m CSE 230 m m m What do DFDs have Interplay of Specification Techniques m CSE 230 m m m What do DFDs have to Offer re. OO Design? q Data Stores (Classes) q Arrow Labels (Parameters) q Input (Method of Class) q Functions (Implementation of Method of Class) q Output (Return of Method of Class) What do DFDs have to Offer re. ER Design? q Data Stores (Entities) q Arrow Labels (Relationships and Keys) What about FSMs? What is Impact w. r. t. Modular or ADT/Class Design? CH 5. 106

Interplay of Specification Techniques CSE 230 CH 5. 107 Interplay of Specification Techniques CSE 230 CH 5. 107

Interplay of Specification Techniques CSE 230 CH 5. 108 Interplay of Specification Techniques CSE 230 CH 5. 108

UML Diagrams m CSE 230 m m UML is a Language for Specifying, Visualizing, UML Diagrams m CSE 230 m m 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? q Model Elements: Concepts and Semantics q Notation: Visual Rendering of Model Elements q Guidelines: Hints and Suggestions for Using Elements in Notation UML has 13 Different Diagrams (2. 0) References and Resources q Web for UML 2. 0: www. uml. org q “The Unified Modeling Language Reference Manual”, Addison-Wesley. CH 5. 109

UML Use-Case Diagrams m Define Functions on Basis of Actors and Actions CSE 230 UML Use-Case Diagrams m Define Functions on Basis of Actors and Actions CSE 230 borrow book return book customer librarian library update CH 5. 110

UML Sequence Diagrams m Describe Object Interactions by Exchanging Messages CSE 230 CH 5. UML Sequence Diagrams m Describe Object Interactions by Exchanging Messages CSE 230 CH 5. 111

UML Sequence Diagrams m Describe Object Interactions by Exchanging Messages CSE 230 CH 5. UML Sequence Diagrams m Describe Object Interactions by Exchanging Messages CSE 230 CH 5. 112

UML Collaboration Diagrams m Object Interactions and Their Ordering CSE 230 CH 5. 113 UML Collaboration Diagrams m Object Interactions and Their Ordering CSE 230 CH 5. 113

UML Statechart Diagrams m Akin to Finite State Machine CSE 230 CH 5. 114 UML Statechart Diagrams m Akin to Finite State Machine CSE 230 CH 5. 114

Activity Diagram m Akin to Petri Net m Let’s Consider UML in Total (Jump Activity Diagram m Akin to Petri Net m Let’s Consider UML in Total (Jump to New Power. Point Presentation) CSE 230 CH 5. 115

Mathematical-Based Specifications m CSE 230 m m Queueing and Simulation Models q Predict and Mathematical-Based Specifications m CSE 230 m m Queueing and Simulation Models q Predict and Simulate System Behavior q CSE 221 Declarative Specifications: q Logic Specifications q Algebraic Specifications q CSE 237 Languages for Modular Specifications q Statecharts and Z CH 5. 116