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

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

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 𝑁={𝑛₁,𝑛₂,…,𝑛_𝑖,…,𝑛_𝑞} 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, 𝐼={𝑚₁,𝑚₂,…,𝑚_𝑛∣𝑛≥0}, where 𝑚₁, 𝑚₂, …, 𝑚_𝑛 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.

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 𝑚₁, 𝑚₂, 𝑚₃, and 𝑚₄ 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 𝑚₄ 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 𝑚₃ (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 𝑜𝑝𝑡₁ 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, 𝑚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 𝑚₁ (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 𝑎𝑙𝑡₁ (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 𝑎𝑙𝑡^𝑆1 (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 𝑎𝑙𝑡^𝐸1 (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.

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

Table 2 

Classes to store information of elements in XMI representation.

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={𝐸𝑎𝑀𝑀𝑒𝑠𝑒𝑠𝑠𝑎𝑠𝑎𝑔𝑔𝑒𝑒𝑜.𝐼𝑏𝑑𝑗𝑒∣𝑐𝑡𝑎𝑠𝑀}𝑒._seq𝑠𝑠𝑎𝑔𝑒existsinthelistof={𝑎𝑀𝑎𝑀𝑒𝑠𝑒𝑠𝑠𝑎𝑠𝑔𝑎𝑒𝑔.𝑒𝑚.𝐼𝑒𝑠𝑑𝑠∣𝑎𝑎𝑔𝑀𝑒𝑇𝑦𝑒𝑠𝑝𝑠𝑒𝑎=𝑔𝑒.𝐼𝑑∈𝑀_𝑠𝑒𝑞&𝐹”𝑟𝑒𝑝𝑙𝑦”}._seq={in𝑎t𝐹h𝑟e𝑎l𝑔i𝑚st𝑒o𝑛f𝑡.𝐸𝐼𝑑𝐹∣𝑟𝑎𝑎𝑔𝐹𝑚𝑟𝑎𝑒𝑛𝑔𝑡𝑚o𝑒b𝑛j𝑡eecxtsis}ts.(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, 𝑆^𝑓𝑖_{𝐸𝑂𝑝𝑟𝑑𝑠}=l𝑎{𝑎i𝐹s𝑎𝑂t𝑂𝑟𝑝𝑎o𝑝𝑒𝑔f𝑒𝑟𝑚𝐸𝑟𝑎𝑎e𝑛𝑂𝑛𝑛𝑑𝑝𝑑𝑡..𝐼𝑒𝑂∣𝑟𝑑𝑝𝑎𝑎𝑒𝑛𝑂&𝑟𝑑𝑝𝑎𝑓𝑒𝑛o𝑟_𝑖𝑑b𝑎𝐿j𝑛e𝑖𝑑c𝑠t𝑡sexc&oisntstaiinnsthe⟶𝑎𝐹𝑟𝑎𝑔𝑚𝑒𝑛𝑡.(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, 𝑆^𝑓𝑖_{𝐸𝑀𝑠𝑔𝑠}=&𝐸𝑎𝑂𝑀𝑎𝑎𝑝𝑀𝑂𝑒𝑒𝑠𝑟𝑝𝑒𝑎𝑠𝑒𝑠𝑎𝑛𝑟𝑠𝑔𝑑𝑎𝑎𝑒.𝑛𝑔𝑀𝑑𝑒ob𝑒∣∈𝑠j𝑎e𝑠𝑆𝑀c𝑎t𝑔s𝑒𝑒𝑠&𝐿𝑠𝑎𝑖_{𝑓𝑖𝐸𝑂𝑝𝑟𝑑𝑠}𝑠𝑔𝑡𝑒ceoxnitsatsinisn𝑎t𝑀he𝑒l𝑠i𝑠st𝑎𝑔o𝑒f.𝐼𝑑.(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 (R1–R6) 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 (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.

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

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={𝑙𝑜𝑜𝑝₁,𝑎𝑙𝑡₁,𝑎𝑙𝑡₂,𝑏𝑟𝑒𝑎𝑘₁,𝑙𝑜𝑜𝑝₂,𝑏𝑟𝑒𝑎𝑘₂} (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∪ {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 𝑖∈𝑀_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.

Table 4 

Node table.

(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 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 M_seq. The 𝐹^ is initialized as the set of all fragments of the interaction diagram, that is, 𝐹^=𝐹_seq={𝑙𝑜𝑜𝑝₁,𝑎𝑙𝑡₁,𝑎𝑙𝑡₂,𝑏𝑟𝑒𝑎𝑘₁,𝑙𝑜𝑜p₂,𝑏𝑟𝑒𝑎𝑘₂}. We observe that 𝑀_{𝑏𝑟𝑒𝑎𝑘1}⊂𝑀_{𝑎𝑙𝑡2},𝑀_{𝑙𝑜𝑜𝑝2}⊂𝑀_{𝑎𝑙𝑡2}, and 𝑀_{𝑏𝑟𝑒𝑎𝑘2}⊂𝑀_{𝑙𝑜𝑜𝑝2}. 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 𝑀_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, loop₁, alt₁, alt₂, 19}.(b)To determine the hierarchy structure of the fragments in 𝐹_seq, let us first consider the fragment loop₂. Only one fragment break₂ is sufficient to replace the largest subset {10} of 𝑀_{𝑙𝑜𝑜𝑝2}={9,10}. After replacing the largest subset of 𝑀_{𝑙𝑜𝑜𝑝2} by break₂, we obtain 𝑀_{𝑙𝑜𝑜𝑝2}={9,𝑏𝑟𝑒𝑎𝑘₂}. 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 𝑀_{𝑎𝑙𝑡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, break₁, 8, loop₂, 11, 12, 13, 14, 15, 16, 17, 18}. It implies that fragment alt₂ contains inner fragments break₁ and loop₂. 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 loop₁, alt₁, break₁, and break₂.

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 M_seq, we obtain P(M_seq) = {1 ≺ 2, 2 ≺loop₁, loop₁≺alt₁, alt₁≺alt₂, alt₂≺ 19} ∪P(𝑀_{𝑙𝑜𝑜𝑝1}) ∪P(𝑀_{𝑎𝑙𝑡1}) ∪P(𝑀_{𝑎𝑙𝑡2}). 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 (𝑀_{𝑙𝑜𝑜𝑝1}) = {Λ ≺ 3, 3 ≺ Λ}.(ii)P (𝑀_{𝑎𝑙𝑡1}) = {Λ ≺ 4, 4 ≺ Λ, Λ ≺ 5, 5 ≺ Λ}.(iii)P (𝑀_{𝑎𝑙𝑡2}) = {Λ ≺ 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 (𝑀_{𝑏𝑟𝑒𝑎𝑘1})}∪P (𝑀_{𝑙𝑜𝑜𝑝2}).(iv)P (𝑀_{𝑏𝑟𝑒𝑎𝑘1}) = {Λ ≺ 7, 7 ≺ Λ}.(v)P (𝑀_{𝑙𝑜𝑜𝑝2}) = {Λ ≺ 9, 9 ≺break₂, break₂≺ Λ} ∪P (𝑀_{𝑏𝑟𝑒𝑎𝑘2}).(vi)P (𝑀_{𝑏𝑟𝑒𝑎𝑘2}) = {Λ ≺ 10, 10 ≺ Λ}. Therefore, P (𝑀_seq) = {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 (𝐼_𝑥,𝐼_𝑦∈𝑀_seq) 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 (𝐼_𝑥∈𝑀_seq,𝐼_𝑦∈𝐹_seq) is satisfied by the precedence relations: 2 ≺loop₁, 6 ≺break₁, 8 ≺loop₂, and 9 ≺break₂, and they correspond to four edges (𝑚₂,𝑙𝑜𝑜𝑝^𝑆1),(𝑚₆,𝑏𝑟𝑒𝑎𝑘^𝑆1), (𝑚₈,𝑙𝑜𝑜𝑝^𝑆2), and (𝑚₉,𝑏𝑟𝑒𝑎𝑘^𝑆2). (iii)There are three precedence relations alt₂≺ 19, break₁≺ 8, and loop₂≺ 11 satisfying the condition (𝐼_𝑥∈𝐹_seq,𝐼_𝑦∈𝑀_seq). Therefore, we draw three edges (𝑎𝑙𝑡^𝐸2,𝑚₁₉),(𝑏𝑟𝑒𝑎𝑘^𝐸1,𝑚₈), and (𝑙𝑜𝑜𝑝^𝐸2,𝑚₁₁). (iv)The two precedence relations: loop₁≺alt₁ and alt₁≺alt₂ 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 loop₁ contains 3; alt₁ contains 4, 5; alt₂ contains 6, 18; break₁ contains 7; loop₂ contains 9; break₂ 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,𝑚₃),(𝑎𝑙𝑡^𝑆1,𝑚₄),(𝑎𝑙𝑡^𝑆1,𝑚₅),(𝑎𝑙𝑡^𝑆2,𝑚₆),(𝑎𝑙𝑡^𝑆2,𝑚₁₈),(𝑏𝑟𝑒𝑎𝑘^𝑆1,𝑚₇),(𝑙𝑜𝑜𝑝^𝑆2,𝑚₉), and (𝑏𝑟𝑒𝑎𝑘^𝑆2,𝑚₁₀). (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 𝑀_{𝑙𝑜𝑜𝑝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 (𝑚₃,𝑙𝑜𝑜𝑝^𝐸1),(𝑚₄,𝑎𝑙𝑡^𝐸1), (𝑚₅,𝑎𝑙𝑡^𝐸1),(𝑚₁₇,𝑎𝑙𝑡^𝐸2),(𝑚₁₈,𝑎𝑙𝑡^𝐸2),(𝑚₇,𝑏𝑟𝑒𝑎𝑘^𝐸1), and (𝑚₁₀,𝑏𝑟𝑒𝑎𝑘^𝐸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 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 (𝑏𝑟𝑒𝑎𝑘^𝑆1,𝑚₇) 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 (loop₁) does not contain an inner fragment and is followed by another fragment 𝑎𝑙𝑡₁, 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 𝑏𝑟𝑒𝑎𝑘₁, we apply the rule 𝑅10 as 𝑏𝑟𝑒𝑎𝑘₁ 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 𝑏𝑟𝑒𝑎𝑘₂, we delete the edge (𝑏𝑟𝑒𝑎𝑘^𝐸2, 𝑙𝑜𝑜𝑝^𝐸2) and add the edge (𝑏𝑟𝑒𝑎𝑘^𝑆2, 𝑙𝑜𝑜𝑝^𝐸2). Here, the loop fragment 𝑙𝑜𝑜𝑝₂ 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, 𝑚₁₁) and delete the edge (𝑙𝑜𝑜𝑝^𝐸2, 𝑚₁₁). 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.

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.

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.