Enhancement of Action Description Language for UML Activity Diagram Review

Enhancement of ADL for
Activity Diagram Review
March 19th, 2013
Chinnapat Kaewchinporn
Department of Computer Engineering,
Software Engineering

Outline
• Introduction
• Action Description Language
• Automation of Activity Diagram Review
• Demonstration
• Evaluation
• Conclusion

Introduction
EnhancementSolutionProblem

Introduction
Problem
• The Unified Modeling Language (UML) is becoming a
standardized modeling notation for expressing the
object-oriented model, and a widely used design tool in
software development.
• For quality and standardization in the design, the UML
Specification has been defined by the Object
Management Group (OMG) for controlling the semantics
and notation of UML.

Introduction
Problem
• However, for large and complex systems, manually
creating UML diagrams with graphic notation is error-
prone and may cause data and behavior inconsistency.
• In addition, software engineers may misunderstand the
semantics and notation, resulting in the diagrams
nonconformance to UML specification.

Introduction
Solution
• Kotb and Katayama [1] proposed a novel XML
semantics approach for checking the semantic
consistency of XML document using attribute
grammar techniques.
• Shen et al. [2] implemented a toolset which could
examine both static and dynamic aspects of a model.
The toolset was based on the semantic model using
Abstract State Machines presented in [3].
[1] Y. Kotb and T. Katayama, “Consistency Checking of UML Model Diagrams Using the XML Semantics Approach”. th international conference on World Wide Web,
(2005), May 10-14; Chiba, Japan.
[2] W. Shen, K. Compton, and J. Huggins, “A Toolset for Supporting UML Static and Dynamic Model Checking”. 26th International Computer Software and Applications
Conference on Prolonging Software Life: Development and Redevelopment, IEEE Computer Society, (2002), August 26-29; Oxford, English.
[3] Y. Gurevich, “Sequential Abstract State Machines Capture Sequential Algorithms”. ACM Transactions on Computational Logic, vol. 1, no.1, (2000), pp.77-111.

Introduction
Solution
• Flater et al. [4] proposed human-readable Activity
Diagram Linear Form (ADLF) for describing activity
diagrams in text format.
• Narkngam and Limpiyakorn [5], [6], [7] introduced a
preventive approach to rendering valid activity
diagrams with a domain specific language called
Action Description Language (ADL).
[4] D. Flater, P.A. Martin, and M.L. Crane, “Rendering UML Activity Diagrams as Human-Readable Text”. Proceedings of the 2009 International Conference on Information and Knowledge Engineering, (2009),
July 13-16; Las Vegas, United States.
[5] C. Narkngam, Y. Limpiyakorn, “Rendering UML Activity Diagrams as a Domain Specific Language - ADL”. th International Conference on Software Engineering and Knowledge Engineering, (2012),
July 1-3; San Francisco, USA.
[6] C. Narkngam, Y. Limpiyakorn, “Designing a Domain Specific Language for UML Activity Diagram”. 4th International Conference on Computer Engineering and Technology, (2012), May 12-13; Bangkok, Thailand.
[7] C. Narkngam and Y. Limpiyakorn, “Domain Specific Language for Activity Diagram”, Ramkhamhaeng Journal of Engineering, vol. 1, (2012).

Introduction
Enhancement
• In this research, the enhancement of the Action
Description Language invented in [5], [6], [7] is carried
out to verify existing activity diagrams whether they
conform to the UML specification version 2.4.1.
• Currently, the prototype developed in this work can
merely inspect the activity diagrams created by
ArgoUML and Modelio due to the restriction caused by
the variations of the XMI format generated by different
UML tools.

Introduction
Enhancement
• This research work could be useful for software
process improvement as the automation of reviews
would lessen defects and resources consumed during
software development.

Action Description Language
• Action Description Language (ADL) is a domain specific
language used for creating activity diagrams that conform
to UML specification.
• The design of ADL covers four elements required to
constitute a DSL: structure, constraints, representation,
and behavior.
• The ADL metamodel (Figure 1) illustrates the language
structure consisting of Element, Object, Relation, Guard,
and Action.

Figure 1. ADL metamodel

