ITEC 3010 Analysis - Data Flow Diagrams

1. ITEC 3010Analysis - Data Flow Diagrams

2. Chapter 6 (Traditional Approach to Requirements) -- Data Flow Diagrams (DFD) • Data Flow Diagram (DFD) • A graphical system model that shows all of the main requirements for an information system: inputs, outputs, processes and data storage • Everyone working on the project (and end users) can see all the aspects of the project in the diagram with minimal training (simple – only 5 symbols)

4. Example of a Data Flow Diagram – fig. 6-3 • The square is an external agent • A person or organization, outside the boundary of a system that provides data inputs or accepts data outputs • The rectangle with rounded edges is a process • A symbol that represents an algorithm or procedure by which data inputs are tranformed into data outputs • The lines are data flows • Represents movement of data • The flat three-sided rectangle are data stores (a file or part of a database) • A place where data is held • Fig. 3-6 corresponds to event “Customer wants to check item available” (see last lecture)

6. Data Flow Diagrams and Levels of Abstraction • Levels of abstraction • Particular to any modeling technique that breaks the system into a hierarchical set of increasingly more detailed models • Example above – a DFD fragment – showing one process in response to one event • Other diagrams show the processing at a higher level (more general) or lower level (a more detailed view of one process) • Higher level processes in a DFD can be decomposed into separate lower level DFD (or some other diagram)

7. Context Diagrams • Context Diagram: A DFD that summarizes all processing activity within the system in single process symbol • Describes highest level view of a system • All external agents and all data flows into and out of a system are shown in the diagram • The whole system is represented as one process • Example – fig. 6-5 shows a context diagram for a university course registration system that interacts with 3 agents: academic dept., student, and faculty member

9. Notes on Context Diagram • Useful for showing system boundaries • External agents are outside the software scope (which is represented by the single process). But not from System Analysis • Data stores are not shown in the context diagram since they are considered to be in the software scope (i.e. the single process) • It is the highest level DFD • Context diagram does not show any details of what takes place within the system (i.e. that single process)

11. DFD Fragments • DFD fragment: A DFD that represents the system response to one event within a single process symbol • A fragment is created for each event in the event list – it is a self-contained model showing how the system responds to a single event • Created one at a time • Fig. 6-7 shows 3 DFD fragments for a course registration system • Each fragment represents all processing for an event within a single process symbols • The data stores in the DFD fragment represent entities in the ERD (Entity Relationship Diagram – see last lecture) – Not Necessarily !

15. The Event-Partitioned System Model • Event-partitioned system model: a DFD that models requirements using a single process for each event • The entire set of DFD fragments can be combined into this single DFD called the event-partitioned system model or diagram 0 • Diagram 0 shows the entire system on a single DFD • Figure 6-10 (next slide) shows a set of four related DFDs • The top diagram shows the Context diagram for course registration (same as fig. 6-5 above) • The diagram below that (Diagram 0) is the decomposition of the one process in the context diagram AND consists of the a combined version of the 3 DFD fragments in fig. 6-7 above (in fig. 6-10, DFD fragment 1 is shown below diagram 0) • Finally, Diagram 1 is a decomposition of the process in DFD fragment 1

17. Dividing the system into subsystems • The RMO customer support system involves 20 events, therefore the event-partitioned system model (diagram 0) would contain 20 processes • This can get to be a crowded diagram! • Solution is to divide the system into subsystems • Events are grouped into related subsystems based on similar: • Interactions with external agents • Interactions with data stores • Required processing • In the RMO example, we can break up the support system into 4 subsystems (see next slide)

19. Next Step: After the subsystems are defined: • A DFD is created to represent the division of the system into subsystems – the subsystem DFD • This subsystem DFD shows how the four RMO subsystems are connected (i.e. how they are related to all the outside sources and destinations of data) • Note that there is a process in the diagram for each of the four subsystems that were defined for RMO • See figure 6-13 for an example based on the 4 subsystems in the RMO example • Note - even with only 4 subsystems (rather than one process for each of the 20 events) the diagram gets cluttered

21. Next Step: can decompose a subsystem DFD into event-partitioned models - one for each subsystem: • In the RMO example can expand the subsystem in fig. 6-13 called “Order entry subsystem” into an event-partitioned model • this model has 5 processes within it – see next slide • The analyst would also create an event-partitioned model for the other 3 subsystems in the RMO example

23. Summary - Relationship of all these diagrams • Figure 6-12 shows the relationship among DFD abstraction levels when subsystems are defined • The figure starts off with the context diagram, which breaks down to the subsystem diagram (one for each subsystem) • The subsystem diagram is turn broken down into the event-partitioned subsystem diagrams • ETC.

