School of Computing and Information

Technology

A FRAMEWORK FOR TRANSFORMING ARTIFACTS FROM DATA FLOW

DIAGRAMS TO UML

Thu Nga Tran

Khaled M. Khan
Yi-Chen Lan

{khaled, yichen}@cit.uws.edu.au

TECHNICAL REPORT NO.: CIT/04/2004

2004 IASTED International Conference on Software Engineering

Innsbruck, Austria
2004
 A FRAMEWORK FOR TRANSFORMING ARTIFACTS FROM DATA FLOW
DIAGRAMS TO UML
Thu Nga Tran Khaled M. Khan Yi-Chen Lan
School of Computing and Information Technology, University of Western Sydney
Locked Bag 1797, Penrith South DC, NSW 1797
Australia
{Khaled, yichen}@cit.uws.edu.au

Abstract and IEEE workshops on program comprehension. Most

papers on this topic focus on program transformation
This work proposes a framework for transforming data from one programming language to another. Very few of
flow diagrams (DFD) into UML artifacts. The framework them address the methodological aspect of the
is a systematic step-by-step approach that enables systems transformation which could aid the understanding of the
analysts and designers to achieve the transformation. process at much lower level of the design process. Our
Many existing legacy systems were designed using work reported in this paper addresses the design level of
structured analysis and design methodology (SAD). Some the transformation from DFD to UML. We developed a
of these legacy systems need to be re-designed and re- step-by-step methodological approach which is based on
produced using object-oriented analysis and design the hierarchical aspects of the design features. We found
(OOAD) method to make the system more maintainable. that it is vital to understand how various design features
We show that a transformation should be done at three are organized in a hierarchy in a particular design
abstraction levels. We have demonstrated the applicability paradigm. We first classify the design elements of DFD
of our framework with a simple case study. into three abstraction layers based on their
interrelationship with each other. We do this to make
Key Words transformation into the corresponding UML features.
The paper is organized as follows. The next section
Design transformation, UML, data flow diagram, entity presents the framework to transform DFD into UML. A
relationship, class diagram, sequence diagram. case study is cited using the proposed framework in
section 3 to demonstrate the applicability of the
framework. Finally, the paper concludes in section 4.
1. Introduction
Software systems always tend to change and evolve as 2. The Framework for Transformation
technology and business rules change. Evolution of
information systems is unavoidable, and it is a natural The proposed transformation framework uses a phase-
phenomenon. Organizations need to support systems based approach. There are three abstraction levels in our
evolution to take advantage of the new technology and to transformation framework. Various elements of DFD are
address the changing business rules. The evolutionary step by step transformed to UML design features at three
nature of software products, in fact, leaves us with two different levels of abstractions keeping the design
options: either maintain the products with their continual information intact. Figure 1 presents the general view of
changing nature, or accept the degrading performance of three abstraction levels of our transformation framework.
the product [4]. In this ever-increasing competitive The shaded rectangles in the figure represent two different
business environment, the latter one would hardly be an methodologies.
option for most enterprises. Software systems designed
with structured design methodology do not support some Abstraction level 1 deals with the highest level of the
of the desired quality attributes such as reusability, and abstraction hierarchy. DFD in SAD is partially mapped
portability [3]. Many large organizations find that systems into use case diagram and components of class diagram in
designed with structured approaches are less reusable and UML. In SAD, DFD reformulates the problem from the
less maintainable than those designed with object-oriented real world into abstract concepts in terms of data flow and
approaches. processing. DFD generally provides a broader
Many research results on software reverse engineering representation of a software system from a process point
have been published in various forums, in particular, of view. Hence, DFD coverage is very broad that cannot
IEEE International conferences on software maintenance be transformed directly into a UML representation.
Abstraction level 2 deals with the transformation of data operations/methods of classes. Again, data
flow. This is where the interactions between objects are flow from or to data store is addressed in the next
presented. abstraction level. These three abstraction levels are
described in details in the following subsections. Table 1
Abstraction level 3 is the conversion of ERD (entity shows the transformation of DFD features into UML
relationship diagrams) to design class diagram. The representations with examples at the abstraction level 1.
mapping from ERD to design class diagram is the finale
stage in the transformation process. Table 1. Abstraction level 1
TABLE SA&D OOA&D
Figure 1. Three abstraction levels of the transformation Component Process Use Case
framework. Example Record Payment, Update Customer Master
Component External Entity Actor
Example Customer, Bank
Component Data Store Class
Example Customer, Bank, Customer Master
Component Data Flow Remained unsolved