• Constraints can be defined as validation and verification
rules described in [7], serving the purposes of preventing
data inconsistency, and fortifying conformance to UML
specification, respectively.
• Representation can be visualized with a digraph using
Graphviz as used in the research or any other graph
visualization software.

• The current ADL covers the generation of intermediate
activity diagrams as shown in Figure 2.
• The research work [5] has defined the syntax of ADL for
an action, a sequence of actions, and a decision, as
illustrated in Figure 3, Figure 4, and Figure 5,
respectively.

actionaction
fork
join
merge
flowfinal
initial
decision
activity final
Figure 2.
Components of
intermediate
activity diagram

action id [[isLocallyReentrant=[true|false]]]
[name 'string']
[<- OID1[,OID2...[,OIDN]]] –-input objects
[-> OID3[,OID4...[,OIDN]]] –-output objects
[precondition 'string']
[postcondition 'string']
end
Figure 3. ADL syntax for defining an action

Figure 4. ADL syntax for defining a
sequence of actions with:
(a) explicit object; (b) implicit object
Say Hello Said Hello Say Goodbye
Say Hello Say Goodbye
(b)
(a)
action sayHello
-> SaidHello
end
action sayGoodbye
<- SaidHello
end
action sayHello end
action sayGoodbye end
sayHello->sayGoodbye

decision ['input']
if 'condition1' then id1
if 'condition2' then id2
...
end
Figure 5. ADL syntax for defining a decision

AUTOMATION OF ACTIVITY
DIAGRAM REVIEW

Automation of Activity Diagram Review
• This paper presents the corrective approach to
reviewing the existing UML activity diagrams.
• The review process of UML activity diagrams
consists of four main steps.
• Figure 6 illustrates the research method how
we adapt ADL for verifying the conformance to
UML specification of existing activity diagrams.

Figure 6. Review
process of UML
activity diagram
1 Standardize
XMI file of activity
diagram with mapping
rules
Activity diagram in
XMI format
Standardized XMI-
formatted activity
diagram
2. Generate
ADL script
ADL script
3.Verify &
Generate
inspection report
Intermediate activity
diagram metamodel
Java ANTLR grammar
Inspection result
UML 2.4.1 constraints
ADL semantic model
4. Parse ADL
script
[conform with UML]
[not conform with UML]
Valid ADL script
ADL metamodel
ADL ANTLR
grammar

1. Standardize
XMI file of
activity diagram
with mapping
rules
1 Standardize
rules
Activity diagram in
XMI format
Standardized XMI-
formatted activity
diagram
2. Generate
ADL script
ADL script
3.Verify &
Generate
inspection report
diagram metamodel
Java ANTLR grammar
Inspection result
ADL semantic model
4. Parse ADL
script
[conform with UML]
Valid ADL script
ADL metamodel
ADL ANTLR
grammar

Standardize XMI file of activity diagram
with mapping rules
• The input of the system is the XMI file of the
UML activity diagram to be reviewed.
• Since different UML tools support different XMI
formats and the UML notations may vary due
to enhanced version, the XMI standard
converter is therefore developed in this work.
• The component is responsible for converting
the XMI format of the input activity diagram to
the defined XMI format.

with mapping rules
• The converter is developed as Eclipse Plug-in
and it uses mapping rules for standardization.
• The mapping rules are particularly defined for
converting the XMI format of ArgoUML and
Modelio.

with mapping rules
• Data extraction from ArgoUML activity diagrams:
• ArgoUML is developed by Jason E. Robbins
using Java language.
• It is open-source software under Eclipse Publish
License 1.0.
• ArgoUML supports XMI standard version 1.2
and UML standard version 1.4.

