UTN - FRLP - Information Systems Engineering

Subject: Systems Analysis

Data Flow Diagrams (DFD)

Data flow diagrams (DFD) are used to model functionality
of a system. As described by DeMarco and Gane & Sarson, a DFD allows
represent a system as a network of data transformation processes that
they exchange information through data flows.
A process in a DFD can represent functionality at different levels of
abstraction, from functional units of an organization (for example: department
from human resources, sales department, etc.) to simple expressions (for example:
calculation of the annual nominal rate of a loan). Figure 1 presents a non-example
necessarily complete, but that illustrates the different components of a DFD.

Data of Clients Data Flow

Process Client
New Client
Data of
Merchandise Merchandise
Validate
Order Client
Order
Validate Merchandise no
Merchandise Existence Available
Invalid
Client Information
Invalid boarding
Client Data of Registrar
Client Order
Inform Validated Order Fees
Error Pending
Message
of Error
Information Order
of the Rates Pending
Confirmation
of Request Generate
Order of the Request for Pending Orders
Client Client
External Agent
Accepted Orders Data Deposit

Fig1.: Example of DFD - 'Process Customer Orders'

When an order is placed, the customer's data is consulted and their account status is validated.
Then, the existence of the requested merchandise in stock is verified. If there is sufficient stock, it is registered.
as Order Accepted and a confirmation of the order is generated. If there is not enough stock, the
request is registered as pending. If the entered data is not valid, an error message is
generated.

1
 The data flow diagram describes how data flows through the system,
but they do not provide information about control structures or execution sequences.
The only sequence that can be recognized in a DFD is determined by the need.
of information: the Client Order Generation process can complete its functionality
only in the case that the validated customer data flows, information of
Embark Information on the Rates is available (fig.1). On the other hand, the
Validate processes Client and Validate existence do not have a defined execution order
relative to each other, since neither of them receives output flows from the other process.
We can consider the data flow diagram as a graphic language, useful
to describe the functionality of a system, in a certain degree of detail. The syntax of
this language includes the following symbols:
• Data Flows: Information passed from one component to another. They are
represented by labeled arrows.
• Processes: Portions of system functionality. They are represented by bubbles.
or circles with a descriptive name of that functionality.
• Data Deposits: Represent a file, shared memory area or
any data storage mechanism. They are represented by two
parallel lines.
• External Agents: It is a black box that generates flows into the system or receives.
his responses. It represents some external thing or entity that interacts with him.
system.

Data Flows
Data flows are represented by arcs or labeled arrows. The arrow
points in the direction of the flow of information, data flows in that direction. The
The name used to label the arch must be representative of the data contained within it.
In some cases, when the name is obvious, it can be omitted (for example: a flow that
enters or exits a data warehouse representing a complete record) but, in general,
that practice is not advisable.
Extensions to the notation used by DeMarco and Gane & have been proposed.
Mustard, some of them intended to make the DFD more descriptive, incorporating
additional information through design conventions of the flows. In the table
The following is a summary of the most commonly used notations.

2
 Data Flows - Most Used Notations

Flow F The information contained in F is only available for the

A
Discrete process A, at a given moment and with discrete periodicity.
Flow F The information contained in Festa is available for process A.
A
Continuous continuously over a period of time. It is used for
model measurable quantities (e.g.: temperature) in time systems
real.
Flow of Fb Fa The data flow of dialogue is a simplification of two flows of
A B
Dialogue related data (one is a consequence of the other).
A flow with a dashed line is used to model the occurrence.
Flow of from an event that requires an action of the system to be executed. This
A
flow does not transport data.
Control
Flow Ct A A control flow that models the occurrence of a temporal event
Temporal specified by the temporary condition Ct (e.g.: end of the day, etc.).
They are typically labeled with a name prefixed by: "it's time to "
Source F The data flow is provided by one of two sources. The process A
A needs the data contained in the flow but has no further
Multiple
importance of the source.
Destination F
The data flow generated by the process is sent to two
A different recipients (simultaneously).
Multiple

