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

Authors: Debasish Kundu; Debasis Samanta; Rajib Mall
Journal: ISRN Software Engineering
 (2012)

---

## 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 likealt, 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.


---

## Body

## 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 Section2. 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 asalt, 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 asinteraction 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=〈N,E〉, where N={n1,n2,…,ni,…,nq} is a set of nodes and E={〈ni,nj〉} is a set of edges. A node ni∈N represents a model element of the ItrDgm, and an edge 〈ni,nj〉∈E represents a control flow between two model elements say mi (corresponding to ni) and mj (corresponding to nj).Nodes of thecontrol flow graph are of two types: message node and fragment node representing message and fragment boundary, respectively. The messageand fragment node is uniquely represented by a tuple〈T,ID,B,RO,M,PR,RVar〉, where(i)
T 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)
B is the start or end boundary of a fragment. The value of B is set as S and E 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 tomessage node. It has the value null for fragment node.(v)
M 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 methodM, and is null for fragment node.(vii)
RVar is a return variable that keeps the value returned by the method M. It is null for fragment node.Interaction
AninteractionI is a set of zero or more message occurrences in an interaction diagram [1]. That is, I={m1,m2,…,mn∣n≥0}, where m1, m2, …, mn are the n number of messages in the interaction diagram. If n=0, then I is referred to as null interaction, and if n=1, then I is referred to a message. On the other hand, if n>1, then I is referred to a set of messages of a fragment.Precedence Relation
For any twointeractionsIx and Iy in a set of interactionsMI, we say there is a precedence relationIx≺Iy if Ix∈MI occurs immediately before Iy∈MI according to the timing order in the interaction diagram. It implies that if there exists a precedence relation between Ix and Iy in MI, then there would be no Iz∈MI such that Ix≺Iz and Iz≺Iy. This relation satisfies the following properties.(a)
IfIx≺Iy, then Iy⊀Ix, where Ix,Iy∈MI(asymmetric).(b)
IfIx≺Iy and Iy≺Iz, then Ix⊀Iz, where Ix,Iy,Iz∈MI(non-transitive).(c)
Ix⊀Ix(non-reflexive).Null Precedence Relation
LetP(MI) be a set of precedence relations on MI. Note that if MI is the set of messages of a fragment fi and an operand of the fragment fi contains a single message m′, then there would be no precedence relation containing the message m′ in P(MI). To ensure the existence of some precedence relation in P(MI) that would contain m′ as an operand, null interaction may be assumed to have occurred before or after m′. The precedence relation between m′ and null interaction is called null precedence relation, which is defined below.A precedence relation(Ix≺Iy) of P(MI) is called a null precedence relation if either Ix or Iy is null interaction. If Ix is the null interaction, then Ix≺Iy is called the left  null precedence relation and written as Λ≺Iy. On the other hand, if Iy is the null interaction, then Ix≺Iy is called the right null precedence relation and written as Ix≺Λ.


### 2.2. Control Flow Primitives

We now consider control flow primitives for most commonly used fragmentsalt, opt, break, and loop.Alt Fragment
Thealt 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 m2 and m3, respectively.Figure 1
The control primitives for the fragmentsalt, opt, break, and loopof interaction diagram.As observed in Figure1(a), after receiving the message m1 from ObjectA, ObjectB sends the message m2 to itself if C1 becomes true, otherwise, ObjectB sends the message m3 to ObjectC. Finally, reply message m4 is sent from ObjectB to ObjectA. Figure 1(b) depicts corresponding graph representation for the interaction diagram containing alt fragment. Note that four nodes m1, m2, m3, and  m4 represent four messages m1, m2, m3, and m4, respectively, and two nodes alt1S and alt1E correspond to the start and end of the alt fragment, respectively. Two alternative flows are modeled by two outgoing edges from alt1S and two incoming edges at the node alt1E 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
Theopt fragment has only one operand that is executed optionally [12]. In Figure 1(c), an interaction diagram contains an opt fragment with two messages m2 and m3. These two messages are executed if the guard condition C1 becomes true. Figure 1(d) depicts graph representation for the interaction diagram (in Figure 1(c)). Note that when the guard condition C1 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 opt1S (corresponding to the start of opt fragment) to the node opt1E (corresponding to the end of opt fragment) as shown in Figure 1(e).Break Fragment
Thebreak fragment is used to capture an exit point of the systems [12]. In Figure 1(f), we see that if guard condition C1 becomes true, then it exits after execution of two messages m2 and m3, following which no further message (i.e., m4 and m5) would be executed. Note that the control flow which is transferred from the start of break fragment to the message m4 when the guard condition C1 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 break1E (corresponding to the end of the break fragment) as a sink node and introducing an edge from the node break1S to the node m4 in control flow graph (see Figure 1(h)).Loop Fragment
Theloop fragment is used to model repetitive interactions [12]. In Figure 1(i), we see that message m2 of the loop fragment gets executed repeatedly until the guard condition C1 associated with loop fragment becomes false. When C1 becomes false, loop terminates and execution of the message m3 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 loop1E to the node loop1S and another loop exit edge from loop1E to m3 (see Figure 1(k)).There are many more fragments such aspar 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.