with mapping rules
<UML:Model xmi.id = '-64--88-1-5-1cf81117:13aa30d6c5e:-8000:0000000000000865„ name = 'ex1' isSpecification = 'false' isRoot
= 'false' isLeaf = 'false„ isAbstract = 'false'>
<UML:CompositeState.subvertex>
<UML:ActionState xmi.id = '-64--88-1-5-1cf81117:13aa30d6c5e:-8000:0000000000000868„ name = 'Unmarshall Order'
isSpecification = 'false' isDynamic = 'false'>
<UML:StateVertex.outgoing>
<UML:Transition xmi.idref = '-64--88-1-5-1cf81117:13aa30d6c5e:-8000:0000000000000874'/>
</UML:StateVertex.outgoing>
<UML:StateVertex.incoming>
</UML:StateVertex.incoming>
<UML:State.entry>
<UML:UninterpretedAction xmi.id = '-64--88-1-5-1cf81117:13aa30d6c5e:-8000:0000000000000871„ isSpecification
='false' isAsynchronous = 'false'>
<UML:Action.script>
<UML:ActionExpression xmi.id = '-64--88-1-5-1cf81117:13aa30d6c5e:-8000:0000000000000877' language
='' body = 'Unmarshall Order'/>
</UML:Action.script>
</UML:UninterpretedAction>
</UML:State.entry>
</UML:ActionState>
</UML:CompositeState.subvertex>
Figure 7. Example of ArgoUML XMI file

with mapping rules
<UML:Model xmi.id = '-64--88-1-5-1cf81117:13aa30d6c5e:-8000:0000000000000865„ name = 'ex1' isSpecification = 'false' isRoot
= 'false' isLeaf = 'false„ isAbstract = 'false'>
<UML:CompositeState.subvertex>
<UML:ActionState xmi.id = '-64--88-1-5-1cf81117:13aa30d6c5e:-8000:0000000000000868„ name = 'Unmarshall Order'
isSpecification = 'false' isDynamic = 'false'>
<UML:StateVertex.outgoing>
</UML:StateVertex.outgoing>
<UML:StateVertex.incoming>
</UML:StateVertex.incoming>
<UML:State.entry>
<UML:UninterpretedAction xmi.id = '-64--88-1-5-1cf81117:13aa30d6c5e:-8000:0000000000000871„ isSpecification
='false' isAsynchronous = 'false'>
<UML:Action.script>
<UML:ActionExpression xmi.id = '-64--88-1-5-1cf81117:13aa30d6c5e:-8000:0000000000000877' language
='' body = 'Unmarshall Order'/>
</UML:Action.script>
</UML:UninterpretedAction>
</UML:State.entry>
</UML:ActionState>
</UML:CompositeState.subvertex>
UML:ActionState
UML:ObjectFlowState
UML:Pseudostate
UML:FinalState

with mapping rules
<UML:StateMachine.transitions>
<UML:Transition xmi.id = '-64--88-1-5-1cf81117:13aa30d6c5e:-8000:0000000000000873„ isSpecification = 'false'>
<UML:Transition.source>
<UML:ObjectFlowState xmi.idref = '-64--88-1-5-1cf81117:13aa30d6c5e:-8000:0000000000000869'/>
</UML:Transition.source>
<UML:Transition.target>
<UML:ActionState xmi.idref = '-64--88-1-5-1cf81117:13aa30d6c5e:-8000:0000000000000868'/>
</UML:Transition.target>
</UML:Transition>
</UML:StateMachine.transitions>
</UML:Model>

Figure 8.
ArgoUML mapping
rules

with mapping rules
• Data extraction from Modelio activity diagrams:
• Modelio is developed by ModelioSoft.
• It is open-source software under GPLv3 License.
• Modelio supports XMI standard version 2.1
and UML Standard version 2.0.

with mapping rules
<packagedElement xmi:type="uml:Activity“ xmi:id="_mhyeRiZCEeKSKePaylnoVA" name="ex1">
<node xmi:type="uml:OpaqueAction" xmi:id="_mhzFWSZCEeKSKePaylnoVA" name="Unmarshall Order"
outgoing="_mhzFbiZCEeKSKePaylnoVA _mhzsYyZCEeKSKePaylnoVA _mhzsaCZCEeKSKePaylnoVA“ incoming
="_mhzsbSZCEeKSKePaylnoVA">
<body/>
</node>
<node xmi:type="uml:CentralBufferNode" xmi:id="_mhzFXyZCEeKSKePaylnoVA" name="Name" incoming=
"_mhzFbiZCEeKSKePaylnoVA">
<eAnnotations xmi:id="_mhzFYCZCEeKSKePaylnoVA" source="Objing">
<contents xmi:type="uml:Property" xmi:id="_mhzFYSZCEeKSKe PaylnoVA" name="Type">
<defaultValue xmi:type="uml:LiteralString" xmi:id="_mhzFYiZCEeKSKePaylnoVA" value=
"InstanceNode"/>
</contents>
</eAnnotations>
<upperBound xmi:type="uml:LiteralString" xmi:id="_mhzFYyZCEeKSKePaylnoVA" name="UpperBound"
value=“1”/>
</node>
Figure 9. Example of Modelio XMI file

