ISRN Software EngineeringVolume 2012 (2012), Article ID 265235, 22 pagesdoi:10.5402/2012/265235

Research Article

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

Debasish Kundu,¹ Debasis Samanta,¹ and Rajib Mall²

¹School of Information Technology, Indian Institute of Technology, Kharagpur, Kharagpur 721302, India²Department 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 [2–11]. 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 [12–14]. 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

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

Interaction DiagramInteraction 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.

MessageA 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].

FragmentA 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 ElementModel 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 GraphControl flow graph for an interaction diagram say ItrDgm, is a directed graph , where 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, 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.

InteractionAn interaction is a set of zero or more message occurrences in an interaction diagram [1]. That is, , where , , , are the number of messages in the interaction diagram. If , then is referred to as null interaction, and if , then is referred to a message. On the other hand, if , then is referred to a set of messages of a fragment.

Precedence RelationFor 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 RelationLet 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 FragmentThe 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 and , respectively.

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 to itself if becomes true, otherwise, ObjectB sends the message to ObjectC. Finally, reply message is sent from ObjectB to ObjectA. Figure 1(b) depicts corresponding graph representation for the interaction diagram containing alt fragment. Note that four nodes , , , and represent four messages , , , and , respectively, and two nodes and correspond to the start and end of the alt fragment, respectively. Two alternative flows are modeled by two outgoing edges from and two incoming edges at the node 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 FragmentThe 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 and . These two messages are executed if the guard condition becomes true. Figure 1(d) depicts graph representation for the interaction diagram (in Figure 1(c)). Note that when the guard condition 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 (corresponding to the start of opt fragment) to the node (corresponding to the end of opt fragment) as shown in Figure 1(e).

Break FragmentThe break fragment is used to capture an exit point of the systems [12]. In Figure 1(f), we see that if guard condition becomes true, then it exits after execution of two messages and , following which no further message (i.e., and ) would be executed. Note that the control flow which is transferred from the start of break fragment to the message when the guard condition 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 (corresponding to the end of the break fragment) as a sink node and introducing an edge from the node to the node in control flow graph (see Figure 1(h)).

Loop FragmentThe loop fragment is used to model repetitive interactions [12]. In Figure 1(i), we see that message of the loop fragment gets executed repeatedly until the guard condition associated with loop fragment becomes false. When becomes false, loop terminates and execution of the message 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 to the node and another loop exit edge from to (see Figure 1(k)).

There are many more fragments such as par and ref defined in UML [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 , , , , and and two fragments and . 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).

Figure 2: An example interaction diagram and its graph representation. (a) An interaction diagram. (b) Graph representation for Figure 2.

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, ) 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 . 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 . 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 , which imply that ObjectA of ClassA sends a message to ObjectB of ClassB. In other words, for the node (corresponding to the message ) 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 (xmi: id = “_487”; line 33) and tagged elements at 41 and 49 correspond to the end of two operands of the fragment . Furthermore, the tagged elements 33 and 50 correspond to the start and end of the fragment , respectively. Therefore, the node (representing the start of the fragment ) 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 (representing the end of the fragment ). 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.

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

Nodes in Figure 2
Tagged elements in Figure 3

m ₁
4, 66, 25, 24, 62, 20, 16, 2, 21, 17, 3

28, 29

m ₂
5, 67, 53, 52, 54, 21, 17, 3

33, 34, 42

m ₃
8, 68, 59, 58, 39, 21, 17, 3, 22, 18, 7

m ₄
11, 69, 61, 60, 47, 21, 17, 3, 23, 19, 10

41, 49, 50

56, 57

m ₅
63, 26, 27, 70, 21, 17, 3, 20, 16, 2

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.

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 ElementsWe 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).

Table 2: Classes to store information of elements in XMI representation.

Event name
XMI tagged element
Value of attribute “xmi: type”
Class

Operation

- - -
EOperation

CallEvent