2.2 Abstraction Level 2

The abstraction level 1 addresses the transformation of
main components of DFD into UML components. At this
stage, use case diagram and class diagram are
worked out. The entire artifact of the system in SAD is
reproduced in a different way in OOAD. The use case
diagrams and class diagrams (converted from
DFD) roughly represent the conceptual design of the
entire system. Data flow is considered as the bridge
between various SAD components, and can be presented
in five variations:
(i) external entity-to-process;
(ii) data store-to-process,
(iii) process-to-data store;
(iv) process–to-external entity; and
2.1 Abstraction Level 1 (v) process-to-process.

The process defined in DFD representing a function is Table 2 illustrates the transformation of data flow of DFD
transformed into use case defined in UML. The to UML
external entities and data stores connected to Table 2. Abstraction level 2
the processes are transformed into actors and SAD OOAD
classes respectively. The external entity in DATA FLOW VARIATIONS UML
DFD has similar characteristics as of an actor in UML. External entity -to-process Interaction diagram
Data store-to-process (sequence diagram /
The data flow between a process and an collaboration diagram)
Process-to-data store
external entity in DFD represents the relationship Process-to-external entity
between a use case and an actor in UML. The data Process-to-process State transition diagram
flow from a process to an external entity has
quite a different characteristic than the relationship The first four types of data flow can be transformed
between a use case and an actor. The transformation into sequence diagrams (interaction diagrams).
of data flow is discussed in the next section. As Data which flows from process to external
mentioned earlier about the broad coverage of DFD, entity or data store or vice versa in DFD can be
data store is transformed into class which is not represented as messages which are sent from one object to
included in the use case diagram. Part of the data another in the sequence diagram. The sequence
store is transformed into attributes of the class. diagram represents the interactions between objects in a
This is the highest abstraction level; hence class obtains use case. In another words, sequence diagram is
all attributes (data at rest) from data store to constructed for a particular function of the system.
show the static structure of data in class diagram. All Therefore it is broad enough to cover all information
processes associated with a particular data store contained in a data flow. Interaction diagrams capture
(e.g., the dataflow that connects external entity – process the flows of data in terms of messages passed between
– data store) are transformed into objects. Interaction diagrams such as sequence diagrams,
collaboration diagrams in UML represent dynamic model when an event occurs. These changes go through different
of the system. Abstraction level 2 is the middle level in states to show the behavior of the system. An event is a
the abstraction hierarchy of our transformation significant or noteworthy occurrence [2]. An event occurs
framework. The transformation of four variations of data to change the system, for instance, from state 0 to state 1.
flows is slightly different each other. We now discuss The example cited in Figure 4 shows the transformation
each of these in turn. of data flow from process-to-process in DFD into
Data flow from external entity to state transition diagram in UML. The figure
process or from data store to process in shows that the flow of data from a process P1.0 to
DFD can be transformed into sequence diagram in another process P2.0 has been transformed into a state
similar way. An external entity or a data in the transition diagram. The data flow DF1 is transformed into
data store may become a class instance. For object1, process P1.0 becomes state1, and P2.0 is
example, Customer (external entity) becomes transformed into a termination of the state diagram.
:Customer (Class Customer Instance). Data flow from
external entity/data store to process Figure 3. Transformation of data flow to sequence
becomes an object which may be sent from the class diagram
instance to the system as a parameter in the message. As
shown in Figure 2, data flow DF1 is transformed into
Object1 as a parameter in the message1() in UML.
Similarly, external entity E1 becomes ClassE1 Instances.
That means, message1(object1) passes object1
instance from :ClassE1 Instance to the :System.
This transformation is depicted in Figure 2.

Figure 2. Transformation of data flow to sequence

diagram
Data flow variation (process-to-process) happens very
often in SAD as shown in figure 5. It is noted that the
event (in state transition diagram) from one state to
another is not an exact representation of any component in
DFD.

