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

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
The Unified Modeling Language (UML) has increased in complexity over the years and became
a standard for object -oriented software development. This papers proposes a tool that allows
developers, but especially software architects and requirements analysts to validate the integrity
and quality of XML activity diagrams in an automatically way. This tool generates activity
diagrams summaries that ca n be used in different purposes like model quality aspects or
requirements analysis.
This work is the result of my own activity. I have neither given no r received unauthorized
assistance on this work.

General Terms
Software Engineering
Keywords
Unified Modeling Language, Activity diagrams summarization, Program verification

2
Table of contents

Introduction ………………………….. ………………………….. ………………………….. ………………………….. … 4
1. Activity diagrams ………………………….. ………………………….. ………………………….. ……………… 6
1.1. Overview of a ctivity diagrams ………………………….. ………………………….. …………………… 7
1.2. Syntax of activity diagrams ………………………….. ………………………….. ………………………. 8
1.2.1. Activities and flows ………………………….. ………………………….. ………………………….. ………… 10
1.2.2. Parallel activities ………………………….. ………………………….. ………………………….. …………….. 10
1.2.3. Swimlanes ………………………….. ………………………….. ………………………….. ……………………… 11
2. UML Activity Diagrams transformation ………………………….. ………………………….. ………. 12
2.1. Overview of suggested approach ………………………….. ………………………….. ……………… 12
2.2. Transformation of XMI representation into internal graph ………………………….. ………. 13
2.2.1. UML Meta -data summarization ………………………….. ………………………….. …………………….. 13
2.2.2. XMI Parser ………………………….. ………………………….. ………………………….. …………………….. 14
2.2.3. Transformation and traversal algorithm ………………………….. ………………………….. ………….. 15
2.3. Activity diagram syntax validation ………………………….. ………………………….. …………… 18
2.3.1. Validation rules ………………………….. ………………………….. ………………………….. ………………. 19
2.4. Activity diagram quality validation ………………………….. ………………………….. ………….. 19
2.4.1. Validation rules ………………………….. ………………………….. ………………………….. ………………. 20
3. Implementation for validation tool ………………………….. ………………………….. ……………….. 21
3.1. General overv iew of implementation ………………………….. ………………………….. ………… 22
3.2. Development phases of Java application ………………………….. ………………………….. …… 22
3.2.1. Requirements analysis ………………………….. ………………………….. ………………………….. ……… 23
3.2.2. Design ………………………….. ………………………….. ………………………….. ………………………….. . 24
3.2.3. Implementation ………………………….. ………………………….. ………………………….. ………………. 27

3
3.2.4. Testing ………………………….. ………………………….. ………………………….. ………………………….. . 28
3.3. An illustrated scenario ………………………….. ………………………….. ………………………….. .. 28
3.4. Evaluation ………………………….. ………………………….. ………………………….. ………………… 29
Conclusion and future work ………………………….. ………………………….. ………………………….. …… 30
References ………………………….. ………………………….. ………………………….. ………………………….. …. 32

4
Introduc tion

The dissertation focuses on automatic identification of the missing quality aspects by UML activity
diagrams validation
With the expansion of this software area, for software dependent organizations has appeared the
need of reducing the software maintenance activities cost and time. These issues can be solved if
the analysis and design phase of a project are performed before the code writing in order to get the
attention from various de velopers. These steps have been ignored in the past, but now the
importance of these phases is recognized because it have been proved that they lead to a better and
reusable software project. [4]
Unified Modelling Language (UML) is not a simple object -oriented modeling language, but
currently is the standard universal language for software developers worldwide. It provides
architecture running on systems analysis and design objects with appropriate language for
specifying, visualizing, constructing and docu menting the artifacts of systems software. [1]
However, the created UML models can easily lead to inconsistencies which are hard to detect
manually.
In this paper we investigate UML activity diagrams that are a particular case of state diagrams
which are not describing a stream of event -based control, but instead they describe a procedural
one, in which the majority of transitions or even all of them are performed automatically on
completion of actions taken within states. [2] Errors in UML models, includi ng in design models
like activity diagrams should be found and corrected as early as possible because after the system
is going live it may be hard and expensive to correct them. This means that the activity diagram
can be inconsistent or incomplete or it doesn’t respect the requirements. This research proposes a
tool that summarize the XML activity diagrams into models and validates their link connections.
An UML diagram can be converted very easily into an XMI file with different tools and plugins.
For ex ample, we used StarUML v2.8 open source tool with XMI plugin in order to convert the
UML diagrams. This tool have support for Linux, Windows and MAC systems and many others
plugins.