“uml: CallEvent”
ECallEvent

Message

- - -
EMessage

MessageEvent

“uml: MessageOccurrenceSpecification”
EMessageEvent

Lifeline

- - -
ELifeline

CombinedFragment

“uml: CombinedFragment”
EFragment

Operand

- - -
EOperand

Class

“uml: class”
EClass

Object

- - -
EObject

Figure 5: Class diagram for metadata of interaction diagram in XMI.

(b) Synthesizing Details of a MessageWe 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 of the bMessage (because reply message can not have more than one return value). In other words, 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 FragmentsAfter synthesis of values of the attributes of an object aMessage in the list of EMessage objects, we need to find a set of messages , set of reply messages (using the value of attribute “messageType”) from that list. A set of fragments is also to be obtained from the list of EFragment objects. , , can be determined as follows.

(d) Finding Message Sets of FragmentsTo determine the set of messages of a fragment , 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, 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, 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 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

Step 2 (determining the nodes). Initially, control flow graph 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 , set of fragments as obtained in Step 1.(a)For each fragment , we add two fragment nodes and into of , 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 would be null.(b)For each , we add a message node into . To obtain the values of associated attributes: , , , , , 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 , we store corresponding tuple 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 . In other words, we are to find the outermost fragments (the fragments that are not contained in another fragment) built by and then determine the inner fragments contained in each fragment.(a)To find the outermost fragments formed by the messages in , we need to identify the minimal set of fragments that together correspond to the largest subset of . For this, we follow two steps. (i)Initially, set (set of all fragments in interaction diagram).(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 the subset of corresponding to the for each fragment by the ID of the fragment. This implies that the message set covers all fragments in as outermost fragments.(b)To determine the inner fragments contained in each fragment in , we need to find the minimal set of fragments 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 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 of the interaction diagram, we find the edges among nodes in of the using the following steps.(a)We apply the precedence relation on and obtain a set of precedence relations say, . For this, we consider the sequence number of all messages (i.e., SeqNumber of corresponding EMessage objects) in , and in case contains an interaction (i.e., fragment ), then we use the sequence number of a message in the (message set of ). If includes a precedence relation such that or , then , 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 . The reason for union operation in computation of 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 , we draw an edge following the set of rules as mentioned below.(i)If , 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 , , 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 and , 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 , 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 . Note that the implies that is the first interaction in a fragment and that interaction is either a message or a set of messages of the inner fragment of the and , where . Thus, we identify the of a fragment 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 , 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 or between the start boundary of the fragment and the message that occurs first in the .(d)Similarly, for each right null precedence relation , we draw an edge in control flow graph. Note that the implies that is the last interaction in a fragment and that interaction is either a message or a set of messages of the inner fragment of the , where and . Thus, we identify the for a fragment such that contains . If , 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 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 to the edges in CFG. For this, we consider the edge corresponding to each left precedence relation 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 (R1–R6) are for the loop fragment. Rule 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 to are similar to the rule , 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 is applied. Rule is applied when is followed by another fragment . Rule is applied when is contained in some other fragment as the last interaction. Rule is applied if has an inner fragment as the first interaction and is followed by the fragment . Rule 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 with the start node and end node , respectively, then do the following: (i) add an edge from the start of ref fragment to , (ii) add an edge from 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 (R10–R15) 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).

Table 3: Set of rules.

: a fragment with of types opt, break, loop and ref

: two fragment nodes representing the start and end of the fragment

: two message nodes representing two messages

: an edge from the fragment node representing start of fragment to message node

: an edge from to labeled with the condition

: add an edge from to

: add an edge from to labeled with the condition

: delete an edge from to

R1: ( )).

