BABEȘ -BOLYAI UNIVERSITY CLUJ -NAPOCA FACULTY OF MATHEMATICS AND COMPUTER SCIENCE SPECIALIZATION SOFTWARE ENGINEERING DISSERTATION THESIS UML… [602554]

BABEȘ -BOLYAI UNIVERSITY CLUJ -NAPOCA
FACULTY OF MATHEMATICS AND COMPUTER
SCIENCE
SPECIALIZATION SOFTWARE ENGINEERING

DISSERTATION THESIS
UML ACTIVITY DIAGRAMS
VALIDATION TOOL

Supervisor
PhD . Simona Motogna
Author
Adriana Oana Oros

2017

1
Abstract

Max 1 pag

2
Table of contents

Introduction ………………………….. ………………………….. ………………………….. ………………………….. … 4
1. Activity diagrams ………………………….. ………………………….. ………………………….. ……………… 5
1.1. Overview of activity diagrams ………………………….. ………………………….. …………………… 6
1.2. Syntax of activity diagrams ………………………….. ………………………….. ………………………. 7
1.2.1. Activities and flows ………………………….. ………………………….. ………………………….. ………….. 9
1.2.2. Parallel activities ………………………….. ………………………….. ………………………….. ………………. 9
1.2.3. Swimlanes ………………………….. ………………………….. ………………………….. ……………………… 10
2. UML Activity Diagrams transformation ………………………….. ………………………….. ………. 11
2.1. Overview of suggested approach ………………………….. ………………………….. ……………… 11
2.2. Transformation of XMI representation into internal graph ………………………….. ………. 12
2.2.1. XMI Parser ………………………….. ………………………….. ………………………….. …………………….. 12
2.2.2. UML Meta -data summarizatio n ………………………….. ………………………….. …………………….. 12
2.2.3. Transformation and traversal algorithm ………………………….. ………………………….. ………….. 14
2.3. Activity diagram syntax validation ………………………….. ………………………….. …………… 14
2.3.1. Validation rules ………………………….. ………………………….. ………………………….. ………………. 14
2.4. Activit y diagram quality validation ………………………….. ………………………….. ………….. 14
2.4.1. Validation rules ………………………….. ………………………….. ………………………….. ………………. 14
3. Implementation for validation tool ………………………….. ………………………….. ……………….. 15
3.1. General overview of implementation ………………………….. ………………………….. ………… 15
3.2. Development phases of Java application ………………………….. ………………………….. …… 15
3.2.1. Analysis and design ………………………….. ………………………….. ………………………….. ………… 15
3.2.2. Implementation ………………………….. ………………………….. ………………………….. ………………. 15
3.2.3. Testing ………………………….. ………………………….. ………………………….. ………………………….. . 15

3
3.3. An illustrated scenario ………………………….. ………………………….. ………………………….. .. 15
3.4. Evaluation ………………………….. ………………………….. ………………………….. ………………… 15
Conclusion and future work ………………………….. ………………………….. ………………………….. …… 16
References ………………………….. ………………………….. ………………………….. ………………………….. …. 17

4
Introduc tion

The dissertation focuses on au tomatic identification of the missing quality aspects by UML activity
diagrams validation

1 & 1/2 pag

5
1. Activity diagrams

Unified Modeling Language (UML) is an object -oriented modeling language considered standard
by software developers worldwide . UML is a language of graphical representation that can be used
for: modeling business processes, a representation describing the architecture of a system,
capturing system behavior modeling data structures or to build a detailed specification of a system.
The representation is done using standard UML elements: graphical symbols and diagrams.
Symbols are elements that are found within each kind of diagram and are of type connectors,
actors, classes , etc. The diagrams are representations of a process, a system or t heir component
parts.
Within UML are defined the following types of diagrams that are divided into two major
categories: structure diagrams and behavior diagrams [101] .
Structural diagrams are organized around the major groups of elements that can be foun d in system
architecture modeling . This category includes :
 Class Diagram
 Object Diagram
 Package Diagram
 Component Diagram
 Deployment Diagram
 Composite Structure Diagram
 Profile Diagram
