Process Modeling

Process modeling involves graphically representing the processes, or actions, that

capture, manipulate, store, and distribute data between a system and its
environment and among components within a system. A common form of a process
model is a data-flow diagram (DFD). A data-flow diagram is a graphic that
illustrates the movement of data between external entities and the processes and
data stores within a system. Although several different tools have been developed for
process modeling, we focus solely on data-flow diagrams because they are useful
tools for process modeling. Data-flow diagramming is one of several structured
analysis techniques used to increase software development productivity. Although
not all organizations use each structured analysis technique, collectively, these
techniques, like dataflow diagrams, have had a significant impact on the quality of
the systems development process.

Modeling a System’s Process

The analysis team begins the process of structuring requirements with an abundance
of information gathered during requirements determination. As part of structuring,
you and the other team members must organize the information into a meaningful
representation of the information system that exists and of the requirements desired
in a replacement system. In addition to modeling the processing elements of an
information system and transformation of data in the system, you must also model
the structure of data within the system (which we review in Chapter 7). Analysts use
both process and data models to establish the specification of an information system.
With a supporting tool, such as a CASE tool, process and data models can also
provide the basis for the automatic generation of an information system.

Business Process

A process is a coordinated set of activities designed to produce a specific outcome.

There are processes for saving a file, constructing a building, and cooking a meal. In
fact, there is a process for almost everything we do. A business process is a type of
process designed to achieve a particular business objective.

Business processes consist of many components, including:

 The data needed to accomplish the desired business objective

 Individual work tasks that manipulate, review, or act upon the data in some
way
 Decisions that affect the data in the process or the manner in which the process
is conducted
 The movement of data between tasks in the process
 Individuals and groups which perform tasks
Processes can be manual or automated, fully documented or simply knowledge in the
minds of one or more people. They can be simple or complex. They can be formal,
requiring exact adherence to all details; or flexible, provided the desired outcome is
achieved.

Logical Process Modeling

Logical Process Modeling is the representation of a business process, detailing all the
activities in the process from gathering the initial data to reaching the desired
outcome. These are the kinds of activities described in a logical process model:

 Gathering the data to be acted upon

 Controlling access to the data during the process execution
 Determining which work task in the process should be accomplished next
 Delivering the appropriate subset of the data to the corresponding work task
 Assuring that all necessary data exists and all required actions have been
performed at each task
 Providing a mechanism to indicate acceptance of the results of the process, such
as, electronic “signatures”

Logical process modeling methods provide a description of the logical flow of data
through a business process. They do not necessarily provide details about how
decisions are made or how tasks are chosen during the process execution. They may
be either manual or electronic, or a combination of methods. Some of the logical
modeling formats are:

 Written process descriptions

 Flow charts
 Data flow diagrams
 Function hierarchies
 Real-time models or state machines
 Functional dependency diagrams

Context Diagram

The context diagram is used to establish the context and boundaries of the system to
be modeled: which things are inside and outside of the system being modeled, and
what is the relationship of the system with these external entities. (systems,
organizational groups, external data stores, etc.)

A context diagram, sometimes called a level 0 data-flow diagram, is drawn in order

to define and clarify the boundaries of the software system. It identifies the flows of
information between the system and external entities. The entire software system is
shown as a single process.
A Context Diagram (and a DFD for that matter) provides no information about the
timing, sequencing, or synchronization of processes such as which processes occur in
sequence or in parallel. Therefore it should not be confused with a flowchart or
process flow which can show these things.

Benefits:

• Shows the scope and boundaries of a system at a glance including the other
systems that interface with it
• No technical knowledge is assumed or required to understand the
diagram
• Easy to draw and amend due to its limited notation
• Easy to expand by adding different levels of DFDs
• Can benefit a wide audience including stakeholders, business analyst,
data analysts, developers
Drawback:
• fail to give details about the sequence or timing of project processes.

How to construct Context diagram

 Identify data-flows by listing the major documents and information flows

associated with the system
 Identify external entities by identifying sources and recipients of the data-flows,
which lie outside of the system under investigation.
 Draw and label a process box representing the entire system.
 Draw and label the external entities around the outside of the process box.
 Add the data-flows between the external entities and the system box.
Example: Sales order System
Data Flow Diagram(DFD)
• DFD is the abbreviation for Data Flow Diagram. The flow of data of a system or a process is represented by
DFD. It also gives insight into the inputs and outputs of each entity and the process itself. DFD does not have
control flow and no loops or decision rules are present. Specific operations depending on the type of data
can be explained by a flowchart.
• The DFD belongs to structured-analysis modeling tools. Data Flow diagrams are very popular because they
help us to visualize the major steps and data involved in software-system processes.
• DFDs depict logical data flow independent of technology but Flowcharts depict details of physical systems
• Components of DFD
• Process: An activity or function performed for a specific business reason. Manual or computerized
• Data flow: A single piece of data or a logical collection of data. Always starts or ends at a process
• Data Store: A collection of data that is stored in some way. Data flowing out is retrieved from the data
store. Data flowing in updates or is added to the data store
• External entity: A person, organization, or system that is external to the system but interacts with it.