R2: (& .

R3: ( & ).

R4: ( .

R5: .

R6: ) .

R7: .

R8: .

R9: ( & ).

R10: ().

R11: (.

R12: ( & ).

R13: ( & ).

R14: ( & ).

R15: ( & ).

Illustration of Our ApproachWe 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).

Figure 6: Interaction diagram of Generate Bill Use Case.

Identifying the Fragments and Their Message SetsConsidering 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 = {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 is obtained from the list of EFragment objects as (see Figure 6).(b) We then identify set of messages for a fragment with considering the EFragment object corresponding to as well as the set of EOperand objects associated with the EFragment object (see Step 1) as , , = {6,7, 8, 9, 10, 11, 12, 13, 14, 15, 16, 17, 18 }, , = {9, 10}, and .

Determining the NodesWe determine the nodes of control flow graph from and as follows.(a)We add two fragment nodes into the set of nodes N of control flow graph for each fragment and thus obtain N as (see Figure 7). (b)Adding a message node for each, the set of nodes becomes N = N∪ {m ₁, m ₂, m ₃, m ₄, m ₅, m ₆, m ₇, m ₈, m ₉, m ₁₀, m ₁₁, m ₁₂, m ₁₃, m ₁₄, m ₁₅, m ₁₆, m ₁₇, m ₁₈, m ₁₉}. 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 . 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.

Table 4: Node table.

Node
Seq No.
T
ID
B
RO
M
PR
RVar

—
loop
1
S
—
—
—
—

—
loop
1
E
—
—
—
—

—
alt
1
S
—
—
—
—

—
alt
1
E
—
—
—
—

—
alt
2
S
—
—
—
—

—
alt
2
E
—
—
—
—

—
break
1
S
—
—
—
—

—
break
1
E
—
—
—
—

—
loop
2
S
—
—
—
—

—
loop
2
E
—
—
—
—

—
break
2
S
—
—
—
—

—
break
2
E
—
—
—
—

m ₁
1
syn
1
—
POC
GenerateBill
OrderNumber
—

m ₂
2
syn
2
—
ORRG
FindOrder
OrderNumber
aOrder

m ₃
3
syn
3
—
OrderList[i]
MatchOrder
OrderNumber
found

m ₄
4
reply
4
—
POC
—
OrderList[i]
—

m ₅
5
reply
5
—
POC
—
null
—

m ₆
6
syn
6
—
aOrder
GetStatus
—
Status

m ₇
7
syn
7
—
aScreen
DisplayMessage
“Bill will be generated after delivery of the order”
—

m ₈
8
syn
8
—
BRG
GetBillList
—
BillList

m ₉
9
syn
9
—
BillList[i]
MatchOrderID
OrderNumber
BillFound

m ₁₀
10
syn
10
—
aScreen
DisplayMessage
“Bill is already generated”
—

m ₁₁
11
create
11
—
aBill
—
—
—

m ₁₂
12
syn
12
—
aBill
GenerateBillNo
—
—

m ₁₃
13
syn
13
—
aBill
SetBillInfo
OrderNumber
—

m ₁₄
14
syn
14
—
aBill
GetBillNo
—
BillNumber

m ₁₅
15
syn
15
—
aBill
CalculateBill
—
BillAmount

m ₁₆
16
syn
16
—
BRG
AddBill
aBill
—

m ₁₇
17
syn
17
—
aScreen
DisplayMessage
“BillNumber”, BillNumber, “BillAmount”, BillAmount
—

m ₁₈
18
syn
18
—
aScreen
DisplayMessage
“Order is not found while generating bill”
—

m ₁₉
19
reply
19
—
aForm
—
—
—

(a) Graph representation

(b) Control flow graph

Figure 7: Graph representation and control flow graph of interaction diagram for Generate Bill use case.

Determining Fragment StructureIn this step, we first find the outermost fragments formed by the set of messages . 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 M seq. The is initialized as the set of all fragments of the interaction diagram, that is, . We observe that , and . As each message set of three fragments break ₁, loop ₂, and break ₂ is subset of message set of alt ₂, we exclude these three fragments from , which reduces . That implies that fragments loop ₁, alt ₁, and alt ₂ 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 and are the outermost fragments formed by the messages in . Replacing the largest subset of by the fragments in , we obtain = {1, 2, loop ₁, alt ₁, alt ₂, 19}.(b)To determine the hierarchy structure of the fragments in , let us first consider the fragment loop ₂. Only one fragment break ₂ is sufficient to replace the largest subset {10} of . After replacing the largest subset of by break ₂, we obtain . Therefore, loop ₂ contains only one inner fragment break ₂. Now consider another fragment alt ₂. In this case, minimal set of fragments = {break ₁, loop ₂} is sufficient enough to replace together the largest subset {7, 9, 10} of = {6, 7, 8, 9, 10, 11, 12, 13, 14, 15, 16, 17, 18}. Therefore, after replacing corresponding subset of by each fragment in , we obtain = {6, break ₁, 8, loop ₂, 11, 12, 13, 14, 15, 16, 17, 18}. It implies that fragment alt ₂ contains inner fragments break ₁ and loop ₂. Note that , , , and remain unchanged as there is no fragment in that can replace the subset of message sets of fragments loop ₁, alt ₁, break ₁, and break ₂.

Determining the EdgesIn this step, we first apply precedence relations on . Depending on the operand of the precedence relation, we determine the edges. (a)Applying ≺ on M seq, we obtain P(M seq) = {1 ≺ 2, 2 ≺loop ₁, loop ₁≺alt ₁, alt ₁≺alt ₂, alt ₂≺ 19} ∪P() ∪P() ∪P(). These unions are for the fragment operands loop ₁, alt ₁, and alt ₂ present in the precedence relations of P(M seq). To compute the unions, we need to have the sets of precedence relations for each fragment operand: loop ₁, alt ₁, and alt ₂. They are computed as below. (i)P = {Λ ≺ 3, 3 ≺ Λ}.(ii)P = {Λ ≺ 4, 4 ≺ Λ, Λ ≺ 5, 5 ≺ Λ}.(iii)P = {Λ ≺ 6, 6 ≺break ₁, break ₁≺ 8, 8 ≺loop ₂, loop ₂≺ 11, 11 ≺ 12, 12 ≺ 13, 13 ≺ 14, 14 ≺ 15, 15 ≺ 16, 16 ≺ 17, 17 ≺ Λ, Λ ≺ 18, 18 ≺ Λ} ∪P }∪P .(iv)P = {Λ ≺ 7, 7 ≺ Λ}.(v)P = {Λ ≺ 9, 9 ≺break ₂, break ₂≺ Λ} ∪P .(vi)P = {Λ ≺ 10, 10 ≺ Λ}. Therefore, P = {1 ≺ 2, 2 ≺loop ₁, loop ₁≺alt ₁, alt ₁≺alt ₂, alt ₂≺ 19, Λ ≺ 3, 3 ≺ Λ, Λ ≺ 4, 4 ≺ Λ, Λ ≺ 5, 5 ≺ Λ, Λ ≺ 6, 6 ≺break ₁, break ₁≺ 8, 8 ≺loop ₂, loop ₂≺ 11, 11 ≺ 12, 12 ≺ 13, 13 ≺ 14, 14 ≺ 15, 15 ≺ 16, 16 ≺ 17, 17 ≺ Λ, Λ ≺ 18, 18 ≺ Λ, Λ ≺ 7, 7 ≺ Λ, Λ ≺ 9, 9 ≺break ₂, break ₂≺ Λ, Λ ≺ 10, 10 ≺ Λ}. (b)Depending on the operand of a precedence relation () in P(M seq), 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 and thus, we draw seven edges (m ₁, m ₂), (m ₁₁, m ₁₂), (m₁₂, m ₁₃), (m ₁₃, m ₁₄), (m ₁₄, m ₁₅), (m ₁₅, m ₁₆), and (m ₁₆, m ₁₇) in control flow graph. (ii)The condition is satisfied by the precedence relations: 2 ≺loop ₁, 6 ≺break ₁, 8 ≺loop ₂, and 9 ≺break ₂, and they correspond to four edges , , and . (iii)There are three precedence relations alt ₂≺ 19, break ₁≺ 8, and loop ₂≺ 11 satisfying the condition . Therefore, we draw three edges , and . (iv)The two precedence relations: loop ₁≺alt ₁ and alt ₁≺alt ₂ satisfy the condition . Considering these two precedence relations, we draw two edges and . (c)In our example, (as obtained in step (a)) has the following left null precedence relations: Λ ≺ 3, Λ ≺ 4, Λ ≺ 5, Λ ≺ 6, Λ ≺ 7, Λ ≺ 9, Λ ≺ 10, and Λ ≺ 18. Here, the fragment loop ₁ contains 3; alt ₁ contains 4, 5; alt ₂ contains 6, 18; break ₁ contains 7; loop ₂ contains 9; break ₂ contains 10 (see the message sets , , , , , and ). For these eight left precedence relations, we draw the following edges , and . (d)There are eight right null precedence relations: 3 ≺ Λ, 4 ≺ Λ, 5 ≺ Λ, 17 ≺ Λ, 18 ≺ Λ, 7 ≺ Λ, break ₂≺ Λ, and 10 ≺ Λ. Among them, only one break ₂≺ Λ has fragment operand and the fragment loop ₂ contains break ₂ (see the and after replacement in the step [determine fragment structure]). For this right null precedence relation, we draw an edge . For remaining seven right null precedence relations, we draw seven edges , , and .

Identifying the Labels of EdgesWe 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, , this means that fragment break ₁ contains the message 7. The only one operand of the break ₁ that contains the message 7 is associated with the condition Status “Delivered”. Therefore, the edge 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 RulesIn 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 (loop ₁) does not contain an inner fragment and is followed by another fragment , and thus we apply the rule . Applying the rule , we add two edges (, ) and and delete the edge . For the fragment , we apply the rule as does not contain an inner fragment and is not followed by another fragment. Applying the rule, we delete the edge (, ) and add the edge (, ). Applying rule for the fragment , we delete the edge (, ) and add the edge (, ). Here, the loop fragment does not contain a fragment as first interaction and is not followed by a fragment. So, we apply the rule and add edges (, ) and (, ) and delete the edge (, ). 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 (XMI of interaction diagram to control flow graph) following our approach. We have implemented in Java language (Java 2) using NetBeans IDE 6.1 [23]. Input of is the XMI representation of UML interaction diagram. We have used MagicDraw 16.0 [21] to draw interaction diagram and subsequently exported this diagram in the form of XMI representation. visualizes the control flow graph as the output. 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.

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

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 , , , , , , , , 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 s 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). 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 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 UnitThe 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 .

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

Figure 9: Screen shot of 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 ) 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 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 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

“OMG Unified Modeling LanguageTM (OMG UML), superstructure version 2.2,” http://www.omg.org/spec/UML/2.2/Superstructure/

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

D. Pilone and N. Pitman, UML 2.0 in a Nutshell, O’Reilly, 2005.

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.

G. Booch, J. Rumbaugh, and I. Jacobson, Object-oriented Analysis and Design, Addison-Wesley, Reading, Mass, USA, 2002.

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.

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.

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.

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

http://www.omg.org/technology/xml/

https://moodle.cs.ualberta.ca/

http://www.magicdraw.com

http://xerces.apache.org/xerces2-j/

http://netbeans.org/

http://www.graphviz.org/Documentation/dotguide.pdf

http://www.loria.fr/~szathmar/off/projects/java/GraphVizAPI/index.php

A. V. Aho, R. Sethi, and J. D. Ullman, Compilers: Principles, Techniques, and Tools, Addison-Wesley, Delhi, India, 2000.