About this Journal Submit a Manuscript Table of Contents
ISRN Software Engineering
Volume 2012 (2012), Article ID 265235, 22 pages
http://dx.doi.org/10.5402/2012/265235
Research Article

An Approach to Convert XMI Representation of UML 2.x Interaction Diagram into Control Flow Graph

1School of Information Technology, Indian Institute of Technology, Kharagpur, Kharagpur 721302, India
2Department of Computer Science and Engineering, Indian Institute of Technology, Kharagpur, Kharagpur 721302, India

Received 23 August 2011; Accepted 20 September 2011

Academic Editors: F. Ipate and A. Lastovetsky

Copyright © 2012 Debasish Kundu et al. This is an open access article distributed under the Creative Commons Attribution License, which permits unrestricted use, distribution, and reproduction in any medium, provided the original work is properly cited.

Abstract

For automation of many software engineering tasks such as program analysis, testing, and coverage analysis, it is necessary to construct a control flow graph. With the advancement of UML, software practitioners advocate to construct control flow graph from some of the UML design artifacts. UML 2.x supports the modeling of control flow information in interaction diagram by means of message sequences and different types of fragments like alt, opt, break, loop, and so forth. Leading UML modeling tools, namely MagicDraw, IBM's Rational, and so forth export models in XMI format. Construction of control flow graph from the XMI representation of an interaction diagram is not straightforward as model elements of interaction diagram are captured in XMI by means of values of attributes of multiple tagged elements and correlations among these tagged elements is not explicitly specified. This paper proposes an approach for construction of control flow graph from XMI representation of UML 2.x interaction diagram. A prototype tool based on our approach has been developed which can be plugged in any computer-aided software engineering tool.

1. Introduction

UML has now become a standard modeling language in software industries [1]. Currently, UML models are being used in many software engineering tasks such as program analysis, testing, and coverage analysis [211]. For automation of these tasks, it is necessary to construct a control flow graph from UML models. UML 2.x supports the modeling of control flow information in an interaction diagram by means of message sequences and different types of fragments like alt, opt, break, loop, and so forth [1214]. UML models are usually exported from UML modeling tools in XMI representation [15]. Unfortunately, construction of control flow graph from XMI representation of interaction diagram is not straightforward. The factors contributing to the complexity of construction of control flow graph are: (i) model elements of interaction diagrams are captured in XMI by means of values of attributes of multiple tagged elements, (ii) correlations among tagged elements are not explicitly specified [16], and (iii) control flow information is modeled by means of different types of fragments that can be nested fragment with arbitrary nesting depth.

Existing approaches [2, 4, 11, 17, 18] consider a set of mapping rules to construct control flow graph from interaction diagrams [12]. Mapping rules are in essence as follows. (1) Message, start and end of a fragment correspond to nodes of the control flow graph. (2) An edge is constructed between two nodes depending on various conditions such as type of nodes (message, start/end of a fragment) and type of fragments (alt, opt, loop, etc.). For applying these mapping rules to XMI representation of an interaction diagram, we need to do the following: (i) process the information associated with multiple tagged elements that correspond to a node in control flow graph, (ii) track the tagged elements stored in XMI representation between start and end of each operand of a fragment as well as between start and end of each fragment, and (iii) consider the interpretations of different fragments to map edges. The situation becomes complicated when an operand of a fragment contains a nested fragment of arbitrary nesting depth. In fact, the existing mapping rules are difficult to apply to the XMI representation of interaction diagram. This issue has been addressed in this paper. We propose an approach to parse the XMI representation of interaction diagram in an easy and tangible way and store model information in an intermediate data structure. This intermediate data structure enables us to apply the mapping rules to construct control flow graph. Apart from this, information retrieved from XMI representation can be embedded into control flow graph for many of the automated software engineering tasks such as test case generation, and coverage analysis. Based on our approach, a prototype tool XMI2CFG has been developed which can take any interaction diagram in XMI representation, parse it, construct its control flow graph, and visualize the graph to the users with details in it.

The rest of the paper is organized as follows. Few basic definitions, terminologies, and the control primitives for different types of fragments of interaction diagram have been discussed in Section 2. In Section 3, we discuss some issues of dealing with XMI representation for construction of control flow graph. Section 4 presents the proposed conversion approach from XMI of interaction diagram into control flow graph. We discuss our prototype tool in Section 5. Section 6 discusses related work and compares our work with the existing work. Finally, Section 7 concludes the paper.

2. Preliminaries

In this section, we first present few definitions and terminologies that have been used in the later sections. Then, we discuss control flow primitives for most commonly used fragments such as alt, opt, break, loop of interaction diagram.

2.1. Definitions and Terminologies

XMI
XMI stands for XML metadata interchange. It is a standard representation used for exchanging metadata information by means of extensible markup language (XML) [19].

Interaction Diagram
Interaction diagram is a UML behavioral diagram of a use case [12, 13]. This diagram models control flow by means of sequence of messages among objects of a system. The objects are shown as rectangular boxes arranged horizontally. The vertical lines falling from the rectangular boxes represent lifelines. The message is represented by means of an arrow connecting two lifelines attached to sender and receiver object of the message. Time is represented in the vertical direction showing the sequence of messages.

Message
A message refers to an instruction sent to an object. Sender object sends a message to a receiver object to invoke a method defined for that receiver object. Difference between message and method is that a message is a request for a receiver object to perform some task(s), and the message consists of a message name and a list of (zero or more) arguments. On the other hand, when a message is sent to a receiver object, a method with the same name and argument list as the message gets executed [20].

Fragment
A fragment is a group of set of messages together to show conditional flow in an interaction diagram. A fragment is also termed as interaction operator that operates on a group of operands, and each operand represents a set of messages that occur in a sequence under some guard condition. UML 2.x specification supports different types of fragments like alt (alternative), opt (optional), loop, break, and so forth [1]. A fragment specifies how execution of operands is to be interpreted. For example, alt fragment specifies that only one operand whose guard condition gets satisfied, would be executed.

Model Element
Model element refers to the elements in a UML interaction diagram such as the start of a fragment, and end of a fragment, message.

Control Flow Graph
Control flow graph for an interaction diagram say ItrDgm, is a directed graph CFG=𝑁,𝐸, where 𝑁={𝑛1,𝑛2,,𝑛𝑖,,𝑛𝑞} is a set of nodes and 𝐸={𝑛𝑖,𝑛𝑗} is a set of edges. A node 𝑛𝑖𝑁 represents a model element of the ItrDgm, and an edge 𝑛𝑖,𝑛𝑗𝐸 represents a control flow between two model elements say 𝑚𝑖 (corresponding to 𝑛𝑖) and 𝑚𝑗 (corresponding to 𝑛𝑗).

Nodes of the control flow graph are of two types: message node and fragment node representing message and fragment boundary, respectively. The message and fragment node is uniquely represented by a tuple𝑇,ID,𝐵,RO,𝑀,PR,RVar, where(i)𝑇 is the type of the fragment or message. A fragment is of type like alt, opt, loop, and break, whereas message is of type synchronous, reply, and so forth.(ii)ID is the identification number of message/fragment. Each message/fragment is identified by a unique identification number.(iii)𝐵 is the start or end boundary of a fragment. The value of 𝐵 is set as 𝑆 and 𝐸 for the start and end boundary of the fragment, respectively. It is null for message node.(iv)RO is a reference to the receiver object of the message corresponding to message node. It has the value null for fragment node.(v)𝑀 is a method gets executed when RO receives the message corresponding to message node and is null for fragment node.(vi)PR is the set of parameters of the method 𝑀, and is null for fragment node.(vii)RVar is a return variable that keeps the value returned by the method 𝑀. It is null for fragment node.

Interaction
An interaction 𝐼 is a set of zero or more message occurrences in an interaction diagram [1]. That is, 𝐼={𝑚1,𝑚2,,𝑚𝑛𝑛0}, where 𝑚1, 𝑚2, , 𝑚𝑛 are the 𝑛 number of messages in the interaction diagram. If 𝑛=0, then 𝐼 is referred to as null interaction, and if 𝑛=1, then 𝐼 is referred to a message. On the other hand, if 𝑛>1, then 𝐼 is referred to a set of messages of a fragment.

Precedence Relation
For any two interactions 𝐼𝑥 and 𝐼𝑦 in a set of interactions 𝑀𝐼, we say there is a precedence relation 𝐼𝑥𝐼𝑦 if 𝐼𝑥𝑀𝐼 occurs immediately before 𝐼𝑦𝑀𝐼 according to the timing order in the interaction diagram. It implies that if there exists a precedence relation between 𝐼𝑥 and 𝐼𝑦 in 𝑀𝐼, then there would be no 𝐼𝑧𝑀𝐼 such that 𝐼𝑥𝐼𝑧 and 𝐼𝑧𝐼𝑦. This relation satisfies the following properties.

(a)If 𝐼𝑥𝐼𝑦, then 𝐼𝑦̸𝐼𝑥, where 𝐼𝑥,𝐼𝑦𝑀𝐼(asymmetric).(b)If 𝐼𝑥𝐼𝑦 and 𝐼𝑦𝐼𝑧, then 𝐼𝑥̸𝐼𝑧, where 𝐼𝑥,𝐼𝑦,𝐼𝑧𝑀𝐼(non-transitive).(c)𝐼𝑥̸𝐼𝑥(non-reflexive).

Null Precedence Relation
Let 𝑃(𝑀𝐼) be a set of precedence relations on 𝑀𝐼. Note that if 𝑀𝐼 is the set of messages of a fragment 𝑓𝑖 and an operand of the fragment 𝑓𝑖 contains a single message 𝑚, then there would be no precedence relation containing the message 𝑚 in 𝑃(𝑀𝐼). To ensure the existence of some precedence relation in 𝑃(𝑀𝐼) that would contain 𝑚 as an operand, null interaction may be assumed to have occurred before or after 𝑚. The precedence relation between 𝑚 and null interaction is called null precedence relation, which is defined below.

A precedence relation (𝐼𝑥𝐼𝑦) of 𝑃(𝑀𝐼) is called a null precedence relation if either 𝐼𝑥 or 𝐼𝑦 is null interaction. If 𝐼𝑥 is the null interaction, then 𝐼𝑥𝐼𝑦 is called the left null precedence relation and written as Λ𝐼𝑦. On the other hand, if 𝐼𝑦 is the null interaction, then 𝐼𝑥𝐼𝑦 is called the right null precedence relation and written as 𝐼𝑥Λ.

2.2. Control Flow Primitives

We now consider control flow primitives for most commonly used fragments alt, opt, break, and loop.

Alt Fragment
The alt fragment is used to capture alternative flows by means of multiple operands [12]. In Figure 1(a), an interaction diagram is shown with an alt fragment. The alt fragment has two operands containing the messages 𝑚2 and 𝑚3, respectively.

265235.fig.001
Figure 1: The control primitives for the fragments alt, opt, break, and loop of interaction diagram.

As observed in Figure 1(a), after receiving the message m1 from ObjectA, ObjectB sends the message 𝑚2 to itself if 𝐶1 becomes true, otherwise, ObjectB sends the message 𝑚3 to ObjectC. Finally, reply message 𝑚4 is sent from ObjectB to ObjectA. Figure 1(b) depicts corresponding graph representation for the interaction diagram containing alt fragment. Note that four nodes 𝑚1, 𝑚2, 𝑚3, and 𝑚4 represent four messages 𝑚1, 𝑚2, 𝑚3, and 𝑚4, respectively, and two nodes 𝑎𝑙𝑡𝑆1 and 𝑎𝑙𝑡𝐸1 correspond to the start and end of the alt fragment, respectively. Two alternative flows are modeled by two outgoing edges from 𝑎𝑙𝑡𝑆1 and two incoming edges at the node 𝑎𝑙𝑡𝐸1 in the graph representation. Note that this graph representation contains the same information as in interaction diagram. In this case, control flow is explicitly modeled for alt fragment in interaction diagram and hence, control flow graph would be the same as the graph representation (see Figure 1(b)).