Processes
A process represents a functional component of the system. A process
transform, control, distribute, or generate data. For example, processes can carry out
arithmetic or logical operations on the data it receives to produce some result.
Processes in a DFD are represented by a circle (in DeMarco notation) or
like a box with rounded edges (in Gane & Sarson notation) with the name
of the process inside it. Meaningful names should be used, containing for the
less one verb, to define the operation performed.

DeMarco notation Gane & Sarson Notation

1.5 Reference to the process 1.5

Validate commonly a number Validate
Client composed representing Client
levels of refinement

Regarding processes, a DFD describes only the names and the flows of
entry and exit, without providing any other information about the internal activities of the
processes. To describe in more detail, and specify the functionality for which it is

3
responsible for the process, process specification techniques are used, which will be
described later.
Occasionally, a process will be responsible for controlling the execution of others.
processes of the DFD, instead of having the functionality of transforming data. Those
processes are called control processes.

Data Deposits
A data store included in a DFD to model the need for
store data. A data repository can represent a file on the disk of the
computer or a global memory area for processes. In the literature it is possible
finding that this same concept can receive other names such as for example:
File, Data Storage or Repository.
DeMarco notation Gane & Sarson Notation
Client A1 Client

The readings conducted on a data repository are represented by streams of

outflow (from the deposit), and information updates are represented by flows of
entry (to the warehouse). Commonly, the name of a data warehouse is a noun and
It can also be composed of adjectives. Verbs are not valid as part of the
name, since data storages in the DFDs represent an entity
static, lacking any functionality or behavior. The data structure
contained in the file is documented in a data dictionary, as will be shown further
forward.

External Agents
An external agent establishes the origin or source of the data used by the system.
or the receiver of the data produced by it.
The DeMarco notation Gane & Sarson Notation
external agents Department Department
(also of Sales Sales

denominated

4
external entities) are not part of the system. They are modeled as black boxes that
they generate or receive data from the system. Their functionality and communication with other agents
externals are irrelevant from the perspective of the system being developed.
An external agent can represent a functional area of an organization, or the
position of an official, a government agency, a data-generating device
continuous or another system that must interact with the modeled system.

Process Refinement in a DFD

A DFD is a commonly used tool for top-down analysis, that is
that allows for an analysis that goes from the general to the particular of the problem. The DFDs
are used to model both detailed and high-level views of a system or
program [Yourdon]. The functionality of a process can become so complex that
to understand it, it is necessary to detail your activities separately. Like
example, let's consider a process representing the work of an entire functional area of
an organization. In that case, the complex process can be specified with another DFD
more detailed. Thus, a DFD tree can be developed presenting different levels
of abstraction in the modeling of a system.
Figure 2 presents the specification of a process using another DFD. The
Process P is very complex and needs to be refined to achieve a better understanding.
of its functionality.
A Fs1
Fa
P Level N
Fs2

Fa x Fs1
Ap
P1
z
y Level N + 1
w P3
P2 Fs2

Fig 2: Specification of process P with a more detailed DFD (Refinement)

The refinement of DFDs has a cross-validation rule to ensure

consistency in the modeling of processes at different levels of abstraction:
The input and output flows of a process must be preserved.
in the refinement. That is, all the input and output flows of a
The process must have the same input and output flows as the level DFD.
immediately below, in the tree of levels generated by the process of
refinement.

5
 Figure 3 presents an example of refinement. This example represents a view
more detailed of the process Validate Client of the DFD Process Customer Order
presented in figure 1.

Data of Client The 'Client' Data Deposit

Client it is represented again in this
Data of Level to highlight that it is updated
Order Obtain New Client
data of New Client
Client
Create
Record of
Data new
from Client Client
Client Existing
Invalid
Verify
Credit of
Client
Data of the
Input and Output Flows Validated Clients
in the immediate higher level DFD

Fig3: Process Refinement Validate Client

Validation Rules
The DFD is a very simple modeling tool to use. The notation
it includes only four types of symbols, allowing for good and quick understanding
of the models. Although the construction rules are simple and flexible, there are some
invalid combinations of symbols, which constitute structural errors.