Behavioral diagrams shows the behavior of the system and are generally used to describe its
functionality . This category includes:
 UseCase Diagram
 Activity Diagram
 State Machine Diagram

6
 Interaction Diagram s that are represented by the following types of diagrams:
o Sequence Diagram
o Communication D iagram
o Timing D iagram
o Interact ion overview D iagram

1.1. Overview of activity diagrams

Activity diagram is a UML diagram that describes the importance of the dynamic aspects of the
system . They are used mainly as a flow graph that consists of activities performed by the system,
but activi ty diagrams aren’t flow graphs because they have some additional capacities. These
additional capacities include ramification, parallel flow, swimlanes etc. The activity can be
described as an operation system. An activity diagram is a particular type of b ehavioral diagrams
and it shows the flow of activity sequences and is usually used to describe the work carried out an
operation .
Activity diagrams are used when the other behavioral modeling diagrams are not sufficiently
expressive. The usefulness of acti vity diagrams is observed in any of the following situations:
 When a class contains complex operations that require several steps to be taken, activity
diagrams are useful to present those steps as a sequence of activities ;
 When we need a high level system view. Activity diagrams can be used also in business
process modeling , not just in modeling software operations. Through them we can show
who performs some activities , what decisions should be made and what documen ts are
generated in the process. So this kind of diagram can have a greater impact on
understanding the business details more than the implementation details ;
 When a usecase behavior is too complex and require multiple sequence diagrams, an
activity diagram would be simpler to create and to under stand.
Activity diagram s are also suitable for workflow system modeling. An applica tion can have
multiple systems and an a ctivity diagram captures these systems and describes the flow from one

7
system to another. This specific use is not available in other diagrams . These systems can be
database, external queues or any other system .

1.2. Syntax of activity diagrams

Activity diagram describes the system behavior with elements of implementation. The most
important elements of an activity diagram are activities, control flows and object flows .
Figure 1 gives an example of activity diagram that describes the workflow of an online shopping
management system. [2] As showed in the Fig.1, there are different types of elements in an activity
diagram :
 Activity states – are defined by the oval elements and are the main element s of a activity
diagram representing the action s developed within a task;
 Initial state – is defined by the simple black point and it’ s the entry point into the respective
activity . The initial state is unique and always starts with a single action ;
 Final state – is defined by the circle with a black point in the middle and it’s the exit point
of the activity. Into a activity diagram can be more than one exit points;
 Control flow – is defined by the a rrow and represents the transition from one action to
another;
 Decision/Merge node – is modeled as a diamond shape. A decision involves selecting,
based on certain conditions, a flow of control of a set of multiple streams of control . Each
of control flows leaving the diamond is labeled with a guard shown between two brackets.
The same notation is used for merge flows (in which case the conditions are no longer
required );
 Guard (condition) – it is a special type of transition used in each of the possible ou tputs of
a decision node . It is defined as a text within two square brackets above the arrow that
connects two nodes;

8
 Bar (fork/join bar) – it is used for cases in which certain actions can take place in parallel
(fork) or for the cases when all transition s that entering the synchronization bar have been
triggered (join);
 Swimlanes – are notated with parallel lines, either horizontal or vertical and their role is to
group activities performed by the same actor or thread.

Figure 1 – Activity diagram of an online shopping system

9
1.2.1. Activities and flows

An activity or an activity state represents a step in the execution of an algorithm , a process or a
step in a process which is described as a coordinated flow of actions . Each operation , seen as a
chain of actions may be detailed in elementary operations. Activities are defined by a rounded
rectangle with their description or name in the middle.
UML Activity Diagram have two types of flows: Control flow and Object flow. Control flows
indicate the order in which activities are performed. A control flow is defined by an arrow that
connects two activities and reprents the beginning of the destionation activity immediately after
the completion of the source activty . They are also named transi tions.
Object flows indicates that an action requires an object as input or returns an object after its
execution. Object flows are definted by an arrow with dotted lines that connects an activity and an
object. The following figure shows the objects used for activities associated with accounting
applications.

