SE205 Software Engineering Data Flow Diagrams SE205 Software Engineering

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

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

1-Apr-17

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

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

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

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! http://www.agilemodeling.com/essays/barelyGoodEnough.html 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

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 www.agilemodeling.com/practices.htm www.agilemodeling.com/principles.htm The supplementary principles and practices are good ideas which you should also consider adopting 1-Apr-17

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 http://www.agilemodeling.com/practices.htm#ModelWithOthers 1-Apr-17

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 http://www.agilemodeling.com/essays/phasesExamined.htm 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

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 www.agilemodeling.com/essays/agileDocumentation.htm 1-Apr-17

Data Flow Diagrams

1-Apr-17

Business Process mapping - XSOL 1-Apr-17

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

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

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

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

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

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

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

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

Data Flow Diagram Symbols 1-Apr-17

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

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

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

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

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

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

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

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

1-Apr-17

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

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

1-Apr-17

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

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

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

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

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

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

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

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

Creating Data Flow Diagrams

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

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

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

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

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

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

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

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

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

1-Apr-17

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

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

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

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

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

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

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

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

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

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

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