Presentation is loading. Please wait.

Presentation is loading. Please wait.

1 ECE 355: Software Engineering Traditional Analysis and Modeling Approaches Lectures notes by Instructor: Krzysztof Czarnecki.

Similar presentations


Presentation on theme: "1 ECE 355: Software Engineering Traditional Analysis and Modeling Approaches Lectures notes by Instructor: Krzysztof Czarnecki."— Presentation transcript:

1 1 ECE 355: Software Engineering Traditional Analysis and Modeling Approaches Lectures notes by Instructor: Krzysztof Czarnecki

2 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 3 Outline for today Introduction  Data Flow Diagrams Entity Relationship Diagrams Further Reading

4 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 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 6 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 Validate Customer Order

7 7 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 verified_order customer_address zip_code phone_# street_address

8 8 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 Orders

9 9 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 Customer

10 10 Components of a DFD Put Together Orders order part_numbernew_order Customer Validate Order Stock

11 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.,

12 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 13 An alternative notation... Customer CustomersD1 ID Sales Clerk Validate Customer Order 2 Location validate_order Process (rectangle instead a circle!) Data flow Data store External agent (an oval instead of a rectangle)

14 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 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 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 17 Example of a context diagram

18 18 Context diagram for a telephone system

19 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 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 21 Refinement of “Telephone System” processing element in the context diagram

22 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 23 Refinement of “PBX” processing element

24 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 25 DFD fragment corresponding to the “off hook”

26 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 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 28 Example of a decision table

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

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

31 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 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 33 Example Student FName LName Address Course C# CName CDescription takes Entity (or more precisely: entity set or type) Entity attribute Relationship

34 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 35 Meaning of ER diagrams wifehusband Entities represent object types Associations between individual objects 11

36 36 One-To-Many Relationship motherchildren 1n

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

38 38 Partial participation 1

39 39 Kinds of Relationships Mathematically, a relationship on the entities E 1,..,E n is a mathematical relation on E 1,..,E n, i.e., a subset of the Cartesian product E 1 x E 2 x…E n. 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 E 1 and E n is one the same set

40 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 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 42 Notation used here ,6 Exactly one Many (zero or more) Optional (zero or one) One or more Numerically specified Relationship (unrary and binary only) Entity

43 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 Additional diagram type in Structured Design: –Structure chart (module structure)

44 44 Further Reading Book by Ed Yourdon “Just Enough Structured Analysis” –Online version at Series of articles on ER modeling (discusses available tools): –“Entity Relationship Modeling from an ORM perspective” by Terry Halpin –see


Download ppt "1 ECE 355: Software Engineering Traditional Analysis and Modeling Approaches Lectures notes by Instructor: Krzysztof Czarnecki."

Similar presentations


Ads by Google