CSE1204 - Information Systems 1
Process Modelling Data Flow Diagrams
Process Modelling Process modelling aims to graphically represent the processes which capture, manipulate, store and distribute data. • • • •
data flow diagrams function decomposition structured English decis ecisio ion n tab tables les and decisio ision n trees
Data flow Diagrams Data flow diagrams model the flow of data into, through, and out of an information system: • show the the process processes es that that change change or transform transform data • show the movem movement ent of of data between between processes • represen representt a system system as as a network network of processes which transform data flowing between them
1
Example DFD DFDs fit neatly onto a single page • the user is not overwhelmed by a DFD invalid orders
WAREHOUSE
ORDERS
CUSTOMERS shipping details order details 1. RECEIVE ORDER
orders
books 2. SHIP BOOKS
customer name, customer address
CUSTOMERS
billing informatio n
customer name, customer address
books
INVOICES
customer name, invoice details
3. COLLECT PAYMENTS
invoices, statements
CUSTOMERS payments, enquiries
Data Flow Diagrams
Data flow diagrams (or DFDs): • a well-known process modelling technique • easily understood • a good communication tool • model both manual and automated processes
Components of a DFD 2
1.
Process
2.
Data flow
3.
Data store
4.
External agent
calculate price
loan application
Products
Suppliers
(Source/Sink)
2
1. Process
• transforms incoming data flows into outgoing flows:
data
the work performed on data which changes it • each process has a unique number and name
2 calculate price
1. Process • name each process using a verb and a noun phrase eg.
calculate price check customer details accept supplier delivery
• the name of a process should describe what the process does • avoid vague names where possible e.g.
"process data"
2. Data Flow • a data flow represents data in motion, moving from one place in the system to another • describes a "packet" of data or data that moves together: a data flow may consist of many individual, related pieces of data that move together to a common destination loan application
3
•
name each data flow using a noun or noun phrase eg.
customer order
•
the name of a data flow should describe the contents of the data "packet"
•
the name should include as much information as possible about the data flow eg."customer payment" rather than just "payment"
customer order
2
valid customer order
validate customer order
invalid customer order
3. Data Store
• a data store represents a collection of data flows "at rest" • each data store has a unique name • the name should describe the contents of the data store • a data store may represent many different types of physical locations of data • a data store may be a temporary or a permanent repository of data
The Data Store
different notations
4
data flows to and from a data store can remain unlabelled if all attributes in the store are moving, i.e. if an entire data packet (or packets) is going into or out of the data store 2 sales order
check sales order
Sales orders 3 produce weekly sales totals
weekly sales totals
4. External Agent (Source/Sink) • an external agent represents an entity with which the system communicates and which is outside the scope of the system eg.
an outside organisation or individual, another department or another system, a person or group within the department supported by the system who interacts with the system
• an external agent is a source if it is an origin of data coming into the system • an external agent is a sink if it is a destination of data leaving the system
Suppliers
4. External Agent (Source/Sink)
• data flows connecting the external agents to the processes within the system represent the interface between the system and its environment • external agents are outside the system and define its boundaries • an external agent may be both a source and a sink what a sink does with data it receives from the system and how a source produces data which it inputs to the system are outside the boundary of the system and are not shown on the data flow diagram
5
Example DFD sales order
Sales Order System
purchase order Suppliers
goods returned
goods unavailable notice
Inventory System
shipping slip
supplier delivery
checked supplier invoice
Warehouse
Accounts Department
Example Data Flow Diagram Customers
sales order 1 check sales order
Suppliers Sales orders 2 produce purchase order
purchase order
Guidelines for Drawing DFDs • each object on a data flow diagram must have a unique name • each process must have at least one data flow coming in (input) and at least one data flow going out (output) • the inputs to a process are different from the outputs of that process • a process must be able to build its outputs using only the information in its input data flows plus any constant information
6
Guidelines for Drawing DFDs data flows are permitted: • between processes • from a data store to a process • from a process to a data store • from a source to a process • from a process to a sink
Guidelines for Drawing DFDs data flows are NOT permitted: •
between external agents
•
between data stores
•
from an external agent to a data store
Identify six errors in this abstract DFD Data Store 2 EE1 Data store 1
1 process2
EE2 2
EE3
Process1
7
Levelling Data Flow Diagrams Any "real" system is too large to represent as a single data flow diagram • the solution is to decompose the system into a hierarchy of levels of processing • the process model of the system then consists of a set of levelled data flow diagrams • levelling of DFDs improves their readability and usefulness as a communication tool
Levelling of DFDs Levelling creates a hierarchical decomposition of the processing within the system Context diagram • Level 0 diagram Level 1 diagrams Level 2 diagrams . . . Level n diagrams
Levelling of DFDs
Context diagram
Level 0 diagram
Level 1 diagrams Level 2 1.1.1 diagrams
1.1
1.1.2
1
1.2
2
1.3
2.1
3
2.2
3.1
4
3.2
3.2.1
4.1
4.2
4.3
3.2.2
8
Context Diagram • the highest level data flow diagram is the context diagram • the context diagram shows the interaction of the system with its environment in terms of data flows • the context diagram defines the boundary of the system (the scope of the system) • only the data flows which leave the system and the data flows which come from outside the system are shown
Context Diagram • the entire system is represented as a single process • all external agents (sources and sinks) are shown • no data stores are shown: they are inside the boundary of the system
EASY GO HOTEL
Example Context Diagram sales order
Sales Order System
purchase order Suppliers
goods returned
goods unavailable notice
shipping slip
Warehouse
Inventory System
supplier delivery
checked supplier invoice
Accounts Department
9
Level Zero Diagram • the level zero data flow diagram is the diagram at the level immediately below the context diagram • it "expands" the single process on the context diagram to show the major, high-level processes (or functions) within the system
1.0
4.0
2.0 3.0
Level Zero Diagram • all external agents (sources and sinks) are included because the level zero diagram, like the context diagram, represents the entire system • the number of each process ends in .0 which corresponds to the level of the diagram: e.g.
1.0, 2.0, 3.0 etc.
often just 1, 2, 3 etc. are used
Example Level Zero Diagram Order Entry System
purchase order
Suppliers
sales order 2.0 Monitor Stock levels 3.0
1.0 out of stock notice
Fill Sales Orders
Accept Deliveries
supplier delivery
Stock file
shipping slip
Warehouse
checked supplier invoice
Accounts Department
10
Level 1 and lower level diagrams each Level 1 diagram and diagrams at lower levels (e.g. Level 2, Level 3) show only a part of the processing Level 1 processes are numbered 1.1, 1.2, 1.3, and 2.1, 2.2, 2.3 etc that part is shown in more detail than on the Level zero diagram no external agents are shown on a Level 1 or lower diagrams, as the entire system is not being represented
Level 1 diagrams a set of data flow diagrams is created at Level 1 there is one Level 1 diagram for each of the processes at Level zero each diagram decomposes a Level zero process into several processes
2.4 2.3 2.1
2.5 2.2
Levelling DFDs
1 2 Context diagram
3 Level zero diagram 2.1
3.1
2.2
3.2
Diagram 3 (level 1)
Further diagrams or process descriptions
Diagram 3 (level 1)
11
Example Level zero diagram SUPPLIERS CUSTOMERS
p.o. number
Customer details Product details product qty
p.o. invoice product holding
INVENTORY
product delivered qty
product order qty
1
product product holding order qty
Record and Invoice Sales
SALES ORDERS
customer invoice
2
delivery qty
Maintain Product Inventory
product order qty
Example Level 1 diagram INVENTORY
1.2
Customer details
Check Stock Available
1.1
Check Customer Credit
product holding
product qty
INVOICES product
Product details
customer credit status
SALES ORDERS 1.4
1.3
product qty
available qty
Record Sales Demand
Create Sales Invoice
customer invoice
Guidelines for Levelling DFDs • numbering: when a process is decomposed, its diagram is given the same number as that process • balancing of DFDs: all data flows entering and leaving a process must appear on the corresponding diagram which decomposes that process • external agents: are only included on the two diagrams which represent the entire system, i.e. the context and level zero diagrams
12
Guidelines for Levelling DFDs balancing data flows: if data flows are decomposed at lower levels then the contents of the data flows across levels must be balanced sales order
customer shipping details
1 out of stock notice
customer order items 1.1
Fill Sales Orders
1.2
Check shipping details
Check stock available
shipping slip
sales order
=
customer + shipping details
customer order items
Guidelines for Levelling DFDs The access to data stores across levels of diagrams must be consistent: •the direction of accesses must match and all accesses on higher level diagrams must appear on corresponding lower level diagrams •a data store is first shown on the highest level diagram where it is accessed by more than one process •it can then appear on all lower level diagrams where it is accessed
1 1.1
1.2 1.3
2
Guidelines for Levelling DFDs partition processes to: • form cohesive, related groups of activities • minimise the data flows between them
all parts of the system need not be decomposed to the same level
13
Guidelines for Levelling DFDs How many levels should be in a set of DFDs? • each diagram usually has between 3 and 7 processes • level the diagrams until bottom level or primitive processes are reached primitive processes cannot be further decomposed as a data flow diagram
An example - Context Diagram Line
Applicant
Manager Address Position Spec
Applicant name Position
Acknowledgement
Employment System
Decision
Successful Applicant
Payroll System
Position
An example - Level zero diagram Applicant Position
Applicant name
Address 1 Acknowledgement
Line Manager
Ackn’d Appn
Accept Application
Position Spec Decision
2 Evaluate Applicants
Applicant Position Unsuccessfuls file Evaluation results
Successful Applicant
Payroll System
14
Level 1- Diagram 1
Address
Applicant name
Position 1.1
Acknowledgement
Verified Application 1.2
Verify for Completeness
Acknowledge Application
Acknowledged Application
L e v e l 1 - Di a g r a m 2 Ackn’d Appn
Position Spec
Qualified applicant
2.1 Screen Applicants
unqualified applicant
Decision
2.2
2.3
Reject Unsuitabl es
Schedule Evaluation
Decision Successful Applicant Unsuccessfuls file
Evaluation results
References WHITTEN, J.L., BENTLEY, L.D. and DITTMAN, K.C. (2001) 5th ed.,Systems Analysis and Design Methods, Irwin/McGraw-HilI, New York, NY. Chapters 8 HOFFER, J.A., GEORGE, J.F. and VALACICH (2005) 4th ed., Modern Systems Analysis and Design, Benjamin/Cummings, Massachusetts. Chapter 7
15