with mapping rules
<edge xmi:type="uml:ObjectFlow" xmi:id="_mhzsbSZCEeKSKePaylnoVA" name="ObjectFlow“ source=
"_mhzFWiZCEeKSKePaylnoVA" target="_mhzFWSZCEeKSKePaylnoVA">
<eAnnotations xmi:id="_mhzsbiZCEeKSKePaylnoVA" source="Objing">
<contents xmi:type="uml:Property" xmi:id="_mhzsbyZCEeKSKePaylnoVA" name="Effect">
<defaultValue xmi:type="uml:LiteralString" xmi:id="_mhzscCZCEeKSKePaylnoVA"
value="READ_FLOW"/>
</contents>
</eAnnotations>
<weight xmi:type="uml:LiteralInteger" xmi:id="_mhzscSZCEeKSKePaylnoVA" value="1"/>
</edge>
Figure 9. Example of Modelio XMI file

Figure 10.
Modelio
mapping rules

2. Generate ADL
Script
1 Standardize
rules
Activity diagram in
XMI format
Standardized XMI-
formatted activity
diagram
2. Generate
ADL script
ADL script
3.Verify &
Generate
inspection report
diagram metamodel
Java ANTLR grammar
Inspection result
ADL semantic model
4. Parse ADL
script
[conform with UML]
Valid ADL script
ADL metamodel
ADL ANTLR
grammar

Generate ADL Script
• The second step is to transform the XMI standard
document obtained from the previous step into the ADL
script.
• The method is to reverse the approach presented in [5],
[6], [7].
• If the resulting ADL script fails during the verification in
the next step, it can be accessed and revised.

Generate ADL Script
• The initial step of ADL script generation is to parse the
XMI standard document obtained from the previous step
to node and edge array lists.
• Next, the ADL script generator will inspect node/edge
and generate the script based on each item.
• The following three steps are carried out during the
script generation.
1. Generate actions.
2. Generate decisions.
3. Generate sequence of actions.

Generate ADL Script
Figure 10. Example of activity diagram

Generate ADL Script
Record Problem
Reproduce Problem
Correct Problem
ID Problem and
Resolution
Verify Resolution
Communicate
Results
Audit and Record
1. Generate actions
1) explicit object
2) implicit object.
action Record Problem end
action Reproduce Problem end
action Correct Problem end
action Id Problem And Resolution end
action Verify Resolution end
action Audit And Record end
action Communicate Result end
Figure 11. Extraction of all
actions in example activity
diagram