Opt Fragment
The opt fragment has only one operand that is executed optionally [12]. In Figure 1(c), an interaction diagram contains an opt fragment with two messages 𝑚2 and 𝑚3. These two messages are executed if the guard condition 𝐶1 becomes true. Figure 1(d) depicts graph representation for the interaction diagram (in Figure 1(c)). Note that when the guard condition 𝐶1 becomes false, the control flow is transferred from the start of opt fragment to its end. This control flow is implicitly captured in interaction diagram and so in its graph representation. However, this control flow is modeled explicitly in control flow graph as an edge from the node 𝑜𝑝𝑡𝑆1 (corresponding to the start of opt fragment) to the node 𝑜𝑝𝑡𝐸1 (corresponding to the end of opt fragment) as shown in Figure 1(e).

Break Fragment
The break fragment is used to capture an exit point of the systems [12]. In Figure 1(f), we see that if guard condition 𝐶1 becomes true, then it exits after execution of two messages 𝑚2 and 𝑚3, following which no further message (i.e., 𝑚4 and 𝑚5) would be executed. Note that the control flow which is transferred from the start of break fragment to the message 𝑚4 when the guard condition 𝐶1 becomes false is implicitly captured in both interaction diagram and its graph representation (see Figure 1(g)). The control flow for the break fragment is modeled explicitly by reducing the node 𝑏𝑟𝑒𝑎𝑘𝐸1 (corresponding to the end of the break fragment) as a sink node and introducing an edge from the node 𝑏𝑟𝑒𝑎𝑘𝑆1 to the node 𝑚4 in control flow graph (see Figure 1(h)).

Loop Fragment
The loop fragment is used to model repetitive interactions [12]. In Figure 1(i), we see that message 𝑚2 of the loop fragment gets executed repeatedly until the guard condition 𝐶1 associated with loop fragment becomes false. When 𝐶1 becomes false, loop terminates and execution of the message 𝑚3 commences. Figure 1(j) shows the graph representation for the interaction diagram Figure  1(i). The control flow for the loop fragment is explicitly modeled in the control flow graph by a back edge from the node 𝑙𝑜𝑜𝑝𝐸1 to the node 𝑙𝑜𝑜𝑝𝑆1 and another loop exit edge from 𝑙𝑜𝑜𝑝𝐸1 to 𝑚3 (see Figure 1(k)).

There are many more fragments such as par and ref defined in UML 2.x [12], whose graph representations and control flow graphs are not being discussed in this paper due to space limitation; however, they can be treated likewise.

3. Issues with Construction of Control Flow Graph

In this section, we discuss the issues that arise in construction of control flow graph from XMI representation of interaction diagram using mapping rules as followed in the existing approaches.

Let us consider a simple interaction diagram as shown in Figure 2(𝑎). The interaction diagram in Figure 2(𝑎) has five messages 𝑚1, 𝑚2, 𝑚3, 𝑚4, and 𝑚5 and two fragments 𝑜𝑝𝑡1 and 𝑎𝑙𝑡1. Figure 2(𝑏) shows the graph representation with usual bearings as discussed in the previous section. The XMI representation of the interaction diagram as exported from MagicDraw 16.0 tool [21] appears as shown in Figure 3. All tagged elements in the XMI representation are referred by line numbers printed on the left side (see Figure 3).

265235.fig.002
Figure 2: An example interaction diagram and its graph representation. (a) An interaction diagram. (b) Graph representation for Figure 2(𝑎).
fig3
Figure 3: XMI representation of Figure 2(a) exported from Magic Draw 16.0.

Let us consider the mapping rules used for construction of a graph representation from an interaction diagram [2, 4, 11, 17, 18]. As per the mapping rules: (1) message, start and end of a fragment are mapped into nodes in the graph representation; (2) an edge is considered between two nodes representing (a) two messages where one message follows another, or (b) one message and start of a fragment where the fragment follows the message, or (c) end of a fragment and one message where message follows the fragment, or (d) end of a fragment and start of another fragment where second fragment follows the first one; (3) for each fragment, edges are drawn (a) from the node representing the start of a fragment to the node representing the first element (message, fragment) in each of its operands and (b) from the node corresponding to the last element of each operand of the fragment to the node corresponding to end of that fragment. In order to apply the mapping rules as stated above, the primary task is to find the detailed information of model elements such as message, start and end of a fragment in interaction diagram from its XMI representation.

Let us see how the information such as sender and receiver objects and their classes of a message (say, 𝑚1) can be obtained from XMI representation. For this, we need to identify a tagged element that specifies the method whose name is the same as the message 𝑚1. In XMI representation, we observe that name attribute of the tagged element “〈ownedOperation〉” (representing an operation) at line 4 contains the value as same as the name of the message 𝑚1. The corresponding method is defined as call event “_443” in XMI representation (line 66). The call event “_443” actually corresponds to the receive event “_441” of the message “_439” (lines 66 and 25). Note that send and receive events of the message “_439” correspond to the tagged elements containing the attribute value as “xmi: type = MessageOccurrenceSpecification” (lines 24 and 25). These send and receive events occur at the object lifelines referred as the attribute “covered = _376” and “covered = _393” (lines 24 and 25), respectively. The tagged elements corresponding to the lifelines (“xmi: id = _376, “xmi: id = _393”) refer to the associated objects as the attribute “represents = _377” and “represents = _394” (lines 20 and 21). The tagged elements with the attribute xmi: id (“_377”, “_394”) contain the names of the objects: ObjectA and ObjectB (lines 16 and 17). Their class types are obtained as ClassA and ClassB from tagged elements at lines 2 and 3. All these information are for the message 𝑚1, which imply that ObjectA of ClassA sends a message 𝑚1 to ObjectB of ClassB. In other words, for the node 𝑚1 (corresponding to the message 𝑚1) in graph representation, we are to retrieve the information encapsulated in the tagged elements 4, 66, 25, 24, 62, 20, 16, 2, 21, 17 and 3 of the XMI representation.

Similar to a message, start and end of a fragment also correspond to multiple tagged elements in XMI representation. For example, the tagged elements at 34 and 42 correspond to start of two operands of the fragment 𝑎𝑙𝑡1 (xmi: id = “_487”; line 33) and tagged elements at 41 and 49 correspond to the end of two operands of the fragment 𝑎𝑙𝑡1. Furthermore, the tagged elements 33 and 50 correspond to the start and end of the fragment 𝑎𝑙𝑡1, respectively. Therefore, the node 𝑎𝑙𝑡𝑆1 (representing the start of the fragment 𝑎𝑙𝑡1) would correspond to the tagged elements at 33, 34 and 42, whereas the tagged elements at 41, 49 and 50 would correspond to the node 𝑎𝑙𝑡𝐸1 (representing the end of the fragment 𝑎𝑙𝑡1). Note that correspondence among tagged elements (33, 34 and 42) or (41, 49 and 50) are not explicitly specified in XMI representation.

Table 1 shows the association of each node in graph representation with a group of tagged elements in XMI representation. It is evident from Table 1 that the information of each node in graph representation is not only associated with multiple tagged elements but also spread in different places of XMI representation. This implies that the mapping of model elements from XMI representation of interaction diagram to the nodes of its graph representation is not necessarily straightforward. In fact, the conversion process becomes complex when we try to apply the mapping rules to construct edges in graph representation for the fragments of an interaction diagram. This is due to the association of multiple tagged elements in XMI representation with each model element in interaction diagram and tracking the tagged elements between start and end of each operand of a fragment as well as between start and end of each fragment. This is difficult because tagged elements for a fragment are stored in an unstructured way, that is, intermingled with tagged elements of other fragments. The situation becomes more complicated when an operand of a fragment contains a nested fragment of arbitrary nesting depth. That is why the mapping rules are indeed too difficult to apply straightway to XMI representation.

tab1
Table 1: Association of nodes in Figure 2(𝑏) with tagged elements in XMI representation of Figure 3.

4. Proposed Approach

To overcome the difficulties pointed out in the previous section, we have proposed the concept of interaction sequence. Here, the term interaction signifies either a single message or a set of messages of a fragment. We propose a solution to extract the interaction sequences for each fragment precisely and then map them to control flow graph following the mapping rules as discussed in Section 2.2. The major steps in our approach are shown in Figure 4. The first step in our approach is to synthesize metainformation from XMI representation of a given UML interaction diagram. These metainformation are then processed to identify the fragment set and message set. These sets are used to determine the nodes of graph representation in the second step. The fragment structure is obtained in next step. The fourth step determines the edges among nodes of the graph. The edges are labeled in the fifth step. This completes the revealing graph representation of the input interaction diagram. The last step applies set of control flow rules for different types of fragments to obtain the control flow graph. We now discuss the various steps in detail in the following.

265235.fig.004
Figure 4: Block diagram of conversion procedure from XMI of interaction diagram to control flow graph.

Step 1 (identifying the fragments and their message sets). The first step of our conversion approach is to identify a set of fragments and their message sets from values of the attributes of the tagged elements in XMI representation. For this, we use standard SAX (Simple API for XML) parser [22]. Note that SAX is an event-based parser. As the name implies, SAX parser generates events while reading an XML document. The events are related to element opening tags, element closing tags, content of elements, and so forth in the XML document. These events notify an application by calling appropriate event handlers implemented by the application. For example, two event handlers: startElement() and endElement() are invoked when parser reads the opening tag and closing tag of an element, respectively. During invocation of event-handlers, attributes of the tagged elements are passed as a list of parameters. The processing of values of the attributes of the elements in XMI representation is necessary to identify the fragments and their message sets. For this, following the steps need to be carried out.

(a) Storing Values from Tagged Elements
We store values of the attributes of tagged elements as objects of the following classes: EMessage, EMessageEvent, ECallEvent, EOperation, EFragment, EOperand, EObject, EClass, and ELifeline as referred in Table 2. The association of tagged element and value of its attribute “xmi:type” (see Figure 3) with an event is shown in Table 2. This table also depicts which class of object is used to store the values of attributes of a tagged element. Attributes of the classes are shown in Figure 5. The values of the most of the attributes for the objects of these classes would be obtained directly from the values of the attributes of the corresponding tagged elements. Moreover, values of some attributes of objects are to be either obtained from other objects or set with specific value. For example, value of the attribute “type” of an object say, aMEvent (of EMessageEvent class) corresponding to a send event is set as aMEvent.type =sendEvent”, whereas for receive event, it is set as aMEvent.type =receiveEvent”. If an operand contains an inner fragment with its Id as 𝑓𝑖 and aOperand (of EOperand class) is the object corresponding to the operand, then 𝑓𝑖 would be stored in “MessageList” of aOperand along with Ids of other messages in the same sequence as they appear in the operand. In a nutshell, after storing the values of attributes of the tagged elements we would obtain a set of lists of objects of the following classes: (a) EMessage, (b) EMessageEvent, (c) ECallEvent, (d) EOperation, (e) EFragment, (f) EOperand, (g) EObject, (h) EClass, and (i) ELifeline (see Table 2).

tab2
Table 2: Classes to store information of elements in XMI representation.
265235.fig.005
Figure 5: Class diagram for metadata of interaction diagram in XMI.