Structural Errors
f Two data repositories cannot be connected by a flow.
Yes d from data without a process that serves as an intermediary.
f There must be at least one input flow and one output flow.
Dm output in all data repositories.
f Deposits cannot "magically" generate or be
Ds data sinks
f An external agent cannot communicate directly with
Ag d data undeposit.
f The connections between external agents are not relevant.
Ag1 Ag2 for the system. They are black boxes.
f There must be at least one input flow.1and a flow of
Pm
output in all processes.
f Processes cannot generate 'magically', nor be
Ps drains of data.

1 Without considering data deposit reading flows.

6
 In addition, balance rules in the inflows must be taken into account.
and output of processes and deposits, with the aim of maintaining the system model
consistent and complete.
Balance of Inflows and Outflows
Deposits x
z
Everything that is deposited must be withdrawn.
of Data d at some point, otherwise it doesn't make sense
store it. And everything that is extracted from it must have been
y
entered before, or I could not find it.
x The outputs of a process must be able to be
z
Processes P defined as a function of input flows:
z=p(x,y)
y

Systematic Construction of the DFD

When developing large and complex systems, in general, there are no means that
someone to the systems analyst in the design of a DFD. The analyst sits at his desk,
contemplating a sheet of paper, waiting for a moment of divine inspiration or
saturating himself with ideas that are impossible for him to express all at once. This uncertainty
it can be eliminated by trying to apply a systematic construction method, assisted by
complementary tools that help break down the problem into parts and address them one by one
for once in an organized way.
A concrete example of systematic construction will be developed below
DFDs. The method we will apply is described informally, in order to present
some other tools that assist in building a functional model of a
system, expressed in a hierarchy of DFDs.
When developing a system, regardless of its size, it is necessary to have in the first place
term, with a textual narrative and a concise statement of the system's objectives (the
functionality that is required, that is to say what is expected for the system to do), of course
validated with the system user (the people to whom it is intended).
Below is a textual narrative and its corresponding statement.
objectives, regarding the case study that we will address: the development of a system of
information for the management of a hotel.

Case Study - Hotel Management

A hotel accepts room reservations and requires a 50% advance payment.

the rate (price of the room * number of days). In the booking operation, a passenger,
inquiries about your accommodation needs. The receptionist, in order to respond,

7
create a code based on the client's request. With this code, check availability,
and it is communicated to the passenger along with the price, or if it does not have the required items, requests

alternatives. When the passenger confirms their reservation, the employee takes the personal details and gives them
give a reservation number. Upon payment of the reservation, it is registered along with the date of
payment is made and a receipt is sent back by mail.
This hotel has a dealership in the bar and restaurant service, whose
diners are not necessarily accommodated. In the case that they are, the signed vouchers
by the guests are processed by the hotel management, which will add the amount of
those consumptions to the invoice that is issued when the guest leaves the hotel. Before the
client payments are prepared and receipts are delivered. Once a week the
management prepares a report for the bar concessionaire with the details of the
consumptions made by customers, accompanied by the corresponding amount.
The management receives a report of the issued invoices weekly. Upon request.
A statistical report on room occupancy is prepared from it.

Functional Objectives:

• Information Management on Reservations.

• Passenger Information Management.

• Rate management and room occupancy.

• Online billing.

• Weekly Services Report Generation.

• Weekly Billing Report Generation.

• Generation of Room Occupancy Statistics.

From this narrative, a description of the facts must be obtained, which

occur in the environment in which the system will operate, and to which the system
must provide a pre-planned response. That is to say, we can see the system as an agent that
reacts to certain stimuli that occur in its external world. Once
Knowing what stimulates the system, our task will be to plan its reactions.
in accordance with the objectives.

We will use this to describe and list the facts or events that stimulate the
system and what makes it react, a tool called event list.

8
Building the Event List

To detect the events, all the sentences of the narrative must be analyzed.
fundamentally analyzing the different nouns that appear. Based on them
we will be able to recognize external subjects, that is, entities that can generate stimuli
system, and other candidate objects of which the system maintains information, that is
that will constitute their essential memory.
In most cases, the easiest way to identify events
relevant to a system is to visualize the system in action: it implies examining each subject
(entity, external agent) and ask what effect their actions may have on the
system.
When extracting the events from the narrative and building the list of events, it is necessary
take into account that an event:
• It occurs in the system environment (it is generated by some external subject to
sistema).

• Generate a pre-planned response from the system.

