1. SE205 Software Engineering
Data Flow Diagrams
SE205 Software Engineering

2. Iteration 2: Functional delivery in context
1-Apr-17

3. Functional delivery
Deliver to the client a system that meets most of their needs
Usable
Stable
1-Apr-17

4. 1-Apr-17

5. Requirements determination
Determine how the current information system operates and what users would like to see in the new system.
Outcomes: Various forms of information gathered
1-Apr-17

6. Structured Modeling
We can model the functions of a business using a range of structured diagrams and techniques:
Functional decomposition
Data flow
Entity Relationship
Logic structure
Structure charts
1-Apr-17

7. Agile Modeling (AM)
AM is a chaordic, practices-based process for modeling and documentation
AM is a collection of practices based on several values and proven software engineering principles
AM is a light-weight approach for enhancing modeling and documentation efforts for other software processes such as XP and RUP
AM is a partial method which is meant to be tailored into other processes such as RUP, FDD, and XP
The AM site has a wealth of material
1-Apr-17

8. What Are Agile Models? Agile models:
Fulfill their purpose
Are understandable
Are sufficiently accurate
Are sufficiently consistent
Are sufficiently detailed
Provide positive value
Are as simple as possible
Agile models are just barely enough!
Agile models are the most effective possible because you invest just enough effort to get the job done.
If the model isn’t good enough yet then you can invest more effort into it and still get value.
If the model is good enough, for your current needs, or more than good enough, then any more work done on it would be a waste.
Good enough is in the eye of the beholder, so this can be tough. Active Stakeholder Participation and Model With Others to know what the audience for the model actually needs, don’t guess.
1-Apr-17

9. The Core of AM You Need to Adopt at Least the Core
Core Principles
Assume Simplicity
Embrace Change
Enabling the Next Effort is Your Secondary Goal
Incremental Change
Model With a Purpose
Multiple Models
Maximize Stakeholder Investment
Quality Work
Rapid Feedback
Software Is Your Primary Goal
Travel Light
Core Practices
Active Stakeholder Participation
Apply the Right Artifact(s)
Collective Ownership
Create Several Models in Parallel
Create Simple Content
Depict Models Simply
Display Models Publicly
Iterate to Another Artifact
Model in Small Increments
Model With Others
Prove it With Code
Single Source Information
Use the Simplest Tools
The supplementary principles and practices are good ideas which you should also consider adopting
1-Apr-17

10. Model With Others The modeling equivalent of pair programming
You are fundamentally at risk whenever someone works on something by themselves
Several heads are better than one
Software development is a lot like swimming, very dangerous to do it alone
1-Apr-17

11. Agile Models www.agilemodeling.com/artifacts/
Software development is complex
Each type of model is good at one type of view, but you need many views
No starting point, no ending point
You need to know a range of techniques to be effective, but you don’t need to know all of them
In each category there are often several similar techniques, use the one that works for you
1-Apr-17

12. Agile Documentation Agile documents: Valid reasons to document:
Maximize stakeholder investment
Are concise
Fulfill a purpose
Describe information that is less likely to change
Describe “good things to know”
Have a specific customer and facilitate the work efforts of that customer
Are sufficiently accurate, consistent, and detailed
Are sufficiently indexed
Valid reasons to document:
Your project stakeholders require it
To define a contract model
To support communication with an external group
To think something through
1-Apr-17

13. Data Flow Diagrams

14. 1-Apr-17

15. Business Process mapping - XSOL
1-Apr-17

16. Process Modeling Data flow diagramming Graphical depiction of a system
Show how data flows through your system and what is being done to it along the way
1-Apr-17

17. Figure 2-2 A General Depiction of a System
1-Apr-17

18. Figure 2-4 A Fast Food Restaurant as a System
1-Apr-17

19. Figure 2-7 A Fast Food Restaurant’s Customer Order Information System Depicted in a Data Flow Diagram
1-Apr-17

20. Process Modeling Graphically Represents Which Functions or Processes
Capture
Manipulate
Store
Distribute data between a system, its environment and its components
1-Apr-17

21. Deliverables Set of data flow diagrams showing: Scope of system
Existing system modeled
New system modeled
1-Apr-17

22. Key Definitions
Logical process models describe processes without suggesting how they are conducted
Physical models include information about how the processes are implemented
1-Apr-17

23. Deliverables - ideal Context data flow diagram [DFD]
Shows system scope
DFD/s of current physical system
Specifies people and technologies used
DFD/s of current logical system
Show data processing functions
DFD/s of new logical system
Description of each DFD component
Data repository
1-Apr-17

24. Data Flow Diagram Symbols
1-Apr-17

25. Process
The work or actions performed on data so that they are transformed, stored or distributed
Verb phrase name, eg,
Update
Calculate
Verify
1-Apr-17

26. Data store
Data at rest, which may take the form of many different physical representations Eg,
Database
Files
Folder
1-Apr-17

27. Source/sink
The origin and/or destination of data, sometimes referred to as external entities
Eg,
Clients
Employees
Bank
Inland Revenue
1-Apr-17

28. Data flow
Data in motion, moving from one place in the system to another
Eg,
Invoice
Receipt
Enrolment form
Must be named, often has a paper form associated with it.
1-Apr-17

29. Concepts Data movement Coupling Timing of data flow
DFD hides some Physical Characteristics
Frequency
Volume of Data
1-Apr-17

30. Steps in Building DFDs Build the context diagram Create DFD fragments
Organize DFD fragments into level 0
Decompose level 0 DFDs as needed
Validate DFDs with user
1-Apr-17

31. Context Diagram Shows the context into which the business process fits
Shows the overall business process as just one process
Shows all the outside entities that receive information from or contribute information to the system
1-Apr-17