(b) Synthesizing Details of a Message
We need to synthesize detail information of a message such as name of object method that gets executed when the message is sent, sender object and its class, receiver object and its class, parameters of the message, and return variable (if any). In other words, we are to find the values of the attributes: MethodName, SenderObject, SenderClass, ReceiverObject, ReceiverClass, SeqNumber, ParameterList, and ReturnVar of the object aMessage (of EMessage class) corresponding to a message from the data stored in other objects. To do this, it is necessary to find relationships among classes of these objects. For this, we consider the inherent structure of XMI representation as well as metamodel of interaction diagram as given in UML superstructure specification [1]. The class diagram for representing the relationships among the classes which are used to store tagged elements is shown in Figure 5. Note that one message corresponds to two message events, namely, send and receive events, which may or may not correspond to a call event. This is because only receive event of a message (other than reply message) and send event of reply message correspond to call events. Further, a call event (except for reply message) corresponds to an operation. All this information is represented in the class diagram (see Figure 5). To synthesize values of attributes for an object aMessage of EMessage class using associations (as shown in Figure 5), we identify two objects sMEvent, and rMEvent from the list of EMessageEvent objects such that (i) sMEvent and rMEvent correspond to send and receive events of the message corresponding to aMessage, respectively, (ii) if aMessage represents a reply message, then sMEvent should correspond to a call event (represented by an object say aCallEvent in the list of ECallEvent objects) otherwise, rMEvent would correspond to a call event (corresponding to aCallEvent) that is associated with an operation (represented by an object say, aOperation in the list of EOperation objects). In other words, the conditions are to be satisfied as follows.(a)sMEvent.type = “sendEvent” & sMEvent.Id = aMessage.SendEventId.(b)rMEvent.type = “receiveEvent” & Event.Id = aMessage.ReceiveEventId.(c)(aCallEvent.Id = rMEvent.CallEventId & aOperation.Id = aCallEvent.OperationId) OR (aCallEvent.Id = sMEvent.CallEventId & aMessage.messageType = “reply). These send and receive events (represented by sMEvent and rMEvent) must occur at two lifelines (represented by two objects say sLifeline and rLifeline in the list of ELifeline objects). These two lifelines (sLifeline and rLifeline) are associated with two objects sObject and rObject in the list of EObject objects, respectively. All these imply the satisfiability of the following conditions.(d)sLifeline.Id = sMEvent.LifelineId & rLifeline.Id = rMEvent.LifelineId.(e)sObject.Id = sLifeline.ObjectId & rObject.Id = rLifeline.ObjectId.(f)sClass.Id = sObject.ClassId & rClass.Id = rObject.ClassId.
Using the objects: sObject, rObject, sClass, rClass, aCallEvent, and aOperation as referred in conditions (a)–(f), we obtain the values of instance variables: MethodName, SenderObject, SenderClass, ReceiverObject, ReceiverClass, and SeqNumber of the aMessage object in the list of “EMessage” objects as follows.aMessage.MethodName = aOperation.Name (if aMessage.messageType≠reply”).aMessage.SenderObject = sObject.Name. aMessage.ReceiverObject = rObject.Name.aMessage.SenderClass = sClass.Name.aMessage.ReceiverClass = rClass.Name. aMessage.SeqNumber = aCallEvent.SeqNo.aMessage.parameterList = aOperation.parameterList.Next, we are to find the return variable associated with the message say, 𝑚𝑎 corresponding to object aMessage. Note that the return variable of 𝑚𝑎 is represented as a reply message and specified immediately after 𝑚𝑎 in XMI representation. For this, we identify an object bMessage from a list of EMessage objects such that(g)bMessage.SenderObject = aMessage.ReceiverObject.(h)bMessage.ReceiverObject = aMessage.SenderObject.(i)bCallEvent.SeqNo. aCallEvent.SeqNo. = 1. bMessage.messageType = “reply”.(k)aMessage.messageType≠reply”.Here, bCallEvent refers to a call event for the message corresponding to bObject. If such bMessage object exists for the aMessage, then we set ReturnVar of the aMessage object same as the return value stored in argumentValueList [0] of the bMessage (because reply message can not have more than one return value). In other words, [0]𝑎𝑀𝑒𝑠𝑠𝑎𝑔𝑒.𝑅𝑒𝑡𝑢𝑟𝑛𝑉𝑎𝑟=𝑏𝑀𝑒𝑠𝑠𝑎𝑔𝑒.𝑎𝑟𝑔𝑢𝑚𝑒𝑛𝑡𝑉𝑎𝑙𝑢𝑒𝐿𝑖𝑠𝑡(1) Once value of aMessage.ReturnVar is synthesized from the bMessage object, then bMessage becomes redundant and it should be removed from the list of EMessage objects.

(c) Finding Message Sets and Set of Fragments
After synthesis of values of the attributes of an object aMessage in the list of EMessage objects, we need to find a set of messages 𝑀seq, set of reply messages 𝑅seq (using the value of attribute “messageType”) from that list. A set of fragments 𝐹seq is also to be obtained from the list of EFragment objects. 𝑀seq, 𝑅seq, 𝐹seq can be determined as follows. 𝑀seq𝑅={𝑎𝑀𝑒𝑠𝑠𝑎𝑔𝑒.𝐼𝑑𝑎𝑀𝑒𝑠𝑠𝑎𝑔𝑒existsinthelistof𝐸𝑀𝑒𝑠𝑠𝑎𝑔𝑒𝑜𝑏𝑗𝑒𝑐𝑡𝑠}.seq={𝑎𝑀𝑒𝑠𝑠𝑎𝑔𝑒.𝐼𝑑𝑎𝑀𝑒𝑠𝑠𝑎𝑔𝑒.𝐼𝑑𝑀𝑠𝑒𝑞&𝑎𝑀𝑒𝑠𝑠𝑎𝑔𝑒.𝑚𝑒𝑠𝑠𝑎𝑔𝑒𝑇𝑦𝑝𝑒=𝑟𝑒𝑝𝑙𝑦𝐹}.seq={𝑎𝐹𝑟𝑎𝑔𝑚𝑒𝑛𝑡.𝐼𝑑𝑎𝐹𝑟𝑎𝑔𝑚𝑒𝑛𝑡existsinthelistof𝐸𝐹𝑟𝑎𝑔𝑚𝑒𝑛𝑡objects}.(2)