5
The rest of the paper is structured as follows. Section 2 starts with some semantics and syntax of
activity diagrams. Section 3 introduces our perspective specifying the proposed system, the
activity diagrams summaries definitions and the verification steps. Section 4 points to the related
work. Section 5 summarizes the conclusi ons of our paper and discusses some further work.

6
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 b uild 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 diagram s are representations of a process, a system or their 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 aro und the major groups of elements that can be found 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

7
 Interaction Diagram s that are represented by the following types of diagrams:
o Sequence Diag ram
o Communication D iagram
o Timing D iagram
o Interaction 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 activity 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 syst em. An activity diagram is a particular type of behavioral 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 no t sufficiently
expressive. The usefulness of activity 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 sequenc e 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
activit y diagram would be simpler to create and to understand.
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

8
system to anot her. 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 ele ments 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 poin t 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 on e exit points;
 Control flow – is defined by the arrow 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 m ultiple 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 t ype of transition used in each of the possible outputs of
a decision node . It is defined as a text within two square brackets above the arrow that
connects two nodes;

9
 Bar (fork/join bar) – it is used for cases in which certain actions can take place in par allel
(fork) or for the cases when all transitions 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 acto r or thread.

Figure 1 – Activity diagram of an online shopping system

10
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 transitions.
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 indepen dent 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. Thi s 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 sho ws that the online shopping system uses the concurrency 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.

11
1.2.3. Swim lanes

Swimla nes are used in UML diagrams for representing more 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 vert ical 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 e xample, the shopping system could have the following swimlanes
illustrared in figure 2: customer, sales and stockroom.

Figure 2 – Shopping system with swimlanes

