SUMMARIZATION OF XML ACTIVITY DIAGRAMS Oros Adriana Oana, group 258 Abstract The Unified Modeling Language ( UML ) has increased in co mple xity over… [602975]

22.12.2016
1
SUMMARIZATION OF XML ACTIVITY DIAGRAMS
Oros Adriana Oana, group 258
Abstract
The Unified Modeling Language ( UML ) has increased in co mple xity 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 can be used in different p urposes like model quality aspects or
requirements analysis .
General Terms
Software Engineering
Keywords
Unified Modeling Language , Activity diagrams summariza tion, Program verification
1. Introduction
With the expansion of this software area, for software dependent organizations has appeared
the need of reducing the software maintenance ac tivities 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 developers . These step s 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 universal language standard for software developers worldwide . It provides
architecture running on systems analysis and design objects with appropriate language for
specifying, visualizing, constructing and documenting the artifacts of systems sof tware . [1]
However , the created UML models can easily lead to inconsistencies which are hard to detect
manually .

22.12.2016
2
In this paper we investigate UML activity diagrams that are a partic ular 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, including in design models
like activity diagrams should be found and corrected as early as possi ble because after the system
is going live it may be hard and expensive t o correct them . This means that the ac tivity diagram
can be inconsistent or incomplete or it doesn ’t respect the requirements. This res earch proposes a
tool that summarize the XML activit y diagrams into models and validate s their link connection s.
An UML diagram can be converted very easily into an XMI file with different tools and plugins .
For example , 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.
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 pro posed system, the
activity diagrams summaries definitions and the verification steps . Section 4 points to the related
work . Section 5 summarizes the conclusions of our paper and discusses some further work.

2. Overview of activity diagrams
Activity diagrams 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 in clude ramification, parallel flow , swimlanes etc. 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:
 Action states (activity states ) – are defined by the oval elements and represents the
action developed within a task ;
 Initia l state – is defined by the simple black point and it ’s the entry point in to the
respective activity . The initial state is unique and always starts a with single action ;

22.12.2016
3
 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 act ivity diagram can be more than one exit points;
 Control flow – is defined by the arrow and r epresents the transition from one action to
another ;
 Decision /Merge nod e – is defined by the diamond shape ;
 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 transitions that entering the synchronization bar
have been t riggered ( join).

Figure 1- Activity diagram of a n online shopping system

22.12.2016
4
3. Summarization
This section presents our approach that is perfor med in four big steps . The first step is
represented by the XML parsing and UML models summarization . The second one deals with the
activity diagram syntax validation, the third one with graph transformations and the last step is
represented by the activity diagram as a graph verification. An overview of our approach is
described in the Figure 2.

Figure 2 – Steps overview

3.1. UML models summarization
In order to build our system, we have to perform several steps and the first step implies creation
of meta -models for Activity Diagram by parsing the XML file . We have proposed eight classes
based on activity diagrams description given in the Section 2:
ActivityDiagram – This class represents the activity diagram entity .
Node – This class has a single attribute – type and represen ts an activity diagram node. This class
it’s inherited by ActivityState , InitialState , Final State , DecisionNode , MergeNode and
BarNode .
Activity State – This class represents the action state and it’s composed by the following attributes:
actionName ( identification attribute and must be unique and can ’t be empty ), entryNode and
exitNode (the actions that are before a nd after the current one ).

22.12.2016
5
InitialState – This class represents the initial state of the activity diagram.
Final State – This class points to the final state of the activity diagram.
DecisionNode – This class points to the dec ision node and has a name, an entryNode and two
exitNodes as attributes .
MergeNode – This class represen ts merge node and has a name, an exitNode and two entryNodes
as attributes .
BarNode – This class represents a fork or join bar and it has two attributes: entryNodeList and
exitNodeList.

3.2. Syntax validation
The first type of validation of an act ivity diagram happens at the second step and here we check
if all nodes are correct or not. A node is incorrect if the current act ion has already been taken in a
previous step or there is a node that should have another action tak en but it isn ’t. If a single node
is incorrect , the tool returns a negative answer.

3.3. Graph transformation
In our tool we have transformed the activity diagram into a graph in order to continue our
validation. The main concept of this transformation is to simplify the activity diagram by removing
the intermediate levels between actions nodes which are : decision nodes, merge nodes, fork nodes
and join nodes .
To create a new control flow by removing join a nd merge nodes, it requires to look over every
incoming edge of the nodes and to map them to the new type of entity node that will have as
attributes a name, a list of entry nodes, a list of exit nodes and a list of adjacent edges for that node .
For removing decision and fork nodes, it requires the inspection of every exit node and to add them
in the l ist of exit nodes of their entry node in the new entity . Also, we save t he list of edges which
has objects with the following attributes : name , enabled , list of start nodes and list of end nodes.

22.12.2016
6
3.4. Validation rules
In order to validate the activity diagram that we already have been transformed , certain
validation rules must be taken. As we put every node in the queue starting with the initial node,
we need to enable every current edge from the list of edges. The edge will be enabled only if it s
start nodes are active.
First validation rule is that all activity nodes must be consistent . Two nodes are inconsi stent if
one of them happens the get to another node while the last one it’s still active .
The second rule is that the graph must be stable. The graph is stable if there is no enabled edge
and the queue of action nodes is empty.

4. Related work
There have been several articles about UML diagrams validations [5, 6, 7], but few for activity
diagrams [8]. However, Eshuis presents two different translations from activity diagrams
(requirements -level translation and implementation -level translation ) and he’s experiment shows
that even larger activit y diagrams can be successfully checked with requirements -level translation ,
but with implementation -level translation is not so efficient .

5. Conclusion and future work
In this paper, we proposed a summarizat ion tool that verify XML Activity D iagrams . We
parsed the XML activity diagrams and created a virtual activity diagram composed by me ta-
models. We verified if the diagram has syntax or se mantic issues, including loops by generating a
graph with the given activity diagram descriptions . The possibility to verify this kind of issues
could promot e activity diagrams and its usefu lness in a big project .
In the future, we want to verify the XML Activity Di agram 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 sy stem.

22.12.2016
7
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.agil emodeling.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 Lan guage Summaries for Java Classes , National Science Founda tion (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 Comput ing 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 .