(d) Finding Message Sets of Fragments
To determine the set of messages of a fragment 𝑓𝑖𝐹seq, we identify the aFragment object (corresponding to the fragment 𝑓𝑖) from the list of EFragment objects and then the set of EOperand objects 𝑆𝑓𝑖𝐸𝑂𝑝𝑟𝑑𝑠 such that an object 𝑎𝑂𝑝𝑒𝑟𝑎𝑛𝑑𝑆𝑓𝑖𝐸𝑂𝑝𝑟𝑑𝑠 is associated with aFragment object, that is, aFragment.OperandList contains the aOperand.Id. In other words, 𝑆𝑓𝑖𝐸𝑂𝑝𝑟𝑑𝑠={𝑎𝑂𝑝𝑒𝑟𝑎𝑛𝑑𝑎𝑂𝑝𝑒𝑟𝑎𝑛𝑑existsinthelistof𝐸𝑂𝑝𝑒𝑟𝑎𝑛𝑑objects&𝑎𝐹𝑟𝑎𝑔𝑚e𝑛𝑡.𝑂𝑝𝑒𝑟𝑎𝑛𝑑𝐿𝑖𝑠𝑡contains𝑎𝑂𝑝𝑒𝑟𝑎𝑛𝑑.𝐼𝑑&𝑓𝑖.𝑎𝐹𝑟𝑎𝑔𝑚𝑒𝑛𝑡(3) We then find the set of EMessage objects 𝑆𝑓𝑖𝐸𝑀𝑠𝑔𝑠 for the fragment 𝑓𝑖 such that 𝑎𝑀𝑒𝑠𝑠𝑎𝑔𝑒𝑆𝑓𝑖𝐸𝑀𝑠𝑔𝑠 is associated with an object 𝑎𝑂𝑝𝑒𝑟𝑎𝑛𝑑𝑆𝑓𝑖𝐸𝑂𝑝𝑟𝑑𝑠, that is, 𝑎𝑂𝑝𝑒𝑟𝑎𝑛𝑑.𝑀𝑒𝑠𝑠𝑎𝑔𝑒𝐿𝑖𝑠𝑡 contains aMessage.Id. In other words, 𝑆𝑓𝑖𝐸𝑀𝑠𝑔𝑠=𝑎𝑀𝑒𝑠𝑠𝑎𝑔𝑒𝑎𝑀𝑒𝑠𝑠𝑎𝑔𝑒existsinthelistof𝐸𝑀𝑒𝑠𝑠𝑎𝑔𝑒objects&𝑎𝑂𝑝𝑒𝑟𝑎𝑛𝑑.𝑀𝑒𝑠𝑠𝑎𝑔𝑒𝐿𝑖𝑠𝑡contains𝑎𝑀𝑒𝑠𝑠𝑎𝑔𝑒.𝐼𝑑&𝑎𝑂𝑝𝑒𝑟𝑎𝑛𝑑𝑆𝑓𝑖𝐸𝑂𝑝𝑟𝑑𝑠.(4) We may note that for the nested fragment 𝑓𝑖, 𝑆𝑓𝑖𝐸𝑀𝑠𝑔𝑠 would contain an object aFragment in the list of EFragment objects and therefore, for each aFragment (corresponding to a fragment 𝑓𝑗) in 𝑆𝑓𝑖𝐸𝑀𝑠𝑔𝑠, we update 𝑆𝑓𝑖𝐸𝑀𝑠𝑔𝑠 as 𝑆𝑓𝑖𝐸𝑀𝑠𝑔𝑠=𝑆𝑓𝑖𝐸𝑀𝑠𝑔𝑠𝑆𝑓𝑗𝐸𝑀𝑠𝑔𝑠{𝑎𝐹𝑟𝑎𝑔𝑚𝑒𝑛𝑡},(5) where 𝑆𝑓𝑗𝐸𝑀𝑠𝑔𝑠 is the set of EMessage objects for the fragment 𝑓𝑗.
Once the update of 𝑆𝑓𝑖𝐸𝑀𝑠𝑔𝑠 is complete, we obtain the set of messages 𝑀𝑓𝑖 of the fragment 𝑓𝑖 from 𝑆𝑓𝑖𝐸𝑀𝑠𝑔𝑠 as 𝑀𝑓𝑖=𝑎𝑀𝑒𝑠𝑠𝑎𝑔𝑒.𝐼𝑑𝑎𝑀𝑒𝑠𝑠𝑎𝑔𝑒𝑆𝑓𝑖𝐸𝑀𝑠𝑔𝑠.(6)

Step 2 (determining the nodes). Initially, control flow graph CFG𝑁,𝐸 is empty. That is, the set of nodes 𝑁 and set of edges 𝐸 are both null. In this step, we determine the message nodes and fragment nodes (i.e., 𝑁) of 𝐶𝐹𝐺. For this, we use the set of messages 𝑀seq, set of fragments 𝐹seq as obtained in Step 1.(a)For each fragment 𝑓𝑖𝐹seq, we add two fragment nodes 𝑓𝑆𝑖 and 𝑓𝐸𝑖 into 𝑁 of CFG𝑁,𝐸, where 𝑓𝑆𝑖 and 𝑓𝐸𝑖 represent the start and end of the fragment 𝑓𝑖, respectively. For each fragment node, we consider (i) the values of instance variables: 𝑡𝑦𝑝𝑒 (𝑇), ID of the EFragment object corresponding to the fragment 𝑓𝑖 and (ii) the boundary (𝐵) of the fragment 𝑓𝑖 (i.e., start boundary or end boundary represented by the fragment node). The value of attribute (𝐵) for the start boundary and end boundary is 𝑆 and 𝐸, respectively. For fragment node, the values of the attributes: RO, 𝑀, PR, and RVar of corresponding tuple 𝑇,ID,𝐵,RO,𝑀,PR,𝑅𝑉𝑎𝑟 would be null.(b)For each 𝑚𝑖𝑀seq, we add a message node 𝑚𝑖 into 𝑁. To obtain the values of associated attributes: 𝑇, ID, RO, 𝑀, PR, and 𝑅𝑉𝑎𝑟 of the tuple for the message node 𝑚𝑖, we consider the values of the instance variables: messageType (𝑇), 𝐼𝑑, ReceiverObject (RO), MethodName (𝑀), ParameterList and ArgumentValueList (set of parameters and their values, PR), and ReturnVar (RVar) (if any) of the EMessage object corresponding to the message 𝑚𝑖. For message node, value of the attribute 𝐵 would be null.(c)For each node in 𝑁 of CFG𝑁,𝐸, we store corresponding tuple 𝑇,ID,𝐵,RO,𝑀,PR,𝑅𝑉𝑎𝑟 in a table, called Node table. The entries corresponding to message nodes in Node table would be in a sequence as same as the sequence number (SeqNumber) of corresponding 𝐸𝑀𝑒𝑠𝑠𝑎𝑔𝑒 objects.

Step 3 (determining fragment structure). In order to find the edges among nodes in 𝑁 of 𝐶𝐹𝐺, we need to determine the hierarchy structure of the fragments formed by the set of messages of interaction diagram (𝑀seq). In other words, we are to find the outermost fragments (the fragments that are not contained in another fragment) built by 𝑀seq and then determine the inner fragments contained in each fragment.(a)To find the outermost fragments formed by the messages in 𝑀seq, we need to identify the minimal set of fragments 𝐹𝐹𝑠𝑒𝑞 that together correspond to the largest subset of 𝑀seq. For this, we follow two steps. (i)Initially, set𝐹=𝐹seq (set of all fragments in interaction diagram).(ii)Exclude the fragment𝑓𝑖 fromF if there exists another fragment𝑓𝑗𝑓𝑖 and𝑓𝑗𝐹 such that𝑀𝑓𝑖𝑀𝑓𝑗, where𝑀𝑓𝑖 and𝑀𝑓𝑗 are the sets of messages of the fragments𝑓𝑖 and𝑓𝑗, respectively. Repeat this step until no such fragment𝑓𝑖 in𝐹 can be excluded. The resultant set𝐹 is the minimum set of fragments that can replace the largest subset of the𝑀seq.We then replace the subset of𝑀seq corresponding to the𝑀𝑓𝑖 for each fragment𝑓𝑖𝐹 by the ID of the fragment𝑓𝑖. This implies that the message set𝑀seq covers all fragments in𝐹 as outermost fragments.(b)To determine the inner fragments contained in each fragment 𝑓𝑖 in 𝐹seq, we need to find the minimal set of fragments 𝐹𝐹seq that together correspond to the largest subset of 𝑀𝑓𝑖 (messages of the fragment 𝑓𝑖). For this, we follow two steps given below.(i)Find the set of fragments 𝐹𝐹seq such that the set of messages say, 𝑀𝑓𝑘 of a fragment 𝑓𝑘𝐹 corresponds to the subset of 𝑀𝑓𝑖 such that 𝑖𝑘.(ii)Exclude the fragment 𝑓𝑘 from 𝐹 if there exists another fragment 𝑓𝑗𝑓𝑘 and 𝑓𝑗𝐹 such that 𝑀𝑓𝑘𝑀𝑓𝑗, where 𝑀𝑓𝑘 and 𝑀𝑓𝑗 are the sets of messages of the fragments 𝑓𝑘 and 𝑓𝑗, respectively. Repeat this step until no such fragment 𝑓𝑘 in 𝐹 can be excluded. The resultant set 𝐹 is the minimum set of fragments that can replace the largest subset of the 𝑀𝑓𝑖.We then replace that largest subset of 𝑀𝑓𝑖 by the IDs of the fragments in 𝐹.

Step 4 (determining the edges). After determining the hierarchy structure of the fragments formed by the set of messages 𝑀seq of the interaction diagram, we find the edges among nodes in 𝑁 of the 𝐶𝐹𝐺 using the following steps.(a)We apply the precedence relation on 𝑀seq and obtain a set of precedence relations say, 𝑃(𝑀seq). For this, we consider the sequence number of all messages (i.e., SeqNumber of corresponding EMessage objects) in 𝑀seq, and in case 𝑀seq contains an interaction (i.e., fragment 𝑓𝑖), then we use the sequence number of a message in the 𝑀𝑓𝑖 (message set of 𝑓𝑖). If 𝑃(𝑀seq) includes a precedence relation (𝐼𝑥𝐼𝑦) such that 𝐼𝑥𝐹seq or 𝐼𝑦𝐹seq, then 𝑃(𝑀seq)=𝑃(𝑀seq)𝑃(𝑀𝑓𝑘), where 𝑃(𝑀𝑓𝑘) is the set of precedence relations on the set of messages of the fragment 𝑓𝑘 and 𝑓𝑘=𝐼𝑥 or 𝐼𝑦. The unions are repeated for all fragment operands present in the precedence relations of 𝑃(𝑀seq). The reason for union operation in computation of 𝑃(𝑀seq) is the presence of some fragment operand 𝑓𝑘 in some precedence relation, which implies that precedence relations among the messages in the fragment 𝑓𝑘 also need to be considered. Note that we compute 𝑃(𝑀𝑓𝑘) using sequence of message 𝐼𝑑(s) in the 𝑀𝑒𝑠𝑠𝑎𝑔𝑒𝐿𝑖𝑠𝑡 of the EOperand objects associated with EFragment object corresponding to the fragment 𝑓𝑘.(b)Considering a precedence relation (𝐼𝑥𝐼𝑦) in 𝑃(𝑀seq), we draw an edge following the set of rules as mentioned below.(i)If 𝐼𝑥,𝐼𝑦𝑀seq, then we draw an edge from the message node (corresponding to 𝐼𝑥) to the message node (corresponding to 𝐼𝑦). This edge implies that the message 𝐼𝑥 occurs immediately before the message 𝐼𝑦.(ii)If 𝐼𝑥𝑀seq, 𝐼𝑦𝐹seq, then an edge is drawn from the message node (corresponding to the message 𝐼𝑥) to the fragment node (corresponding to the start of the fragment 𝐼𝑦). The signification of this edge is that the message 𝐼𝑥 occurs immediately before the start of the interaction that corresponds to the fragment 𝐼𝑦.(iii)If 𝐼𝑥𝐹seq and 𝐼𝑦𝑀seq, then we draw an edge from the fragment node (corresponding to the end of the fragment 𝐼𝑥) to the message node (corresponding to the message 𝐼𝑦). This edge implies that the message 𝐼𝑦 occurs immediately after the end of the interaction that corresponds to the fragment 𝐼𝑥.(iv)If 𝐼𝑥,𝐼𝑦𝐹seq, then an edge is drawn from the fragment node (corresponding to the end of the fragment 𝐼𝑥) to the fragment node (corresponding to the start of the fragment 𝐼𝑦). The significance of this edge is that the end of the interaction which corresponds to the fragment 𝐼𝑥 occurs immediately before the start of the interaction that corresponds to the fragment 𝐼𝑦.(c)Next, we draw an edge corresponding to each left null precedence relation (Λ𝐼)𝑃(𝑀seq). Note that the (Λ𝐼) implies that 𝐼 is the first interaction in a fragment 𝑓𝑘𝐹seq and that interaction 𝐼 is either a message or a set of messages of the inner fragment 𝑓𝑖 of the 𝑓𝑘 and 𝑓𝑖,𝑓𝑘𝐹seq, where 𝑓𝑖𝑓𝑘. Thus, we identify the 𝑀𝑓𝑘 of a fragment 𝑓𝑘𝐹seq such that 𝑀𝑓𝑘 contains 𝐼. It may be noted that 𝑀𝑓𝑘 contains fragments other than messages because the subset of 𝑀𝑓𝑘 has been replaced by the fragments in the preceding step (determine fragment structure). If 𝐼𝐹seq, then we draw an edge from the fragment node (corresponding to start of the fragment 𝑓𝑘) to the fragment node (representing the start of the fragment 𝐼) otherwise, we draw an edge from the fragment node (corresponding to start of the fragment 𝑓𝑘) to the message node (corresponding to the message 𝐼). The edge thus obtained for a left null precedence relation implies that the edge is either between start boundaries of two fragments 𝑓𝑘,𝐼𝐹seq or between the start boundary of the fragment 𝑓𝑘 and the message that occurs first in the 𝑓𝑘.(d)Similarly, for each right null precedence relation (𝐼Λ)𝑃(𝑀seq), we draw an edge in control flow graph. Note that the (𝐼Λ) implies that 𝐼 is the last interaction in a fragment 𝑓𝑘𝐹seq and that interaction 𝐼 is either a message or a set of messages of the inner fragment 𝑓𝑖 of the 𝑓𝑘, where 𝑓𝑖,𝑓𝑘𝐹seq and 𝑓𝑖𝑓𝑘. Thus, we identify the 𝑀𝑓𝑘 for a fragment 𝑓𝑘𝐹seq such that 𝑀𝑓𝑘 contains 𝐼. If 𝐼𝐹seq, then we draw an edge from the fragment node (representing the end of the fragment 𝐼) to the fragment node (representing the end of the fragment 𝑓𝑘) otherwise, we draw an edge from the message node (corresponding to the message 𝐼) to the fragment node (corresponding to end of the fragment 𝑓𝑘). The edge thus obtained for a right null precedence relation implies that the edge is either between end boundaries of two fragments 𝐼,𝑓𝑘𝐹seq or between the message that occurs last in the fragment 𝑓𝑘 and the end boundary of the 𝑓𝑘.

Step 5 (identifying the labels of edges). Once the edges of the control flow graph (CFG) are determined, we assign the guard conditions associated with operands of each fragment of 𝐹seq to the edges in CFG. For this, we consider the edge corresponding to each left precedence relation (Λ𝐼)𝑃(𝑀seq) and label the edge same as the guard condition associated with the operand of the fragment that contains 𝐼 (combined fragment or message). To obtain guard condition, we use value of the instance variable Guard of the EOperand object whose MessageList contains the Id of the 𝐼. The interpretation of this label assignment is, if the guard condition associated with edge is satisfied then all messages in the operand of the fragment would be executed. All other edges would have no label.

Step 6 (applying control flow rules). Once preceding five steps are over, construction of graph representation for the interaction diagram is complete. Note that graph representation of interaction diagram captures control flow for the fragments loop, opt, break, ref, and so forth implicitly (see the discussions in Section 2.2). To reduce this graph representation into control flow graph, we propose a set of rules with the help of the notations given in Table 3.(a)Loop Fragment. The first six rules (R1R6) are for the loop fragment. Rule 𝑅1 says that if there is an edge labeled with 𝑐 from the fragment node representing the start of loop fragment 𝑙𝑜𝑜𝑝𝑖 to message node 𝑚𝑗 and another edge from fragment node representing the end of the loop fragment 𝑙𝑜𝑜𝑝𝑖 to message node 𝑚𝑘, then do the following: (i) add back edge from end of loop fragment 𝑙𝑜𝑜𝑝𝑖 to the start of that loop fragment, (ii) add a loop exit edge from the start of loop fragment 𝑙𝑜𝑜𝑝𝑆𝑖 to the message node 𝑚𝑘 with the label same as !𝑐, and (iii) delete the edge from end of the loop fragment 𝑙𝑜𝑜𝑝𝑖 to the message 𝑚𝑘. Rules 𝑅2 to 𝑅6 are similar to the rule 𝑅1, but only the difference is the contexts where rules are applied. For example, when loop fragment 𝑙𝑜𝑜𝑝𝑖 has an inner fragment 𝑓𝑗 as the first interaction, then rule 𝑅2 is applied. Rule 𝑅3 is applied when 𝑙𝑜𝑜𝑝𝑖 is followed by another fragment 𝑓𝑘. Rule 𝑅4 is applied when 𝑙𝑜𝑜𝑝𝑖 is contained in some other fragment 𝑓𝑘 as the last interaction. Rule 𝑅5 is applied if 𝑙𝑜𝑜𝑝𝑖 has an inner fragment 𝑓𝑗 as the first interaction and 𝑙𝑜𝑜𝑝𝑖 is followed by the fragment 𝑓𝑘. Rule 𝑅6 is applied when loop fragment 𝑙𝑜𝑜𝑝𝑖 has an inner fragment 𝑓𝑗 as the first interaction, and 𝑙𝑜𝑜𝑝𝑖 is contained in some other fragment 𝑓𝑘 as the last interaction. (b)Opt Fragment. The two rules (R7 and R8) are for the opt fragment. According to the rule R7, if there is an edge labeled with 𝑐 from the fragment node representing the start of opt fragment 𝑜𝑝𝑡𝑖 to some message node 𝑚𝑗, then add an edge with the label same as !𝑐 from fragment node representing the start of opt fragment 𝑜𝑝𝑡𝑖 to the end of that opt fragment. Rule R8 is similar to the rule R7, but the difference is that rule R8 is applied only when the opt fragment contains an inner fragment 𝑓𝑗 as the first interaction. (c)Ref Fragment. Only one rule (R9) is for the Ref fragment. Rule R9 says that if ref fragment refers to the interaction diagram ID whose graph representation is ID(𝑆ID,𝐸ID) with the start node 𝑆ID and end node 𝐸ID, respectively, then do the following: (i) add an edge from the start of ref fragment to 𝑆ID, (ii) add an edge from 𝐸ID to the end of ref fragment, and (iii) delete the edge from the start of ref fragment to the end of ref fragment.(d)Break Fragment. Next six rules (R10R15) are for the break fragment. Rules R10–R15 are similar to the rules R1–R6, but only the difference is that back edge is not there in case of break fragment, which is added for loop fragment (see the rules from R1 to R6 and from R10 to R15).

tab3
Table 3: Set of rules.

Illustration of Our Approach
We illustrate our approach for conversion from XMI representation of an interaction diagram to an equivalent control flow graph with the help of a case study pertaining to a Restaurant Automation System (RAS). The RAS automates various functionalities of a restaurant such as Make Order, Process Order, and Generate Bill. Here, we focus only on a particular use case, namely, Generate Bill. In Generate Bill use case, manager of the restaurant inputs Order Number of an order whose Bill is to be generated. Depending on current status of the order (which may not even be processed or delivered) and whether Bill has already been generated for this Order or not, many scenarios can occur, which are modeled in interaction diagram as shown in Figure 6. All messages and fragments in the interaction diagram are referred to as Message Numbers and Fragment labels, respectively (see Figure 6).

265235.fig.006
Figure 6: Interaction diagram of Generate Bill Use Case.

Identifying the Fragments and Their Message Sets
Considering XMI representation of interaction diagram as input (see Figure 6), we first parse it using SAX parser and then obtain a set of lists of objects of following classes: (a) EMessage, (b) EMessageEvent, (c) ECallEvent, (d) EOperation, (e) EFragment, (f) EOperand, (g) EObject, (h) EClass, and (i) ELifeline (see Table 2). The values of the instance variables of aMessage object in the list of EMessage objects are set with the values from the objects of other classes considering class relationships as discussed in Step 1. We then obtain the following.(a)From the list of EMessage objects, we find set of messages 𝑀seq = {1, 2, 3, 4, 5, 6, 7, 8, 9, 10, 11, 12, 13, 14, 15, 16, 17, 18, 19}. On the other hand, the set of fragments 𝐹seq is obtained from the list of EFragment objects as 𝐹seq={𝑙𝑜𝑜𝑝1,𝑎𝑙𝑡1,𝑎𝑙𝑡2,𝑏𝑟𝑒𝑎𝑘1,𝑙𝑜𝑜𝑝2,𝑏𝑟𝑒𝑎𝑘2} (see Figure 6).(b) We then identify set of messages for a fragment 𝑓𝑖𝐹seq with considering the EFragment object corresponding to 𝑓𝑖 as well as the set of EOperand objects associated with the EFragment object (see Step 1) as 𝑀𝑙𝑜𝑜𝑝1={3}, 𝑀𝑎𝑙𝑡1={4,5}, 𝑀𝑎𝑙𝑡2 = {6,7, 8, 9, 10, 11, 12, 13, 14, 15, 16, 17, 18 }, 𝑀𝑏𝑟𝑒𝑎𝑘1={7}, 𝑀𝑙𝑜𝑜𝑝2 = {9, 10}, and 𝑀𝑏𝑟𝑒𝑎𝑘2={10}.

Determining the Nodes
We determine the nodes of control flow graph from 𝑀seq and 𝐹seq as follows.(a)We add two fragment nodes into the set of nodes N of control flow graph for each fragment 𝑓𝑖𝐹seq and thus obtain N as {𝑙𝑜𝑜𝑝𝑆1,𝑙𝑜𝑜𝑝𝐸1,𝑎𝑙𝑡𝑆1,𝑎𝑙𝑡𝐸1,𝑎𝑙𝑡𝑆2,𝑎𝑙𝑡𝐸2,𝑏𝑟𝑒𝑎𝑘𝑆1,𝑏𝑟𝑒𝑎𝑘𝐸1,𝑙𝑜𝑜𝑝𝑆2,𝑙𝑜𝑜𝑝𝐸2,𝑏𝑟𝑒𝑎𝑘𝑆2,𝑏𝑟𝑒𝑎𝑘𝐸2} (see Figure 7). (b)Adding a message node 𝑚𝑖 for each𝑖𝑀𝑠𝑒𝑞, the set of nodes𝑁 becomes N = N∪ {m1, m2, m3, m4, m5, m6, m7, m8, m9, m10, m11, m12, m13, m14, m15, m16, m17, m18, m19}. Here, the filled nodes represent fragment nodes, and empty nodes represent message nodes (see control flow graph in Figure 7).(c)We store the values of tuple 〈T, ID, B, RO, M, PR, RVar〉 for all nodes in N of CFG 𝑁,𝐸 in a table named as Node table (see Table 4). For message node 𝑚𝑖𝑁, we use the values of instance variables of EMessage object corresponding to the message 𝑖𝑀seq. We obtain the information for the fragment nodes from the EFragment objects (see Table 4). Note that for message node corresponding to a reply message, PR would be same as the return value if any, and both M and RVar would be empty.

tab4
Table 4: Node table.
fig7
Figure 7: Graph representation and control flow graph of interaction diagram for Generate Bill use case.

Determining Fragment Structure
In this step, we first find the outermost fragments formed by the set of messages 𝑀seq. We then determine the inner fragments contained in each fragment to find the hierarchy structure of the fragments. (a)We need to determine the minimum number of fragments 𝐹 that together correspond to the largest subset of Mseq. The 𝐹 is initialized as the set of all fragments of the interaction diagram, that is, 𝐹=𝐹seq={𝑙𝑜𝑜𝑝1,𝑎𝑙𝑡1,𝑎𝑙𝑡2,𝑏𝑟𝑒𝑎𝑘1,𝑙𝑜𝑜p2,𝑏𝑟𝑒𝑎𝑘2}. We observe that 𝑀𝑏𝑟𝑒𝑎𝑘1𝑀𝑎𝑙𝑡2,𝑀𝑙𝑜𝑜𝑝2𝑀𝑎𝑙𝑡2, and 𝑀𝑏𝑟𝑒𝑎𝑘2𝑀𝑙𝑜𝑜𝑝2. As each message set of three fragments break1, loop2, and break2 is subset of message set of alt2, we exclude these three fragments from 𝐹, which reduces 𝐹={𝑙𝑜𝑜𝑝1,𝑎𝑙𝑡1,𝑎𝑙𝑡2}. That implies that fragments loop1, alt1, and alt2 together are sufficient to replace the largest subset {3, 4, 5, 6, 7, 8, 9, 10, 11, 12, 13, 14, 15, 16, 17, 18} of 𝑀seq and are the outermost fragments formed by the messages in 𝑀seq. Replacing the largest subset of 𝑀seq by the fragments in 𝐹, we obtain 𝑀seq = {1, 2, loop1, alt1, alt2, 19}.(b)To determine the hierarchy structure of the fragments in 𝐹seq, let us first consider the fragment loop2. Only one fragment break2 is sufficient to replace the largest subset {10} of 𝑀𝑙𝑜𝑜𝑝2={9,10}. After replacing the largest subset of 𝑀𝑙𝑜𝑜𝑝2 by break2, we obtain 𝑀𝑙𝑜𝑜𝑝2={9,𝑏𝑟𝑒𝑎𝑘2}. Therefore, loop2 contains only one inner fragment break2. Now consider another fragment alt2. In this case, minimal set of fragments 𝐹 = {break1, loop2} is sufficient enough to replace together the largest subset {7, 9, 10} of 𝑀𝑎𝑙𝑡2 = {6, 7, 8, 9, 10, 11, 12, 13, 14, 15, 16, 17, 18}. Therefore, after replacing corresponding subset of 𝑀𝑎𝑙𝑡2 by each fragment in 𝐹, we obtain 𝑀𝑎𝑙𝑡2 = {6, break1, 8, loop2, 11, 12, 13, 14, 15, 16, 17, 18}. It implies that fragment alt2 contains inner fragments break1 and loop2. Note that 𝑀𝑙𝑜𝑜𝑝1, 𝑀𝑎𝑙𝑡1, 𝑀𝑏𝑟𝑒𝑎𝑘1, and 𝑀𝑏𝑟𝑒𝑎𝑘2 remain unchanged as there is no fragment in 𝐹seq that can replace the subset of message sets of fragments loop1, alt1, break1, and break2.

Determining the Edges
In this step, we first apply precedence relations on 𝑀seq. Depending on the operand of the precedence relation, we determine the edges. (a)Applying on Mseq, we obtain P(Mseq) = {1 2, 2 ≺loop1, loop1≺alt1, alt1≺alt2, alt2 19} ∪P(𝑀𝑙𝑜𝑜𝑝1) ∪P(𝑀𝑎𝑙𝑡1) ∪P(𝑀𝑎𝑙𝑡2). These unions are for the fragment operands loop1, alt1, and alt2 present in the precedence relations of P(Mseq). To compute the unions, we need to have the sets of precedence relations for each fragment operand: loop1, alt1, and alt2. They are computed as below. (i)P (𝑀𝑙𝑜𝑜𝑝1) = {Λ 3, 3 Λ}.(ii)P (𝑀𝑎𝑙𝑡1) = {Λ 4, 4 Λ, Λ 5, 5 Λ}.(iii)P (𝑀𝑎𝑙𝑡2) = {Λ 6, 6 ≺break1, break1 8, 8 ≺loop2, loop2 11, 11 12, 12 13, 13 14, 14 15, 15 16, 16 17, 17 Λ, Λ 18, 18 Λ} ∪P (𝑀𝑏𝑟𝑒𝑎𝑘1)}∪P (𝑀𝑙𝑜𝑜𝑝2).(iv)P (𝑀𝑏𝑟𝑒𝑎𝑘1) = {Λ 7, 7 Λ}.(v)P (𝑀𝑙𝑜𝑜𝑝2) = {Λ 9, 9 ≺break2, break2 Λ} ∪P (𝑀𝑏𝑟𝑒𝑎𝑘2).(vi)P (𝑀𝑏𝑟𝑒𝑎𝑘2) = {Λ 10, 10 Λ}. Therefore, P (𝑀seq) = {1 2, 2 ≺loop1, loop1≺alt1, alt1≺alt2, alt2 19, Λ 3, 3 Λ, Λ 4, 4 Λ, Λ 5, 5 Λ, Λ 6, 6 ≺break1, break1 8, 8 ≺loop2, loop2 11, 11 12, 12 13, 13 14, 14 15, 15 16, 16 17, 17 Λ, Λ 18, 18 Λ, Λ 7, 7 Λ, Λ 9, 9 ≺break2, break2 Λ, Λ 10, 10 Λ}. (b)Depending on the operand of a precedence relation (𝐼𝑥𝐼𝑦) in P(Mseq), we draw an edge in control flow graph as follows. (i) In our example, we have seven precedence relations 1 2, 11 12, 12 13, 13 14, 14 15, 15 16, and 16 17 satisfying the condition (𝐼𝑥,𝐼𝑦𝑀seq) and thus, we draw seven edges (m1, m2), (m11, m12), (m12, m13), (m13, m14), (m14, m15), (m15, m16), and (m16, m17) in control flow graph. (ii)The condition (𝐼𝑥𝑀seq,𝐼𝑦𝐹seq) is satisfied by the precedence relations: 2 ≺loop1, 6 ≺break1, 8 ≺loop2, and 9 ≺break2, and they correspond to four edges (𝑚2,𝑙𝑜𝑜𝑝𝑆1),(𝑚6,𝑏𝑟𝑒𝑎𝑘𝑆1), (𝑚8,𝑙𝑜𝑜𝑝𝑆2), and (𝑚9,𝑏𝑟𝑒𝑎𝑘𝑆2). (iii)There are three precedence relations alt2 19, break1 8, and loop2 11 satisfying the condition (𝐼𝑥𝐹seq,𝐼𝑦𝑀seq). Therefore, we draw three edges (𝑎𝑙𝑡𝐸2,𝑚19),(𝑏𝑟𝑒𝑎𝑘𝐸1,𝑚8), and (𝑙𝑜𝑜𝑝𝐸2,𝑚11). (iv)The two precedence relations: loop1≺alt1 and alt1≺alt2 satisfy the condition (𝐼𝑥,𝐼𝑦𝐹seq). Considering these two precedence relations, we draw two edges (𝑙𝑜𝑜𝑝𝐸1,𝑎𝑙𝑡𝑆1) and (𝑎𝑙𝑡𝐸1,𝑎𝑙𝑡𝑆2). (c)In our example, 𝑃(𝑀seq) (as obtained in step (a)) has the following left null precedence relations: Λ 3, Λ 4, Λ 5, Λ 6, Λ 7, Λ 9, Λ 10, and Λ 18. Here, the fragment loop1 contains 3; alt1 contains 4, 5; alt2 contains 6, 18; break1 contains 7; loop2 contains 9; break2 contains 10 (see the message sets 𝑀𝑙𝑜𝑜𝑝1, 𝑀𝑎𝑙𝑡1, 𝑀𝑎𝑙𝑡2, 𝑀𝑏𝑟𝑒𝑎𝑘1, 𝑀𝑙𝑜𝑜𝑝2, and 𝑀𝑏𝑟𝑒𝑎𝑘2). For these eight left precedence relations, we draw the following edges (𝑙𝑜𝑜𝑝𝑆1,𝑚3),(𝑎𝑙𝑡𝑆1,𝑚4),(𝑎𝑙𝑡𝑆1,𝑚5),(𝑎𝑙𝑡𝑆2,𝑚6),(𝑎𝑙𝑡𝑆2,𝑚18),(𝑏𝑟𝑒𝑎𝑘𝑆1,𝑚7),(𝑙𝑜𝑜𝑝𝑆2,𝑚9), and (𝑏𝑟𝑒𝑎𝑘𝑆2,𝑚10). (d)There are eight right null precedence relations: 3 Λ, 4 Λ, 5 Λ, 17 Λ, 18 Λ, 7 Λ, break2 Λ, and 10 Λ. Among them, only one break2 Λ has fragment operand and the fragment loop2 contains break2 (see the 𝑀𝑙𝑜𝑜𝑝2 and 𝑀𝑏𝑟𝑒𝑎𝑘2 after replacement in the step [determine fragment structure]). For this right null precedence relation, we draw an edge (𝑏𝑟𝑒𝑎𝑘𝐸2,𝑙𝑜𝑜𝑝𝐸2). For remaining seven right null precedence relations, we draw seven edges (𝑚3,𝑙𝑜𝑜𝑝𝐸1),(𝑚4,𝑎𝑙𝑡𝐸1), (𝑚5,𝑎𝑙𝑡𝐸1),(𝑚17,𝑎𝑙𝑡𝐸2),(𝑚18,𝑎𝑙𝑡𝐸2),(𝑚7,𝑏𝑟𝑒𝑎𝑘𝐸1), and (𝑚10,𝑏𝑟𝑒𝑎𝑘𝐸2).

