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

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”. 14th 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”. 24th 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.

[5] C. Narkngam, Y. Limpiyakorn, “Rendering UML Activity Diagrams as a Domain Specific Language - ADL”. 24th 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

• 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

• 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.

[7] C. Narkngam and Y. Limpiyakorn, “Domain Specific Language for Activity Diagram”, Ramkhamhaeng Journal of Engineering, vol. 1, (2012).


• 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.

[5] C. Narkngam, Y. Limpiyakorn, “Rendering UML Activity Diagrams as a Domain Specific Language - ADL”. 24th International Conference on Software Engineering and Knowledge Engineering, (2012), July 1-3; San Francisco, USA.


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 -> SaidHelloendaction sayGoodbye <- SaidHello end

action sayHello endaction sayGoodbye endsayHello->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 resultUML 2.4.1 constraints

ADL semantic model4. 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





diagram


ADL script

3.Verify & Generate

inspection report


Java ANTLR grammar



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.



• 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.



• 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.


<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


<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:ActionStateUML:ObjectFlowStateUML:PseudostateUML:FinalState



<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


• 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.


<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


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



<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 10. Modelio mapping rules

2. Generate ADL Script





diagram


ADL script

3.Verify & Generate

inspection report


Java ANTLR grammar



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 actions1) explicit object2) implicit object.

action Record Problem endaction Reproduce Problem endaction Correct Problem endaction Id Problem And Resolution endaction Verify Resolution endaction Audit And Record endaction 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


Verify Resolution

[cannot reproduce problem]

[can reproduce problem]

[duplication of another problem

[known problem and solution]


Verify Resolution

[else]

[problem not solved]

2. Generate decisions

decision from Record Problemif 'recorded' then

if 'problem statement rectified' then Audit And Record and Communicate Result

else if 'else' then Reproduce Problemendif

endifelse

if 'not recorded' then breakendif

endifend

Figure 12. Extraction of all decisions in example activity

diagram

Generate ADL Script


[not recorded]

[recorded]


[else]

Correct Problem


Verify Resolution






Verify Resolution

[else]



decision from Reproduce Problemif 'cannot reproduce problem' then

Correct Problemelse if 'can reproduce problem' then

Id Problem And Resolutionelse if 'duplication of another problem' then

Verify Resolutionelse if 'known problem and solution' then

Audit And Record and Communicate Result endif

endifendif

endifend


diagram

Generate ADL Script


[not recorded]

[recorded]


[else]

Correct Problem


Verify Resolution






Verify Resolution

[else]



decision from Verify Resolutionif 'problem not solved' then

Id Problem And Resolutionelse if 'else' then Audit And Record and

Communicate Result endif

endifend


diagram

Generate ADL Script


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





diagram


ADL script

3.Verify & Generate inspection

report


Java ANTLR grammar



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.

Figure 15. Java ANTLR grammar

Verify and Generate Inspection Result

Figure 16. Intermediate activity diagram metamodel

UML Specification 2.4.1 Constraints

• Constraints of Activity1. 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 ActivityEdge1. 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 ObjectFlow1. 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 ControlFlow1. Control flows may not have object nodes at either end,

except for object nodes with control type.


• Constraint of ObjectNode1. 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 FinalNode1. A final node has no outgoing edges.


• Constraints of DecisionNode1. 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.


• Constraints of DecisionNode6. 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.


• Constraints of DecisionNode8. 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 MergeNode1. 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 JoinNode1. 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





diagram


ADL script

3.Verify & Generate

inspection report


Java ANTLR grammar



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.

Figure 17. ADL ANTLR grammar

DEMONSTRATION

EVALUATION

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] เจร�ญศั�กดี�� นาคงาม.ข"อก�าหนดีร#ปน�ยเพ%&อทวนสอบแผนภาพก�จกรรมของกระแสกระบวนการ.ว�ทยาน�พนธ์)ปร�ญญามหาบ�ณฑิ�ต, สาขาว�ศัวกรรมซอฟต)แวร). คณะว�ศัวกรรมศัาสตร) จ.ฬาลงกรณ)มหาว�ทยาล�ย, 2554.

Example 1

Figure 22. Activity diagram result

Figure 23. Inspection result of first case

Example 2

Figure 24. Second case of examined activity diagram created by ArgoUML

Figure 25. Second case of examined activity diagram created by Modelio



Example 2


Figure 29. Inspection result of second case

Example 3

Figure 30. Third case of examined activity diagram created by ArgoUML

Figure 31. Third case of examined activity diagram created by Modelio


Example 3

Figure 32. ADL script from [10]Figure 33. ADL script result


Example 3


Figure 35. Inspection result of third case

Example 4

Figure 36. Fourth case of examined activity diagram created by ArgoUML

Figure 37. Fourth case of examined activity diagram created by Modelio


Example 4



Example 4


Figure 41. Inspection result of fourth case

Example 5

Figure 42. Fifth case of examined activity diagram created by ArgoUML

Figure 43. Fifth case of examined activity diagram created by Modelio



Example 5


Figure 47. Inspection result of fifth case

Example 6

Figure 48. Sixth case of examined activity diagram created by ArgoUML

Figure 49. Sixth case of examined activity diagram created by Modelio


Example 6



Example 6


Figure 53. Inspection result of sixth case

Example 7

Figure 54. Seventh case of examined activity diagram created by ArgoUML

Figure 55. Seventh case of examined activity diagram created by Modelio



Example 7

Figure 58. Inspection result of seventh case

Example 8

Figure 59. Eighth case of examined activity diagram created by ArgoUML

Figure 60. Eighth case of examined activity diagram created by Modelio


Example 8



Figure 63. Inspection result of eighth case

CONCLUSION

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 youEnhancement of ADL for Activity Diagram Review

การขยายความสามารถเอดี�แอลส�าหร�บการตรวจทานแผนภาพก�จกรรม

Enhancement of Action Description Language for UML Activity Diagram Review

Technology

uml activity diagrams

uml diagrams

notation of uml

software engineering

uml static

uml specification

valid activity diagrams

unified modeling language