Abstract
In the object-oriented approach, the focus is on capturing the structure and behavior
of information systems into small modules that combines both data and process. The
main aim of Object Oriented Design (OOD) is to improve the quality and productivity
of system analysis and design by making it more usable. In this paper, we compared
the differences about Data Flow Diagram and Use Case Diagram in order to view their
concept of both diagrams and find out the advantages and disadvantages. As a result
both diagrams have their own strength and weakness depending on the situation
needed such as use case are a powerful technique for capturing and communicating
functional requirement for software development whilst DFD is powerful tools through
system analysis and design process and if the system has complex functions but
relatively trivial data structures, DFD will be the best tool.
1. Introduction
Nowadays, most organization used different kinds of systems design in analysing and
designing information for any process and system such as based on process models,
data models or object-oriented model. Therefore, the needs of using Data Flow
Diagram (DFD) become most popular compare to other diagram such as Entity
Relationship Diagram (ERD), structure chart, state machine is less used [1]. DFD is
part of the structured-analysis modelling tools. System analysts use DFD as a tool for
modelling and analyzing the processes in the system based on behaviour and actions.
It would be helping an analysts to visualize the data processes since data enter to the
system, and then they are used by the system until they are returned to the
environment. System Analysts also use DFDs to study alternative information handling
procedures during the process of designing new information services. In addition, Data
Flow Diagrams can be used for comparing the new system and the old system which
is non object oriented and Object-oriented. With this comparison, system analysts can
find the gap between two systems and the effectiveness of the improved system.
DFD’s are having certain advantages compare to other diagram. The hierarchy
structure of DFD provides different abstraction level which is very useful in system
designing [2]
Thus, in object oriented (O-O) approach, which use case diagram on the
easiest way is a representation of the user's interaction with a system that shows the
relationship between the user and different use cases where the affected users . In
the other word its combine both processes and data to improve the quality and
productivity of system analysis and design by making it more usable.
In the analysis phase, model O-O used to fill the gap between problem and
solution. It is often also in a situation where the system will undergo continuous design,
acceptance and maintenance. They identify objects in the domain problem, classifying
them in terms of data and behaviour[3].
Unified Modelling Language (UML) is the most important tool for model OO and
model creation. There are basic characteristics of Object Oriented Systems such as
1)Classes and Objects 2) Methods and Messages 3)Encapsulation and Information
Hiding 4) Inheritance and 5) Polymorphism [4]
Data Flow Diagram ( DFD )
The history of Data Flow Diagram (DFD) formerly was used in operations
research for workflow model in the organization. DFD who first proposed by Edward
Yourdon, Larry Constantine, Tom DeMarco, Chris Gane and Trish Sarson.[5]
DFDs became popular in the late 1970’s and has maintained its use extensively
with easy to understand. Visually display how work processes or system that can hold
people's attention and explain complex concepts better than text block can be, so that
DFDs can help almost anyone who understand a system or process logic and
functionality. DFDs is useful to document the flow of key data or to explore new design
high level in terms of the flow of data. [6]
There are two types of DFDs such as logical and physical. Logical diagrams
display the theoretical process of moving information through a system, like where the
data comes from, where it goes, how it changes, and where it ends up. Physical
diagrams shows the practical process of moving information through a system, like
how your system’s specific software, hardware, files, employees, and customers
influences its flow of information.[ 7 ]
DFD is widely used for structured software analysis and design. It is also
widespread in the field of business administration DFD includes following
characteristics: (1) supporting the analysis and requirement stage of system design;
(2) a diagramming technique with annotation; (3) describing a network of
activities/processes of the target system; (4) allowing for behaviors of parallel and
asynchronous ; (5) stepwise refinement through hierarchical decomposition of
processes.[8 ]
DFD is a graphical representation of the flow of data through an information
system [9] .It is one of the most commonly used systems-modeling tools, particularly
in the operational system in which functions of the system are the most important and
more complex than the data that the system manipulates. Rather than showing the
strict order of execution of steps, it shows how processes depend on one another for
information. It shows data flow from external into the system and shows how the data
moved from one process to another process.[10]
Data Flow Diagram Syntax ( NOTATIONS )
A Data flow diagram presents a system of symbols to describe the data flow
and the mechanism of decomposition to explain detail about a system at all levels.
DFD cannot present information on operation sequence. Therefore, it is not a process
or procedure modeling method [11]. Data flow diagram showing the process, store
data and external entities in commerce or other system and data flow connected [12].
There are only four symbols for a data flow diagram: 1) Squares or Ovals, 2) Circle or
Rounded Rectangles, 3) Arrows, and 4) Open-ended Rectangles. Yourdon and Coad
Gene Sarson are two major methods used in DFDs notations, and both use and tags
to represent the four major elements in the DFD-external entities, processes, data
flows and data stores such as below [13]
Figure 1 : DFD notation
Square / oval
Squares or Ovals represent external entities such as a person or a group of people
outside the control of the system being modeled. It also explain where the information
comes from and where it will go.
Circle / Rectangle
The circles or rectangles round represents the processes in the system. It
shows a part of the system that transforms inputs into outputs. The name of the
process in the symbols usually explains what the process does so that it is generally
used with verb-object phase. In some cases, however, the process may contain the
name of the person or group of people, or a mechanical device. So, it sometimes tells
us who or what is carrying out the process, rather than describing what the process is.
Arrow
Arrows represent the data flows. It can be either be electronic data or physical
items or both. The name of the arrows represents the meaning of the packet (data or
items) that flow along. In addition, like Arrows in flow charts, Arrows in data flow
diagrams show direction to indicate whether data or items are moving out or into a
process.
Open-ended rectangles
Open-ended rectangles represent data stores, including both electronic stores
and physical stores. Data stores is repositories of data in the systems. It may be used
for the data collected for a short or long times period.
Use Case Diagram ( UCD )
Use Cases originated as a requirements modeling technique within the object-
oriented (OO) software development community many years ago. Use case diagram
was introduced by Ivar Jacobson in 1986 [14]. By the mid-1990s, use case modeling
was formalized as part of the Unified Modeling Language (UML) specification, which
is managed by not-for-profit open consortium known as the Object Management
Group (OMG). The UML is the OMG’s most-used specification and the defacto
standard for modeling application structure, behaviour, and architecture within the OO
paradigm of software development. Use case diagrams are one of the twelve type of
diagrams defined within the UML specification, Class Diagram, sequence diagram,
and activity diagrams are some of the other well-known UML diagrams [15].
Use case diagram aims to capture the dynamic aspects of the system. It is
used to collect system requirements including internal and external influences. This
requirement is very important to the system analyst because they must know what the
system must do or what features it should have. Requirements grow from detailed
statements of the commercial abilities that a system should have to detailed
statements of the technical way the capabilities will be implemented in the new system.
The value of use cases is in the technique of writing the textual description, the basic
and alternate flows.
In the Unified Modeling Language (UML), a use case diagram is a sub class of
behavioural diagrams [16]. The purpose of UML use case diagram are to 1)
demonstrating the goals of system-user interactions 2) Defining and organizing
functional requirements in a system 3) Specifying the context and requirements of a
system and 4) Modeling the basic flow of events in a use case
Use Case Diagram is one of the Object Oriented Diagrams. It is intentionally
very simple. It shows how a system interacts with the external entities. So, it is
relatively sparse about the details of how the system behaves internally and how the
external environment is configured [16]. As a conclusion, few purpose to describe
about Use Case Diagram as follows 1) use to gather the requirement of a system 2)
use to get an outside view of a system 3) Identify the external factors influencing the
system 4) Show the interaction among the requirement are actors ( Tutorial )
Use Case Diagram Syntax ( NOTATIONS )
There are 4 major symbols in the use case diagrams: use cases, actors,
associations and system boundary. Therefore, there are more symbols about use
case relationship such as generalization or inheritance, include relationships and
exclude relationships to explain detail provisions required.
Use Case
Use case is represented as an eclipse with a name inside it. It may contain
additional responsibilities. It also describe a sequence of actions. Those actions
must provide the measurable value to an actor. Use case is used to capture
high level functionalities of a system. Example of use case as below :
Figure 2 : Use case
Actor
An actor can be defined as some internal or external entity that interacts with
the system. An actor is used in a use case diagram to describe the internal or external
entities.
Figure 3 : Actor
Association relationship
Associations or Communications specify the interaction described by a use
case. Basically it is represented by lines connecting between use cases and actors
with an optional arrowhead on one end of the line. It describes links an actor with the
use case which it interacts.
. .
Figure 4 : Association relationship
System Boundary
System boundary is the rectangle around the use cases. Everything within this
boundary is the functionality in scope of the system. System analysts and designers
must remember that interaction among actors is not shown in the use case diagrams.
Thus, the system boundary should re-examine if the interaction between actors is
essential to a coherent description of the desired behavior. Furthermore, actors are
formed based on the role we set. So, the different actors may actually be the same
person.
System Boundary
Figure 5 : System Boundary
Generalization Relationship
Generalization describes the inheritance relationship of the object-oriented
world. It is parent and child relationship. Generalization is represented by an arrow
with a hollow arrow head as shown in the following figure. One end represents the
parent element and the other end represents the child element. Generalization is used
to describe parent-child relationship of two elements of a system.
Figure 6 : Generalization or Inheritance
An Include relationship
Include is represent the inclusion of functionality of one use case within
another.In other words describe relationship between two use cases that are used to
show that the behavior of use case is inserted into behaviours, including use case .
The include relationship could be used: 1) to simplify large use case by splitting it into
several use cases, 2) to extract common parts of the behaviors of two or more use
cases. Include relationship between use cases is shown by a dashed arrow with an
open arrowhead from the including (base) use case to the included (common part) use
case. The arrow is labeled with the keyword «include».
«include»
Figure 7 : Include relationship
An extend relationship
Extend is a directed relationship that specifies how and when the behavior
defined in usually supplementary (optional) extending use case can be inserted into
the behavior defined in the extended use case.
The extension takes place at one or more extension points defined in the
extended use case. Extend relationship is shown as a line with an open arrowhead
directed from the extending use case to the extended (base) use case. The arrow is
labeled with the keyword «extend».
«extend».
Figure 8 : Extend relationship
2. LITERATION REVIEW
Atif A. A. Jilani, et al [2] present a survey of the existing Data Flow Diagram
(DFD) to Unified Modeling language (UML) transformation techniques. They analyze
transformation techniques using a set of parameters, identified in the survey. Based
on identified parameters, then they present an analysis matrix, which describes the
strengths and weaknesses of transformation techniques. It is observed that most of
the transformation approaches are rule based, which are incomplete and defined at
From comparison between DFD and UML, It is also observed from the literature review
that different analysts/designers have their own interpretation of different DFD
graphical symbols as DFD has informal syntax
Ido Millet, Robert Nelson [17] studied about Data Flow Diagrams versus Use
Cases – Student Perceptions found that they recently used both methodologies in
teaching eight sections of a required systems analysis course. Questionnaire results
indicate that students perceive these methodologies as equally easy to understand
and use. Students believe that data flow diagrams are better at communicating with
users and programmers.
Arwa [18] studied about the comparative study between data flow diagram and
use case diagram and found that both diagram have their own strength and weakness.
As a result conclude that DFD still powerful tools but difficult to understand because
there are many level or sub function whilst use case can be used as a first draft
between system analyst and user requirement.
For empirical studied done by Wang [18] performed an experiment using 32
undergraduate students with no previous systems analysis training or experience. The
subjects were randomly divided into two groups. One group was trained for five hours
on the data flow diagram (DFD) method, while the other group was trained for five
hours on an object-oriented analysis method. The subjects were then presented with
a mini-case in management information systems analysis. The 00 group spent
significantly less time on their analyses of the problem and created solutions that were
significantly more accurate. After completing the analysis, the subjects responded to
a questionnaire concerning their perceptions of the analysis method used. The 00
group reported that the OOA method was easier to learn and understand. The OOA
method was also rated superior overall. This study confirms the results of several
previously cited studies: OOA produces higher quality models more quickly than
procedural analysis.
3. METHODOLOGY RESEARCH
This paper is more about comparative study about DFD and UCD. The main
objectives of this study focuses on the comparison between DFD and UCD. So, the
target for this research to the people such as System Analyst And Design, developers,
businesses, architect etc. to understand and find out the detailed differences between
of them. Table 1 and 2 shows DFD and UCD syntax, while table 3 show the other
advantages and disdvantages between DFD and UCD.
4. RESULT AND DISCUSSION
From the explanation and the literation review was given about DFD and UCD
.Both of diagram are functional systems that interacted between user and system.
However here want to make discussion only for both diagram in order to know whether
both diagram has its own advantages, disadvantages and similarities or differences of
each other. From the studied, both diagrams have the main similarity such as identify
functional requirements. DFD is concerned with the flow of information/data and
processes in the system working with this information/data. It helps in identifying any
business processes or existing business processes, while use case is concerned with
defining about what the system has to offer to its users.
Advantages of data flow diagram:
For DFDs, there are many advantages and they provide a very important tool
for software engineering. DFD aids in describing the boundaries of the system. It is
beneficial for communicating existing system knowledge to the users. Because they a
straightforward graphical technique which is easy to recognise, DFDs can provide a
detailed representation of system components and very easier to understand by
technical and nontechnical audiences. Besides, it is used as the part of system
documentation file. It also supports the logic behind the data flow within the system
The technique of decomposition of high level data-flow diagrams to a set of more
detailed diagrams, provides an overall view of the complete system, as well as a more
detailed breakdown and description of individual activities, where this is appropriate,
for clarification and understanding.
Advantages of Use case diagram
Use cases provide some very clear benefits to the analysis phase. One
important benefit of use case driven analysis is that it helps manage complexity, then
it emphases on one specific usage aspect at a time. Use cases start from the very
simple viewpoint that a system is built first and foremost for its users [19]. Another
benefit of use cases is that they provide basic foundation for the requirements
document, user manual and test cases. Use cases also encourage designers to
predict outcomes before attempting to specify outcomes, and thereby they help to
make requirements more proactive in system development As a user orientation, use
cases help ensure that the correct system is developed by capturing the requirements
from the user's point of view. Use cases are a powerful technique for the elicitation
and documentation of black box functional requirements. Because they are written in
natural language, use cases are easy to understand and provide an excellent way for
communicating with customers and users.
Additionally, use case using tools like CASE to enable the system analyst to
help manage large projects with the help of interacting diagrams that match the
requirement of users. Use case naturally involve the collaboration of multiple objects
and classes, use cases help provide the rational for the messages that glue the objects
and classes together. Use cases also provide an alternative to the overemphasis of
traditional object-oriented development methods on such static architecture issues as
inheritance and the identification of objects and classes.
5. CONCLUSION
From the discussion, data flow Diagram is a graphic representation of a system.
It consists of data flows, processes, sources, destinations and stores. Data Flow
Diagram does not show the strict order of execution steps but it shows how processes
depend upon one another for information. Use Case Diagram shows some of the use
cases in your system, some of the actors in your system, and the relationships
between them. It shows what we want our system to do, but it does not explain the
way how those requirements can be accomplished.
Each of diagram displays a different aspect of some complex system. System
Analyst must realize that to effectively analysis the systems, they need to understand
the main information they got from each diagramming tool. One diagramming tool may
not enough for analyzing the system and they may require using various diagrams.
Also, it is important to remember that diagrams are documentations. It is a means of
communication between groups of human beings and needs to be understandable to
both senders and receivers.[20] What diagrams need to be develop depend on the
kind of system you are developing. For example, if the system you are analyzing has
complex functions but relatively trivial data structures, Data Flow Diagram will be the
best tool. However, in many cases of the real systems, they are required that system
analysts must be dealing with more than one diagramming tools.
6. REFERENCES
[1]
[2] Atif A. A. Jilani , Muhammad Usman, Aamer Nadeem, Zafar I. Malik , Zahid
Halim(2011), Comparative Study on DFD to UML Diagrams Transformations,
World of Computer Science and Information Technology Journal(WCSIT) Vol.
1, No.1,10-16, 2011.
[3] Object Oriented Approach available at https://www.tutorialspoint.com/system
_analysis_Design_object_oriented_approach.htm. Last seen 20 April 2019.
[4] Dennis, Wixom, Tegarden ( 2015 ) System Analyst and Design : An Object-
Oriented Approach with UML Fifth Edition, USA: Wiley
[5} Yourdon, Edward (1975). "Structured programming and structured design as art
forms". Proceedings of the May 19–22, 1975, National Computer Conference
and Exposition on - AFIPS '75: 277. doi:10.1145/1499949.1499997.
[6] Craig., Larman (2012). Applying UML and patterns : an introduction to object-
oriented analysis and design and iterative development (3rd ed.). New Delhi:
Pearson
[7] Lorenz, Mark( 1993 ). Object-Oriented Software Development: A Practical
Guide.Englewood Cliffs, NJ. PTR Prentice Hall
[8] Wikipedia available at https://en.wikipedia.org/wiki/Use_case_diagram Seen
April 20, 2019.
[9] Rob, P. Coronel, C. (2007), Database Systems: Design, Implementation, and
Management, Sixth Edition.
[10] Wikipedia available at https://en.wikipedia.org/wiki/Data_flow_diagram, last
seen April 2,. 2019.
[11]
[12] Elmasri, R., Navathe, S. (2002) Fundamentals of Database Systems, Forth
Edition
[13] Ed Yourdon – Just Enough Structured Analysis –
http://www.yourdon.com/strucanalysis/chapters/ch9.html, Last accessed
April 20, 2019.
[14] Use case diagram , available at http://en.wikipedia.org/wiki/Use_case_
diagram Last seen April 20, 2019.
[15] Elenburg, D. (2005). Use Cases: Background, Best Practices, and Benefits. An
MKS White Paper.
[16] Munassar, N. ; Govardhan, A. (2011) Comparison between Traditional
Approach and Object-Oriented Approach in Software Engineering
Development, IJACSA, International Journal of Advanced Computer Science
and Applications, Vol. 2, No. 6
[17] Millet & Nelson (2007 ). Data Flow Diagrams vs. Use Cases – Student
Perceptions, International Journal of Information and Communication
Technology Education , Volume 3, Issue 1
[18] Wang, S. "Toward Formalized Object-oriented Management Information
System Analysis," Journal of Management Information Systems, 12:4, Spring
1996, pp. 117-141.
[19} Lee, Jonathan and Nien-Lin Xue. Analyzing User Requirements by Use Cases:
A Goal-Driven Approach. IEEE Software. v.16 n.4 July/August 1999. p92-100
[20] System Diagram Essentials, http://www.jwrider.com/lib/DiagramEssential.htm
Last accessed 22 April , 2019.
Notation Function Symbol
External entity Represents a person or a group of
people outside the system, explain
where the information comes from and
where it will go
Process Represents the processes in the system.
It shows a part of the system that
transforms inputs into outputs
Data Flow represent the data flows. indicate
whether data or items are moving out
or into a process
Data store represent data stores, including both
electronic stores and physical stores.
Data stores is repositories of data in the
systems
7. APPENDIX
Table 1 : DFD Notation ( Source : Yourdon and Coad Gene Sarson )
Table 2 : Use Case Notation ( Source Wiley Fifth edition )
ADVANTAGES
Data Flow Diagram Use Case Diagram
It aids in describing the boundaries Use case help to capture the functional
of the system. requirements of a system.
It is beneficial for communicating Use cases are traceable.
existing system knowledge to the Use cases can serve as the basis for the
users. estimating, scheduling, and validating
A straightforward graphical effort.
technique which is easy to Use case can evolve at each iteration from a
recognise. method of capturing requirements, to
DFDs can provide a detailed development guidelines to programmers, to
representation of system a test case and finally into user
components. documentation.
It is used as the part of system Use case alternative paths capture
documentation file. additional behavior that can improve
DFDs are easier to understand by system robustness.
technical and nontechnical Use cases have proved to be easily
audiences understandable by business users, and so
It supports the logic behind the have proven an excellent bridge between
data flow within the system. software developers and end users
Table 3 : Comparison on Advantages and Disadvantages
DISADVANTAGES
DataNotation
Flow Diagram Function Use Case Diagram Symbol
It make the programmers little They do not capture the non-functional
confusing concerning the system. requirements easily.
Actor Person or of
The biggest drawback a group
the DFDof people
is outside
There might be a learning curve for the
that it simplythe system
takes a long time to developer and/or specially, the client in
Use case create, so long that the analyst
Fuction of the system using these use cases.
may not receive support from
management to complete it.
Physical considerations
Association Link an actorarewith
leftthe use case
out.
relationship
DFD partitions system into a set of
hierarchical functions which can
not be seamlessly
System boundary implemented
Includes the names of as the system insde
objects in object oriented
or on top
languages Represent the scope of the system
Generalization/ Represent a specialized use case Patient
Inheritance
Old New
An Include Represent the inclusion of the «include»
relationship functionality of one use case within
another
An extend Represent the extension of the use «extend».
relationship case to include optional behavior
.