Identifying the Labels of Edges
We label the edges in the control flow graph corresponding to the left null precedence relations. Let us now consider a left null precedence relation Λ 7. Here, 7𝑀𝑏𝑟𝑒𝑎𝑘1, this means that fragment break1 contains the message 7. The only one operand of the break1 that contains the message 7 is associated with the condition Status Delivered”. Therefore, the edge (𝑏𝑟𝑒𝑎𝑘𝑆1,𝑚7) corresponding to (Λ 7) is labeled with the constraint: Status Delivered”. Similarly, the edges corresponding to other left null precedence relations are labeled as shown in Figure 7. At the end of this step, the control flow graph for Generate Bill interaction diagram is the same as the graph representation as shown in Figure 7(a).

Applying Control Flow Rules
In our example interaction diagram, we have two loop fragments and two break fragments. So, we need to apply the control flow rules for them. We observe that first loop fragment (loop1) does not contain an inner fragment and is followed by another fragment 𝑎𝑙𝑡1, and thus we apply the rule 𝑅3. Applying the rule 𝑅3, we add two edges (𝑙𝑜𝑜𝑝𝐸1, 𝑙𝑜𝑜𝑝𝑆1) and (𝑙𝑜𝑜𝑝𝑆1,𝑎𝑙𝑡𝑆1) and delete the edge (𝑙𝑜𝑜𝑝𝐸1,𝑎𝑙𝑡𝑆1). For the fragment 𝑏𝑟𝑒𝑎𝑘1, we apply the rule 𝑅10 as 𝑏𝑟𝑒𝑎𝑘1 does not contain an inner fragment and is not followed by another fragment. Applying the rule, we delete the edge (𝑏𝑟𝑒𝑎𝑘𝐸1, 𝑚8) and add the edge (𝑏𝑟𝑒𝑎𝑘𝑆1, 𝑚8). Applying rule 𝑅13 for the fragment 𝑏𝑟𝑒𝑎𝑘2, we delete the edge (𝑏𝑟𝑒𝑎𝑘𝐸2, 𝑙𝑜𝑜𝑝𝐸2) and add the edge (𝑏𝑟𝑒𝑎𝑘𝑆2, 𝑙𝑜𝑜𝑝𝐸2). Here, the loop fragment 𝑙𝑜𝑜𝑝2 does not contain a fragment as first interaction and is not followed by a fragment. So, we apply the rule 𝑅1 and add edges (𝑙𝑜𝑜𝑝𝐸2, 𝑙𝑜𝑜𝑝𝑆2) and (𝑙𝑜𝑜𝑝𝑆2, 𝑚11) and delete the edge (𝑙𝑜𝑜𝑝𝐸2, 𝑚11). After applying these control flow rules, we obtain the final control flow graph as shown in Figure 7(b).

