CSC 375 Notes: Process Modeling

Process Modeling

A process model is a formal way of depicting the operation of a system showing both the activities performed and the movement of data within the system.

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:

First create an intuitive, text-based, description of the process - such as our use cases and scenarios.
Then provide a context diagram showing the relationship of the overall process to the outside world.
Finally provide different levels of DFDs to precisely describe each of the subprocesses or activities in a "top-down" style.

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.

Processes

Processes represent individual activities in the system, and are represented in DFDs using either an oblong or an oval.

For each process, we also record the following information on a second text form:

a unique number, or identifier, for the process
a name for the process, succinctly describing the activity
a description of the process
the output data flows resulting from the process
the input data flows used by the process

Note that every process in each DFD must have at least one input and at least one output.

Data flows

Data flows represent the generation and use of data items by activities in the system, and are represented in DFDs using arrows.

For each data flow, we also record the following information:

a name for the data flow, describing the type of data generated and/or used
one or more source activities, which generate the data
one or more destination activities, which use the data
a description of the data

There are times when we will combine, or join two or more data flows together to form a more complex one (e.g. when two different activities each produce part of the necessary information)

There are also times when we will separate, or split, one data flow into two separate parts (e.g. where two different activities each need a different part of the produced data)

If data could be used in two or more different ways then both data flows are shown on the DFD, and the description field is used to indicate the alternative processing possibilities (e.g. under some conditions the data is sent to one activity, and under other conditions it is sent to a different activity)

Note that at least one end of every data flow must connect to a process (you cannot move data directly between data stores, or directly between a data store and an external entity).

Data stores

Data stores represent collections of data to be stored in some way (to be decided later, during the design phase and physical modeling), and are represented in DFDS using rectangles.

For each data store, we also record the following information:

a unique number, or identifier, for the store
a name for the store, describing the type of data stored there
one or more input data flows, identifying the activities which are sources for the data in the store
one or more output data flows, identifying the activities which access the stored data
a description of the data store

External entities

External entities represent individuals or systems which interact with the system being modeled. This can include users and other systems. External entities are represented in DFDs using a rectangle.

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

For each external entity, we also record the following information:

a name, summarizing the external entity's role in interacting with the system
a description of the external entity.

Note on names/labels

The names/labels used on your DFD should make it easy and intuitive to distinguish between the different data items being moved, and the different data stores, processes, and external entities in use.

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:

the top layer is referred to as DFD0,
for each subprocess depicted in DFD0, we can include a more detailed DFD layer DFD1
for each subprocess depicted in one of the DFD1 diagrams, we can include a more detailed DFD in layer DFD2,
etc

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

NOTE: ALL THAT IS SHOWN HERE FOR THE CONTEXT DIAGRAM AND DFD0 ARE THE BASIC DIAGRAMS:
ALL THE SUPPORTING DESCRIPTION STILL NEEDS TO BE ADDED

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: DFD 0

Overview

In this section we describe our overall system: identifying the key processes, external entities, data stores, and the flow of data between these items.

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.

Processes

There are three high-level processes in Our System, handling sales requests, invoicing and sales reporting, and auditing systems, respectively:

1 Process X

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

2 Process Y

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

3 Process Z

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

External Entities

There are three types of external entity that interact with Our System, the clients, members of the sales staff, and members of the auditing team:

Client

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

Auditor

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

Sales

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

Data Stores

We have a single high-level data store in use for Our System: the D1 Data Store. This stores both our client and our inventory information:

D1 Data Store

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, 0Flow012

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

Data Flows

There are thirteen data flows represented at the high level in Our System (note that the diagram shows nine arcs, but three are bidirectional). The data flows represent the following:

Request (Client -> 1 Process X)

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

Reply (2 Process Y -> Client)

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

Sales Requests ( Sales -> 1 Process X )

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

Sales Report ( 2 Process Y -> Sales )

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

Audit Report ( 3 Process Z -> Auditor )

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

The date flow entries are not filled in for numbers 6 through 13, consider it an exercise for the reader...

Data C ( 1 Process X -> 2 Process Y )

ID: 0Flow006
Description:
Source:
Destination:
Cross Reference IDS:
   Processes: 0Proc001, 0Proc002

Data A ( 2 Process Y -> D1 Data Store )

ID: 0Flow007
Description:
Source:
Destination:
Cross Reference IDS:
   Processes: 0Proc002
   Data stores: 0Data001

Data A ( D1 Data Store -> 2 Process Y )

ID: 0Flow008
Description:
Source:
Destination:
Cross Reference IDS:
   Processes: 0Proc002
   Data stores: 0Data001

Data B ( 1 Process X -> D1 Data Store )

ID: 0Flow009
Description:
Source:
Destination:
Cross Reference IDS:
   Processes: 0Proc001
   Data stores: 0Data001

Data B ( D1 Data Store -> 1 Process X )

ID: 0Flow010
Description:
Source:
Destination:
Cross Reference IDS:
   Processes: 0Proc001
   Data stores: 0Data001

Data AB ( 3 Process Z -> D1 Data Store )

ID: 0Flow011
Description:
Source:
Destination:
Cross Reference IDS:
   Processes: 0Proc003
   Data stores: 0Data001

Data AB ( D1 Data Store -> 3 Process Z )

ID: 0Flow012
Description:
Source:
Destination:
Cross Reference IDS:
   Processes: 0Proc003
   Data stores: 0Data001

Report Request ( Auditor -> 3 Process Z )

ID: 0Flow013
Description:
Source:
Destination:
Cross Reference IDS:
   External entities: 0Enti002
   Processes: 0Proc003

Other Notes

A higher level view of this system is given in the Context Diagram (include page number or link). More detailed views of the processes are given in DFD's 1, 2, and 3 (again, include page numbers or links), while more detailed data descriptions are available in the ERD (link/page number again).

End of DFD0 Supporting Text Example Note that this was just the supporting text for a single DFD. Most system models are going to include many DFDs, each of which will have its own accompanying supporting text, making for a substantial amount of information.