32. Figure 8-4 Context Diagram of Hoosier Burger’s Food Ordering System
One process only
Single process (0) represents entire system
1-Apr-17

33. 1-Apr-17

34. Level 0 Diagram
Shows all the processes that comprise the overall system
Shows how information moves from and to each process
Adds data stores
1-Apr-17

35. Figure 8-5 Level-0 DFD of Hoosier Burger’s Food Ordering System
1-Apr-17

36. 1-Apr-17

37. Decomposition of DFDs Functional Decomposition Level-n diagram
iterative process of breaking down the description of a system into finer and finer detail
keep going until point where process can no longer be logically broken down
creates a series of exploding charts
Level-n diagram
1-Apr-17

38. Level 1 Diagrams
Shows all the processes that comprise a single process on the level 0 diagram
Shows how information moves from and to each of these processes
Shows in more detail the content of higher level process
Level 1 diagrams may not be needed for all level 0 processes
1-Apr-17

39. Figure 8-7 Level-1 Diagram Showing Decomposition of Process 1
Figure 8-7 Level-1 Diagram Showing Decomposition of Process 1.0 from the Level-0 Diagram
1-Apr-17

40. Figure 8-5 Level-0 DFD of Hoosier Burger’s Food Ordering System
1-Apr-17

41. Level 2 Diagrams
Shows all processes that comprise a single process on the level 1 diagram
Shows how information moves from and to each of these processes
Level 2 diagrams may not be needed for all level 1 processes
Correctly numbering each process helps the user understand where the process fits into the overall system
1-Apr-17

42. Figure 8-8 Level-1 Diagram Showing the Decomposition of Process 4
Figure 8-8 Level-1 Diagram Showing the Decomposition of Process 4.0 from the Level-0 Diagram
1-Apr-17

43. Figure 8-9 Level-2 Diagram Showing the Decomposition of Process 4
Figure 8-9 Level-2 Diagram Showing the Decomposition of Process 4.3 from the Level-1 Diagram for Process 4.0
1-Apr-17

44. Your Turn Sketch a context diagram for your project
At this point in the process it is easy to lose track of the “big picture”.
Sketch a context diagram for your project
How many processes?
What are the external sources and sinks?
1-Apr-17

45. Creating Data Flow Diagrams

46. Data flow diagram components
Data Store
Process
Source/Sink
Data flow
1-Apr-17

47. Process
The work or actions performed on data so that they are transformed, stored or distributed
Verb phrase name, eg,
Update
Calculate
Verify
1-Apr-17

48. Data store
Data at rest, which may take the form of many different physical representations Eg,
Database
Files
Folder
1-Apr-17

49. Source/sink
The origin and/or destination of data, sometimes referred to as external entities
Eg,
Clients
Employees
Bank
Inland Revenue
1-Apr-17

50. Data flow
Data in motion, moving from one place in the system to another
Eg,
Invoice
Receipt
Enrolment form
Must be named, often has a paper form associated with it.
1-Apr-17

51. Concepts Data movement Coupling Timing of data flow
DFD hides some Physical Characteristics
Frequency
Volume of Data
1-Apr-17

52. Steps in Building DFDs Build the context diagram Create DFD fragments
Organize DFD fragments into level 0
Decompose level 0 DFDs as needed
Validate DFDs with user
1-Apr-17

53. Context Diagram Overview of the system showing: System Boundaries
External Entities that interact with the system
Major information flows between Entities and System
1-Apr-17

54. Figure 2-2 A General Depiction of a System
1-Apr-17

55. 1-Apr-17

56. Next step
What processes are represented by the single process in the context diagram?
Capturing data from different sources
Maintaining data stores
Producing and distributing data to different sinks
High level descriptions of data transformation operations
1-Apr-17

57. DFD Layout Tips All process names must be verb phrases
Maintain organisation’s viewpoint in naming processes
Layouts often place
processes in the center
inputs from the left
outputs to the right
stores beneath the processes
1-Apr-17

58. Level - 0 diagram
A dataflow diagram that represents all of the system’s major processes, data flows, and data stores at a high level of detail.
Often corresponds to selection of activities on main system menu.
1-Apr-17

59. Level 0 Tips
Generally move from top to bottom, left to right
Minimize crossed lines
Iterate as needed
The DFD is often drawn many times before it is finished, even with very experienced systems analysts
1-Apr-17

60. Figure 8-5 Level-0 DFD of Hoosier Burger’s Food Ordering System
1-Apr-17

61. Tips for Level 1 and Below
Sources for inputs and outputs listed at higher level
List source and destination of data flows to processes and stores within each DFD
Depth of DFD depends on overall system complexity
Two processes generally don’t need lower level
More than seven processes become overly complex and difficult to read
1-Apr-17

62. Data Flow Splits and Joins
A data flow split shows where a flow is broken into its component parts for use in separate processes
Data flow splits need not be mutually exclusive nor use all the data from the parent flow
As we move to lower levels we become more precise about the data flows
A data flow join shows where components are merged to describe a more comprehensive flow
1-Apr-17

63. Balancing DFD’s
Balancing involves ensuring that information presented at one level of a DFD is accurately represented in the next level DFD.
1-Apr-17

64. Validating the DFD Syntax errors Assure correct DFD structure
Semantics errors
Assure accuracy of DFD relative to actual/desired business processes
User walkthroughs
Role-play processes
Examine lowest level DFDs
Examine names carefully
1-Apr-17

65. Guidelines for drawing
Use a CASE tool: BPWin, Visible Analyst
Completeness
no data flows leading to nowhere
Consistency
is nesting appropriate?
Timing, never started, never stops
Iterative development
1-Apr-17

66. Summary Requirements Structuring Deliverables Process modelling
Data flow diagrams
Deliverables
Three sets of DFDs
current physical, current logical, new logical
1-Apr-17