DFD Symbols
• Process: work or actions performed
on data (inside the system)
• Data store: data at rest (inside the
system)
• Source/sink: external entity that is
origin or destination of data (outside
the system)
• Data flow: arrows depicting
movement of data
DFD Diagramming Rules:
S.N. Rules Depiction
1 • No process can have only outputs(called Miracle) or only
inputs(called blackhole)…processes must have both
outputs and inputs.
• Process labels should be verb phrases.

2 • All flows to or from a data store must move through a

process.
• Data store labels should be noun phrases

3 • No data moves directly between external entities without

going through a process.

• Interactions between external entities without intervening

processes are outside the system and therefore not
represented in the DFD.
• Source and sink labels should be noun
Software phrases.
Design by Ishwar Dhungana 31

DFD Diagramming Rules:

S.N. Rules Depiction
4 • Bidirectional flow between process and data store is
represented by two separate arrows.
• Forked data flow must refer to exact same data item (not
different data items) from a common location to multiple
destinations.

5 • Joined data flow must refer to exact same data item (not
different data items) from multiple sources to a common
location.
• Data flow cannot go directly from a process to itself, must
go through intervening processes.

6 • Data flow from a process to a data store means update

(insert, delete or change).
7. • Data flow from a data store to a process means retrieve or
use.
 • Functional Decomposition:
• An iterative process of breaking a system description down into finer and finer detail
• High-level processes described in terms of lower-level sub-processes
• DFD charts created for each level of detail
• DFD Levels
• Context DFD
• Overview of the organizational system
• Level-1 DFD
• Representation of system’s major processes at high level of abstraction
• Level-2 DFD
• Results from decomposition of Level 1 diagram
• Level-n DFD
• Results from decomposition of Level n-1 diagram
• How to Draw DFD?
1.Identify major inputs and outputs in your system
2.Build a context diagram
3.Expand the context diagram into a level 1 DFD
4.Expand to a level 2+ DFD
5.Confirm the accuracy(do DFD Balancing) of your final diagram

Example of DFD:Food Ordering System

Fig:Context diagram of Food Ordering System Fig:Level-1 diagram of Food Ordering System
NOTE: only one process symbol, and no data NOTE:Processes are labeled 1.0, 2.0, etc. These will be
stores shown. decomposed into more primitive (lower-level) DFDs.
Example of DFD:Food Ordering System

Fig:level-2 DFD for process 4.0 of food ordering system Fig: Level-n diagram of Food Ordering System
Processes are labeled 4.1, 4.2, etc. These can be further NOTE: Processes are labeled 4.3.1, 4.3.2, etc. If this is the
decomposed in more primitive (lower-level) DFDs if lowest level of the hierarchy, it is called a primitive DFD.
necessary.

Prepare the context diagram and Level1 diagram of cloth ordering system
Cloth Ordering System:
1.List of External Entities:Customer,Clothes Store,Clothes Supplier,Sales Manager
2.List of Data flows:
o Customer puts order to the cloths ordering system and gets receipt from the system.
o Cloth Store and Supplier gets order from Order Cloths process and Supplier provides receipt to the
system.
o Order clothes sends the inventory details to the inventory database and order details to the order
database
o The inventory details and order details was send to the report generation process and the reports was
sends to the Sales manager.
o Sales manager Provides inventory order to the order inventory process and inventory order was send to
supplier and the inventory record was send to store in inventory database.

On the basis of Above Scenario Prepare Context diagram ,Level 0 Diagram and Level 1 diagram of
Cloth Ordering System
 Inventory order

•
software application in terms of objects.
• It is real world based modeling approach for
software modeling and designing. It was developed
basically as a method to develop object-oriented •
systems and to support object-oriented
programming. It describes the static structure of the •
system.
• Object Modeling Technique is easy to draw and use. •
It is used in many applications like
telecommunication, transportation, compilers etc. It •
is also used in many real world problems.
• OMT is one of the most popular object oriented
development techniques used now-a-days. OMT was •
developed by James Rambaugh.
problem.
Purpose of Object Modeling Technique:
• It is
• To test physical entity before construction of them.
• In analysis, the focus is to full y
• To make communication easier with the customers.
that form the vocabulary of the problem domain.
• To present information in an alternative way i.e.
visualization.
• To reduce the complexity of software. • In design, we
• To solve the real world problems.
Software Design by Ishwar Dhungana 38