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
of the system.
 It is beneficial for communicating
existing system knowledge to the
users.
 A straightforward graphical
technique which is easy to
recognise.
 DFDs can provide a detailed
representation of system
components.
 It is used as the part of system
documentation file.
 DFDs are easier to understand by
technical and nontechnical
audiences
 It supports the logic behind the
data flow within the system.
Table 3 : Comparison on Advantages and Disadvantages
 Use case help to capture the functional
requirements of a system.
 Use cases are traceable.
 Use cases can serve as the basis for the
estimating, scheduling, and validating
effort.
 Use case can evolve at each iteration from a
method of capturing requirements, to
development guidelines to programmers, to
a test case and finally into user
documentation.
 Use case alternative paths capture
additional behavior that can improve
system robustness.
 Use cases have proved to be easily
understandable by business users, and so
have proven an excellent bridge between
software developers and end users

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
.