Figure 4. Transformation of data flow to state transition

diagram

Data flow from process-to-external entity or

from process-to-data store can be transformed
into sequence diagram in similar way. An
external entity or a data store becomes a
class instance. Data flow from a process to
external entity/data store becomes an object
which is sent from the system to a class instance as a
parameter of the message. The process becomes the In DFD, components (process, external entity, and data
message which passes the object from the system to the store) are connected to each other through data flows
class instance. In Figure 3, data flow DF1 flows from the which are not the same as the relationship between use
process P1.0 to data store D1 in DFD. In UML, the cases and actors in the use case diagram. If there are
process P1.0 is transformed into message1() , data relationships between a process and an external entity or
flow DF1 becomes Object1 used as a message data store in DFD, those can become relationships
parameter and data flow D1 becomes class Instance between use case and actor in use case diagram. As
:ClassD1 Instance. This transformation is depicted mentioned earlier, in DFD it is possible to make data flow
in Figure 3. from process to process. There is no such provision in
The last variation of the data flow is process-to- UML to make relationship between two use cases.
process. Data flow between processes can be However, it is possible in some exceptional situation,
represented through a series of state changes in state where the <<use>> relationship of use case can be
transition diagram. State transition diagrams applied. This is where one use case initiates or uses the
capture the change of states of an object or a use case behavior of another use case.
 Figure 5. A transformation of data flow into state Figure 6. The proposed methodology transformation
transition diagram framework

DFD PORTION
Receive Generate
Customer Order
Customer Customer
Order Receipt

STATE TRANSITION DIAGRAM

initial state:
"Receive
Customer
Order"

In Store

checkOut( Item ) checkIn( CustomerOrder )

Checked Out

checkIn( Item )

For Sale

The entire framework is summarized in Figure 6. The

sold( Item )
right hand column shows the abbreviation used in the left
end state: hand column.
"Generate Customer Receipt"

3. Case Study
2.3 Abstraction Level 3
The case study we discuss in this section is an inventory
Entities in ERD are transformed into classes in design system called Hoosier Inventory Control System. This
class diagram. Attributes of the entities become properties case study is used to illustrate the applicability of the
of the corresponding classes. Relationships that connect proposed transformation framework from DFD to UML.
one entity to another are transformed into methods of the Figure 7 cites the DFD for Hoosier Inventory Control
corresponding classes. Table 3 lists the transformation System.
rules.
3.1 Case study: Level 1 transformation
Table 3. Abstraction Level 3
SAD OOAD In the first level of the abstraction, Hoosier DFD [1] is
Component Entity Class analyzed and converted into use case diagram. Table 4
Associated entity Association presents the transformation of each component in DFD
Example Sales – Item Sales – Product - Invoice – into UML.
Component Attribute Attribute/
Identifier attribute property
After the analysis, these components are put into use case
Multi-valued attribute diagram as shown in Figure 8. Note that external entity
Example Sale_Date, Receipt_No, Prod_ID, Prod_Desc “Stock on Hand” and data store “Inventory” can be
Component Relationship Operation/ transformed into “Classes” with corresponding attributes
method/ and operations in “Class Diagram”.
association
Example Sell(), Order(), Receive()
3.2 Case study: Level 2 transformation

The relationship in ERD has two different types which are This level transforms the data flows into sequence
“Is a part of” relationship (aggregation) and “Is diagrams. Data flows in DFD fall into following
a” relationship (generalization). The relationships are the variations: process to external entity (Orders, Payments,
same as the “associations” in design class diagram. Query Result); external entity to process (Invoices,
Another aspect in ERD is cardinality. This is similar to Counts, Request); Process to data store (Amount Added,
the “multiplicity” in the design class diagram. Amount Used, Query); data store to process (Inventory
Levels, Minimum Order Quantities).
 Figure 7 Data flow diagram for Hoosier’s Inventory Figure 8. Use case diagram for Hoosier’s Inventory
Control System (Source: Hoffer, George and Valacich Control System (ICS)
[1]) ICS

Update Inventory Used

Storeman
in charge of
"Stock On Hand"
See note below *
Update Inventory Added

