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

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. UML Meta -data summarization ………………………….. ………………………….. …………………….. 12
2.2.2. XMI Parse r ………………………….. ………………………….. ………………………….. …………………….. 13
2.2.3. Transformation and traversal algorithm ………………………….. ………………………….. ………….. 14
2.3. Activity diagram syntax validation ………………………….. ………………………….. …………… 17
2.3.1. Validation rules ………………………….. ………………………….. ………………………….. ………………. 18
2.4. Activit y diagram quality validation ………………………….. ………………………….. ………….. 18
2.4.1. Validation rules ………………………….. ………………………….. ………………………….. ………………. 19
3. Implementation for validation tool ………………………….. ………………………….. ……………….. 20
3.1. General overview of implementation ………………………….. ………………………….. ………… 21
3.2. Development phases of Java application ………………………….. ………………………….. …… 21
3.2.1. Analysis and design ………………………….. ………………………….. ………………………….. ………… 22
3.2.2. Implementation ………………………….. ………………………….. ………………………….. ………………. 22
3.2.3. Testing ………………………….. ………………………….. ………………………….. ………………………….. . 22

3
3.3. An illustrated scenario ………………………….. ………………………….. ………………………….. .. 22
3.4. Evaluation ………………………….. ………………………….. ………………………….. ………………… 22
Conclusion and future work ………………………….. ………………………….. ………………………….. …… 23
References ………………………….. ………………………….. ………………………….. ………………………….. …. 24

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 scenarios 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 scenarios . 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
scenarios , 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 represented by fork, respectively join bars
and they are more complex than infinite loops. Fork nodes leads to threads that are executing
independently and m ay result 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 activity diagram.

2.2. Transformation of XMI representation into internal graph
2.2.1. 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:
 Compact – should include only necessary information;
 Adequate – should include all necessary information.

13
First, we identified the most important elements that help to describe the activity diagram, such as
activities, control flows, object flows and swimlanes, then t heir 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 state 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 of 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 node / d estination 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 – origin of t he 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 a ctivities execution
 Activity nodes – the list of activity nodes for which execution is responsible.
2.2.2. XMI Parser

First step of the validation process is to parse the UML activity diagram already converted into an
equivalent XMI representation. The XMI -stand ard (XML Metadata Interchange) adopted by the
Object Management Group (OMG) can be used as a model interchange format for the Unified

14
Modeling Language ( UML ) because it provides a complete description of object oriented models
[108] .
There are many tools that can convert an UML diagram into XMI representation, for example, we
used the opensource StarUml application. In order to get all the necessary information from the
XMI representation into our UML meta -data summarization, we perform several transformat ions.
After the first time the parser goes through the document, the summarization is almost done, but
wihout linking the connections between the nodes and transitions. In order to fulfill the
summarization and to link the connections be tween the nodes and transitions, we just need to go
through the list of control flow already saved.
The XMI parser extracts the action st ates, decisions, fork nodes, join nodes and swimlanes and the
corresponding tra nsistion and guard information and stores them in the meta -data summarization
and connect the transitions with the linked nodes . After the summar ization is completed and linked,
the tool analyzez the syntax of the activity diagram and generates all possible scenarios t hat the
system can have using path coverage criteria.

2.2.3. Transformation and traversal algorithm

In the following, we describe the algorithm required for activity diagram graph traversal. The
algorithm should ensure that the execut ion trace crosses at least once all the transitions present in
the activity diagram graph. This means that for every edge ∈ ADG (Activity Diagram Graph) we
can find at least one program execution trace as activity diagrams represent the implementation of
an operation and we can check all possible issues and quality models .
First we initialize the stack in order to keep the trace of the execution flow to find all the possible
scenarios with the initial state of the activity diagram and validate the syntax of it.
traverseActivityGraph (ADG)
begin
//initialize data
DFSStack = ∅, pathScenario s = ∅,

