Structured Design and Modeling CS 123CS 231 Design

Structured Design and Modeling CS 123/CS 231

Design Models Revisited z. UML: Modeling Language for OO Systems z. For the Procedural (Structured) Paradigm ÕData and processes are separately considered ÕData Model: Entity-Relationship Diagram ÕProcess Model: Data-Flow Diagram z. Some modeling techniques apply to both paradigms

ERDs z. Entity-Relationship Diagrams z. Used to produce a data model for an enterprise z. Models data entities, their attributes, and relationship among data entities z. Database Design

Entities and Attributes z. Entity Õthing, person, place Õexamples: Book, Sales Invoice, Student, Customer, Employee, Department, Airport z. Attribute Õfeature of an entity Õexamples: Name, Address, Age, QCA, Title, Author, Amount, City

Relationships z. Relationship Õan association between (at least) two entities Õexamples: student borrows a book z. Cardinality ÕOne-to-one, one-to-many, many-to-many z. Intersection Data Õattribute resulting from relationship Õexample: date-borrowed

The Notation z. Rectangles - Entities z. Ellipses - Attributes z. Diamonds - Relationships z. Links z. Labels * Other models omit the diamonds and use the lines and other notation to denote relationships

Sample Notation

Example

Example: The University Setting z. Description ÕStudents enroll in classes. Each class is a section of a particular course. z. Entities ÕStudent, Section, Course

name address year id number qca Student

index Student M M enrolls room sched Section M grade Course cat num title 1 desc has

Example 2: Library z. Student borrows book Õmany to many relationship between students and books Õsee first diagram z. Further analysis reveals there could be several copies of a book Õstudent borrows copy, book has copy Õsee second diagram

Student M borrows M Book

Student M M borrows Copy M Book 1 has Exercise: Complete Diagram by filling in attributes

ERDs and the Software Life Cycle z. Used at the design phase of the software life cycle for database systems, although it is often used as early as the analysis phase z. In design, it precedes table definition

From ERD to Tables z. Create a table for each entity Õattributes associated to entity are columns of the table (a primary key should exist per table) z. For each 1: M relationship Õadd the primary key of the “ 1” participant as an attribute of the “M” participant (foreign key); intersection data is also added to the “M” participant

ERD to Tables, continued z. For each 1: 1 relationship Õadd primary key of one table plus intersection data to the other table z. For each M: M relationship Õcreate a new table Õattributes are the primary keys of the participants plus intersection data

University Setting Example z. Student Õid number, name, address, year, qca z. Section Õindex, room, sched, cat num z. Course Õcat num, title, desc z. Enroll Õid number, index, grade

DFDs z. Data Flow Diagrams z. Models Operations (Processes) z. Also used in analysis and design

Traditional approach z. System is a collection of processes z. Processes interact with data entities z. Processes accept inputs and produce outputs

DFD Definition z. A graphical representation of data processes in the organization z. Depicts the broad overview of system inputs, processes and outputs z. Dataflow approach emphasizes the logic underlying the system z. A tool for system analysis - aid to conceptualization

Processes z. An operation or function in a system Õexample: Borrow Book z. Involves Õdata flow (input and results) ÕData stores, sources and sinks Example: student and book-copy info are data that flow into the process; results stored in borrow table

Notation z. Circle (Bubble) or Square with rounded corners - Process z. Arrows - Data Flows z. Rectangles – Stores and Entities (Sources and Sinks) z. Labels

id num, copy num Student 1 Borrow Book Copy borrow confirmation Borrow

Conventions - Symbols External entity that can send data or receive data Source/Origin or Sink/Destination - Noun Movement of data from one point to another - Noun Transforming process representing work being performed within the system - Verb-Adjective-Noun Repository of data or data store which could be manual or computerized - Noun

Comparison of De. Marco & Yourdon and Gane & Sarson DFD Symbol Sets

Illegal Data Flows

DFD Levels z. A process may involve sub-processes Õprovides detail about the process z. DFD levels emerge z. Process hierarchy also depicted using a structure chart

id num 1. 1 Check Student Status borrower status Student copy num Copy 1. 2 Check Book Copy Status copy status

borrower status, copy status id num, copy num 1. 3 Record Borrow borrow confirmation Borrow Copy

Developing DFDs - Top Down Approach 1. List business activities and determine Õexternal entities Õdata flows Õprocesses Õdata stores 2. Create context diagram Õshow external entities and data flows in and out of the system Õno detailed processes or data stores

Developing DFDs 3. Draw Diagram 0 Õshow processes, keep them general Õshow data stores at this level 4. Create the Child Diagram/s for all processes of Diagram 0, as necessary 5. Check for errors and make sure labels are meaningful

Context Diagram z. Highest level and contains only one process representing the entire system z. Broadest possible conceptualization of the system - bird’s eye view of data movement z. Contains the external entities and data flow to and from the system z. No data stores z. Numbered 0

Context Diagram z. Top-level view of an information system that shows the system’s boundaries and scope. z. Start by placing the process symbol at the center; place external entities at the perimeter

Context Diagram of Hoosier Burger’s Food Ordering System

Diagram 0 - Next Level z. Context diagram explosion into subprocesses; entities and data flows intact z. Contains new lower level data flows and data stores; shows details inside black box z. Handling of exceptions is ignored z Up to 9 processes in single sheet z. Numbered by integers, left to right z. Data stores numbered sequentially - “D#”

Level 0 DFD of Hoosier Burger’s Food Ordering System Diagram 0: Food Ordering System

Child Diagram - Low Level z. Parent Process in Diagram 0 is exploded to one or more Child Diagrams z. Vertical balancing - Diagram 0 data flows intact; called “interface data flow” z. New data flows; error line included z. No external entities z. New data stores; Diagram 0 data stores are optional

Child Diagram - Low Level z. Numbering follows Parent Process - “ 3. 1” z. Primitive Process ÕIf Parent Process is not exploded and is functionally primitive ÕIf Child Diagram Process cannot be further broken down ÕLogic is written as Process Specifications

Level 1 Diagram Showing Decomposition of Process 1. 0 from the Level 0 Diagram 1: Receive and Transform Customer Order

Level 1 Diagram Showing the Decomposition of Process 4. 0 from the Level 0 Diagram 4: Produce Management Reports

Level 2 Diagram Showing the Decomposition of Process 4. 3 from the Level 1 Diagram for Process 4. 0 Diagram 4. 3: Prepare Management Reports

About DFDs z. Data flows should “balance” between levels z. Number label format X. X. X provides level information z. Context Diagram ÕLevel 0 (or system-level) DFD z. Notational Variations

Checking for Errors z. Forgetting to include a data flow or pointing the arrow in the wrong direction Õshows all inputs and no outputs or vice versa ÕConnecting data stores and entities directly should only connect to a process z. Incorrect label for process and data flow z. Not too many processes in a diagram Õcluttered diagram and hinders communication

Checking for Errors z. Omitting data flow; linear flows with single input and single output are rare and may indicate missing data z. Creating unbalanced decomposition in child diagrams; interface data flows should be same as parent z. Exception - error lines only in child diagram

DFD Summary z. DFDs are structured analysis tools for better understanding of the logical movement of data and its transformation presented in visual form z. DFDs are used to document systems independent of its analyst

Summary z. Modeling techniques and notation Õneeded in analysis and design Õmodels data and processes of a system z. Other techniques and notation Õstate diagrams, structure charts, flowcharts, document flow diagrams, more. . . z. Structured vs OO Paradigm Õsome techniques specific to the paradigm