5. XMI2CFG: A Prototype Tool

We have developed a prototype tool named as 𝑋𝑀𝐼2𝐶𝐹𝐺 (XMI of interaction diagram to control flow graph) following our approach. We have implemented 𝑋𝑀𝐼2𝐶𝐹𝐺 in Java language (Java 2) using NetBeans IDE 6.1 [23]. Input of 𝑋𝑀𝐼2𝐶𝐹𝐺 is the XMI representation of UML 2.x interaction diagram. We have used MagicDraw 16.0 [21] to draw interaction diagram and subsequently exported this diagram in the form of XMI representation. 𝑋𝑀𝐼2𝐶𝐹𝐺 visualizes the control flow graph as the output. 𝑋𝑀𝐼2𝐶𝐹𝐺 consists of two main components: CFGConstructionUnit and VisualizationUnit. CFGConstructionUnit first parses the XMI of interaction diagram and then converts it into control flow graph. Taking control flow graph as the input, VisualizationUnit changes it into the DOT language format [24] and produces an image to visualize the control flow graph. Two components: CFGConstructionUnit and VisualizationUnit are described below.

CFGConstructionUnit
This component parses the XMI representation of interaction diagram using SAX parser. The class diagram of this component is shown in Figure 8. This component comprises of two main classes: MyParser, and CFGConstructor, and other auxiliary classes: EMessage, ELifeline, EClass, ECallEvent, EMessageEvent, EObject, Fragment, EOperand, EOperation, EFragment, Node, and Edge. Dependency among these classes is also depicted in Figure 8.

265235.fig.008
Figure 8: The class diagram of 𝐶𝐹𝐺𝐶𝑜𝑛𝑠𝑡𝑟𝑢𝑐𝑡𝑖𝑜𝑛𝑈𝑛𝑖𝑡.

The 𝑀𝑦𝑃𝑎𝑟𝑠𝑒𝑟 class implements the event-handlers startElement(), endElement(), characters(), and endDocument() to interface with SAX parser. For this, we have used the library of Apache Xerces available in the web portal [22]. In the event-handler startElement(), we process the tagged elements starting with the names same as “ownedAttribute”, “lifeline”, “fragment”, “operand”, “guard”, “specification”, “argument”, “body”, “ownedParameter”, “message” and “packagedElement”, “ownedOperation”, “ownedBehavior”, “guard”, and “ownedParameter”. Depending on type of tagged elements, we categorize them as “MessageEvent”, “Fragment”, “CallEvent”, “Object”, “Class”, “Lifeline”, “Operand”, “Message”, “Operation”, “Parameter”, “SequenceDiagram”, and “Guard”. When multiple tagged elements start with the same name, then we consider the value of the attribute “XMI type”. For example, tagged elements specifying the class name and call event start with the same name “𝑝𝑎𝑐𝑘𝑎𝑔𝑒𝑑𝐸𝑙𝑒𝑚𝑒𝑛𝑡”. In order to distinguish them, we have considered whether the attribute “XMI type” has the value as “uml:CallEvent” or “uml:Class”. For each processed tagged element, we retrieve the associated metainformation of interaction diagram from SAX parser and store them by means of instance variables: 𝐼𝑑, 𝑁𝑎𝑚𝑒, 𝐶𝑙𝑎𝑠𝑠𝐼𝑑, 𝑂𝑏𝑗𝑒𝑐𝑡𝐼𝑑, FragmentType, 𝐺𝑢𝑎𝑟𝑑, 𝑆𝑒𝑛𝑑𝐸𝑣𝑒𝑛𝑡𝐼𝑑, 𝑅𝑒𝑐𝑒𝑖𝑣𝑒𝐸𝑣𝑒𝑛𝑡𝐼𝑑, 𝐶𝑎𝑙𝑙𝐸𝑣𝑒𝑛𝑡𝐼𝑑, 𝑀𝑒𝑠𝑠𝑎𝑔𝑒𝑇𝑦𝑝𝑒, 𝑂𝑝𝑒𝑟𝑎𝑡𝑖𝑜𝑛𝐼𝑑, 𝑀𝑒𝑠𝑠𝑎𝑔𝑒𝐼𝑑, and 𝐿𝑖𝑓𝑒𝑙𝑖𝑛𝑒𝐼𝑑 of the class named 𝑀𝑦𝑃𝑎𝑟𝑠𝑒𝑟. Note that after processing of a tagged element, only relevant variables would have meaningful values, and the rest would have the 𝑛𝑢𝑙𝑙 value.