1.2.2. Parallel activities

Parallel (asynchronous) activities are actions that can run in parallel. In real life, these actions are
actions that are independent of each other . In UML , the concurrency is represented by a short bar,
vertical or horizontal. If one control flow leads to such a bar , then two or more transitions are
triggered once the transition corresponding control flow entering is completed. This is called a
fork bar. Likewise , if in one bar enters multiple transitions and just one control flow exits, the
transition of the last control flow occurs only if all control flows entering were completed. This
type of bar is named join bar.
Figure 1 shows that the online shopping system uses the concu rrency after the order confirmation
is finished in order to send the bill to the customer and ship the order. Once that both activities are
completed, the application can check the payment.

10
1.2.3. Swim lanes

Swimlanes are used in UML diagrams for representing mor e accurately the elements that are
responsible for activities execution by setting every action on the corresponding lane of the actor
that is executing that action. One lane is either a horizontal or a vertical region (band) , delimited
by parallel lines, which indicate s the element that has the responsibility to perform activities
located in this region. The lane is labeled with the element name responsible for performing the
activities includ ed in it . For example, the shopping system could have the follow ing swimlanes
illustrared in figure 2: customer, sales and stockroom.

Figure 2 – Shopping system with swimlanes

11
2. UML Activity Diagrams transformation

This chapter presents our approach of UML activity diagrams validation. We used the activity
diagrams as XMI files . The XML -based Metadata Interchange (XMI) is an interchange format for
metadata that is defined in terms of the Meta Object Facility (MOF) standard [108] . Since the
adopted UML specification defines the UML meta -mode l as a MOF meta -model, XMI can be used
as a model interchange format fo r UML. This allows UML modeling tools to use XMI to exchange
UML models [109] .
2.1. Overview of suggested approach

Our approach parses the activity diagram as an XML -based Metadata Intercha nge (XMI) file and
generates activity diagrams summaries that can be used in different purposes like model quality
aspects or requirements analysis, but also it generates test scenarious in order to cover all paths
that the system behavior could have for a better understanding of how the system would work .
The firs t step is represented by the XMI parsing and UML meta -data summarization that leads to
an internal graph . While the new transformed activity diagram graph is traversed using depth first
search (D FS) method and its transitions as thread traces until we reach to a final state, we keep the
execution flow into a stack in order to find all the possible sce narious. Every step of the flow is
checked against syntax validation rules and quality validation rules that are exemplified in the
following sections. A basic overview of our appro ach is described in the Figure 3 .
By an activity diagram scenario we understand a path from the initial state to a final state that
represents one linear execution of the sy stem. Because an activity diagram could have several
scenarious, we need to cover all the possible paths of it using depth first search method until we
visit all the transitions in the internal graph at least once.

12

Figure 3 – System overview

The main complexity of activity diagram graph traversion is given by loops, thread concurrency
and synchronization. This approach handle the infinite loops through the destionation
edge/transition prioritization based on the visit number o f the transition and a strategy of completed
loop mark. Thread concurrency and synchronization are given by fork, respectively join nodes and
they are more complex than infinite loops. Fork nodes leads to threads that are executing
independently and may re sult in infinite loops if not treated correspondently along with their pair.
If a path isn’t consistent, that means that it couldn’t reach to a final state or its trace contains invalid
activities, then the execution trace isn’t consistent so neither the a ctivity diagram.

2.2. Transformation of XMI representation into internal graph
2.2.1. XMI Parser
2.2.2. UML Meta -data summarization

In order to define an activity diagram graph we need to make an UML Meta -data summarization
that will corespond to certain criterias:
 Compac t – should include only necessary information;

13
 Adequate – should include all necessary information.