12
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 -model 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 a ctivity diagram as an XML -based Metadata Interchange (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 diagra m graph is traversed using depth first
search (DFS) 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 system. 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 o nce.

13

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/transit ion prioritization based on the visit number of 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 may 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 th e 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.

14
First, we identified the most important elements that help to describe the activity diagram, such as
activities, con trol 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 diag ram 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 o f 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 / 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, i f it exits
 Source id of the node – origin 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 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 a n
equivalent XMI representation. The XMI -standard (XML Metadata Interchange) adopted by the
Object Management Group (OMG) can be used as a model interchange format for the Unified

15
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 transformations.
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 transistion and guard information and stores them in the meta -data summarization
and connect the transitions with the linked nodes. After the summarization is completed and linked,
the tool analyzez the syntax of the activity diagram and generates all possible scenarios that 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 execution 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 = ∅,

16
visitedTransitions = 0, totalTr ansitions = 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 f lows 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 f ork 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 ( traverseConcurrentF lows). 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 vis ited according to the priority criteria until a full path is completed.
traverseConcurrentFlows( DFSS tack, forkNode) {
begin

17
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(no de, 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
DFSS tack.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 f low until we get to join or final node
DFSStack .push(node );
exitEdge = getPrioritized DestinationEdge (node);
endif

18
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 algorithm described above, we will traverse all the tran sitions and nodes of the
activity diagram graph and we will get the list of possible improvements of the diagram and the
whole list of scenarios of the system behaviour. Each scenario is identified by the stack trace from
the initial state to the final one .

2.3. Activity diagram syntax validation

The syntax of the UML activity diagrams has several limitations. The activity diagram elements
are composed of transitions, nodes and swimlanes. The nodes represent processes or process
control, including action state s, decisions, forks and joins. The transitions are marked with the
arrows and represent the control flow of activities. Swim lanes enable the activity diagram to group
activities based on who is performing them and subdivide activities based on the responsi bilities
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 internal activity. In order to validate
the activity diagram that we already have been transf ormed, certain validation rules must be taken
as stated in UML 2.0 definitions [101] .

19
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 hav e 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 destina tion 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 co rrectly ;
 All nodes should have at least one incoming edge and at least one destination edge, except
initial and final states;
 Every decision node opened after the initialization of a fork node must be merged.

2.4. Activity diagram quality validation

Testing i s 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 ac tivity 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 software analysis c an 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 preven t the potential
problems.

20
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 numb er of transistions 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.

21
3. Implementati on 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 implemented into a tool
prototype ADVT (Activity Diagram Valida tion Tool) which 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 work . The UML Activity
Diagram can be d eveloped 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 giv es 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 and provide a
brief introduction to the tools and technologies used at each step.

Figure 4 – Architecture of the validation aproach

22
3.1. General overview of implementation

Activity Diagram Validation Tool is a web application developed with Spring Framework . We
choosed web application to the detriment of desktop applicati on 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, tes t 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 s atisfy the consistency of the system.

3.2. Development phases of Java application

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

Figur e 5 – Software development life cycle

23
Initially, time will be spent to decide upon the project Requirements analysis. Building on these
requirements, an architectural and user interface Design will be defined before the project mov es
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. Requirements a nalysis

Requirements analysis is the initial part of requirements engineering that have the a ssignment of
“determining the needs or conditions to meet for a new or altered product, taking account of the
possibly conficting requirements of the various stakeholders, such as benefciaries or users” as
noted in [110].
In order to identify the require ments of this tool we should answer the following question “What
the application should do?”. Since the price of correcting an error after the system was released is
usually very high, the design models like activity diagram should be complete and with any errors.
Because manually would be hard to observe the error or it would simple go unnoticeable , it’s
needed a tool that will check automatically the quality of the diagram and generate all the possible
cases that the system could have. So the critical req uirements of this tool are to check the quality
models and possible improvements of the provided activity diagram, to generate all the possible
scenarios of the system behavior without exaggerating the number of path combinations, and the
last requirement is to validate the syntax of the activity diagram. Other requirements like securit y
of the application or other extra functionalities aren’t needed because that ’s not the goal of this
master’s thesis .
The hardware and software requirements rel ate to the building, compiling and use of ADVT tool
in terms of the hardware and software used . The application is written in Java , fact that ensures its
processor architecture portability and so runs on every operating system . To create the project
structure and automate library dependencies, ADVT uses Apache Maven. The application is
configured to work with two servers, Apache Tomcat and Jetty , to have a more flex ibility and the
possibility to be easily extended. Both Tomcat and Jetty open source and offer high performance
for web application, supporting HTTP server, HTTP client and the javax.servlet container. The
recommended minimum versions are 6.1.25 for Jetty and 7 for Apache Tomca t. Running the

24
application with Jetty is done by: mvn clean install jetty:run execution in the command line,
and for tomcat mvn clean install tomcat7: run or by configuring it and adding the war
application file to the configured loca tion webapps directory. To display correctly the content of
the application, the browser must support jQuery .
3.2.2. Design

After the requirements analysis phase, the design section will begin to build upon the requirements
in ord er to define the overall system architecture that will be applied to ADVT. In addition to this,
this section is used to describe the application structure and the user interface design.
Activity Diagram Validation Tool is developed with Spring MVC (Model View Control) using
REST architec tural style which is a standard for building web services on the web because they’re
easy to build and easy to consume .The biggest advantage of using Spring Framework is because
of dependency injection which, as well, has several advantages like: responsib ility separation,
loosely couple architecture, the code is separated by the configuration, and because of that, using
configuration, a different implementation can be supplied without changing the dependent code
[111] . The request handling architecture of ADVT is illustrated in figure 6.

Figure 6 – Request handling architecture

25
As described in figure 6, the controller class is responsible for the request handling and it doesn’t
contain business logic. The s ervice classes represen ts the logic of the application, being responsible
for activity diagram validation and traversion engine , and at the level of pr esentation, the user
interface, which consists of JSP pages, uses the controllers to manipulate user requests .
Figure 7 illustr ates the ActivityDiagramValidationTool class diagram. This diagram describes the
structure of the system by presenting classes and relationships between them. In order to maintain
a certain visibility, the entities, attributes and operations, except privat e ones, respectively
protected, were not included in the diagram . The main class with the most business logic of the
application, ADVServiceImpl, represents the engine of our approach. The ADVService
implementation is responsible with activity diagram inte rnal graph traversal, getting the
summarization from StarUMLParser implementation that parse the provided file, and creating the
execution scenarios with the help of ASVTextCreationService.
The User Interface of any application is highly important, so desi gning a wellconstructed and
thoughtful UI is imperative. Because the application doesn’t have many functionalities, and the
main focus of the Activity Diagram Validation Tool is intented to validation, the user interface
should be simple and very easy to u se and to provide enough information to the user.

26

Figure 7 – Activity Diagram Validation Tool Class diagram

27
3.2.3. Implementation

To this point the project has provided a foundation for the third phase of the software development
cycle , the implementation phase of ActivityDiagramValidationTool. This extensive requirements
and design process allowed us to imp lement the proposed application.
Rather than covering each element of the implementation in its entirety, greater attention has bee n
paid to the key areas that were either problematic, or otherwise interesting. The main challenges
of implementing ADVT project are discussed and recommendations are naturally derived, which
will be covered in detail in Chapter 3.4 – Evaluation.
The propo sed idea was implemented in Java language, version 1.8 with Spring MVC Framework
on the server side and JSP and Jquery on the client side and perform REST calls to the server. It
allows the code to be separated by the configuration and supply a different implementation without
changing the dependent code at any time . An algorithm analyze the source file, transform it and
get the desired data following the described algorithm and steps from Chap ter 2.2.3
(Transformation and traversal algorithm ).
The system user interface is designed in the Eclipse project, the first page beeing index.jsp, which
is returned to the correspondin g JSP page by the ADVController . To make the user interface design
more dynamic and user -friendly, it was built with Boostrap and JQuery using AJAX methods to
perform asynchronous HTTP request s to the server. Figure 8 shows the user interface design for
an invalid activity diagram input file.

Figure 8 – User interface with error message

28
The security part is missing because the authentification step or the possibility of different types
of users in order to access the functionalities of this tool wasn ’t a requirement . However, even if
it wasn ’t the scope of this thesis, the implementation of the application with the Spring MVC
Framework and using MCV pattern will play a signifi cant role in further reengineering and
analysing process , simplifying the process of increasing the application or making it an API server
adding new fu nctionalities.
3.2.4. Testing

In order to verify and validate ActivityDiagramValidationTool meets the specification and delivers
the expected functionality, a nu mber of testing mechanisms have been applied . We need to verify
if the application meets the initial requirements and p erforms efficiently .
The requirements verification process aim s to ensure that an application conforms to its original
specification . Since the origina l requirements are actually represented by the algorithm described
in the above chapter, they are fulfilled.
Performance test involves the evaluation of system per formance under normal and heavy
conditions as a result of various users and a large data volum e in order to ensure the system
security, reliability, and execution efficiency, and find out feas ible methods to maintain a good
system performance. In the Web -based application testing, pe rformance test adds load to the server
with requests by simulating a large number of user operations .
3.3. An illustrated scenario

In this scenario analysis the user will validate an activity diagram XMI file with ADVT application.
The UML activity diagram is presented in figure 9, and a part of the co rresponding XMI file is
described in figure 10.

After the user added the XMI file and pushed the button “Submit ”, the results with the quality
models and generated scenarios are displayed in figure 11.

29
3.4. Evaluation

30
Conclu sion and future work

Regarding the research work and the scientific contributions that have been presented in this
dissertation, we were able to draw some conclu sions, which are now mentioned. We consider that
the thesis sta tement presented in Chapter 2 was successfully proven, as this dissertation addresses
several research issues related to reverse engineering, design recovery, and program understanding
for activity d iagrams validation and scenario generation .
In this paper, we proposed a summarization tool that verify XML Acti vity Diagrams. We parsed
the XMI activity diagrams and created an internal activity diagram graph composed by meta -data
models. We verified if the diagram has syntax or semanti c issues, including loops and concurrency
issues by generating a nd traversing the inernal graph with the provided activity diagram
descriptions. The possibility to verify this kind of issues could promote activity diagrams and its
usefulness in a big project. UML diagrams are considered as defacto standard for development
models and this verification tool has facilitated a possible future for the software development .
This is a first improvement which is achieved by means of a few simple and safe optimisations.
Further optimisations are possible and they are subject of our future research. In the future, we
want to verify the XMI Activity Diagram against the documentation with the natural language
specifications. This will bring a new type of validation for developers to have a better
understanding of the system. We also consider the possibility to validate other ty pes of UML
diagrams in order to grow the tool functionalities .
There have been several articles about UML diagrams validations like class diagrams and
statechar t diagrams [5, 6, 7], and a few for activity diagrams [8, 112 , 113 ]. Eshuis [8] presents two
different translations from activity diagrams (requirements -level translation and implementation –
level translation) and he’s experiment shows that even larger activity diagrams can be success fully
checked with requirements -level translation, but with implementation -level translation is not so
efficient. Mingsong, Xiaok ang and Xuandong [112] used UML activity diagrams to present some
test case g eneration as well. Their approach generates test cases for a Java program and they are
comparing them with the given activity diagram.

31
Even if our work is comparable with previous approaches, our method has a few distinct features.
Unlike above approach es, we have taken in consideration the quality validation of the activity
diagrams which will promote the lack of issues in the future projects because it will detect more
faults. Another difference that should be point out is that the execution is totally automated without
manual work and even if Nanda , Mohapatra and Swain have considered the fork -join complication
too, they haven ’t though about more complicated scenarios like a fork node into an already fork –
join pair. Ou r approach covers that scenario , thus it will reduce the probability of issues and can
save the t esting cost .

32
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/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 g eneration 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, 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.

33
[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
[110] Gerald Kotonya and I. Sommerville. Requirements engineering: processes and techniques.
Worldwide series in computer science. J. Wiley, 1998.
[111] http://spring.io
[112] C. M ingsong, Q. Xiaokang, and L. Xuandong, “Automatic Test CaseGenerat ion for UML
Activity Diagrams”, AST’06, May 23, 2006,Shanghai, China
[113] Generation of Test Scenarios Using Activity Diagram , P. Nanda, D. P. Mohapatra and S.
K. Swain , Proceedings of SPIT -IEEE Colloquium and International Conference, Mumbai, India ,
pag 69-73, 2008