## 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 asinteraction 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=〈N,E〉, where N={n1,n2,…,ni,…,nq} is a set of nodes and E={〈ni,nj〉} is a set of edges. A node ni∈N represents a model element of the ItrDgm, and an edge 〈ni,nj〉∈E represents a control flow between two model elements say mi (corresponding to ni) and mj (corresponding to nj).Nodes of thecontrol flow graph are of two types: message node and fragment node representing message and fragment boundary, respectively. The messageand fragment node is uniquely represented by a tuple〈T,ID,B,RO,M,PR,RVar〉, where(i)
T 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)
B is the start or end boundary of a fragment. The value of B is set as S and E 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 tomessage node. It has the value null for fragment node.(v)
M 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 methodM, and is null for fragment node.(vii)
RVar is a return variable that keeps the value returned by the method M. It is null for fragment node.Interaction
AninteractionI is a set of zero or more message occurrences in an interaction diagram [1]. That is, I={m1,m2,…,mn∣n≥0}, where m1, m2, …, mn are the n number of messages in the interaction diagram. If n=0, then I is referred to as null interaction, and if n=1, then I is referred to a message. On the other hand, if n>1, then I is referred to a set of messages of a fragment.Precedence Relation
For any twointeractionsIx and Iy in a set of interactionsMI, we say there is a precedence relationIx≺Iy if Ix∈MI occurs immediately before Iy∈MI according to the timing order in the interaction diagram. It implies that if there exists a precedence relation between Ix and Iy in MI, then there would be no Iz∈MI such that Ix≺Iz and Iz≺Iy. This relation satisfies the following properties.(a)
IfIx≺Iy, then Iy⊀Ix, where Ix,Iy∈MI(asymmetric).(b)
IfIx≺Iy and Iy≺Iz, then Ix⊀Iz, where Ix,Iy,Iz∈MI(non-transitive).(c)
Ix⊀Ix(non-reflexive).Null Precedence Relation
LetP(MI) be a set of precedence relations on MI. Note that if MI is the set of messages of a fragment fi and an operand of the fragment fi contains a single message m′, then there would be no precedence relation containing the message m′ in P(MI). To ensure the existence of some precedence relation in P(MI) that would contain m′ as an operand, null interaction may be assumed to have occurred before or after m′. The precedence relation between m′ and null interaction is called null precedence relation, which is defined below.A precedence relation(Ix≺Iy) of P(MI) is called a null precedence relation if either Ix or Iy is null interaction. If Ix is the null interaction, then Ix≺Iy is called the left  null precedence relation and written as Λ≺Iy. On the other hand, if Iy is the null interaction, then Ix≺Iy is called the right null precedence relation and written as Ix≺Λ.


## 2.2. Control Flow Primitives

