1 / 48

Structured Design and Modeling

Structured Design and Modeling. CS 123/CS 231. Design Models Revisited. UML: Modeling Language for OO Systems For the Procedural (Structured) Paradigm Data and processes are separately considered Data Model: Entity-Relationship Diagram Process Model: Data-Flow Diagram

adamdaniel
Download Presentation

Structured Design and Modeling

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript


  1. Structured Designand Modeling CS 123/CS 231

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

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

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

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

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

  7. Sample Notation

  8. Example

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

  10. address name year id number qca Student

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

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

  13. M M Student borrows Book

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

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

  16. From ERD to Tables • Create a table for each entity • attributes associated to entity are columns of the table (a primary key should exist per table) • 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

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

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

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

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

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

  22. Processes • An operation or function in a system • example: Borrow Book • 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

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

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

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

  26. Comparison of DeMarco & Yourdon and Gane & Sarson DFD Symbol Sets

  27. Illegal Data Flows

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

  29. 1.1 Check Student Status id num borrower status Student 1.2 Check Book Copy Status copy num copy status Copy

  30. borrower status, copy status 1.3 Record Borrow borrow confirmation id num, copy num Borrow Copy

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

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

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

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

  35. Context Diagram of Hoosier Burger’s Food Ordering System

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

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

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

  39. Child Diagram - Low Level • Numbering follows Parent Process - “3.1” • 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

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

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

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

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

  44. Checking for Errors • 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 • Incorrect label for process and data flow • Not too many processes in a diagram • cluttered diagram and hinders communication

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

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

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

More Related