15
visitedTransitions = 0, total Transitions = ADG.getControlFlow().size();
node = {ADG.getInitialNode()}
DFSStack.push(node );
repeat
if node is of type FINAL
then we build the path scenario and go back to last path separation
elseif node is of type FORK
then //we traverse concurrent flows and then we peek the node from the top of the DFSStack to go
forward
traverseConcurrentFlows( DFSStack , node);
node = DFSStack .peek( );
else
Transition destinationEdge = get Prioritized DestinationEdge(node);
if destinationEdge. visits = 0
then visitedTransitions = visitedTransitions + 1;
endif
destinationEdge.visits = destinationEdge.visits + 1 ;
node = de stinationEdge.getDestinationNode ;
DFSStack .push(node);
endif
until totalTransitions = visitedTransitions
end
When a fork node is found, we start to traverse the concurrent flows between the fork node and
join node or final node. Because there could be another fork node into the first one, we handled
this situation by making it a backtracking function ( traverseConcurren tFlows ). The process continue
to trace the execution until all the concurrent transitions are visited . After visiting a join node, our
approach checks if all entering activities are synchronized or not. If not, then the next activity
initiated at fork is v isited according to the priority criteria until a full path is completed.
traverseConcurrentFlows( DFSS tack, forkNode) {
begin

16
exitEdge = getPrioritized DestinationEdge (forkNode);
if exitEdge .visits = 0
then visitedTransitions = visitedTransitions + 1;
endif
exitEdge .visits = exitEdge .visits + 1;
previousNode = forkNode ;
node = exitEdge.getDestinationNode;
maxTransitions = 500, transitionsNumber = 0;
while ( transiti onsNumber++) < maxTransitions
if node is of type JOIN
then
visitPr eviousEntry( node, previousNode );
if all incoming concurrent flows that was initiated at fork are synchronized
then
DFSS tack.push(node);
return;
endif
exitEdge = getPrioritized DestinationEdge (forkNode);
elseif node is of type FINAL
DFSStack.push(node);
return;
elseif node is of type FORK
DFSS tack.push(node);
traverseConcu rrentFlows( DFSStack , node);
joinNode = DFSStack .peek() ;
exitEdge = getPrioritized DestinationEdge (joinNode);
else // continue the thread flow until we get to join or final node
DFSStack .push(node );
exitEdge = getPrioritized DestinationEdge (node);
endif

17
if exitEdge .visits = 0
then visitedTransitions = visitedTransitions + 1;
endif
exitEdge .visits = exitEdge .visits + 1;
previousNode = node ;
node = exitEdge.getDestinationNode ;
endwhile
if transitionsNumber > maxTransitions
then printf ( Invalid control flow inside fork node )
endif
end
After applying the algorit hm described above, we will traverse all the transitions and nodes of the
activity diagram graph and we will ge t the list of possible improvements of the diagram and the
whole list of scenarios of the system behaviour . Each scenario is identified by the st ack trace from
the initial state to the final one.

2.3. Activity diagram syntax validation

The syntax of the UML activity diagr ams has several limitations. The activity diagram elements
are composed of transitions, nodes and swimlanes. The nodes represent processes or process
control, including action states, decisions, forks and joins. The transitions are marked with the
arrows a nd represent the control flow of activities. Swim lanes enable the activity diagram to group
activi ties based on who is performing them and subdivide activities based on the responsibilities
of some components. An activity is a state with an internal action and one or more outgoing
transitions which automatically follow the termination of the intern al activity. In order to validate
the activity diagram that we already have been transformed, certain validation rules must be taken
as stated in UML 2.0 definitions [101] .

18
2.3.1. Validation rules

 Initial state need to start with a single action ;
 The initial state must be unique ;
 Final states must have 0 destination states ;
 Action states must have at least 1 source state and 1 destination state ;
 Decision nodes must have 1 source state and at least 2 destination states ;
 Merge nodes must have at least 2 source states and 1 destination state ;
 Fork nodes must have 1 source state and at least 2 destination states ;
 Join nodes must have at least 2 source states and 1 destination state ;
 For every fork node must be a join node pair;
 Each control flow leaving the decision node must have a guard ;
 The number of incoming concurrent flows must be synchronized correctly ;
 All nodes should have at least one incoming edge and at least one destination edge, except
initial and final states;
 Every decision nod e opened after the initialization of a fork node must be me rged.

2.4. Activity diagram quality validat ion

Testing is an important part of quality assurance in the software life -cycle. As the complexity and
size of software systems grow, it’s more difficult to manual observe different issues or possible
improvements. In the case of specifications, use case models and activity diagrams have been
found most useful for verifying and validating requirements . In this section, we formally described
some rules that can detect possible fault -prone in eariler releases or earlier like cycle phases. This
type of softw are analysis can also find different indicators of potential problems that the manually
wouldn’t be hard to observe or it would simple go un noticeable . This validation isn ’t required by
the UML validation syntax, but it will get the developer ’s attention and will prevent the potential
problems.

19
2.4.1. Validation rules

 Action states should not have similar names ;
 Each guard of an decision node must be unique ;
 Each swimlane must have a name and be unique in that specific activity diagram;
 Every thread must be finished;
 The number of t ransistions over the swimlanes shouldn ’t be disproportionated ;
 The number of nodes over the swimlanes shouldn ’t be disproportionated;
 If the operation would have too many concurrent actions would lead the system to
performance issues.

20
3. Implementation for validation tool

This is the chapter dedicated to the practical application of the theoretical concepts defined in the
previous chapters . The approach presented in this paper have been imp lemented into a tool
prototype ADVT ( Activity Diagram Validation Tool ) whic h validates activity diagrams exported
as XMI files and generates all possible scenarios paths that helps the user to have a better
understanding and a bigger picture of how the system works or should wo rk. The UML Activity
Diagram can be developed using any UML tool such as StarUML or MagicDraw and then can be
converted into an equivalent XMI representation by exporting it as a XMI file . We have used the
opensource StarUml application to develop and export the activity diagram.
Figure 4 gives an overview of the grammar -driven approach to UML Activity Diagram validation.
The remainder of this section will elaborate on the various stages of the approach an d provide a
brief introduction to the tools and technologies used at each step.

Figure 4 – Architecture of the va lidation aproach

21
3.1. General overview of implementation

Activity Diagram Validation Tool is a web application developed with Spr ing Framework . We
choosed web application to the detriment of desktop application because of the flexibility and
increased accessibility that the web applications offer s.
The tool parses the provided XMI activity diagram file and generates activity diagrams summaries
which contains model quality aspects or requirements analysis, test scenarios that cover s all paths
that the system behavior could have or in case the diagram isn ’t valid, it throws an adequate
message. By comparing the system execution traces with the activity diagram, the application
provides the test cases that will satisfy the con sistency of the system.

3.2. Development phases of Java application

To formally begin the software development proc ess, this project will be spl it into standard phases
normally recognised as the Waterfall Model as described in figure 5 .

Figure 5 – Software development life cycle

22
Initially, time will be spent to decide upon the project Requirements analysis. Build ing on these
requirements, an architectural and user interface Design will be defined before the project moves
into the Implementation phase. The application will further be tested in the Testing phase, and
Maintenance will be not be explicitly performed .
3.2.1. Analysis and design
3.2.2. Implementation
3.2.3. Testing
3.3. An illustrated scenario
3.4. Evaluation

23
Conclu sion and future work

1page

24
References

[1] Rumbaugh J., Jacobson I., Booch G. The unified modeling language Reference manual Second
Editio n, Pearson Education, Boston, 2004.
[2] ***, UML Activity Diagrams , http://www.agilemodeling.com/artifacts/activityDiagram.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 , National 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 Collabo rations ,
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, Month 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, 2001
[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 Facility Specification, version 1.3.1, OMG document 01 -11-02.

25
[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