Generate ADL Script
Record Problem Reproduce Problem
[not recorded]
[recorded]
[problem statement rectified]
[else]
Correct Problem
ID Problem and
Resolution
Verify Resolution
[cannot
reproduce
problem]
[can reproduce
problem]
[duplication of another problem
[known problem and solution]
ID Problem and
Resolution
Verify Resolution
[else]
[problem not solved]
2. Generate decisions
decision from Record Problem
if 'recorded' then
if 'problem statement rectified' then
Audit And Record and Communicate Result
else if 'else' then Reproduce Problem
endif
endif
else
if 'not recorded' then break
endif
endif
end
decisions in example activity
diagram

Generate ADL Script
[not recorded]
[recorded]
[else]
Correct Problem
ID Problem and
Resolution
Verify Resolution
[cannot
reproduce
problem]
[can reproduce
problem]
ID Problem and
Resolution
Verify Resolution
[else]
decision from Reproduce Problem
if 'cannot reproduce problem' then
Correct Problem
else if 'can reproduce problem' then
Id Problem And Resolution
else if 'duplication of another problem' then
Verify Resolution
else if 'known problem and solution' then
Audit And Record and Communicate
Result
endif
endif
endif
endif
end
diagram

Generate ADL Script
[not recorded]
[recorded]
[else]
Correct Problem
ID Problem and
Resolution
Verify Resolution
[cannot
reproduce
problem]
[can reproduce
problem]
ID Problem and
Resolution
Verify Resolution
[else]
decision from Verify Resolution
if 'problem not solved' then
Id Problem And Resolution
else if 'else' then Audit And Record and
Communicate Result
endif
endif
end
diagram

Generate ADL Script
ID Problem and
Resolution
Verify Resolution
Correct Problem
Communicate
Results
Audit and Record
3. Generate sequence of
actions
Id Problem And Resolution->Verify Resolution
Correct Problem->Audit And Record and
Communicate Result
Figure 13. Extraction of all action
sequences in example activity
diagram

Figure 14.
ADL script of
example activity
diagram

3. Verify and
Generate
Inspection
Result
1 Standardize
rules
Activity diagram in
XMI format
Standardized XMI-
formatted activity
diagram
2. Generate
ADL script
ADL script
3.Verify &
Generate
inspection report
diagram metamodel
Java ANTLR grammar
Inspection result
ADL semantic model
4. Parse ADL
script
[conform with UML]
Valid ADL script
ADL metamodel
ADL ANTLR
grammar

Verify and Generate Inspection Result
• The third step is to examine the ADL script generated
from the previous step.
• Java ANTLR grammar (Figure 15) is developed for the
inspection process and report generation.
• The Intermediate activity diagram metamodel (Figure 16)
is used to indicate what elements will be examined
against the constraints of UML 2.4.1.
• The review process ensures that the syntax of each
element comprising the model conforms to the standards
and guidelines specified by OMG.

Verify and Generate Inspection Result
Figure 16. Intermediate activity diagram metamodel

UML Specification 2.4.1 Constraints
• Constraints of Activity
1. The nodes of the activity must include one
ActivityParameterNode for each parameter.
2. An activity cannot be autonomous and have a classifier
or behavioral feature context at the same time.
3. The groups of an activity have no super groups.

• Constraints of ActivityEdge
1. The source and target of an edge must be in the same
activity as the edge.
2. Activity edges may be owned only by activities or
groups.
• Constraint of ActivityNode
1. Activity nodes can only be owned by activities or
groups.

• Constraints of ObjectFlow
1. Object flows may not have actions at either end.
2. Object nodes connected by an object flow, with optionally
intervening control nodes, must have compatible types. In
particular, the downstream object node type must be the
same or a super type of the upstream object node type.
3. Object nodes connected by an object flow, with optionally
intervening control nodes, must have the same upper
bounds.
• Constraint of ControlFlow
1. Control flows may not have object nodes at either end,
except for object nodes with control type.

• Constraint of ObjectNode
1. All edges coming into or going out of object nodes must
be object flow edges.
• Constraints of InitialNode
1. An initial node has no incoming edges.
2. Only control edges can have initial nodes as source.
• Constraint of FinalNode
1. A final node has no outgoing edges.

• Constraints of DecisionNode
1. A decision node has one or two incoming edges and at
least one outgoing edge.
2. The edges coming into and out of a decision node, other
than the decision input flow (if any), must be either all
object flows or all control flows.
3. The decisionInputFlow [2] of a decision node must be an
incoming edge of the decision node.
4. A decision input behavior has no output parameters, no
in-out parameters and one return parameter.
5. If the decision node has no decision input flow and an
incoming control flow, then a decision input behavior has
zero input parameters.

6. If the decision node has no decision input flow and an
incoming object flow, then a decision input behavior has
one input parameter whose type is the same as or a
super type of the type of object tokens offered on the
incoming edge.
7. If the decision node has a decision input flow and an
incoming control flow, then a decision input behavior
has one input parameter whose type is the same as or
a super type of the type of object tokens offered on the
decision input flow.

8. If the decision node has a decision input flow and a
second incoming object flow, then a decision input
behavior has two input parameters, the first of which
has a type that is the same as or a super type of the
type of the type of object tokens offered on the non-
decision input flow and the second of which has a type
that is the same as or a super type of the type of object
tokens offered on the decision input flow.

• Constraints of MergeNode
1. A merge node has one outgoing edge.
2. The edges coming into and out of a merge node must
be either all object flows or all control flows.
• Constraints of ForkNode
1. A fork node has one incoming edge.
2. The edges coming into and out of a fork node must be
either all object flows or all control flows.

• Constraints of JoinNode
1. A join node has one outgoing edge.
2. If a join node has an incoming object flow, it must have
an outgoing object flow, otherwise, it must have an
outgoing control flow.

4. Parse ADL
Script
1 Standardize
rules
Activity diagram in
XMI format
Standardized XMI-
formatted activity
diagram
2. Generate
ADL script
ADL script
3.Verify &
Generate
inspection report
diagram metamodel
Java ANTLR grammar
Inspection result
ADL semantic model
4. Parse ADL
script
[conform with UML]
Valid ADL script
ADL metamodel
ADL ANTLR
grammar

Parse ADL Script
• The final step is to generate the ADL semantic model by
parsing the validated ADL script.
• The ADL ANTLR grammar, accompanied with the ADL
metamodel, is used to transform the ADL syntax into the
semantic model.
• The resulting ADL semantic model consists of nodes,
object evidence, guard condition objects, and
relationships.
• The semantic model is useful for further applications such
as generating: test cases, design document, Java source
code, and etc.

Example 1
Figure 18. First case of examined
activity diagram created by ArgoUML
Figure 19. First case of examined
activity diagram created by Modelio
Figure 20. ADL script from [10] Figure 21. ADL script result
[10] . .
,

Example 1
Figure 22. Activity diagram result
Figure 23. Inspection result of first case

Example 2
Figure 24. Second case of examined
Figure 25. Second case of examined
[10] . .
,

Example 2
Figure 29. Inspection result of second case

Example 3
Figure 30. Third case of examined
Figure 31. Third case of examined
[10] . .
,

Example 3
Figure 32. ADL script from [10]
Figure 33. ADL script result
[10] . .
,

Example 3
Figure 35. Inspection result of third case

Example 4
Figure 36. Fourth case of examined
Figure 37. Fourth case of examined
[10] . .
,

Example 4
[10] . .
,

Example 4
Figure 41. Inspection result of fourth case

Example 5
Figure 42. Fifth case of examined
Figure 43. Fifth case of examined
[10] . .
,

Example 5
Figure 47. Inspection result of fifth case

Example 6
Figure 48. Sixth case of examined
Figure 49. Sixth case of examined
[10] . .
,

Example 6
[10] . .
,

Example 6
Figure 53. Inspection result of sixth case

Example 7
Figure 54. Seventh case of examined
Figure 55. Seventh case of examined
[10] . .
,

Example 7
Figure 58. Inspection result of seventh case

Example 8
Figure 59. Eighth case of examined
Figure 60. Eighth case of examined
[10] . .
,

Example 8
[10] . .
,
Figure 63. Inspection result of eighth case

Conclusion
• UML Activity diagrams are widely used as the
blueprints for describing procedural logic,
business processes and workflows.
• In mature software development processes, it
is suggested to detect and remove defects at
the phase they were injected in order to
reduce the cost of rework and promote the
quality of product.

Conclusion
• This research thus presents an automation
approach to reviewing the UML activity
diagrams.
• The method deploys a domain specific
language called Action Description Language
(ADL) created in [5], [6], [7].
• In this work, we have enhanced ADL for
reviewing the existing activity diagrams
whether they conform to UML specification
v.2.4.1.

Conclusion
• The proposed method can be considered as
the reverse of the research work [5], [6], [7],
which generates UML activity diagrams from
ADL scripts.
• Conversely, this research generates ADL
scripts from existing activity diagrams.

Conclusion
• However, the final output obtained from the
proposed approach is the ADL semantic
model, which is useful for further applications,
namely the automated generation of test
cases, design blueprints, and source code.
• Moreover, the ADL scripts obtained from this
work can be used for later modification and
generation of UML activity diagrams as being
processed in the preventive approach
presented in [5], [6], [7].

Conclusion
• Future research work could be the
enhancement of mapping rules to the
framework capable to support the
standardization of various XMI formats.

Thank you
Enhancement of ADL for Activity Diagram Review

Enhancement of Action Description Language for UML Activity Diagram Review

More Related Content

What's hot (20)

Viewers also liked (16)

Similar to Enhancement of Action Description Language for UML Activity Diagram Review (20)

Recently uploaded (20)

Enhancement of Action Description Language for UML Activity Diagram Review