SEKE 2012 Proceedings - Knowledge Systems Institute

a = O1 → a → O2
b = O2 → b → O3
c = O2 → c → O4
Next, the sequences of actions can be derived as:
a . b = O1 → a → O2 → b → O3
a . c = O1 → a → O2 → c → O4
According to (3), the parallel behaviors with object relations
can be expressed as (4).
a . (b || c) = O1 → a → O2 → (b → O3 || c → O4)
D. Defining Condition
Activity diagrams use a decision node and guard conditions
to denote alternative composition or choices. That is, when a
decision node accepts a token, it will ev aluate if th e token
satisfies which guard condition annotated in square brackets on
branches, and th en deliver the token to th e outgoing edge
satisfying the condition.
Example activity diagram containing a decision and the
associated ADL script are illustrated in Fig. 3.
action receiveOrder end
action fillOrder end
action closeOrder end
receiveOrder -> fillOrder ['order accepted']
receiveOrder -> closeOrder ['order rejected']
Fill Order
[order accepted]
Receive Order
[order rejected]
Figure 3. Example for defining condition
E. Defining Nested Condition
For complex decisions or nested decisions, additional
information of guard conditions will be added to the sequence
of actions. A guard condition also owns input and output
objects to create a co nnection between actions related to it.
Given the following chunk of ADL script,
01 action a end 06 if 'guard2'
02 action b end 07 then b
03 decision from a 08 endif
04 if 'guard1' 09 endif
05 then 10 end
Close Order
the sequence of actions a . b can be expressed as (5).
Suppose
a = O1 → a → O2
b = O2 → b → O3
then a . guard1 & guard2:→ b = O1 → a → O → G1 (5)
→ G2 → b → O3
where G1, G2 denote output objects produced from ‘guard1’
and ‘guard2’, respectively. The values of G1 and G2 a re O2
attached with the evaluated condition.
IV. GENERATING ACTIVITY DIAGRAM FROM ADL
Parsing ADL scripts results in ADL semantic models,
which cannot be directly transformed to activity diagrams
because they still lack the information of controls, namely fork,
join, decision, and merge. However, the particular pattern
exists for each control and can be detected from the details of
edges (incoming/ outgoing), labeled edges, and flow detail
contained in ADL scripts. Steps to generate activity diagrams
from ADL scripts are illustrated in Fig. 4.
Parse ADL
Script
Normalize Fork and
Decision Nodes
Construct Join and
Merge Nodes
ADL Semantic
Model
Construct Fork and
Decision Nodes
Normalize Join and
Merge Nodes
Figure 4. Steps to generate activity diagrams from ADL scripts
A constructor or a m odel is required for retriev ing loss
information of controls and generating the activity diagram. To
accomplish model-to-model transformation, QVT or query/
view/ transformation specification [11] is applied to describe
the transformation from the semantic model of ADL
metamodel to the semantic model of the metamodel for
constructing activity diagrams, as sh own in Fig. 5. Starting
from defining top-level relations of model transformation that
specify the mappings between the two models as follows,
transformation adl (adl : ADL, constructor :
ADConstructor) {
top relation ObjectToObjectNode {...}
top relation RelationToEdge {...}
top relation ActionToActivityNode {...}
relation ActionToAction {...}
relation ActionToControlNode {...}
}
Build Objects and
Relations
Build Actions
the semantic model for constructing activity diagrams is then
created. Next, it will be transformed to the semantic model of
the metamodel for constructing activity diagrams using the
mappings of top-level relations defined as follows:
transformation ad (constructor : ADConstructor, ad :
AD) {
top relation ObjectNodeToObjectNode {
checkOnly domain constructor left:ObjectNode {
hidden=false, name=on}
enforce domain ad right:ObjectNode {name=on}
...
}
top relation ActionToAction {...}
top relation EdgeToActivityEdge {...}
relation ActivityEdgeToControlFlow {...}
relation ActivityEdgeToObjectFlow {...}
top relation InitialNodeToInitialNode {...}
top relation FlowFinalNodeToFlowFinalNode {...}
top relation ActivityFinalNodeToActivityFinalNode
{...}
top relation ActivityNodeToEdgeDetail {...}
relation OutgoingEdgeToForkAndDecisionNode {...}
relation IncomingEdgeToJoinAndMergeNode {...}
}
726