Store
Generate Order Co-ordinator
Supplier
manages all
"Inventory" activities
(See note below **)

Query Inventory Levels

Generate Payment Manager

System Boundary

Sequence diagram in UML represents dynamic models of

interactions between objects. Messages which are sent Figure 9. Sequence diagram for use case “Update
from one object to another defined in sequence diagram, Inventory Added”
in fact, could represent data flows from one component to
Supplier System Inventory
another (e.g., process to external entity) in DFD. As
sequence diagram is developed for each use case, there
are four sequence diagrams (not included all) for Hoosier 1: generateInvoice
(Invoices)
Inventory Control System as shown in Figures 9 to 12.
2: updateInventory
These are: (1) Update Inventory Added, (2) Update (AmountAdded)
Inventory Used, (3) Generate Orders, and (4) Query
Inventory Levels. Some data flows related to these
processes are presented in those four sequence diagrams.

Table 4. Transformation from SAD to OOAD

Figure 10. Sequence diagram for use case “Update
SAD OOAD
Inventory Used”
Process Use Case
Stock-On-Hand System Inventory
Update Inventory Added
Update Inventory Used
Generate Orders
Generate Payments 1: check
Query Inventory Levels Stock(Counts)
External Entity Actor
Supplier
Manager 2: updateInventoty
Stock-On-Hand Used(Amount
Data Store Class Used)
Inventory
Data Flow -
Addressed at the Abstraction Level 2
 Figure 11. Sequence diagram for use case “Generate Figure 14. Class diagram for Hoosier Inventory Control
Orders” System
Inventory System Supplier
Sales Invoice
Sale_Date Invoice_No
1: checkInventory
Receipt_No Vendor_ID
(InventoryLevels)
Invoice_Date
sell( ) Paid
2: selectOrder (Min
OrderQuantities) 1 include( )

3: generateOrders sells 1
(Orders) 1..*
include
Item Sale 1..*
Quantity_Sold Invoice Item
Quantity_added
sold( )
order( ) receive( )
0..* 0..*
is received for
order
1
Figure 12. Sequence diagram for use case “Query
1 Inventory Item
Inventory Levels” Product Item_ID
Manager System Inventory
Prod_ID Item_Desc
Prod_Desc Item_Type
Quantity_In_Stock
1: generateRequest
order( ) Min_Odered_Quantity
(Request)

1..* receive( )
2: queryInventory
Levels(Query)
1..*
3: check
Inventory(Inventory
Levels) 1 1
Recipy
4: respond
Request(Query Quantity_Used
Result)

data stores to classes; and from external entities to actors.

Data flow consists of five variations which are
transformed into various artifacts of UML at the
Figure 13. ERD for Hoosier Inventory Control System abstraction level 2. All data flow variations are
transformed into sequence diagrams. At the abstraction
level 3, ERD is mapped into a design class diagram.
Based on three abstraction levels of the proposed
framework, DFD elements are step by step transformed
into components of UML. We acknowledge that the
proposed framework does not address the detail in-depth
issues of the transformation; nevertheless it lays the initial
foundation for such a methodology.

References
[1] Hoffer, J.A., George, J.F. and Valacich, J.S., “Modern
System Analysis and Design”.Prentice Hall. New Jersey,
2002.
3.3 Case study: Level 3 transformation [2] Wessels, D.M., Sloane, A.M, and Sommerville, I., “Software
Design”. URL available:
The ERD of the system is cited in Figure 13. It has been http://engr.uark.edu/~wessels/softw/fall99/notes/design.html
transformed into class diagram as shown in Figure 14. . View on 20 September 2002.
[3] Charnick, E.J.,. “Object-Oriented Methods”. URL available:
http://userpages.umbc.edu/~echarn2/cs445/#AD. View on 20
4. Conclusion September 2002.
[4] Khan, K., et al., “Tasks and Methods of Software
Our transformation framework is based on three Maintenance: A Process Oriented Framework”, Australian
abstraction levels. At the first level, DFD components are Journal of Information Systems, Vol. 9-1, September 2001,
transformed into UML representations. Basically, the pp. 51-60.
transformation is done from processes to use cases; from