First, we identified the most important elements that help to describe the activity diagram, such as
activities, control flows, object flows and swimlanes , then their attributes and role. After the
summarization the following elements will be used as basis for defining an activity diagram (all
elements have an id and name) :
 ActivityDiagram – represents the activity diagram entity
 Initial node – the initial st ate as a node;
 Lanes – the list of the swim lanes of the activity diagram;
 Activity nodes – all the nodes included in the activity diagram;
 Control flow – the list of transitions.
 ActivityNode – represents the node of the activity diagram
 Type – the type o f the activity node: initial state, final state, action state, decision
node, merge node, fork node or join node;
 Entry edges – the transitions or arrows that entry into the node / source transitions;
 Exit edges – the transitions or arrows that exit the no de / destination transitions;
 Lane – the swimlane of which the node belongs.
 Transition – represents the control flow of the activity diagram, i.e., every arrow between
two different nodes and the associated guard, if it exits
 Source id of the node – origi n of the arrow;
 Destination id of the node – destination of the arrow;
 Guard – the associated guard;
 Visits – the number of visits per transition;
 Completed – if all the destination nodes are completed .
 SwimLane – represents the element that is responsible for activities execut ion
 Activity nodes – the list of activity nodes for which execution is responsible .

14
2.2.3. Transformation and traversal algorithm

2.3. Activity diagram syntax validation
2.3.1. Validation rules

2.4. Activity diagram quality validation
2.4.1. Validation rules

15
3. Implementation for validation tool

3.1. General overview of implementation
3.2. Development phases of Java application
3.2.1. Analysis and design
3.2.2. Implementation
3.2.3. Testing
3.3. An illustrated scenario
3.4. Evaluation

16
Conclu sion and future work

1page

17
References

[1] Rumbaugh J., Jacobson I., Booch G. The unified modeling language Reference manual Second
Edition , Pearson Education, Boston, 2004.
[2] ***, UML Activity Diagrams , http://www.agilemodeling.com/artifacts/activityD iagram.htm
[3] ***, UML Activity Diagrams , https://msdn.microsoft.com/en -us/library/dd409465.aspx
[4] L. Moreno, J. Aponte, G. Sridhara, A. Marcus, L. Pollock and K. Vijay -Shanker , Automatic
Generation of Natural Language Summaries for Java Classes , Nation al Science Foundation (CCF –
0845706, CCF -1017263,and CCF -0915803), 2013.
[5] Wafa Chama, Raida Elmansouri and Allaoua Chaoui, Model checking and code generation for
UML diagrams using graph transformation , International Journal of Software Engineering &
Applications (IJSEA), Vol.3, No.6, Algeria, 2012, pp.39 -55.
[6] Schafer T., Knapp A. and Merz S., Model Checking UML State Machines and Collaborations ,
Electronic Notes in Theoret ical Computer Science 47, Paris, France, 2001, pp.1 -13.
[7] Mikk, E., Lakhnech Y. and Siegel M., Hierarchical Automata as Model for Statecharts , Proc.
3rd Asian Computing Science Conf., Lect. Notes Comp. Sci. 1345, 1997, pp. 181 –196.
[8] Eshuis R., Symbolic Model Checking of UML Activity Diagrams , ACM Journal Name, Vol. V,
No. N, Mon th 20YY, Eindhoven, Netherlands .
[9] Bill Evjen, Kent Sharkey, Thiru Thangarathinam, Michael Kay, Alessandro Vernet, Sam
Ferguson. Professional XML , Wiley Publishing, Indianapolis, 2007
[10] Brett McLaughlin. Java and XML 2nd Ed., O'Reilly, Sebastopol, 20 01
[11] Brian Benz, John R. Durant. XML Programming Bible , Wiley Publishing, New York, 2003
[101] ***, UML Diagrams, http://www.uml -diagrams.org/uml -25-diagrams.html
[108] OMG: Meta Object Fa cility Specification, version 1.3.1, OMG document 01 -11-02.

18
[109] Kovse J., Härder T., Generic XMI -Based UML Model Transformations , Proc. 8th Int.
Conf. on Object -Oriented Information Systems, Springer -Verlag , Germany, 2002, pp. 192 -198