ECE 355: Software Engineering

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/