Once metainformation of interaction diagram is available through instance variables of 𝑀𝑦𝑃𝑎𝑟𝑠𝑒𝑟 object, we instantiate metaobject of particular type as mentioned in metaclass diagram of interaction diagram (see Figure 5). We then pass the meta-object to CFGConstructor object via parameter of its method RegisterSAXEvent(). After all necessary metaobjects are passed to 𝐶𝐹𝐺𝐶𝑜𝑛𝑠𝑡𝑟𝑢𝑐𝑡𝑜𝑟, then 𝐶𝐹𝐺𝐶𝑜𝑛𝑠𝑡𝑟𝑢𝑐𝑡𝑜𝑟 object would have a set of arraylists of objects: 𝐸𝑀𝑒𝑠𝑠𝑎𝑔𝑒𝐿𝑖𝑠𝑡, 𝐸𝐹𝑟𝑎𝑔𝑚𝑒𝑛𝑡𝐿𝑖𝑠𝑡, 𝐸𝑂𝑝𝑒𝑟𝑎𝑛𝑑𝐿𝑖𝑠𝑡, 𝐸𝑂𝑝𝑒𝑟𝑎𝑡𝑖𝑜𝑛𝐿𝑖𝑠𝑡, 𝐸𝐶𝑎𝑙𝑙𝐸𝑣𝑒𝑛𝑡𝐿𝑖𝑠𝑡, 𝐸𝑀𝑒𝑠𝑠𝑎𝑔𝑒𝐸𝑣𝑒𝑛𝑡𝐿𝑖𝑠𝑡, 𝐸𝐿𝑖𝑓𝑒𝑙𝑖𝑛𝑒𝐿𝑖𝑠𝑡, 𝐸𝑂𝑏𝑗𝑒𝑐𝑡𝐿𝑖𝑠𝑡, and 𝐸𝐶𝑙𝑎𝑠𝑠𝐿𝑖𝑠𝑡. These arraylists store meta object of types 𝐸𝑀𝑒𝑠𝑠𝑎𝑔𝑒, 𝐸𝐹r𝑎𝑔𝑚𝑒𝑛𝑡, 𝐸𝑂𝑝𝑒𝑟𝑎𝑛𝑑, 𝐸𝑂𝑝𝑒𝑟𝑎𝑡𝑖𝑜𝑛, 𝐸𝐶𝑎𝑙𝑙𝐸𝑣𝑒𝑛𝑡, 𝐸𝑀𝑒𝑠𝑠𝑎𝑔𝑒𝐸𝑣𝑒𝑛𝑡, 𝐸𝐿𝑖𝑓𝑒𝑙𝑖𝑛𝑒, 𝐸𝑂𝑏𝑗𝑒𝑐𝑡, and 𝐸𝐶𝑙𝑎𝑠𝑠, respectively. To keep the track of the hierarchy structure of fragments as well as operands of a fragment, we use two arraylists: 𝐹𝑟𝑎𝑔𝑚𝑒𝑛𝑡𝐼𝐷𝐿𝑖𝑠𝑡 and 𝑂𝑝𝑒𝑟𝑎𝑛𝑑𝐼𝐷𝐿𝑖𝑠𝑡. Note that 𝐹𝑟𝑎𝑔𝑚𝑒𝑛𝑡𝐼𝐷𝐿𝑖𝑠𝑡 and 𝑂𝑝𝑒𝑟𝑎𝑛𝑑𝐼𝐷𝐿𝑖𝑠𝑡 keep the 𝐼𝐷s of fragments and operands whose processing is still remaining. In order to update these two arryalists, we add the 𝐼𝐷 into corresponding arraylist within 𝑠𝑡𝑎𝑟𝑡𝐸𝑙𝑒𝑚𝑒𝑛𝑡() when SAX parser notifies about the opening of fragment/operand tag. Similarly, we remove the ID of fragment/operand from the corresponding list within 𝑒𝑛𝑑𝐸𝑙𝑒𝑚𝑒𝑛𝑡(), when SAX parser notifies about the closing of the fragment/operand. We also use different flags such as 𝑂𝑝𝑒𝑟𝑎𝑡𝑖𝑜𝑛𝑃𝑎𝑟𝑎𝑚𝑒𝑡𝑒𝑟𝐹𝑙𝑎𝑔, and 𝐺𝑢𝑎𝑟𝑑𝐹𝑙𝑎𝑔 to keep tracking the end of processing of parameters of recent operation and guard associated with fragment operand.

The conversion logic is encapsulated in different methods such as 𝐶𝑜𝑚𝑝𝑢𝑡𝑒𝑀𝑒𝑠𝑠𝑎𝑔𝑒𝑆𝑒𝑡(), 𝐶𝑜𝑚𝑝𝑢𝑡𝑒𝐹𝑟𝑎𝑔𝑚𝑒𝑛𝑡𝑆𝑒𝑡(), 𝐷𝑒𝑡𝑒𝑟𝑚𝑖𝑛𝑒𝐹𝑟𝑎𝑔𝑚𝑒𝑛𝑡𝑆𝑡𝑟𝑢𝑐𝑡𝑢𝑟𝑒(), 𝐷𝑒𝑡𝑒𝑟𝑚𝑖𝑛𝑒𝐶𝐹𝐺𝑁𝑜𝑑𝑒𝑠(), 𝐶𝑜𝑚𝑝𝑢𝑡𝑒𝑃𝑟𝑒𝑐𝑒𝑑𝑒𝑛𝑐𝑒𝑅𝑒𝑙𝑎𝑡𝑖𝑜𝑛𝑠(), 𝐷𝑒𝑡𝑒𝑟𝑚𝑖𝑛𝑒𝐶𝐹𝐺𝐸𝑑𝑔𝑒𝑠(), 𝐷𝑒𝑡𝑒𝑟𝑚𝑖𝑛𝑒𝐸𝑑𝑔𝑒𝐿𝑎𝑏𝑒𝑙(), and 𝐴𝑝𝑝𝑙𝑦𝐶𝑜𝑛𝑡𝑟𝑜𝑙𝐹𝑙𝑜𝑤𝑅𝑢𝑙𝑒𝑠() of 𝐶𝐹𝐺𝐶𝑜𝑛𝑠𝑡𝑟𝑢𝑐𝑡𝑜𝑟 class. Two methods 𝐶𝑜𝑚𝑝𝑢𝑡𝑒𝑀𝑒𝑠𝑠𝑎𝑔𝑒𝑆𝑒𝑡() and 𝐶𝑜𝑚𝑝𝑢𝑡𝑒𝐹𝑟𝑎𝑔𝑚𝑒𝑛𝑡𝑆𝑒𝑡() perform the first step of our conversion approach, that is, computing the message set and fragment set. Two arraylists 𝐸𝑀𝑒𝑠𝑠𝑎𝑔𝑒𝐿𝑖𝑠𝑡 and 𝐸𝐹𝑟𝑎𝑔𝑚𝑒𝑛𝑡𝐿𝑖𝑠𝑡 are used for this purpose. 𝐷𝑒𝑡𝑒𝑟𝑚𝑖𝑛𝑒𝐶𝐹𝐺𝑁𝑜𝑑𝑒𝑠() performs the second step of conversion. Two 𝑁𝑜𝑑𝑒 objects for each fragment (specifying the start and end of the fragment) and one 𝑁𝑜𝑑𝑒 object for each message are instantiated. Node information (i.e., the values of instance variables of 𝑁𝑜𝑑𝑒 object) is obtained from arraylists 𝐸𝑀𝑒𝑠𝑠𝑎𝑔𝑒𝐿𝑖𝑠𝑡 and 𝐸𝐹𝑟𝑎𝑔𝑚𝑒𝑛𝑡𝐿𝑖𝑠𝑡. Once a 𝑁𝑜𝑑𝑒 object is instantiated, it is added into arraylist named 𝐶𝐹𝐺𝑁𝑜𝑑𝑒𝐿𝑖𝑠𝑡. As per our conversion approach, 𝐷𝑒𝑡𝑒𝑟𝑚𝑖𝑛𝑒𝐹𝑟𝑎𝑔𝑚𝑒𝑛𝑡𝑆𝑡𝑟𝑢𝑐𝑡𝑢𝑟𝑒() first identifies the minimum number of outermost fragments that can replace largest subset of message set of interaction diagram and replaces that subset by IDs of outermost fragments. After that, for message set of each fragment, a set of inner fragment IDs is identified, and the subset of message set of the fragment is replaced by 𝐼𝐷s of inner fragments (see details in the third step of our conversion procedure). C𝑜𝑚𝑝𝑢𝑡𝑒𝑃𝑟𝑒𝑐𝑒𝑑𝑒𝑛𝑐𝑒𝑅𝑒𝑙𝑎𝑡𝑖𝑜𝑛𝑠() computes the precedence relations using 𝑆𝑒𝑞𝑁𝑜. of interaction (message/fragment) in message set of interaction diagram. If a fragment operand is found in some precedence relation, then precedence relations among messages of the fragment also need to be computed. Based on type of operand in precedence relation, 𝐷𝑒𝑡𝑒𝑟𝑚𝑖𝑛𝑒𝐶𝐹𝐺𝐸𝑑𝑔𝑒𝑠() determines the edges between message and message, message and fragment start, fragment end and message, and fragment end and fragment start. In addition to this, 𝐷𝑒𝑡𝑒𝑟𝑚𝑖𝑛𝑒𝐶𝐹𝐺𝐸𝑑𝑔𝑒𝑠() also finds the edges corresponding to null precedence relations. These edges are between fragment start and message, fragment start and fragment start, message and fragment end, and fragment end and fragment end. For each edge, we identify a pair of 𝑁𝑜𝑑𝑒 objects which correspond to the end nodes of the edge, and then instantiate an 𝐸𝑑𝑔𝑒 object using references of the associated 𝑁𝑜𝑑𝑒 objects. Once an 𝐸𝑑𝑔𝑒 object is instantiated, it is added into arraylist named 𝐶𝐹𝐺𝐸𝑑𝑔𝑒𝐿𝑖𝑠𝑡. To construct the edge label, 𝐷𝑒𝑡𝑒𝑟𝑚𝑖𝑛𝑒𝐸𝑑𝑔𝑒𝐿𝑎𝑏𝑒𝑙() first identifies 𝐸𝑑𝑔𝑒 object corresponding to that edge and hence, 𝐸𝑂𝑝𝑒𝑟𝑎𝑛𝑑 object corresponding to an operand which contains the fragment/message referenced by the second operand of the precedence relation for that edge. After that, the 𝐸𝑑𝑔𝑒 label is set as same as the instance variable 𝐺𝑢𝑎𝑟𝑑 of the corresponding 𝐸𝑂𝑝𝑒𝑟𝑎𝑛𝑑 object. The A𝑝𝑝𝑙𝑦𝐶𝑜𝑛𝑡𝑟𝑜𝑙𝐹𝑙𝑜𝑤𝑅𝑢𝑙𝑒𝑠() adds and deletes the edges depending on control flow rules for the fragments: 𝑜𝑝𝑡, 𝑏𝑟𝑒𝑎𝑘, 𝑙𝑜𝑜𝑝, and so forth. Final control flow graph is captured in two arryalists: 𝐶𝐹𝐺𝑁𝑜𝑑𝑒𝐿𝑖𝑠𝑡 and 𝐶𝐹𝐺𝐸𝑑𝑔𝑒𝐿𝑖𝑠𝑡.

Visualization Unit
The main task of this component is to visualize the control flow graph in an image form. VisualizationUnit comprises of two main classes: 𝐷𝑜𝑡𝐶𝑜𝑛𝑣𝑒𝑟𝑡𝑜𝑟 and 𝐺𝑟𝑎𝑝𝑉𝑖𝑧. We have used the code of 𝐺𝑟𝑎𝑝𝑉𝑖𝑧 available in [25]. Taking two arraylists 𝐶𝐹𝐺𝑁𝑜𝑑𝑒𝐿𝑖𝑠𝑡 and 𝐶𝐹𝐺𝐸𝑑𝑔𝑒𝐿𝑖𝑠𝑡 as the input, the 𝐷𝑜𝑡𝐶𝑜𝑛𝑣𝑒𝑟𝑡𝑜𝑟 object creates a  .𝑑𝑜𝑡 file by using node and edge specification as per DOT language [24]. To specify them in 𝐷𝑂𝑇 language, we have used different methods such as 𝑠𝑡𝑎𝑟𝑡_𝑑𝑖𝑔𝑟𝑎𝑝(), 𝑎𝑑𝑑𝑙𝑛(), and 𝑒𝑛𝑑_𝑔𝑟𝑎𝑝() of 𝐺𝑟𝑎𝑝𝑉𝑖𝑧 class. Once  .𝑑𝑜𝑡 file is created, an image is produced by calling the methods 𝑔𝑒𝑡𝐷𝑜𝑡𝑆𝑜𝑢𝑟𝑐𝑒(), 𝑔𝑒𝑡𝐺𝑟𝑎𝑝(), and 𝑤𝑟𝑖𝑡𝑒𝐺𝑟𝑎𝑝𝑇𝑜𝐹𝑖𝑙𝑒() of 𝐺𝑟𝑎𝑝𝑉𝑖𝑧.