• It occurs at a point in time.

The detected events are recorded as follows:

subject
For the subjects, we will use the indefinite article in singular form (a, an).

Event List created for the Case Study:

A passenger makes a reservation request
A passenger accepts the reservation
A passenger pays the reservation
A passenger cancels the reservation
5. A passenger arrives to check in.
6. A passenger informs that they are leaving
7. A passenger pays the bill
8. The dealer issues a voucher for consumption
9. It ’s time to prepare the report for the dealership and pay.
a week has passed since the last report
10. It's time to prepare the billing report for Management (C.t.: ha
a week has passed since the last report
11. Management requests a report of occupancy statistics
12. Management sends new rates for rooms
In addition to a description of the stimuli to which the system responds, it is necessary
also, a description of the boundaries that separate the system from its environment.
This description will give us a good understanding of the scope of the system.

9
We will use the Context Diagram to describe this. This diagram is a case
special of the data flow diagram, in which a single bubble represents the system
whole. The name given to this bubble (process) is usually the name of the
system or an acronym pattern or model.

Construction of the Context Diagram

The construction of the context diagram involves the following steps:

• An external entity is drawn for each subject in the list of events.

• For each event, find a name for the data package that serves as
stimulus.

• For each event, draw a flow from the external entity to the system, placing it
name and the number of the event that generates it.

