1 / 44

ECE 355: Software Engineering

ECE 355: Software Engineering. Traditional Analysis and Modeling Approaches Lectures notes by Instructor: Krzysztof Czarnecki. Three main views of the traditional approach (Structured Analysis). Process/functional view: Data flow diagrams Data structures: Entity-relationship diagrams

Download Presentation

ECE 355: Software Engineering

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. ECE 355: Software Engineering Traditional Analysis and Modeling Approaches Lectures notes by Instructor: Krzysztof Czarnecki

  2. Three main views of the traditional approach(Structured Analysis) • Process/functional view:Data flow diagrams • Data structures:Entity-relationship diagrams • Time-dependent behavior:State-transition diagrams

  3. Outline for today • Introduction • Data Flow Diagrams • Entity Relationship Diagrams • Further Reading

  4. Data Flow Diagrams (DFDs) • A DFD is a graphical representation of • the processes of a system, • the data being transformed and stored • A DFD gives a very good overview of what is happening in the system • A DFD represents • the process view of a system (processes are actions or sets of actions) • the functional view (processes as functions) • (workflow model)

  5. Components of a DFD • DFD is very easy to read since it is a graphical model and • there are only four symbols to learn: • Processes • Data Flows • Data Stores • External Agents

  6. Validate Customer Order <process title> Process • Processes transform a data flow by changing its structure or by generating new information from it • A process must have at least one data flow into it and one data flow out of it • A process cannot exist independently

  7. <flow name> verified_order zip_code customer_address phone_# street_address Data Flows • A data flow is represented by an arrow and depicts the fact that some data is flowing from one process to another • Data moved is sometimes called a packet of data • The name of data flows should be different if the data is changed on entering the process

  8. <store name> Orders Data Stores • When a process needs other data other than what it receives from another process, to perform its function, this ‘other’ data can be retrieved from data stores • A data store is a collection of related information for example, a telephone book, student records held in a filing cabinet

  9. <external agent name> Customer Sources and sinks • External agents exist in the system’s environment and can: • provide data to the system (i.e. a source or input) or • receive data from the system (i.e. a sink or output) • External entities include people like customers, managers, and include places like departments and suppliers • The boundaries of a system determine what entities are external • External agents are also referred to as terminators

  10. Customer order Validate Order new_order part_number Orders Stock Components of a DFD Put Together

  11. Please note... • A DFD does not represent any control flow aspect in your system • Therefore, no sequencing information can be read from a DFD • However, this lack of control flow is not a drawback of DFD, because what we are modeling using DFDs are requirements and not how those are implemented • Note: In general, a DFD is not a dependency diagram (where a process produces output whenever all inputs are available) • Some extensions of DFD for real-time systems consider control flow (e.g., http://www.yourdon.com/books/msa2e/)

  12. Direct data flow vs. data store • The analyst may decide if intermediate data needs to be stored persistently • implied by the user’s needs • implicates development cost

  13. D1 Customers 2 Sales Clerk Validate Customer Order validate_order An alternative notation... ID Location Process (rectangle instead a circle!) Data flow Data store Customer External agent (an oval instead of a rectangle)

  14. A few comments about notation... • The modeling notation being used should be appropriate and efficient for the task at hand • Beyond that it’s a matter of taste • Circle, rectangle, a cloud... • Use a standard whenever a standard available • In any case, be consistent • Underlying concepts matter • Surface syntax can be learned quickly...

  15. DFD Leveling • DFDs allow the analyst to look at the system at different levels of detail • Even quite small systems can be made up of many processes • To include all processes in a single diagram can: • make it look cluttered, • make it difficult to see in detail what a process does • To overcome this, we can ‘break down’ a single diagram, into a number of diagrams • This process is known as leveling

  16. Context Diagrams (Overview or Level 0) • Represents the system at the highest level of detail. • Comprised of • A single process representing the entire system modeled • External entities • The data flows that pass between the external entities and the system • Purpose is • to identify and examine the interfaces between the external entities and the system

  17. Example of a context diagram

  18. Context diagram for a telephone system

  19. Guidelines for drawing a Context Diagram • List potential external entities (people, places). Look for entities that • give data to the system without explaining the process that creates that data • take data from the system without explaining what it does with that data • Establish what flows are sent to and from the system from the external entities • Draw the context diagram

  20. Level 1 Diagram • Show • the system in more detail • how data enters the system • how these data items are transformed by the processes • how they leave the system • A level 1 diagram must have the same number of inputs and outputs as its context diagram • The flows are connected to and from the actual processes which create, receive or change them • Processes represent a breakdown of the activities which make up the system

  21. Refinement of “Telephone System” processing element in the context diagram

  22. Guidelines for drawing a Level 1 Diagram • Take one sentence at a time and try to identify potential processes (look for verbs) • Group potential processes so you end up with (minimum) 3 to (maximum) 10 • Identify and list the data flows (generally documents but could also be physical items). A data flow is really anything that moves around the system • Identify and list the data stores • Draw the level one diagram

  23. Refinement of “PBX” processing element

  24. DFD Fragments • A DFD fragment is created for each event in the event list • A DFD fragment is a self-contained model showing how the system responds to a single event • As an analyst, you create DFD fragments one at a time

  25. DFD fragment corresponding to the “off hook”

  26. Bottom Level • Continue decomposing a DFD into lower levels until the processes get so simple that you can describe them using: • Process specifications in pseudocode • Decision tables

  27. Example of a process specification using pseudocode 1. IF the dollar amount of the invoice times the number of weeks overdue is greater than $10,000 THEN: a. Give a photocopy of the invoice to the appropriate salesperson who is to call the customer. b. Log on the back of the invoice that a copy has been given to the salesperson, with the date on which it was done. c. Refile the invoice in the file for examination two weeks from today. 2: OTHERWISE IF more than four overdue notices have been sent THEN: a. Give a photocopy of the invoice to the appropriate salesperson to call the customer. b. Log on the back of the invoice that a copy has been given to the salesperson, with the date on which it was done. c. Refile the invoice in the file to be examined one week from today. 3: OTHERWISE (the situation has not yet reached serious proportions): ...

  28. Example of a decision table

  29. Data in data flow diagrams • Data and data stores defined using Entity Relationship Diagrams and data dictionaries

  30. Outline for today • Introduction • Data Flow Diagrams • Entity Relationship Diagrams • Further Reading

  31. Entity Relationship Diagrams (ERD) • ER diagrams describe things and relationships between them • They were first proposed by Chen in 1976 • Unify different approaches to database design (hierarchical, network and relational) • Original reference: Peter Pin-Shan Chen. The entity-relationship model—toward a unified view of data . ACM Transaction on Database Systems. Vol. 1, No 1, 1976, pp 9-36 • Different ERD notations in use, but basically the same underlying concepts

  32. Components of ERDs • Entities: Things about which we want or need to maintain information • E.g., students, courses, suppliers, parts • Attributes: Properties of entities • E.g. student ID, Course #, course name • Relationships: • Associations between two or more entities • Students take courses • ERDs can represent real world (or even imaginary worlds) in a diagram

  33. Example Entity (or more precisely: entity set or type) Student Course FName C# takes CName LName Address CDescription Relationship Entity attribute

  34. Relationships • How two or more entities are related (if at all…) • Cardinality • 1:1 (wife-husband) • 1:N (mother-children) • N:M (grandparents-grandchildren) • Participation • Total participation • Every child has a mother • Partial participation • Not every person has a child

  35. Meaning of ER diagrams Entities represent object types 1 1 wife husband Associations between individual objects

  36. One-To-Many Relationship 1 n mother children

  37. Many-To-Many Relationship 4 m grand parents grand children

  38. Partial participation 1

  39. Kinds of Relationships • Mathematically, a relationship on the entities E1,..,En is a mathematical relation on E1,..,En, i.e., a subset of the Cartesian product E1 x E2 x…En. • n gives rise to the arity of a relationship • Binary relationship (n=2) • Ternary relationship (n=3) • N-ary relationships • Unary relationship (n=1; basically, a predicate) • Most likely represented as an Boolean attribute • A recursive binary relationship is one where E1 and En is one the same set

  40. Attributes • Atomic: e.g. SSN • Compound: e.g. address (contain other atomic attributes: street, zip, state. Can expand it to several attributes ) • Multi-valued: e.g. hobbies ( can have more than one hobby. Can expand to a relationship) • Derived: e.g. age (can be derived from date of birth. You can decide whether you want to store the derived attributes in the database or not) • Key: An attribute that uniquely identifies a thing

  41. ERD Notation • Different notations • No single standard notation • Some variations • Using diamond to denote relationships or not • Providing cardinality or not • Way of specifying cardinality

  42. Notation used here Entity Relationship (unrary and binary only) Exactly one Many (zero or more) Optional (zero or one) +1 One or more 1-3,6 Numerically specified

  43. Summary of Diagrams in the Traditional Approach • Three main views: • Data flow diagrams - process/functional view • Entity-relationship diagrams - view of data structures • State-transition diagrams - view of time-dependent behavior • Two additional detailed views: • Data dictionary - detailed structure of data • Process specification - detailed structure of processes • The above diagram types are used in Structured Analysis • see http://www.yourdon.com/books/msa2e/ • Additional diagram type in Structured Design: • Structure chart (module structure)

  44. Further Reading • Book by Ed Yourdon “Just Enough Structured Analysis” • Online version at http://www.yourdon.com/books/msa2e/ • Series of articles on ER modeling (discusses available tools): • “Entity Relationship Modeling from an ORM perspective” by Terry Halpin • see http://www.inconcept.com/JCM/

More Related