𝑋𝑀𝐼2𝐶𝐹𝐺 supports different menu options for selecting an XMI file, displaying XMI file, parsing selected XMI file, starting conversion, and display control flow graph in both DOT language and image form. One typical usage scenario of 𝑋𝑀𝐼2𝐶𝐹𝐺 is depicted in Figure 9. In this usage scenario, we first select and display the XMI file in upper left panel. We then select the option to start parsing and subsequently construct the control flow graph. For this, we invoke CFGConstructionUnit component. Once control flow graph construction is complete, we visualize it in both DOT language format and image form in lower left and right panel, respectively.

265235.fig.009
Figure 9: Screen shot of 𝑋𝑀𝐼2𝐶𝐹𝐺 showing conversion of XMI representation of interaction diagram into control flow graph.

6. Comparison with Related Work

Control flow analysis has been investigated widely in the context of program analysis and compiler design [26]. However, control flow analysis in the context of XMI representation of UML interaction diagram (it is referred as sequence diagram in earlier version of UML 2.x) has scarcely been reported [2, 4, 5, 11, 17, 18]. Garousi et al. [17, 18] propose a methodology to analyze control flow of UML 2.x sequence diagrams using formal annotations in object constraint language (OCL). For control flow analysis, they have considered concurrent systems, which subsumes nonconcurrent systems. For activity diagram having concurrency constructs (fork-join), they derive an extended activity diagram metamodel, called as concurrent control flow graph (CCFG) based on UML 2.x activity diagrams. Garousi et al. [17, 18] propose formal OCL-based mapping rules to map an instance of sequence diagram into an instance of CCFG metamodel. A formal representation of concurrency control flow path is also discussed in their work. The differences between Garousi et al.’s approach [17, 18] and our approach is as follows. First, Garousi et al.’s approach formalizes the control flow analysis using meta-model information and object constraint language (𝑂𝐶𝐿) annotations. Our approach on the other hand, achieves conversion by processing XMI representation of sequence diagram. For this, we have considered the inherent structure of XMI representation of sequence diagram as well as meta-model of sequence diagram as specified by OMG. Second, their approach considers the mapping rules for construction of edges in control flow graph, whereas our approach uses message sets of fragments and precedence relations among interactions. Third, their control flow analysis considers both the synchronous and asynchronous messages but our approach considers synchronous messages only as most method calls in object-oriented programming languages are synchronous. Note that asynchronous call generally occurs in multithreaded applications, which is not considered in this work. Fourth, our approach is directly applicable in an industry scenario where XMI representation of UML model is exported from UML modeling tools for further processing, which is the standard practice to process UML models.

Sarma et al. [5] use control flow graph for test case synthesis from UML sequence diagrams. First, all operation scenarios are identified from UML sequence diagram, where an operation scenario represents a sequence of messages. The operation scenarios are used to form a directed graph called sequence diagram graph (𝑆𝐷𝐺), where a node represents a message and an edge represents control flow. Sarma et al. augment the nodes of 𝑆𝐷𝐺 with different information like attributes of participating objects, parameters of the method, predicate (if any), range of attribute values, and so forth necessary to compose test vectors. This information is obtained from use case templates, class diagrams, and data dictionary. With the node information, 𝑆𝐷𝐺 is used to generate test cases. The differences between Sarma’s work and our work is as follows. First, Sarma’s work uses UML 1.x sequence diagram that does not support fragments whereas our work considers fragments supported by UML 2.x sequence diagram. In fact, handling sequence diagram containing nested fragments for conversion is a nontrivial problem, which our work has addressed. Second, Sarma’s work has not reported how to obtain 𝑆𝐷𝐺 from XMI representation of sequence diagram but our approach includes a detailed conversion process from XMI of UML 2.x sequence diagram into control flow graph.

Nayak and Samanta [4] propose an approach to synthesize test cases from UML 2.0 interaction diagrams. They convert interaction diagrams into a control flow graph called scenario graph encapsulating control flow and fragment structure. The scenario graph consists of different types of nodes: block node, decision node, merge node, fork node, and join node. Note that block node represents a set of messages that execute consecutively. Subsequently, scenario graph is processed to build an intermediate testable model called ITM. To build an ITM, minimum regions (a region has single entry and single exit node and is not contained in other region) are identified in scenario graph and then replaced by composite nodes successively until scenario graph becomes a single chain of nodes, called ITM. The ITM is used to generate test scenarios by expanding each composite node into its internal paths in successive iterations. The test scenarios are further processed to synthesize test cases. But Nayak et al. have not reported how to apply proposed mapping rules to XMI representation of an interaction diagram for obtaining ITM, which is indeed a nontrivial problem.

Dinh-Trong et al. [11] propose an approach to generate inputs to test UML design models. Dinh-Trong et al. consider the information encapsulated in class and sequence models and combine them to build a graph structure called variable assignment graph (VAG). A VAG is a control flow graph annotated with data flow information. The graph contains two types of nodes: message node representing a message of sequence diagram and control node showing alternate execution paths of messages from the combined fragments. Edges between two nodes in VAG represent the control flow. Dinh-Trong et al. select a path from the VAG based on some structural coverage criteria like node coverage, edge coverage, path coverage, and generate test inputs by solving the constraints along the selected path. Extending this work, Bandyopadhyay and Ghosh [2] augment the VAG with information derived from the state machines of the participating objects to build a testable model called the extended variable assignment graph (EVAG). Once EVAG is built, they solve the path constraints to generate test inputs for each EVAG path. But they [2, 11] have not reported how mapping rules can be applied to XMI representation of a sequence diagram to obtain a VAG like Sarma et al. [5] and Nayak and Samanta [4].

7. Conclusions

Control flow graph is an important data structure used in many software engineering processes. This paper proposes an approach how a control flow graph can be obtained from XMI representation of UML 2.x interaction diagram. The proposed approach overcomes the difficulties of attributing all information from XMI tagged elements and then obtains its equivalent graph representation. From the reported work, it is not understood how actually a UML interaction diagram is processed, if automatically. We give a way out to this hindrance. The prototype tool XMI2CFG based on the proposed approach has been tested with a large number of interaction diagrams in real-life applications. A thorough investigation on these applications substantiates the correctness of the proposed approach. Indeed the proposed approach bridges the gap between theory and practice of converting (XMI representation of) UML 2.x interaction diagram to control flow graph. To add more, the methodology can be extended to other UML diagrams such as activity diagram and interaction overview diagram with a minor enhancement in each case.

References

  1. “OMG Unified Modeling LanguageTM (OMG UML), superstructure version 2.2,” http://www.omg.org/spec/UML/2.2/Superstructure/.
  2. A. Bandyopadhyay and S. Ghosh, “Test input generation using UML sequence and state machines models,” Proceedings of the 2nd International Conference on Software Testing, Verification, and Validation, (ICST '09), pp. 121–130, 2009. View at Publisher · View at Google Scholar
  3. F. Fraikin and T. Leonhardt, “SeDiTeC—testing based on sequence diagrams,” in Proceedings of the IEEE International Conference on Automated Software Engineering, (ASE '02), pp. 261–266, 2002.
  4. A. Nayak and D. Samanta, “Model-based test cases synthesis using UML interaction diagrams,” ACM SIG-SOFT Software Engineering Notes, vol. 34, no. 2, pp. 1–10, 2009.
  5. M. Sarma, D. Kundu, and R. Mall, “Automatic test case generation from UML sequence diagram,” in Proceedings of the 15th International Conference on Advanced Computing and Communications (ADCOM, '07), pp. 60–67, IEEE Computer Society, Washington, DC, USA, 2007.
  6. D. Kundu, M. Sarma, D. Samanta, and R. Mall, “System testing for object-oriented systems with test case prioritization,” Software Testing, Verification and Reliability, vol. 19, no. 4, pp. 297–333, 2009. View at Publisher · View at Google Scholar · View at Scopus
  7. S. K. Swain, D. P. Mohapatra, and R. Mall, “Test case generation based on use case and sequence diagram,” International Journal of Software Engineering, vol. 3, no. 2, pp. 21–52, 2010.
  8. B.-L. Li, Z.-S. Li, Q. Li, and Y. H. Chen, “Test case automate generation from UML sequence diagram and OCL expression,” in Proceedings of the International Conference on Computational Intelligence and Security, (CIS '07), pp. 1048–1052, IEEE Computer Society, Washington, DC, USA, 2007. View at Publisher · View at Google Scholar
  9. Y. Fu and S. Li, “A graph-based testing of UML2 sequence diagram,” International Journal of Computer and Network Security, vol. 2, no. 9, pp. 73–78, 2010.
  10. S. Supavita and T. Suwannasart, “Testing polymorphic interactions in UML sequence diagrams,” in Proceedings of the International Conference on Information Technology: Coding and Computing, (ITCC '05), vol. 2, pp. 449–454, IEEE Computer Society, Washington, DC, USA, 2005.
  11. T. T. Dinh-Trong, S. Ghosh, and R. B. France, “A systematic approach to generate inputs to test UML design models,” in Proceedings of the International Symposium on Software Reliability Engineering, (ISSRE '06), pp. 95–104, IEEE Computer Society, Washington, DC, USA, 2006. View at Publisher · View at Google Scholar
  12. D. Pilone and N. Pitman, UML 2.0 in a Nutshell, O’Reilly, 2005.
  13. C. Larman, Applying UML and Patterns: An Introduction to Object-Oriented Analysis and Design and the Unified Process, Prentice Hall, New York, NY, USA, 2nd edition, 2004.
  14. G. Booch, J. Rumbaugh, and I. Jacobson, Object-oriented Analysis and Design, Addison-Wesley, Reading, Mass, USA, 2002.
  15. L. Bjrn, L. Brian, P. Anna, and M. Anders, “UML model interchange in heterogeneous tool environments: an analysis of adoptions of XMI 2,” in Model Driven Engineering Languages and Systems, O. Nierstrasz, J. Whittle, D. Harel, and G. Reggio, Eds., vol. 4199 of Lecture Notes in Computer Science, pp. 619–630, Springer, Berlin, Germany, 2006.
  16. A. Bandyopadhyay and S. Ghosh, “Developing model transformation tools using the UML metamodel: challenges and solutions,” in Proceedings of the International Conference on Software Engineering and Applications, pp. 545–550, 2007.
  17. V. Garousi, L. C. Briand, and Y. Labiche, “Control flow analysis of UML 2.0 sequence diagrams,” Lecture Notes in Computer Science, vol. 3748, pp. 160–174, 2005. View at Publisher · View at Google Scholar
  18. “Control flow analysis of UML 2.0 sequence diagrams,” Tech. Rep., 2005, http://squall.sce.carleton.ca/pubs/tech_report/TR_SCE-05-09.pdf.
  19. http://www.omg.org/technology/xml/.
  20. https://moodle.cs.ualberta.ca/.
  21. http://www.magicdraw.com.
  22. http://xerces.apache.org/xerces2-j/.
  23. http://netbeans.org/.
  24. http://www.graphviz.org/Documentation/dotguide.pdf.
  25. http://www.loria.fr/~szathmar/off/projects/java/GraphVizAPI/index.php.
  26. A. V. Aho, R. Sethi, and J. D. Ullman, Compilers: Principles, Techniques, and Tools, Addison-Wesley, Delhi, India, 2000.