MILESTONE 4
PROCESS MODELING
PURPOSE
The purpose of this milestone is to develop the process models for the proposed system for GPAIC. This requires
developing the following models - system decomposition diagram, context diagram, a leveled set of data flow
diagrams and specifying the processing logic for the primitive processes.
After completing this milestone, you will have accomplished the following:
1.
2.
3.
4.
5.
Developed a context model so that the boundary of your system is clearly defined.
Factored your system into component subsystems, processes and tasks (elementary processes) and depicted
its structure using a decomposition diagram. Identify business, temporal and state events and map one
process for each event.
Captured the data flows between the external environment and the system and those within the system.
Modeled the data flows and the relationships between the system, sub-systems, processes and tasks using
data flow diagrams.
Defined the processing logic for the elementary process using techniques such as flow charts or decision
tables or decision trees or structured english.
Documented your DFDs in VAW to help users reference, read, and understand your data flow diagrams.
DELIVERABLES
The following are the deliverables for this milestone
1) fully-specified process models which include a system decomposition diagram, a context diagram and
leveled set of data flow diagrams. The data flow diagrams should be exploded until elementary
processes are depicted in the model. The data stores and attributes that constitute data flows should
correspond to your data model. The systems decomposition diagram can be generated using VAW
after you have developed all the data flow diagrams (you will however, have to create a rough sketch
(paper & pencil will do) of how you plan to decompose the system and use it as a road map to develop
the DFDs). Where necessary the processing logic must be specified.
2) a copy of the project files created in VAW on a floppy. All data flows must be labeled and their
constituent attributes defined in the repository. Make sure that the DFDs do not have any illegal data
flows or other errors (black holes, gray holes and miracles). The DFDs should be balanced.
3) a printout of all the diagrams and a report depicting the data flow definitions.
SUGGESTIONS
1.
Develop a context model that defines the boundary of the system. Depict only net data flows in the context
diagram. This is the level 0 model of the set of leveled DFDS you will be developing.
2.
Outline the system before drawing the DFDs by drawing a systems decomposition diagram. There are several
ways to draw good decomposition diagrams. The general model illustrated in the text book is a good one to
emulate. (Draw this on paper and use it as a reference to develop your data flow diagrams. Once you implement
the data flow diagrams in VAW, you can generate the decomposition diagram automatically using the
“decompose” option in the tool).
3.
Compile an event response list by identifying business events. Events could be external events (triggered by
external agents), temporal events (triggered by time) or state events (triggered by changes in system state).
Update the systems decomposition diagram by adding one process for each event identified. The processes
should be added under respective sub-systems.
4.
Now you are ready to draw the DFDs. DFDs are drawn in a leveled fashion - the levels typically correspond to
the levels in your system decomposition diagram. Explode the context diagram (level 0) to draw the level 1
DFD. This typically will include only the various sub-systems. Then explode each process in the level 1 DFD to
draw level 2 DFDs and so on. Note the student edition allows you to develop only 10 DFDs in one project. You
probably would exceed this limit in this project. An easy workaround to this constraint is to partition the DFDs
and create two separate projects. For example, one project could explode one sub-system and depict all the
processes and tasks under that sub-system.
5.
Continue exploding processes until elementary processes are depicted in the DFDs.
6.
Use the traditional numbering scheme for process numbers (VAW automatically numbers the processes if you
use the Explode option).
7.
Make sure your levels balance. We suggest that diagrams balance downward, not upward. In other words, any
data flow to or from a parent process should be evident as a net data flow to or from one of the children
processes. However, to keep the upper levels uncluttered and readable, a net input or output data flow from
child process doesn’t have to appear on the parent process unless it is one of the key data flows for that parent.
8.
Check your data flow diagrams for black holes (processes that have no outputs), miracles (processes that have
no inputs), and gray holes (processes that couldn’t possibly produce the indicated outputs given the indicated
inputs). These are serious errors that should not occur at any level.
9.
The only DFD with one process is the context diagram. You explode processes to show greater detail.
Therefore, you cannot explode one process into one child process - every parent has two or more children!
10. Naming conventions should be clear and consistent. Don’ t limit yourself to programming size constraints on
names. This isn’t programming! Follow suggestions given in the book for naming processes and data flows.
11. Where necessary, specify the processing logic for the elementary processes. It is sufficient to specify the logic
only at the elementary process level. It is also not necessary to specify the logic for all elementary processes. If
decisions are involved as part of the processing logic use appropriate decision tables or trees.