We now consider control flow primitives for most commonly used fragmentsalt, opt, break, and loop.Alt Fragment
Thealt 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 m2 and m3, respectively.Figure 1
The control primitives for the fragmentsalt, opt, break, and loopof interaction diagram.As observed in Figure1(a), after receiving the message m1 from ObjectA, ObjectB sends the message m2 to itself if C1 becomes true, otherwise, ObjectB sends the message m3 to ObjectC. Finally, reply message m4 is sent from ObjectB to ObjectA. Figure 1(b) depicts corresponding graph representation for the interaction diagram containing alt fragment. Note that four nodes m1, m2, m3, and  m4 represent four messages m1, m2, m3, and m4, respectively, and two nodes alt1S and alt1E correspond to the start and end of the alt fragment, respectively. Two alternative flows are modeled by two outgoing edges from alt1S and two incoming edges at the node alt1E 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
Theopt fragment has only one operand that is executed optionally [12]. In Figure 1(c), an interaction diagram contains an opt fragment with two messages m2 and m3. These two messages are executed if the guard condition C1 becomes true. Figure 1(d) depicts graph representation for the interaction diagram (in Figure 1(c)). Note that when the guard condition C1 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 opt1S (corresponding to the start of opt fragment) to the node opt1E (corresponding to the end of opt fragment) as shown in Figure 1(e).Break Fragment
Thebreak fragment is used to capture an exit point of the systems [12]. In Figure 1(f), we see that if guard condition C1 becomes true, then it exits after execution of two messages m2 and m3, following which no further message (i.e., m4 and m5) would be executed. Note that the control flow which is transferred from the start of break fragment to the message m4 when the guard condition C1 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 break1E (corresponding to the end of the break fragment) as a sink node and introducing an edge from the node break1S to the node m4 in control flow graph (see Figure 1(h)).Loop Fragment
Theloop fragment is used to model repetitive interactions [12]. In Figure 1(i), we see that message m2 of the loop fragment gets executed repeatedly until the guard condition C1 associated with loop fragment becomes false. When C1 becomes false, loop terminates and execution of the message m3 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 loop1E to the node loop1S and another loop exit edge from loop1E to m3 (see Figure 1(k)).There are many more fragments such aspar 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 Figure2(a). The interaction diagram in Figure 2(a) has five messages m1, m2, m3, m4, and m5 and two fragments opt1 and alt1. Figure 2(b) 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 Figure2(a).XMI representation of Figure2(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,m1) 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 m1. 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 m1. 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 m1, which imply that ObjectA of ClassA sends a message m1 to ObjectB of ClassB. In other words, for the node m1 (corresponding to the message m1) 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 fragmentalt1 (xmi:id = “_487”; line 33) and tagged elements at 41 and 49 correspond to the end of two operands of the fragment alt1. Furthermore, the tagged elements 33 and 50 correspond to the start and end of the fragment alt1, respectively. Therefore, the node alt1S (representing the start of the fragment alt1) 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 alt1E (representing the end of the fragment alt1). Note that correspondence among tagged elements (33, 34 and 42) or (41, 49 and 50) are not explicitly specified in XMI representation.Table1 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 Figure2(b) with tagged elements in XMI representation of Figure 3.
Nodes in Figure2(b)Tagged elements in Figure3m14, 66, 25, 24, 62, 20, 16, 2, 21, 17, 3opt1S28, 29m25, 67, 53, 52, 54, 21, 17, 3alt1S33, 34, 42m38, 68, 59, 58, 39, 21, 17, 3, 22, 18, 7m411, 69, 61, 60, 47, 21, 17, 3, 23, 19, 10alt1E41, 49, 50opt1E56, 57m563, 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 ofinteraction 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 standardSAX (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 fi and aOperand (of EOperand class) is the object corresponding to the operand, then fi 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 nameXMI tagged elementValue of attribute “xmi: type”ClassOperation〈ownedOperation〉- - -EOperationCallEvent〈packagedElement〉“uml: CallEvent”ECallEventMessage〈message〉- - -EMessageMessageEvent〈fragment〉“uml: MessageOccurrenceSpecification”EMessageEventLifeline〈lifeline〉- - -ELifelineCombinedFragment〈fragment〉“uml: CombinedFragment”EFragmentOperand〈operand〉- - -EOperandClass〈packageElement〉“uml: class”EClassObject〈ownedAttribute〉- - -EObjectFigure 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, ma corresponding to object aMessage. Note that the return variable of ma is represented as a reply message and specified immediately after ma 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,
(1)aMessage.ReturnVar=bMessage.argumentValueList[0]
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 objectaMessage in the list of EMessage objects, we need to find a set of messages Mseq, set of reply messages Rseq (using the value of attribute “messageType”) from that list. A set of fragments Fseq is also to be obtained from the list of EFragment objects. Mseq, Rseq, Fseq can be determined as follows. 							(2)Mseq={aMessage.Id∣aMessageexistsinthelistofEMessageobjects}.Rseq={aMessage.Id∣aMessage.Id∈Mseq&aMessage.messageType=“reply"}.Fseq={aFragment.Id∣aFragmentexistsinthelistofEFragmentobjects}.(d) Finding Message Sets of Fragments
To determine the set of messages of a fragmentfi∈Fseq, we identify the aFragment object (corresponding to the fragment fi) from the list of EFragment objects and then the set of EOperand objects SEOprdsfi such that an object aOperand∈SEOprdsfi is associated with aFragment object, that is, aFragment.OperandList contains the aOperand.Id. In other words,
(3)SEOprdsfi={aOperand∣aOperandexistsinthelistofEOperandobjects&aFragment.OperandListcontainsaOperand.Id&fi⟶aFragment}.
We then find the set of EMessage objects SEMsgsfi for the fragment fi such that aMessage∈SEMsgsfi is associated with an object aOperand∈SEOprdsfi, that is, aOperand.MessageList contains aMessage.Id. In other words,
(4)SEMsgsfi={SEOprdsfiaMessage∣aMessageexistsinthelistofEMessageobjects&aOperand.MessageListcontainsaMessage.Id&aOperand∈SEOprdsfiMessage}.
We may note that for the nested fragment fi, SEMsgsfi would contain an object aFragment in the list of EFragment objects and therefore, for each aFragment (corresponding to a fragment fj) in SEMsgsfi, we update SEMsgsfi as
(5)SEMsgsfi=SEMsgsfi∪SEMsgsfj-{aFragment},
where SEMsgsfj is the set of EMessage objects for the fragment fj.
Once the update ofSEMsgsfi is complete, we obtain the set of messages Mfi of the fragment fi from SEMsgsfi as
(6)Mfi={aMessage.Id∣aMessage∈SEMsgsfi}.Step 2 (determining the nodes).
Initially, control flow graphCFG〈N,E〉 is empty. That is, the set of nodes N and set of edges E are both null. In this step, we determine the message nodes and fragment nodes (i.e., N) of CFG. For this, we use the set of messages Mseq, set of fragments Fseq as obtained in Step 1.(a)
For each fragmentfi∈Fseq, we add two fragment nodesfiS and fiE into N of CFG〈N,E〉, where fiS and fiE represent the start and end of the fragment fi, respectively. For each fragment node, we consider (i) the values of instance variables: type (T), ID of the EFragment object corresponding to the fragment fi and (ii) the boundary (B) of the fragment fi (i.e., start boundary or end boundary represented by the fragment node). The value of attribute (B) for the start boundary and end boundary is S and E, respectively. For fragment node, the values of the attributes: RO, M, PR, and RVar of corresponding tuple 〈T,ID,B,RO,M,PR,RVar〉 would be null.(b)
For eachmi∈Mseq, we add a message nodemi into N. To obtain the values of associated attributes: T, ID, RO, M, PR, and RVar of the tuple for the message nodemi, we consider the values of the instance variables: messageType (T), Id, ReceiverObject (RO), MethodName (M), ParameterList and ArgumentValueList (set of parameters and their values, PR), and ReturnVar (RVar) (if any) of the EMessage object corresponding to the message mi. For message node, value of the attribute B would be null.(c)
For each node inN of CFG〈N,E〉, we store corresponding tuple 〈T,ID,B,RO,M,PR,RVar〉 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 EMessage objects.Step 3 (determining fragment structure).
In order to find the edges among nodes inN of CFG, we need to determine the hierarchy structure of the fragments formed by the set of messages of interaction diagram (Mseq). In other words, we are to find the outermost fragments (the fragments that are not contained in another fragment) built by Mseq and then determine the inner fragments contained in each fragment.(a)
To find the outermost fragments formed by the messages inMseq, we need to identify the minimal set of fragments F′⊆Fseq that together correspond to the largest subset of Mseq. For this, we follow two steps.
(i)
Initially, setF′=Fseq (set of all fragments in interaction diagram).(ii)
Exclude the fragmentfi fromF′ if there exists another fragmentfj≠fi andfj∈F′ such thatMfi⊂Mfj, whereMfi andMfj are the sets of messages of the fragmentsfi andfj, respectively. Repeat this step until no such fragmentfi inF′ can be excluded. The resultant setF′ is the minimum set of fragments that can replace the largest subset of theMseq.We then replace the subset ofMseq corresponding to theMfi for each fragmentfi∈F′ by the ID of the fragmentfi. This implies that the message setMseq covers all fragments inF′ as outermost fragments.(b)
To determine the inner fragments contained in each fragmentfi in Fseq, we need to find the minimal set of fragments F′′⊂Fseq that together correspond to the largest subset of Mfi (messages of the fragment fi). For this, we follow two steps given below.
(i)
Find the set of fragmentsF′′⊂Fseq such that the set of messages say, Mfk of a fragment fk∈F′′ corresponds to the subset of Mfi such that i≠k.(ii)
Exclude the fragmentfk from F′′ if there exists another fragment fj≠fk and fj∈F′′ such that Mfk⊂Mfj, where Mfk and Mfj are the sets of messages of the fragments fk and fj, respectively. Repeat this step until no such fragment fk in F′′ can be excluded. The resultant set F′′ is the minimum set of fragments that can replace the largest subset of the Mfi.We then replace that largest subset ofMfi by the IDs of the fragments in F′′.Step 4 (determining the edges).
After determining the hierarchy structure of the fragments formed by the set of messagesMseq of the interaction diagram, we find the edges among nodes in N of the CFG using the following steps.(a)
We apply theprecedence relation≺ on Mseq and obtain a set of precedence relations say, P(Mseq). For this, we consider the sequence number of all messages (i.e., SeqNumber of corresponding EMessage objects) in Mseq, and in case Mseq contains an interaction (i.e., fragment fi), then we use the sequence number of a message in the Mfi (message set of fi). If P(Mseq) includes a precedence relation(Ix≺Iy) such that Ix∈Fseq or Iy∈Fseq, then P(Mseq)=P(Mseq)∪P(Mfk), where P(Mfk) is the set of precedence relations on the set of messages of the fragment fk and fk=Ix or Iy. The unions are repeated for all fragment operands present in the precedence relations of P(Mseq). The reason for union operation in computation of P(Mseq) is the presence of some fragment operand fk in some precedence relation, which implies that precedence relations among the messages in the fragment fk also need to be considered. Note that we compute P(Mfk) using sequence of message Id(s) in the MessageList of the EOperand objects associated with EFragment object corresponding to the fragment fk.(b)
Considering aprecedence relation(Ix≺Iy) in P(Mseq), we draw an edge following the set of rules as mentioned below.
(i)
IfIx,Iy∈Mseq, then we draw an edge from the message node (corresponding to Ix) to the message node (corresponding to Iy). This edge implies that the message Ix occurs immediately before the message Iy.(ii)
IfIx∈Mseq, Iy∈Fseq, then an edge is drawn from the message node (corresponding to the message Ix) to the fragment node (corresponding to the start of the fragment Iy). The signification of this edge is that the message Ix occurs immediately before the start of the interaction that corresponds to the fragment Iy.(iii)
IfIx∈Fseq and Iy∈Mseq, then we draw an edge from the fragment node (corresponding to the end of the fragment Ix) to the message node (corresponding to the message Iy). This edge implies that the message Iy occurs immediately after the end of the interaction that corresponds to the fragment Ix.(iv)
IfIx,Iy∈Fseq, then an edge is drawn from the fragment node (corresponding to the end of the fragment Ix) to the fragment node (corresponding to the start of the fragment Iy). The significance of this edge is that the end of the interaction which corresponds to the fragment Ix occurs immediately before the start of the interaction that corresponds to the fragment Iy.(c)
Next, we draw an edge corresponding to eachleft null precedence relation(Λ≺I)∈P(Mseq). Note that the (Λ≺I) implies that I is the first interaction in a fragment fk∈Fseq and that interactionI is either a message or a set of messages of the inner fragment fi of the fk and fi,fk∈Fseq, where fi≠fk. Thus, we identify the Mfk of a fragment fk∈Fseq such that Mfk contains I. It may be noted that Mfk contains fragments other than messages because the subset of Mfk has been replaced by the fragments in the preceding step (determine fragment structure). If I∈Fseq, then we draw an edge from the fragment node (corresponding to start of the fragment fk) to the fragment node (representing the start of the fragment I) otherwise, we draw an edge from the fragment node (corresponding to start of the fragment fk) to the message node (corresponding to the message I). The edge thus obtained for a left null precedence relation implies that the edge is either between start boundaries of two fragments fk,I∈Fseq or between the start boundary of the fragment fk and the message that occurs first in the fk.(d)
Similarly, for eachright null precedence relation(I≺Λ)∈P(Mseq), we draw an edge in control flow graph. Note that the (I≺Λ) implies that I is the last interaction in a fragment fk∈Fseq and that interactionI is either a message or a set of messages of the inner fragment fi of the fk, where fi,fk∈Fseq and fi≠fk. Thus, we identify the Mfk for a fragment fk∈Fseq such that Mfk contains I. If I∈Fseq, then we draw an edge from the fragment node (representing the end of the fragment I) to the fragment node (representing the end of the fragment fk) otherwise, we draw an edge from the message node (corresponding to the message I) to the fragment node (corresponding to end of the fragment fk). The edge thus obtained for a right null precedence relation implies that the edge is either between end boundaries of two fragments I,fk∈Fseq or between the message that occurs last in the fragment fk and the end boundary of the fk.Step 5 (identifying the labels of edges).
Once the edges of thecontrol flow graph (CFG) are determined, we assign the guard conditions associated with operands of each fragment of Fseq to the edges in CFG. For this, we consider the edge corresponding to each left precedence relation(Λ≺I)∈P(Mseq) and label the edge same as the guard condition associated with the operand of the fragment that contains I (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 I. 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 fragmentsloop, 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 R1 says that if there is an edge labeled with c from the fragment node representing the start of loop fragment loopi to message node mj and another edge from fragment node representing the end of the loop fragment loopi to message node mk, then do the following: (i) add back edge from end of loop fragment loopi to the start of that loop fragment, (ii) add a loop exit edge from the start of loop fragment loopiS to the message node mk with the label same as !c, and (iii) delete the edge from end of the loop fragment loopi to the message mk. Rules R2 to R6 are similar to the rule R1, but only the difference is the contexts where rules are applied. For example, when loop fragment loopi has an inner fragment fj as the first interaction, then rule R2 is applied. Rule R3 is applied when loopi is followed by another fragment fk. Rule R4 is applied when loopi is contained in some other fragment fk as the last interaction. Rule R5 is applied if loopi has an inner fragment fj as the first interaction and loopi is followed by the fragment fk. Rule R6 is applied when loop fragment loopi has an inner fragment fj as the first interaction, and loopi is contained in some other fragment fk 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 c from the fragment node representing the start of opt fragment opti to some message node mj, then add an edge with the label same as !c from fragment node representing the start of opt fragment opti 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 fj 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(SID,EID) with the start node SID and end node EID, respectively, then do the following: (i) add an edge from the start of ref fragment to SID, (ii) add an edge from EID 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.
fi: a fragment withID=i of types opt, break, loop and reffiS,fiE: two fragment nodes representing the start and end of the fragmentfimj,mk: two message nodes representing two messagesfiS→mj: an edge from the fragment node representing start of fragmentfi to message node mjfiS→cmj: an edge fromfiS to mj labeled with the condition cfiS⇝mj: add an edge fromfiS to mjfiS⇝!cmj: add an edge fromfiS to mj labeled with the condition !cfiE↛mj: delete an edge fromfiE to mjR1: (loopiS→cmj&piE→mk)⇒(loopiE⇝loopiS&loopiS⇝!cmk&loopiE↛mk).R2: (loopiS→cfjS& loopiE→mk)⇒(loopiE⇝loopiS&loopiS⇝!cmk&loopiE↛mk).R3: (loopiS→cmj & loopiE→fkS)⇒(loopiE⇝loopiS&loopiS⇝!cfkS&loopiE↛fkS).R4: (loopiS→cmj&loopiE→fkE)⇒(loopiE⇝loopiS&loopiS⇝!cfkE&loopiE↛fkE).R5:(loopiS→cfjS&loopiE→fkS)⇒(loopiE⇝loopiS&loopiS⇝!cfkS&loopiE↛fkS).R6:(loopiS→cfjS&loopiE→fkE) ⇒(loopiE⇝loopiS&loopiS⇝!cfkE&loopiE↛fkE).R7:(optiS→cmj)⇒(optiS⇝!coptiE).R8:(optiS→cfjS)⇒(optiS⇝!coptiE).R9: (refiS→IDrefiE & ID(SID,EID))⇒(refiS⇝SID&EIDrefiE&refiS↛refiE).R10: (breakiS→cmj&breakiE→mk)⇒(breakiS⇝!cmk&breakiE↛mk).R11: (breakiS→cfjS&breakiE→mk)⇒(breakiS⇝!cmk&breakiE↛mk).R12: (breakiS→cmj & breakiE→fkS)⇒(breakiS⇝!cfkS&breakiE↛fkS).R13: (breakiS→cmj & breakiE→fkE)⇒(breakiS⇝!cfkE&breakiE↛fkE).R14: (breakiS→cfjS & breakiE→fkS)⇒(breakiS⇝!cfkS&breakiE↛fkS).R15: (breakiS→cfjS & breakiE→fkE)⇒(breakiS⇝!cfkE&breakiE↛fkE).Illustration of Our Approach
We illustrate our approach for conversion from XMI representation of an interaction diagram to an equivalentcontrol 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 ofGenerate Bill Use Case.Identifying the Fragments and Their Message Sets
Considering XMI representation of interaction diagram as input (see Figure6), 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 ofEMessage objects, we find set of messages Mseq = {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 Fseq is obtained from the list of EFragment objects as Fseq={loop1,alt1,alt2,break1,loop2,break2} (see Figure 6).(b)
We then identify set of messages for a fragmentfi∈Fseq with considering the EFragment object corresponding to fi as well as the set of EOperand objects associated with the EFragment object (see Step1) as Mloop1={3}, Malt1={4,5}, Malt2 = {6,7, 8, 9, 10, 11, 12, 13, 14, 15, 16, 17, 18 }, Mbreak1={7}, Mloop2 = {9, 10}, and Mbreak2={10}.Determining the Nodes
We determine the nodes ofcontrol flow graph from Mseq and Fseq as follows.(a)
We add twofragment nodes into the set of nodes N of control flow graph for each fragment fi∈Fseq and thus obtain N as {loop1S,loop1E,alt1S,alt1E,alt2S,alt2E,break1S,break1E,loop2S,loop2E,break2S,break2E} (see Figure 7).(b)
Adding amessage nodemi for eachi∈Mseq, the set of nodesN becomes N = N∪ {m1, m2, m3, m4, m5, m6, m7, m8, m9, m10, m11, m12, m13, m14, m15, m16, m17, m18, m19}. Here, the filled nodes representfragment nodes, and empty nodes representmessage 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 〈N,E〉 in a table named as Node table (see Table 4). For message nodemi∈N, we use the values of instance variables of EMessage object corresponding to the message i∈Mseq. 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.
NodeSeqNo.TIDBROMPRRVarloop1S—loop1S————loop1E—loop1E————alt1S—alt1S————alt1E—alt1E————alt2S—alt2S————alt2E—alt2E————break1S—break1S————break1E—break1E————loop2S—loop2S————loop2E—loop2E————break2S—break2S————break2E—break2E————m11syn1—POCGenerateBillOrderNumber—m22syn2—ORRGFindOrderOrderNumberaOrderm33syn3—OrderList[i]MatchOrderOrderNumberfoundm44reply4—POC—OrderList[i]—m55reply5—POC—null—m66syn6—aOrderGetStatus—Statusm77syn7—aScreenDisplayMessage“Bill will be generated after delivery of the order”—m88syn8—BRGGetBillList—BillListm99syn9—BillList[i]MatchOrderIDOrderNumberBillFoundm1010syn10—aScreenDisplayMessage“Bill is already generated”—m1111create11—aBill———m1212syn12—aBillGenerateBillNo——m1313syn13—aBillSetBillInfoOrderNumber—m1414syn14—aBillGetBillNo—BillNumberm1515syn15—aBillCalculateBill—BillAmountm1616syn16—BRGAddBillaBill—m1717syn17—aScreenDisplayMessage“BillNumber”, BillNumber, “BillAmount”, BillAmount—m1818syn18—aScreenDisplayMessage“Order is not found while generating bill”—m1919reply19—aForm———Graph representation and control flow graph of interaction diagram forGenerate Bill use case.
(a)
Graph representation(b)
Control flow graphDetermining Fragment Structure
In this step, we first find the outermost fragments formed by the set of messagesMseq. 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 fragmentsF′ that together correspond to the largest subset of Mseq. The F′ is initialized as the set of all fragments of the interaction diagram, that is, F′=Fseq={loop1,alt1,alt2,break1,loop2,break2}. We observe that Mbreak1⊂Malt2,Mloop2⊂Malt2, and Mbreak2⊂Mloop2. As each message set of three fragments break1, loop2, and break2 is subset of message set of alt2, we exclude these three fragments from F′, which reduces F′={loop1,alt1,alt2}. That implies that fragments loop1, alt1, and alt2 together are sufficient to replace the largest subset {3, 4, 5, 6, 7, 8, 9, 10, 11, 12, 13, 14, 15, 16, 17, 18} of Mseq and are the outermost fragments formed by the messages in Mseq. Replacing the largest subset of Mseq by the fragments in F′, we obtain Mseq = {1, 2, loop1, alt1, alt2, 19}.(b)
To determine the hierarchy structure of the fragments inFseq, let us first consider the fragment loop2. Only one fragment break2 is sufficient to replace the largest subset {10} of Mloop2={9,10}. After replacing the largest subset of Mloop2 by break2, we obtain Mloop2={9,break2}. Therefore, loop2 contains only one inner fragment break2. Now consider another fragment alt2. In this case, minimal set of fragments F′′ = {break1, loop2} is sufficient enough to replace together the largest subset {7, 9, 10} of Malt2 = {6, 7, 8, 9, 10, 11, 12, 13, 14, 15, 16, 17, 18}. Therefore, after replacing corresponding subset of Malt2 by each fragment in F′′, we obtain Malt2 = {6, break1, 8, loop2, 11, 12, 13, 14, 15, 16, 17, 18}. It implies that fragment alt2 contains inner fragments break1 and loop2. Note that Mloop1, Malt1, Mbreak1, and Mbreak2 remain unchanged as there is no fragment in Fseq that can replace the subset of message sets of fragments loop1, alt1, break1, and break2.Determining the Edges
In this step, we first applyprecedence relations on Mseq. Depending on the operand of the precedence relation, we determine the edges. (a)
Applying≺ on Mseq, we obtain P(Mseq) = {1 ≺ 2, 2 ≺loop1, loop1≺alt1, alt1≺alt2, alt2≺ 19} ∪P(Mloop1) ∪P(Malt1) ∪P(Malt2). These unions are for the fragment operands loop1, alt1, and alt2 present in the precedence relations of P(Mseq). To compute the unions, we need to have the sets of precedence relations for each fragment operand: loop1, alt1, and alt2. They are computed as below.
(i)
P(Mloop1) = {Λ ≺ 3, 3 ≺ Λ}.(ii)
P(Malt1) = {Λ ≺ 4, 4 ≺ Λ, Λ ≺ 5, 5 ≺ Λ}.(iii)
P(Malt2) = {Λ ≺ 6, 6 ≺break1, break1≺ 8, 8 ≺loop2, loop2≺ 11, 11 ≺ 12, 12 ≺ 13, 13 ≺ 14, 14 ≺ 15, 15 ≺ 16, 16 ≺ 17, 17 ≺ Λ, Λ ≺ 18, 18 ≺ Λ} ∪P(Mbreak1)}∪P(Mloop2).(iv)
P(Mbreak1) = {Λ ≺ 7, 7 ≺ Λ}.(v)
P(Mloop2) = {Λ ≺ 9, 9 ≺break2, break2≺ Λ} ∪P(Mbreak2).(vi)
P(Mbreak2) = {Λ ≺ 10, 10 ≺ Λ}.Therefore,P(Mseq) = {1 ≺ 2, 2 ≺loop1, loop1≺alt1, alt1≺alt2, alt2≺ 19, Λ ≺ 3, 3 ≺ Λ, Λ ≺ 4, 4 ≺ Λ, Λ ≺ 5, 5 ≺ Λ, Λ ≺ 6, 6 ≺break1, break1≺ 8, 8 ≺loop2, loop2≺ 11, 11 ≺ 12, 12 ≺ 13, 13 ≺ 14, 14 ≺ 15, 15 ≺ 16, 16 ≺ 17, 17 ≺ Λ, Λ ≺ 18, 18 ≺ Λ, Λ ≺ 7, 7 ≺ Λ, Λ ≺ 9, 9 ≺break2, break2≺ Λ, Λ ≺ 10, 10 ≺ Λ}.(b)
Depending on the operand of aprecedence relation (Ix≺Iy) in P(Mseq), we draw an edge in control flow graph as follows.
(i)
In our example, we have sevenprecedence relations 1 ≺ 2, 11 ≺ 12, 12 ≺ 13, 13 ≺ 14, 14 ≺ 15, 15 ≺ 16, and 16 ≺ 17 satisfying the condition (Ix,Iy∈Mseq) and thus, we draw seven edges (m1, m2), (m11, m12), (m12, m13), (m13, m14), (m14, m15), (m15, m16), and (m16, m17) in control flow graph.(ii)
The condition(Ix∈Mseq,Iy∈Fseq) is satisfied by the precedence relations: 2 ≺loop1, 6 ≺break1, 8 ≺loop2, and 9 ≺break2, and they correspond to four edges (m2,loop1S),(m6,break1S), (m8,loop2S), and (m9,break2S).(iii)
There are threeprecedence relations alt2≺ 19, break1≺ 8, and loop2≺ 11 satisfying the condition (Ix∈Fseq,Iy∈Mseq). Therefore, we draw three edges (alt2E,m19),(break1E,m8), and (loop2E,m11).(iv)
The twoprecedence relations: loop1≺alt1 and alt1≺alt2 satisfy the condition (Ix,Iy∈Fseq). Considering these two precedence relations, we draw two edges (loop1E,alt1S) and (alt1E,alt2S).(c)
In our example,P(Mseq) (as obtained in step (a)) has the following left null precedence relations: Λ ≺ 3, Λ ≺ 4, Λ ≺ 5, Λ ≺ 6, Λ ≺ 7, Λ ≺ 9, Λ ≺ 10, and Λ ≺ 18. Here, the fragment loop1 contains 3; alt1 contains 4, 5; alt2 contains 6, 18; break1 contains 7; loop2 contains 9; break2 contains 10 (see the message sets Mloop1, Malt1, Malt2, Mbreak1, Mloop2, and Mbreak2). For these eight left precedence relations, we draw the following edges (loop1S,m3),(alt1S,m4),(alt1S,m5),(alt2S,m6),(alt2S,m18),(break1S,m7),(loop2S,m9), and (break2S,m10).(d)
There are eightright null precedence relations: 3 ≺ Λ, 4 ≺ Λ, 5 ≺ Λ, 17 ≺ Λ, 18 ≺ Λ, 7 ≺ Λ, break2≺ Λ, and 10 ≺ Λ. Among them, only one break2≺ Λ has fragment operand and the fragment loop2 contains break2 (see the Mloop2 and  Mbreak2 after replacement in the step [determine fragment structure]). For this right null precedence relation, we draw an edge (break2E,loop2E). For remaining seven right null precedence relations, we draw seven edges (m3,loop1E),(m4,alt1E), (m5,alt1E),(m17,alt2E),(m18,alt2E),(m7,break1E), and (m10,break2E).Identifying the Labels of Edges
We label the edges in thecontrol flow graphcorresponding to the left null precedence relations. Let us now consider a left null precedence relation Λ ≺ 7. Here, 7∈Mbreak1, this means that fragment break1 contains the message 7. The only one operand of the break1 that contains the message 7 is associated with the condition Status≠ “Delivered”. Therefore, the edge (break1S,m7) 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 twoloop fragments and two break fragments. So, we need to apply the control flow rules for them. We observe that first loop fragment (loop1) does not contain an inner fragment and is followed by another fragment alt1, and thus we apply the rule R3. Applying the rule R3, we add two edges (loop1E, loop1S) and (loop1S,alt1S) and delete the edge (loop1E,alt1S). For the fragment break1, we apply the rule R10 as break1 does not contain an inner fragment and is not followed by another fragment. Applying the rule, we delete the edge (break1E, m8) and add the edge (break1S, m8). Applying rule R13 for the fragment break2, we delete the edge (break2E, loop2E) and add the edge (break2S, loop2E). Here, the loop fragment loop2 does not contain a fragment as first interaction and is not followed by a fragment. So, we apply the rule R1 and add edges (loop2E, loop2S) and (loop2S, m11) and delete the edge (loop2E, m11). 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 asXMI2CFG (XMI of interaction diagram to control flow graph) following our approach. We have implemented XMI2CFG in Java language (Java 2) using NetBeans IDE 6.1 [23]. Input of XMI2CFG 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. XMI2CFG visualizes the control flow graph as the output. XMI2CFG 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 Figure8. 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 ofCFGConstructionUnit.TheMyParser 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 “packagedElement”. 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: Id, Name, ClassId, ObjectId, FragmentType, Guard, SendEventId, ReceiveEventId, CallEventId, MessageType, OperationId, MessageId, and LifelineId of the class named MyParser. Note that after processing of a tagged element, only relevant variables would have meaningful values, and the rest would have the null value.Once metainformation of interaction diagram is available through instance variables ofMyParser 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 CFGConstructor, then CFGConstructor object would have a set of arraylists of objects: EMessageList, EFragmentList, EOperandList, EOperationList, ECallEventList, EMessageEventList, ELifelineList, EObjectList, and EClassList. These arraylists store meta object of types EMessage, EFragment, EOperand, EOperation, ECallEvent, EMessageEvent, ELifeline, EObject, and EClass, respectively. To keep the track of the hierarchy structure of fragments as well as operands of a fragment, we use two arraylists: FragmentIDList and OperandIDList. Note that FragmentIDList and OperandIDList keep the IDs of fragments and operands whose processing is still remaining. In order to update these two arryalists, we add the ID into corresponding arraylist within startElement() when SAX parser notifies about the opening of fragment/operand tag. Similarly, we remove the ID of fragment/operand from the corresponding list within endElement(), when SAX parser notifies about the closing of the fragment/operand. We also use different flags such as OperationParameterFlag, and GuardFlag 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 asComputeMessageSet(), ComputeFragmentSet(), DetermineFragmentStructure(), DetermineCFGNodes(), ComputePrecedenceRelations(), DetermineCFGEdges(), DetermineEdgeLabel(), and ApplyControlFlowRules() of CFGConstructor class. Two methods ComputeMessageSet() and ComputeFragmentSet() perform the first step of our conversion approach, that is, computing the message set and fragment set. Two arraylists EMessageList and EFragmentList are used for this purpose. DetermineCFGNodes() performs the second step of conversion. Two Node objects for each fragment (specifying the start and end of the fragment) and one Node object for each message are instantiated. Node information (i.e., the values of instance variables of Node object) is obtained from arraylists EMessageList and EFragmentList. Once a Node object is instantiated, it is added into arraylist named CFGNodeList. As per our conversion approach, DetermineFragmentStructure() 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 IDs of inner fragments (see details in the third step of our conversion procedure). ComputePrecedenceRelations() computes the precedence relations using SeqNo. 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, DetermineCFGEdges() 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, DetermineCFGEdges() 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 Node objects which correspond to the end nodes of the edge, and then instantiate an Edge object using references of the associated Node objects. Once an Edge object is instantiated, it is added into arraylist named CFGEdgeList. To construct the edge label, DetermineEdgeLabel() first identifies Edge object corresponding to that edge and hence, EOperand 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 Edge label is set as same as the instance variable Guard of the corresponding EOperand object. The ApplyControlFlowRules() adds and deletes the edges depending on control flow rules for the fragments: opt, break, loop, and so forth. Final control flow graph is captured in two arryalists: CFGNodeList and CFGEdgeList.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: DotConvertor and GraphViz. We have used the code of GraphViz available in [25]. Taking two arraylists CFGNodeList and CFGEdgeList as the input, the DotConvertor object creates a  .dot file by using node and edge specification as per DOT language [24]. To specify them in DOT language, we have used different methods such as start_digraph(), addln(), and end_graph() of GraphViz class. Once  .dot file is created, an image is produced by calling the methods getDotSource(), getGraph(), and writeGraphToFile() of GraphViz.XMI2CFG 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 XMI2CFG 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 ofXMI2CFG 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 (OCL) 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 (SDG), where a node represents a message and an edge represents control flow. Sarma et al. augment the nodes of SDG 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, SDG 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 SDG 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 UML2.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.



---

*Source: 265235-2012-03-07.xml*