1 / 54

ITEC 3010 Analysis - Data Flow Diagrams

Data Flow Diagrams (DFDs) are graphical models that depict the main requirements for an information system, including inputs, outputs, processes, and data storage. With minimal training, everyone involved in the project can easily understand and visualize the project's aspects. This chapter explores traditional approaches to requirements and the use of DFDs in system analysis.

jmilan
Download Presentation

ITEC 3010 Analysis - Data Flow Diagrams

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

  3. Example of a Data Flow Diagram – fig. 6-4 • 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 transformed 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. 6-4 corresponds to event “Customer wants to check item available” (see last lecture)

  4. 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)

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

  6. 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)

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

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

  9. 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)

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

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

  12. Summary - Relationship of all these diagrams • Figure 6-6 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 in Figure 6-11 • Figure 6-14 shows the decomposition of the Order Entry Subsystem. This is the Diagram Level 0 of the Order-Entry Subsystem.

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

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

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

  16. 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)

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

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

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

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

  21. 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)

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

  23. 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- e.g. 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)

  24. 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.)

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

  26. 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)

More Related