24. Layers of DFD Abstraction

25. Decomposing Processes to see Details of One Activity • Using this same principle of breaking down the model to more detailed level, we can take a DFD fragment (e.g. create new order fragment from the RMO example) and decompose it into sub-processes • In figure 6-15 this is shown • Since fragment “create new order” was the second DFD fragment defined for the RMO example (see fig. 6-8) we will label processes inside of it as processes 2.1, 2.2, 2.3 etc. • The diagram decomposes “create new order” into 4 sub-processes (see fig. 6-15) – labeled sub-processes 2.1-2.4

27. Evaluating DFD Quality • A quality set of DFDs is • Readable • Internally consistent • Accurately represents system requirements • Minimizing complexity • Want to avoid information overload • Occurs when too much information is presented to a user at one time • Two ways to avoid information overload use 7 + or – 2 rule (which limits the number of components) and interface minimization (which minimizes the number of interfaces and connections between components) • A single DFD should have no more than 7 + or – 2 processes • No more than 7 + or – 2 data flows into or out of a process

28. Data Flow Consistency • Want consistency in DFDs • Common errors: • Differences in data flow for a process and its decomposition (want to have balancing: equivalence of data content between data flows entering and leaving a process or its decomposition) • Black hole • A process with data input that is never used to produce a data output • Miracle • A process with a data output that is created out of nothing (I.e. “miraculously appears”) • Black hole and miracle problems apply to both processes and data stores • Most CASE tools perform data flow consistency checking

31. Documenting Data Flow Diagram (DFD) Components • Process Descriptions • Each process on a DFD needs to be defined • Can keep breaking down DFD to more detailed DFD but at some point have to describe the process in structured English • Uses instructions, repetition and if-then-else logic • Note that this is not necessarily a computer program (its an algorithm that describes the process)

33. Limitations of structured English • Good for representing processes such as those in previous slide • Not so good for showing complex decision logic – as shown in next slide • Not so good if there are few or no sequential steps • Decision Table • A tabular representation of processing logic containing decision variables, decision variable values and actions (or formulas) • Decision Tree • A graphical description of process logic that uses lines organized like branches of a tree

35. Making a Decision Table (from the logic on previous slide) • Step 1 • Identify the decision variables • Year to date purchases (YTD) • Number of items ordered • Delivery date • Step 2 • Put variable with fewest possible value ranges in the first row of the table • In this example could put either YTD or number of items

36. Table so far is just one row: YTD Purchases > $250 YES NO • Step 3 – put variable with next fewest possible value ranges as next row in the table, to now get: YTD Purchases > $250 YES NO Number of Items (N) N <=3 N>=4 N<=3 N>=4 • Step 4 – keep inserting rows as in step 3 until all decision variables are included in the table

37. Table now looks like: YTD Purchases > $250 YES NO Number of Items (N) N <=3 N>=4 N<=3 N>=4 Delivery Day Next 2nd 7th Next 2nd 7th Next 2nd 7th Next 2nd 7th • Step 5 – Finally put as bottom row of the table the actions for each of the possible conditions – see next slide (fig. 6-22) from the text for the complete table

39. Decision Tree • A graphical description of process logic that uses lines organized like branches of a tree • Decision table is more compact but decision tree is easier to read • Decision tree can be developed in essentially same way as a decision table (only difference is that it runs horizontally – i.e. Rows in a decision table are columns in the tree – just flip the table sideways and you get the tree)

41. there may be several actions associated with a set of conditions in a Decision Table • Figure 6-24 shows a table where if the customer is new and if an item is on backorder for >= 25 days then two things are done: • (a) include detailed return instructions • (b) expedite delivery • See next slide for this example

43. Data Flow Definitions • Data flow – a collection of data elements • Data flow definition – a textual description of a data flow’s content and internal structure • Lists all the elements- eg. a “New Order”data flow consists of • Customer –Name • Customer-Address • Credit-Card-Information • Item-Number • Quantity • Most of these are stored and correspond to the attributes of data entities • In addition to just listing elements can use algebraic notation • Data flow “equals” one element followed by another (repeating groups can be shown in curly brackets)

48. Data Element Definitions • Describe a data type • E.g. String, integer, floating point, or Boolean • Lengths are usually defined for strings • Numeric values usually have a minimum and maximum value (a valid range) • Might define special codes (e.g. code A means ship immediately etc.)

49. +int 9(4) +9(6).99 String[50]

50. Data Store Definitions • Usually, a data store on the DFD represents a data entity on the ERD • Should look at the ERD for details on this • If no ERD can define the data store as a collection of elements (like did for data flows)