During the analysis stage we begin with logical models of the process, which ignore the implementation of the data and activities, and then in the design stage we begin to focus more on physical models, which try to incorporate and encapsulate implementation details.
Our main tool for modeling processes will be the data flow diagram, or DFD. A common approach to developing DFDs follows three basic stages:
The first step towards the use of DFDs is a discussion of syntax rules for the diagrams. We will begin with simple diagrams, and will gradually create more complex, multi-part, DFDs.
There are four basic components in a DFD: processes, data flows, data stores, and external entities. In the segment below, we discuss each of them in some detail.
To make external entities and data stores easilty identifiable from one another graphically, no numeric label is placed on the external entities, and the data stores are typically depicted with the right side of the rectangle "open".
Levels of Diagrams
As mentioned earlier, we generally divide the system into a number of smaller activities in a heirarchical or top-down fashion, to make the process clearer to model and understand.
To achieve this, we generally show a context diagram - depicting the system in its business context (i.e. how the system as a whole interacts with the rest of the world) and then show the rest of the system in layers beneath that.
For the underlying layers:
As with any top-down strategy, our goal is to balance clarity against overhead: we want our individual DFD diagrams to be simple enough to be clear, but we don't want many trivial layers of DFDs to clutter the design.
Developing DFDs from Use Cases
Observe that, if we followed the use case construction ideas from our earlier notes, all the information we need to create our DFDs should be present in the collection of use case descriptions.
The task is then to collate all this information into a clear set of DFDs.
Example DFDs:
First, we consider the context diagram for a system that interacts with three external entities.
(Presumably we would have a more meaningful name for
the central process than simply "Our System".)
Next, we look at the level 0 DFD which breaks our system up into three major processes.
(Again, presumably we would use much clearer, more descriptive,
labels than Process X/Y/Z, or Data A/B/C/AB.
There is also a missing data flow in this diagram, a Report Request,
which would go from the Auditor to 3 Process Z.
We would then have a DFD1 describing process X, another DFD1 describing process Y, and another DFD1 describing process Z.
If processes X, Y, or Z were complex enough to warrant it, they would be further broken down, and those subprocesses would be described in level 2 DFDs.
Of course, here we have just shown the DFDs themselves. In fact, you would accompany each diagram with forms which contain all the additional information - particularly the descriptions.
For instance, for the diagrams shown above we would probably include an executive summary to go with the context diagram, outlining the system as a whole.
Furthermore, we would include another form for each data store, each data flow, each external entity, and each process, containing all the information outlined earlier in a clearly labelled, uniform, easily readibly format
Each description should be cross referenced to the appropriate other descriptions and diagrams, and there should be a table of contents and an index making it easy for readers to look up key information whereever it may be in the collection of DFD documents.
Thus the DFD becomes both a reference tool and a visual aid, providing a clear means of showing how the data and processes in a system interact.
Example Supporting Text:
We might use a standard template for the supporting text for DFDs. For instance, we might provide the text below to go along with the DFD 0 example above. (Note: the level of detail about both the processes and the data involved gets much more precise with each successive layer of DFDs. At DFD0 we're giving a fairly high-level overview, but by the time all the DFDs are complete there should be a precise description of both the processes and data items.)
DISCLAIMER: The labels used in the DFD0 were suboptimal at best - it would be preferable to pick labels that were far more descriptive of the processes, data flows, and data stores in question.
Our System handles the processing of sales requests from our clients, including the submission of requests directly from clients or through members of our sales team. It addresses the production of invoices, updates to our inventory system, and the production of monthly and annual audit reports for the auditing team.
ID: 0Proc001 Description: This process handles incoming purchase requests, either directly from the Client or via a member of the Sales team. It checks the requested items against the current inventory and stores the customer request (in the D1 Data Store) and passes a summary of the request and current stock to Process Y. Detailed descriptions of the process sequencing can be seen in sequence diagram #XS0, activity diagram #XA0, and state diagram #XD0 (include correct id numbers and/or links). Inputs: Request: a sales request submitted directly by the client Sales Request: a sales request submitted via a member of the sales team Data B (incoming): a summary of the current inventory status of the requested items Outputs: Data B (outgoing): the customer request details Data C: a summary of the customer request and current inventory status Cross Reference IDS: Data flows: 0Flow001, 0Flow003, 0Flow006, 0Flow009, 0Flow010 External entities: 0Enti001 Processes: 0Proc002 Data stores: 0Data001
ID: 0Proc002 Description: This process handles the production of client invoices and sales reports, and updates the status of the client orders and the company inventory. Detailed descriptions of the process sequencing can be seen in sequence diagram #YS0, activity diagram #YA0, and state diagram #YD0 (include correct id numbers and/or links). Inputs: Data C: a summary of the customer request and current inventory status Data A (incoming): a summary of the updated inventory status for the requested items Outputs: Data A (outgoing): a transaction to adjust the client and inventory status in the the data store Sales reports: a summary of the client and invoice data for the sales team member handling a client's order Reply: a client invoice for the available requested items Cross Reference IDS: Data flows: 0Flow002, 0Flow004, 0Flow006, 0Flow007, 0Flow008 External entities: 0Enti003 Processes: 0Proc001 Data stores: 0Data001
ID: 0Proc003 Description: This process is invoked by the auditor, and produces the sales, inventory, and client reports for a specific (monthly or annual) reporting period. It requests the necessary raw data from the central data store, and can store the updated summary/reporting data in the central data store in addition to generating the requested report. Detailed descriptions of the process sequencing can be seen in sequence diagram #ZS0, activity diagram #ZA0, and state diagram #ZD0 (include correct id numbers and/or links). Inputs: Report request: a request from the auditor for inventory, client, and sales reports for a specific month or year Data AB (incoming): inventory, client, and sales raw data for the month or year in question Outputs: Data AB (outgoing): inventory, client, and sales summary data for the month or year in question Audit report: inventory, client, and sales summary reports for the month or year in question Cross Reference IDS: Data flows: 0Flow005, 0Flow011, 0Flow012, 0Flow013 External entities: 0Enti002 Processes: Data stores: 0Data001
ID: 0Enti001 Description: The client represents anyone placing an order with our system, either directly or via a member of our Sales team. Invoices are sent back to the client in either case. Each client has an assigned sales representative (even if they submit their order directly), who will receive a sales report for any client order received. Cross Reference IDS: Data flows: 0Flow001, 0Flow002 Processes: 0Proc001, 0Proc002
ID: 0Enti002 Description: The auditor can request sales, inventory, and client reports for any month or year, and can request the report summary data be stored in the central data store. Cross Reference IDS: Data flows: 0Flow005, 0Flow013 Processes: 0Proc003
ID: 0Enti003 Description: Each client has an associated sales representative (even if the client submits all their orders directly), and this sales representative will receive a sales report for any of the client's orders. The sales representative can also submit orders on behalf of the client (in which case the client will also receive an appropriate invoice). Cross Reference IDS: Data flows: 0Flow003, 0Flow004 Processes: 0Proc002
ID: 0Data001 Description: the central data store holds all the client, staff, and inventory information used in tracking and reporting on sales orders and current part inventory levels. Inputs: Data A (incoming): the adjustment of the client and inventory status for a given order Data B (incoming): the customer order details Data AB (incoming): inventory, client, and sales summary data for the month or year in question Outputs: Data A (outgoing): a summary of the updated inventory status for the requested items Data B (outgoing): a summary of the current inventory status of the requested items Data AB (outgoing): inventory, client, and sales raw data for the month or year in question Data Contents: Inventory Data - for each type of purchase item we record: a part number, the number currently in stock, our purchase price, the current sale price, the current supplier Client Data - for each client we record: their client ID number, their contact information (address, phone, email, fax, contact person), their current account balance, their pending orders (by order ID), their sales representative (by staff ID) Sales Staff Data - for each member of the sales team we record: their staff ID number, Order Data - for each order placed we record: the client (by ID), the sales representative (by ID), whether or not the client placed the order directly, the order date, the order status (completed, cancelled, pending) Order Item Data - for each item type in each order we record: the order number (which order this item was a part of, by order ID), the type of item (by part number), the sale price (at time of order), the number requested Audit Summary Data - for each requested audit summary we record: the start and end dates for the period covered, the quantity of each part sold during that period, the stock levels for each part at the beginning and end of the period, the total sales amounts (in dollars) for each member of the sales team, the total purchase amounts (in dollars) for each client Cross Reference IDS: Processes: 0Proc001, 0Proc002, 0Proc003 Data flows: 0Flow007, 0Flow008, 0Flow009, 0Flow010, 0Flow011, 0Flow012Note that the nature of the data contents is described more fully in the attached ERD (again, include a link or page number - or, even better, include a seperate link or reference for each Data Contents item listed above).
ID: 0Flow001 Description: this represents the information being passed from the client regarding the placement of an order. It will include the client id, date, and a list of parts numbers and quantities. Source: Client (external entity) Destination: 1 Process X (process) Cross Reference IDS: External entities: 0Enti001 Processes: 0Proc001
ID: 0Flow002 Description: this represents the invoice information being returned to the client once an order has been placed (directly or through a sales representative). It includes the order id, date ordered, a list of part numbers and quantities shipped, and prices. Source: 2 Process Y (process) Destination: Client (external entity) Cross Reference IDS: External entities: 0Enti001 Processes: 0Proc002
ID: 0Flow003 Description: this represents the information being passed through a sales representative regarding the placement of an order. It will include the client id, sales id, date, and a list of parts numbers and quantities. Source: Sales (external entity) Destination: 1 Process X (process) Cross Reference IDS: External entities: 0Enti003 Processes: 0Proc001
ID: 0Flow004 Description: this represents the information being passed to a sales representative regarding orders placed by a client. It includes the client id, sales id, order id, date, a list of parts numbers and quantities and prices. Source: 2 Process Y (process) Destination: Sales (external entity) Cross Reference IDS: External entities: 0Enti003 Processes: 0Proc002
ID: 0Flow005 Description: this represents the information being returned to an auditor regarding sales, client, and inventory data for a particular monthly or annual period. It includes the start and end dates for the period, a summary of the inventory amounts for each part number at the beginning and end of the period, a summary of the total sales of each part number for the period, a summary of the total sales for each member of the sales team for the period, and a summary of the total orders for each client for the period. Source: 3 Process Z (process) Destination: Auditor (external entity) Cross Reference IDS: External entities: 0Enti002 Processes: 0Proc003
ID: 0Flow006 Description: Source: Destination: Cross Reference IDS: Processes: 0Proc001, 0Proc002
ID: 0Flow007 Description: Source: Destination: Cross Reference IDS: Processes: 0Proc002 Data stores: 0Data001
ID: 0Flow008 Description: Source: Destination: Cross Reference IDS: Processes: 0Proc002 Data stores: 0Data001
ID: 0Flow009 Description: Source: Destination: Cross Reference IDS: Processes: 0Proc001 Data stores: 0Data001
ID: 0Flow010 Description: Source: Destination: Cross Reference IDS: Processes: 0Proc001 Data stores: 0Data001
ID: 0Flow011 Description: Source: Destination: Cross Reference IDS: Processes: 0Proc003 Data stores: 0Data001
ID: 0Flow012 Description: Source: Destination: Cross Reference IDS: Processes: 0Proc003 Data stores: 0Data001
ID: 0Flow013 Description: Source: Destination: Cross Reference IDS: External entities: 0Enti002 Processes: 0Proc003