• Draw the system's response to each stimulus and label it with the event number.
corresponding. (If the response is internal, meaning it does not leave the system, it does not
draw. The externals are all drawn, and there can be more than one per event.

• Finally, the lack of necessary stimuli should be controlled by observing others.

answers in the narrative.

Another tool used to describe the stimuli and responses of the system is the
stimulus-response table, which is generally constructed along with the diagram of
context. This table associates each stimulus produced in the environment with the responses.
that the system produces, also describing the internal responses or activities that the
system performs in response to each event.

Context Diagram and Stimulus-Response Table for the Case Study

So far, what has been achieved is a better understanding of the problem, that is,
system that we need to develop. We know the events that stimulate it (List of
Events) and the responses generated by each event, as well as which agents
external parties are involved (Context Diagram, figure 4). We also have an idea,
although not very precise, of the activities to be developed in response to each event (internal responses
in Stimulus-Response Table). The models built so far are called
commonly, as a whole, Environmental Model.
At the end of the environmental model construction stage, there is also available a
first version of the Data Dictionary (DD) containing at least one description of
each of the data flows from the context diagram. The DD will be omitted by

10
simplicity, and in order to avoid saturating the exhibition in development. The construction of
data dictionary will be the subject of a later section.
Based on the environmental model, we will have to discover and model the way in which
the system processes the different events it receives to generate the desired responses
external agents and, also, persistent deposits must be discovered and modeled
that will contain the essential information to be managed by the system. That is, we will have
to model everything that happens within the only process of the diagram of
Context, which represents the system.

reservation request (1)

occupancy report (11)

available reservation (1)
Manager
reservation confirmation (2)
billing report (10)
reservation number (2)

request report
entry data (5)
occupation (11)

room number (5)

new rates (12)

receipt reservation (3) System of
Passenger It is time to prepare the report to the 1 week
Management
payment reservation (3)
dealerandpay (9)
Hotel
receipt invoice (7) It's time to prepare the report of 1 week
billing for management (10)
pay invoice (7)
consumption voucher (8)

cancellation of reservation (4)

Dealership
invoice (6)
payment report (9)
withdrawal notice (6)

Fig 4: Context Diagram of the case study

11
 At this point, we could apply a classic structured analysis approach to
downward decomposition or top-down [DeMarco; Gane]. This approach proposes the
construction of a hierarchy of DFDs, each representing a level of abstraction
different. It starts with the construction of a first-level DFD (or level 1), which
it constitutes the explosion of the context diagram. For the construction of the first DFD
At this level, the analyst (or group of analysts) studies the context diagram and creates a DFD.
(level 1) without a strategy to assist it. Using its own knowledge of
problem, or of the type of application, and its common sense, divides the system into 'Bubbles
Important" (representing for example subsystems). These important bubbles, or
main subsystems are further partitioned into others, representing a new level
about the details of the transformations that the system produces on the
data received. This decomposition process applies to each bubble at each level,
describing it with a new DFD, until reaching a bubble that we will call
"atomic" and that does not require further decomposition, and whose operation can be
described through a complementary specification technique (these will be seen in
detail later.

12
 Stimuli Answers
Event Entity Stimulus External Entity Internal
External (Flow of (Data flow) External Activities or Processes
Origin data Destiny that involves
1 Passenger Order_Response Reservation_Availability Passenger • Encode the
herb nibble needs of the
passenger
• Verify
availability
• Inform the passenger
price and
availability
2 Passenger Confirmation_Reservation_Number Passenger • Register reservation
Reservation • Register passenger
3 Passenger Reservation PaymentReservation Receipt Passenger • Register reservation payment
4 Passenger Cancellation ------------------------- ---------------- • Registration cancellation
Reservation reservation
5 Passenger Income_Data • Complete data
on passenger
• Assign a room
• Update reservations
• Open account and invoice
6 Passenger Withdrawal_NoticeInvoice Passenger • Close account and
invoice
7 Passenger Pay_Invoice Invoice Receipt Passenger • Register payment
• Registrar
consumptions
paid
8 Vale Dealership ------------------------- -------------- • Registrar
consumption consumptions for
each passenger
9 Event Payment_Report Dealer • Select
Temporal consumptions
paid
• Issue report
dealership
• Pay dealership
10 Event Billing Report Management • Prepare report
Temporal on weekly of
billing
11 Management Request_Information Occupancy Management • Prepare report
e_Occupation n weekly occupancy
12 Management New Rates • Register new
rates

Fig 5: Stimulus-Response Table of the case study

13
 Although the classic top-down decomposition approach is the cornerstone
fundamental on which structured analysis is based, in practice it presents several
problems: paralysis and uncertainty in analysis, arbitrary physical partitioning of the system,
etc. These problems are mainly due to the lack of a robust strategy that
drive the decomposition.
We could then use a more systematic approach to address the
mentioned problems, trying to exploit the bubble of the context diagram
using the process decomposition algebra described in the previous section.
We will use, however, another approach, with the aim of presenting it remaining its
detailed description for the section covering the Structured Analysis methodology
Modern. The approach we will use here is commonly referred to as the Medium Approach, or
as it would be called by McMenamin and Palmer, “event partitioning.”
The event-partition derivation approach of the DFD proposes to develop a
Preliminary Data Flow Diagram at the level of detail given by the events in the
List of events that will describe the transformations that the system produces on the data.
as a response to events. This approach is often referred to as the Middle Approach due to
that is not a purely top-down activity nor is it purely bottom-up. Once
the preliminary DFD is ready, it may be necessary to create some higher levels
(function abstraction) and/or some lower levels (function decomposition).
The DFD built with this approach (preliminary DFD) presents a bubble for
each event existing in the list of events, and these bubbles do not communicate directly
not with each other, but communication occurs through data deposits. The latter
It is because the bubbles or processes of the preliminary DFD represent functions that
they generate the responses that the system gives in response to each of the events, and the events that
events occurring in the external environment are generally asynchronous. That is, there is no way
to ensure that two events will occur at the same moment, or with seconds apart,
or with some other specific time interval. Events happen when they need to.
to occur, therefore, as the response to an event may require data produced by
another process addressing another event, the only way to synchronize multiple processes
interdependent on the preliminary DFD is through data deposits.

Derivation of the preliminary DFD by events

For each event:

• Draw a bubble that takes care of him.
• Give it a name that matches the transformation that the system performs with it.
stimulus and observing the response that must be given.

14
 • Add the existing flows in the Context Diagram associated with the event.
• Answer for each bubble the question: What data do you need to produce the
response? and add the flows that are needed to provide this data.
• Answer for each bubble the question: What other data does it produce? and add them.
flows needed to produce and respond to this data.
These last questions can be answered by relying on the narrative, and on the
stimulus-response table.
The following presents the result of applying these steps to the events in
our case study.

15
A passenger makes a reservation request
order
reservation

reservation
available Inform reservation

Availability

room

A passenger accepts the reservation.

confirm

number
reservation reservation
Registrar
Reservation
room

3. A passenger pays the reservation

receipt

payment reservation

Registrar
Payment
Reservation

payment
reservation

A passenger cancels the reservation

cancellation of
reservation

Registrar
Cancellation
reservation

Reservation cancellation

16
5. A passenger arrives to check in.

data
income
reservation
number
Registrar room
Accommodation

data income

6. A passenger reports that they are leaving.

Room release

notice
withdrawal

invoice passenger
Invoice
service

A passenger pays the bill

payment
receipt
Registrar
Payments

payment

8. The dealer issues a voucher for consumption

vale
consumption

Registrar
Consumption

vale
consumption

17
9. It's time to prepare the report for the dealership and pay (C.t.: it has passed
a week since the last report

service
It's time to prepare the report
The billing for management
Pay
Dealership

payment report

10. It's time to prepare the billing report for Management.

a week since the last report

report of
billing

To make
Report of
Invoicing
service
It is time to prepare the report
Invoicing for Management

11. Management makes a request for occupancy statistics

request for occupancy report

room
To make
Report
Statistician
Occupation

room number occupancy report

12. Management sends new rates for rooms

new
rates

Registrar
New
Rates

rate

18
 After developing a diagram for each event, the diagrams must be connected.
in one unique, adding the necessary repositories among the data that a bubble
produce and which other consumes. It is worth considering in this step that all information
entering a process that does not originate from the external environment, it must originate
necessarily from a storage. On the other hand, all information generated that is not
It must be stored; it directly emits into the environment. This step can be supported.
also in the construction of a data model (object of study of a section
posterior) and in the candidate objects for essential memory observed in the event list,
to identify the data repositories. In the case study, the repositories
Identified are: Reservations, Rooms, Passengers, and Services.
Preliminary DFD - Hotel Management
receipt
payment
reserve

request Register
reserve cancellation
Payment reserve
Reservation
reserve Register
available Inform reserve
Cancellation
of the reserve
Availability payment
reserve
confirm new
reserve room
rates
reserve
Register
number Reservations New
reserve reserve
Register Rates
Reservation
room order of information
rate
deoccupation
data room
Room Confection
enter Report
reserve Statistics
liberation deOccupancy
number
room room
Register reserve
number. room
number. report of occupation
Accommodation
Passengers
report
data entry billing
notice
withdrawal
Makes
nro.room Report
Invoicing
invoice passenger service
Services of the hourprepare report
Invoicing billing for Manage
service

service
time for the report preparation for the
payment vale dealership pay
receipt consumption
Pay
Register Dealers
Payments
Register
payment
Consumption

payment report

value
consumption

19
 Finally, the diagram will need to be refined by checking that it has no errors.
structural and correct communication failures (add or refine events).
It is necessary to observe that the resulting DFD (preliminary DFD) consists of a
only level with a process for each of the events. For a medium or large system
(50 or more events), the preliminary DFD will contain too many processes and will be presented
probably very unbalanced, with different levels of abstraction being represented
simultaneously. To improve its understanding, we need to subdivide it by making
abstractions. This means that we want to group processes closely.
related in higher-level abstraction functions, in a higher-level diagram
level. Abstractions must be generated for obtaining a level 1 DFD of
appropriate complexity, that is, one of no more than 7 2 processes. This number is not
arbitrary nor should it be rigid, and represents a limit to understanding
human, which experts in communication sciences have found.
Once the level 1 DFD is obtained, downward leveling is carried out.
or explosions, those deemed appropriate to achieve adequate specifications of
the functions of the system. That is, possibly the processes identified in the DFD of
level 1, turn out not to be atomic or primitive processes and require descending partitions
in lower-level DFDs, this means that such processes may be too
complexes to be properly described in a process specification of a
page.
It remains as an exercise for the reader to make appropriate abstractions and explosions.
to achieve a complete functional model of our case study, composed of a
hierarchy of DFDs.
In addition, it would be interesting to complete the system with the functionality that it deems necessary.

missing, adding new events, and determining the impact we produce in our
analysis when incorporating new functional requirements. As a suggestion, at the very least
The following should be addressed: Every day accumulate occupancy and services; and
Register room out of service.

20