Research Article Synthesis of Test Scenarios Using UML Sequence Diagrams

Transcription

1 International Scholarly Research Network ISRN Sotware Engineering Volume 2012, Article ID , 22 pages doi: /2012/ Research Article Synthesis o Test Scenarios Using UML Sequence Diagrams Ashalatha Nayak 1 and Debasis Samanta 2 1 Department o CSE, Manipal Institute o Technology, Manipal , India 2 School o Inormation Technology, Indian Institute o Technology, Kharagpur , India Correspondence should be addressed to Ashalatha Nayak, asha.nayak@manipal.edu Received 20 December 2011; Accepted 8 February 2012 Academic Editors: S. D. Kim and H. Okamura Copyright 2012 A. Nayak and D. Samanta. This is an open access article distributed under the Creative Commons Attribution License, which permits unrestricted use, distribution, and reproduction in any medium, provided the original work is properly cited. UML 2.0 sequence diagrams are used to synthesize test scenarios. A UML 2.0 sequence diagram usually consists o a large number o dierent types o ragments and possibly with nesting. As a consequence, arriving at a comprehensive system behavior in the presence o multiple, nested ragment is a complex and challenging task. So ar the test scenario synthesis rom sequence diagrams is concerned, the major problem is to extract an arbitrary low o control. In this regard, an approach is presented here to acilitate a simple representation o low o controls and its subsequent use in the test scenario synthesis. Also, the low o controls is simpliied on the basis o UML 2.0 control primitives and brought to a testable orm known as intermediate testable model (ITM). The proposed approach leads to the systematic interpretation o control lows and helps to generate test scenarios satisying a set o coverage criteria. Moreover, the ability to support UML 2.0 models leads to increased levels o automation than the existing approaches. 1. Introduction Due to the increasing size and complexity o sotware applications, the design and speciication have become an important activity in the sotware lie cycle. Interaction-based speciications such as UML sequence diagrams have been ound eective in this regard, as they describe system requirements in the most intuitive way. A sequence diagram captures dynamic aspects o a system by means o messages and corresponding responses o collaborating objects. In other words, method calls, parameters, return values, and the collaborating objects can be explicitly modeled in a sequence diagram. As a result, these speciications can be used not only or capturing system behaviors but also or generating test cases that can precisely check or aults at the implementation level. As recommended by Jacobson, the requirements o a system can be represented by a set o use cases [1, 2]. A use case can have several scenarios describing the main (primary) and alternate (secondary) scenarios. Since a scenario represents the single trace o behavior o the system, completely describing a system requires all the possible scenarios. These multiple scenarios o a use case are not completely independent o one another and are related to realize the behavior o a use case [3 5]. So the test scenario synthesis rom sequence diagram must not only consider the sequence diagram corresponding to a single scenario but consider the behavior rom multiple scenarios that are related to a use case. Beore UML 2.0, the sequence diagram notations considered each scenario separately in a single sequence diagram [6, 7]. Probably, due to that, early research on test scenario synthesis rom sequence diagrams has concentrated on each scenario in isolation. However, there have been many problems on maintaining such a large set o sequence diagrams. The redundant inormation leading to dierent errors in design documents is reported by some researchers [8, 9]. Mainly, any change in the speciication induced a lot o modiication in the associated diagrams. In the absence o scenario relationships, many studies are conducted to iner scenario relationships rom multiple sequence diagrams. To get over-all behavior o the system, such independently written partial behaviors are combined in some o the approaches [10, 11]. However, constructing a single consistent model requires signiicant additional eort rom the designers [10]. UML 2.0 speciications have introduced the notion o combined ragments to model multiple scenarios in a concise manner [7, 12]. These new modeling capabilities

2 2 ISRN Sotware Engineering have provided signiicant improvement in the ability to model large-scale sotware systems [6]. Using the standard constructs to model hierarchical capabilities, it is possible to support models at any arbitrary levels o complexity. At one end, maintaining a large set o diagrams and the subsequent eort in combining has been subsumed by new constructs. However, at the other end, it turns out that there remains a gap to generate test scenarios rom the new models. To address the above gap, this paper investigates the application o sequence diagrams in sotware testing. There are many approaches in the literature or generating test cases rom new sequence diagrams. However, these approaches ocus on interpreting each scenario independently rather than identiying dependencies among them. Consequently, none o the models in the existing approaches allow nested and hierarchical constructs o a sequence diagram ever since the inception o UML 2.0. Even the approaches [13 17] proposed ater the introduction o UML 2.0 have only sketched how to derive test cases while paying little attention to the model itsel. In UML-based testing, models serve as the blueprint rom which test cases are derived. To increase the automation o this procedure and thereby to derive greater beneit rom model-based testing, models have to be accurate. In contrast, the existing tools and techniques are not capable o handling new constructs. This can lead to inaccuracies while interpreting the models. Thus, the primary motivation or the proposed research comes rom the need to support higher level o automation and model precision while adopting UML 2.0 standard. Although 2.0 version o sequence diagrams has increased expressive power, it is very hard to interpret sequence diagrams with new structured control constructs [18, 19]. The interpretation o a single scenario is evident but the way it relates to other scenarios cannot be interpreted easily [20]. Obviously, the interpretation becomes harder or large and complex speciications. Hence, despite the advantages, test scenario synthesis rom the sequence diagrams becomes a diicult and challenging task, especially when interactions include repetitive, alternative, and concurrent control lows. A combined ragment may also enclose nested ragment(s). Further, there can be several operands, each containing its combined ragment [7], which can again be a plain combined ragment or another nested ragment. This implies that the nesting can be arbitrarily complex. Also, there can be dierent types o operators designating each ragment and some o the scenarios may denote early exit paths rom these ragments (break ragment). Based on the type and nesting o combined ragments, scenario identiication requires identiying various control lows that are embedded within combined ragments. Moreover, an early exit path o a combined ragment needs detailed interpretation. For example, an early exit path rom a concurrent ragment cannot be mapped into a one-to-one basis with a scenario. The parallel merging leads to more number o scenarios compared to that o an alternative ragment.pan-wei [21] pointed out that exploring every possible use case scenario is a challenging task. This necessitates the conversion o a sequence diagram to a representation suitable or test scenario generation. In other words, the objective is to develop a testable model that can manage the test scenario generation process rom a sequence diagram. This paper aims at providing methodological support or automating the test scenario generation process rom a sequence diagram using a two-phase approach. The control low analysis o a sequence diagram is accomplished in the irst phase. In order to accomplish control low analysis, it is desirable to view a sequence diagram in terms o units o interaction such as in control low analysis o programs [22]. These units o interaction are termed as blocks and identiy the messages o a sequence diagram in terms o blocks o messages. A directed graph representation known as scenario graph is presented as an outcome o the irst phase. In the second phase, test scenarios are generated rom the scenario graph. The rest o the paper is organized as ollows. A brie discussion on basic deinitions and concepts used in proposed methodology is given in Section 2. Section 3 presents the proposed approach to test scenario generation. Section4 presents an illustration to explain the proposed approach. Experimental results are presented in Section 5.In Section 6, the related work is described and compared with the proposed approach. Finally, Section 7 concludes the paper. 2. Basic Concepts In this section, a brie review o UML 2.0 sequence diagram is presented. The scenario graph is then deined or mapping the control low semantics o various ragments. Based on the control primitives appearing in the scenario graph, a classiication scheme is proposed. Finally, the concept o testable model known as Intermediate Testable Model (ITM) is discussed UML 2.0 Sequence Diagrams. A sequence diagram also called interaction diagram graphically displays a sequence o messages among collaborating objects or various scenarios o a use case. A set o such messages orms an interaction. In order to speciy the notion o interaction, the abstract syntax o sequence diagram is deined as ollows. Deinition 1. A sequence diagram is a tuple D = P, E, l, F where one has the ollowing. (i) P is a set o objects denoting participants involved in an interaction. (ii) E is a set o events where each event corresponds to sending or receiving a message. (iii) l is a labeling unction that maps each event e E to one speciic participant p P such that l(e) = p. The participant is known as the sender while an event e E corresponds to sending a message; otherwise it is known as the receiver. (iv) F is a set o ordered (rom top to bottom) ragments. Each ragment is a set o operands such that F i ={opd 1,..., opd q } where q is the number o operands. An operand opd i, i = 1, 2,..., q is in the orm opr, guard, M where

3 ISRN Sotware Engineering 3 opr denotes the interaction operator associated with the ragment and guard denotes a boolean expression that may be associated with the operand. M is a inite set o messages that are associated with the operand and may contain any ragment(s) nested in the operand opd i.eachm is in the orm (m, s, r)wherem is the label o the message and s, r P denote sender and receiver, respectively. There is an ordering relation over the messages in a operand. For any two distinct events e i and e j let e i <e j denote that e j occurs ater e i.two messages M i = (m i, s i, r i )andm j = (m j, s j, r j )inm can be described by the ordering relation <.Is i = s j and es i <es j or i r i = r j and er i <er j or i r i = s j and er i <es j, then M i <M j. Here, es i and er i denote the sending event and receiving event or a message M i,respectively. Example 2. A typical sequence diagram is shown in Figure 1(a) with three participant objects involved in the interaction where P = {Object 1, Object 2, Object 3 }.There are two alt ragments, each ragment with two operands. In addition, a main ragment named sd will exist by deault [7] which holds these two alt ragments. The main ragment is thus divided into several operands which are ordered rom top to bottom. These operands are marked on the rightmost side o Figure 1(a) as to B 7. In this work, it is considered that messages are generated by synchronous interactions among objects. For every message, there can be Occurrence Speciications, which speciies the occurrence o message events such as invoking and receiving o method calls [7]. The occurrence speciications, in this way, denote message end points along a lieline. es i is used here as the convention or labeling message end points. For example, events associated with message m1 are(es 1, er 1 )wherees 1 is the sender event and er 1 is the receiver event. Now consider messages within operand = (opr, guard, M = {m 1, m 2 })whereopr = sd and guard = true. For both messages m 1 and m 2, the sender object is Object1 such that m 1 = (m1, Object1, Object3) and m 2 = (m2, Object1, Object2). Since es 1 < es 2, m 1 < m 2.Next, there appears an alt ragment with two operands B2 andb3 where B2 = (alt,[c1], {m 3, m 4 })andb 3 = (alt,[c 2 ], {m 5 }). Now, or messages m 3 and m 4, the receiver o m3 and sender o m4 are the same. Accordingly, the ordering is established as m 3 <m 4 since er 3 <es 4. Similarly, messages within all operands are ordered that relect the visual order rom top to bottom. To indicate this ordering, the messages are named sequentially as m1 tom9 infigure 1(a). Thus, a sequence diagram precisely speciies the set o objects and the sequences o message exchanges that are involved in a use case Scenario Graph. In order to systematically investigate the comprehensive low o control rom a sequence diagram, the inormation contained in the sequence diagram is extracted and stored in a graph known as scenario graph [23]. The ollowing nodes are considered while mapping a sequence diagram to a scenario graph. (i) An initial node represents the beginning o a scenario graph. (ii) A block node represents a sequence o messages such as messages within operands o a ragment. (iii) A decision node represents a conditional expression such as Boolean expression that needs to be satisied or selection among operands o a ragment. (iv) A merge node represents an exit rom the selection behavior such as an exit rom an alt or an opt ragment. (v) A ork node represents an entry into a par ragment. (vi) A join node represents an exit rom a par ragment. (vii) A inal node represents an exit o a scenario graph. A scenario graph is deined as ollows. Deinition 3. A scenario graph is a directed graph, G = A, E, in, F.Here,in denotes the initial node such that there is a path rom in to all other nodes and F denotes a set o all inal nodes representing terminal nodes o the graph. Here, A is a set o nodes consisting o BN CN where BN is a set o block nodes, and CN = DN MN FN JN is a set o control nodes such that DN is a set o decision nodes, MN is asetomergenodes,fn is a set o ork nodes, and JN is a set o join nodes. E denotes a set o control edges such that E ={(x, y) x, y A}. It is assumed that each edge is labeled with the Boolean expression where the Boolean expression true is the deault edge label attached to an edge. The structure o each node A i A is deined as ollows. nodeid, nodet y pe, nodedetails where one has the ollowing. (i) nodeid is a unique label attached to each node in scenario graph. (ii) nodet ype = {decision, merge, ork, join} or each C i CN and nodet ype ={block, initial, inal} or all other nodes. (iii) nodedetails ={m 1,..., m q q is a number o messages in BN}.Eachm j nodedetails is deined as a triple m, s, r with each message speciying its sender s, receiverr, and name o the message m or all block nodes BN. nodedetails = {alt, loop, break, opt, par} associates an interaction operator to a control node, C i CN. Example 4. Figure 1(b) illustrates the scenario graph or the example sequence diagram o Figure 1(a). In a scenario graph, an operand o a ragment is denoted by a block node. A block node is shown in ovals and only node-id is mentioned or each o the nodes, or brevity. The guard associated with an operand is shown as an edge descriptor. For denoting ork and join nodes thick-line segments are considered whereas or denoting decision and merge nodes diamond symbols are used. A solid circle is used or denoting initial node and a solid circle enclosed within a hollow outer circle is used or denoting inal nodes. Further, node label is used or denoting block nodes. FN i and JN i labels reer to ork and join nodes, respectively. For denoting decision and merge nodes D i and M i are used as node labels. The node

4 4 ISRN Sotware Engineering Object 1 Object 2 Object 3 es 1 es 2 m 1 m 2 er 2 er 1 [c 1 ] D 1 [c 2 ] alt [c 1 ] [c 2 ] es 3 es 5 m 3 m 5 er 3 es 4 m 4 er 4 er 5 B 2 B 3 B 2 B 3 M 1 er 6 m 6 es 6 B 4 B 4 [c 3 ] D 2 [c 4 ] alt [c 3 ] er 7 m 7 es 7 B 5 B 5 B 6 [c 4 ] es 8 m 8 er 8 B 6 M 2 er 9 m 9 es 9 B 7 B 7 (a) An example sequence diagram (b) The scenario graph or the sequence diagram Figure 1: An example illustrating a sequence diagram and its scenario graph. structures or block nodes and control nodes are discussed hereinater. As shown in Figure 1(b), a block node is assigned one or more messages o an operand. Thus, the node structure or is assigned as (nodeid =, nodet ype = block, nodedetails = {m 1, m 2 }). It can be seen that a decision node D 1 is connected to the node. Since D 1 is a control node, the structure (nodeid = D 1, nodet ype = decision, nodedetails = alt) is assigned to the decision node. In this way, a scenario graph provides an alternate representation or the sequence diagram by preserving all the details that are required or scenario generation Control Primitives in a Scenario Graph. A combined ragment encloses a group o messages that are associated with a speciic type o operator and is expressed in terms o its operands. In the ollowing, each combined ragment will be considered as a basic control primitive. This allows to express nested ragments in terms o basic primitives Loop Construct. A loop in a scenario graph is a set o nodes involved in an iterative computation Selection Constructs. The alt ragment and its variants such as break and opt result in a selection behavior, which are collectively reerred here as a selection construct. A selection construct in a scenario graph can be identiied as a set o nodes involved within a decision node and a merge node. However, there can be dierent variations o selection depending on the way a merge node converges. That is, there exist N, N 0, such that N denotes outgoing lows rom a decision node; a merge node may be used to converge K lows where K denotes incoming lows to a merge node and 0 K N. A selection can be termed as matched selection i all outgoing lows rom a decision node can be matched with each incoming low o a merge node; that is, K = N. I K<N, then it is K-out-o-N selection. Further, there may not be a merge node; that is, lows rom a decision node may not converge into any merge node. This situation is reerred as unmatched selection Fork Construct. A pair o ork-join nodes is considered as a ork construct in a scenario graph. The occurrence o a ork node initiates multiple parallel lows whereas a join node synchronizes these parallel lows. The deault action associated with join is AND and thereore the join node introduces a wait action. Only, when all other incoming lows are ready, the control is transerred on the outgoing edge o a join node Intermediate Testable Model (ITM). The scenario graph is built on the description o the message sequences that occurinausecase.inascenariograph,atestscenariois corresponding to an execution thread. A sequence diagram can be arbitrarily complex, and in such a case, it is not

5 ISRN Sotware Engineering 5 straightorward to interpret execution behavior directly rom a scenario graph. In order to manage the complexity o a scenario graph, an intermediate representation o the scenario graph is proposed which is intermediate testable model (ITM). With ITM representation, each control construct can be analyzed independently. That is, a control construct in the scenario graph can be mapped to a special node in ITM termed as composite node. Thisregionistermed as Control Construct Graph (CCG). To preserve the nesting structure, this mapping is done hierarchically such that a compositenodemayenclosezeroormorecompositenodes. An ITM can thereore be viewed as a concise representation o the scenario graph [23]. Since each ragment has been compressed into a composite node, an ITM is inally a chain o nodes a 1,..., a k such that or all i, 1 i k 1, a i is a predecessor o a i+1. Deinition 5. An ITM G k = A, E, in, is a chain o nodes where one has the ollowing. XMI parser Sequence diagram Scenario graph Model element details Control low interpreter Control low analysis (1) A = A B A C : a inite set o nodes. Each node in A B and A C is a block node and composite node, respectively. (2) E {(a i, a j ) a i, a j A, i j}: a set o directed edges between two nodes a i and a j. (3) in A: the start node representing an initial node o the sequence diagram. (4) A: a inal node representing a node without any successor node. 3. STUSD Methodology In this section, the proposed approach or generating test scenarios rom a sequence diagram is presented. The proposed methodology is termed as STUSD where STUSD stands or Synthesis o Test scenarios using UML Sequence Diagrams. Figure 2 gives an overview o the proposed methodology. A sequence diagram modeled using UML 2.0 design speciications is input to the test scenario synthesis methodology. The sequence diagram is composed by a designer using a CASE tool and stored in XMI ormat. The STUSD approach consists o two phases, control low analysis and test scenario synthesis. The control low analysis phase produces the scenario graph which is the directed graph representation o the given sequence diagram. In the irst step o the analysis phase, the XMI parser reads the sequence diagram and retrieves details such as objects, messages, and ragments along with their corresponding guard inormation. In the subsequent step, the control low interpreter deduces the sequence inormation rom the temporal ordering o messages and orms a scenario graph. This graph, in turn, is used as input to the synthesis phase. In the irst step o the synthesis phase, the ITM generator transorms the scenario graph into a testable model called the Intermediate Testable Model (ITM). Subsequently, the test scenario generator generates test scenarios rom the ITM known as abstract test cases. Details o these steps are discussed in the ollowing subsections. ITM generator Test scenarios Intermediate testable model (ITM) Test scenario generator Figure 2: An overview o STUSD. Test scenario synthesis 3.1. Capturing Model Element Details. In order to map a sequence diagram (exported in XMI ormat) to a scenario graph, a parser is designed to retrieve all inormation pertaining to a sequence diagram. The parser considers the ollowing structures or messages and ragments to capture their inormation. A message M i in a sequence diagram is o the orm m i, sender, receiver (see Deinition 1), where the message is m i = methodname, paramlist, rvalue. Here, methodname denotes the name o a method rom the object sender to the object receiver, paramlist = {p 1,..., p n } denotesaseto parameters associated with the method, and rvalue is the return value o the corresponding message on the sequence diagram. Both parameters and return values are denoted by name, type, value. Here,name denotes the name o the attribute, type denotes the data type associated with the attribute, and value is an instance o the value which is assigned to the attribute. Each participant is o the orm ob jectname, classname. Each ragment F i is structured in terms o its operands, that is, F i = {opd 1,..., opd q q is the number o operands}. An operand structure is assumed to contain our elements: opd i = ragmentid, guard, M, F i where

6 6 ISRN Sotware Engineering ragmentiddenotes the interaction operator such as alt, par, and break that designate the type o ragment and guard denotes a Boolean expression that may be associated with each operand. M is a set o messages thatare associated with the operand and F i denotes an optional list o ragments indicating multiple instances o nested ragments within an operand. The retrieved inormation in the ormat as stated previously is used to build the scenario graph, which is discussed in the ollowing subsection Building Scenario Graph. The element structure stated in the previous section is used to build a scenario graph. It may be noted that the scenario graph representation preserves the sequencing among messages o a sequence diagram. Depending on the interaction operator, each ragment can be eatured with its own low o control. In order to extract this control low, the transormation procedure is given or each ragment type. However, there are two particular issues to be considered in order to apply these transormations to a given ragment. (i) Variability o an operand structure: an operand o the ragment may enclose subragments varying the structure o each operand. (ii) Variability o message structure: the number and type o messages contained within an operand o a ragment may vary. To address the previous, messages within each ragment are conined as an unit o interaction and denoted by a block node. Irrespective o the message structure and operand structure, this allows us to construct the semantics o a ragment in terms o its constituent nodes such as block nodes and control nodes. This abstraction results in predeined transormation so that every ragment can be uniquely transormed to a set o nodes and edges. As a result, any nested ragment can be successively transormed in terms o its contained ragments. The approach to build the scenario graph rom a given sequence diagram is stated in algorithm CreateScenario- Graph. It is deined in terms o a recursive unction exitnode = ProcessFragment (ragmentid, entrynode) to extract the control low within nested ragments (Procedure 1 and Algorithm 1). Initially, the main rame that hosts the sequence diagram o a use case is supplied as a ragmentid. Depending on the contained elements within this main rame, the unction is recursively called with the ragmentid o the element to be transormed. In each transormation, two nodes are distinguished entry node and exit node. The entry node is the current node which is connected to the outside by incoming edges and thereore supplied as input to the unction. The exit node is the node which is connected to the outside by outgoing edges and hence returned as output o the unction. The ragments are processed until the termination condition is reached. When the termination condition or the main ragment is reached, the scenario graph is returned with initial node in as the entry node and the inal node nas the exit node (see Procedure 1). Figure 3 depicts each o the ragment transormation in terms o a rule. In Figure 3 the let side o the rule is a ragment and the right side is a set o nodes and edges. Ater applying a particular rule, the ragment on the let side is transormed into a graph structure which is shown at the right side o the transormation rule. The nodes and in each o the transormation depict the nodes which are outside the ragment. For the sake o explicitly showing entry and exit nodes, the nodes and are marked as entry and exit nodes, respectively. An edge with arrow-head pointing to a node is shown to mark the entry node. Similarly, an outgoing edge rom a node is shown to mark the exit node Building an ITM. While obtaining a scenario graph, the emphasis is on extracting the underlying control low semantics o a sequence diagram. However, to generate test scenarios, it is required to analyze the dependencies that arise within nested ragments. It makes sense, thereore, to provide a structured representation or generating test scenarios. Based on the classiication proposed in Section 2.3, a simpliication on the structure o a scenario graph is carried out. A set o basic primitives are identiied to express a scenario graph in terms o a hierarchical structure. The simpliications lead to a testable model known as Intermediate Testable Model (ITM). The ITM is an intermediate orm o the scenario graph. The objective is to identiy all basic primitives in a scenario graph and reduce them to their corresponding composite nodes (see Section 2.4). Such a procedure o replacing the basic primitives by a composite node is termed as composition. To do the composition, the scenario graph G is traversed looking or basic primitives enclosed by its entry and exit node. For each such basic primitive in G, it is replaced by its composite node. Thus a new graph G i is ormed. I regions are nested with other regions, then the composition is done rom the innermost region to the outermost region successively. The traversal o the scenario graph hence may be repeated several times until no more composition is possible. The composition procedure eventually reduces a scenario graph to a single chain o nodes known as ITM. The composite nodes corresponding to selection, loop, and concurrent constructs are reerred as selection nodes, loop nodes, and concurrent nodes, respectively. There are two main tasks in the composition: identiying dierent types o basic constructs and creating respective composite nodes or each o these types. In the ollowing, the issues related to the compositions o various types o constructs are discussed and then the algorithm that makes use o composite nodes or building the ITM is presented Identiying Loops and Creating Composite Nodes. A loop in a scenario graph is modeled through a decision node. The branches that leave a decision node all have a conditional expression. Among these, there exists branch that exits the loop by connecting the branch to the node outside the region. Similarly, there exists branch that continues looping by connecting the branch to the node inside the region. These conditions are mutually exclusive so that the loop is either entered or exited. A loop ragment o a sequence diagram is

7 ISRN Sotware Engineering 7 Input: D: Sequence diagram in XMI orm // D is the main ragment Output: G: scenario graph in the orm A, E, in, F 1: Create initial node in; 2: x = ProcessFragment (D, in) //Processthemain ragment with ragmentid = D 3: i x inal node then 4: Create inal node n F; 5: Connect edge rom xto n; 6: end i 7: return G with entry node in A and exit node n F; 8: stop Algorithm The scenario graph generation algorithm Procedure 1: Function Create Scenario Graph. essentially a pretest loop as the decision node precedes the looping section. For a pretest loop, the decision node is the entry node. A set o nodes and edges within the entry and exit nodes are recognized as a region and constitute a control construct graph. This region is reduced to a single node as shown in Figure 4(a). It may be noted that the edge entering to the entry node is connected to the composite node. Similarly, the edge leaving the exit node is originated rom the composite node. In addition to this, inormation regarding the type o a composite node is associated with the composite node. For example, the type o the composite node would be loop here. The example in Figure 4(a)(i) models a loop primitive. The identiied loop is marked as composite node L1. The composition transorms the scenario graph structure to ITM as shown in Figure 4(a)(ii) Identiying Fork Construct and Creating Composite Nodes. A ork node is used to model two or more parallel execution paths in a scenario graph. These parallel paths are combined into a single low using a join node. A ork in which all N execution paths are converged with a join node indicates that a ork node is an entry node and join node is an exit node. Once a construct is identiied based on entry and exit nodes, then it is reduced to its corresponding composite node. Entry and exit edges are then attached to this newly created composite node. Figure 4(b)(i) shows such a parallel construct. The composite node o type ork known as X1 is associated with control construct graph as shown in Figure 4(b)(i). The ITM is then built using X1as shown in Figure 4(b)(ii) Identiying Types o Selection and Creating Composite Nodes. The ragments alt, opt, and break correspond to selection behavior. The selection in a scenario graph can be represented as a region enclosed by decision node and merge node. Based on the number o outgoing edges, a selection construct can lead to two-way or multiway selections. A twoway selection represents i-then-else logic by capturing nodes that are executed when the condition is true and the nodes that are executed when the condition is alse. The decision node can also be connected to more than two outgoing edgessoastocaptureswitch-case logic known as multiway selection. Since a selection can be o matched, unmatched, or K-out-o-N type, their composition is addressed separately as given hereinater. Case 1 (Matched selection). In this case, the entry and the exit node can be easily identiied. Figure 4(c)(i) depicts a two-way selection where there are two branches leaving the decision node. The selection can thus be represented as a region enclosed by decision node and merge node. In the same way, a multiway merge orms a well-deined region enclosed by boundary node entry node and exit node as shown in Figure 4(c)(ii). The region enclosed by selection construct is identiied based on entry and exit node types. A composite node is then created to represent this region o the graph. For this purpose, the type inormation is attached to the composite node indicating that it represents a matched selection construct. Figure 4(c)(iv) shows an ITM where the region enclosed by multiway selection is reduced to composite node marked as S1. Case 2 (Unmatched selection). In case o unmatched selection, some branch(s) may not converge at the end o the control low. Such a branch is terminated at an exit node. Figure 4(c)(v) depicts an unmatched selection. A composite node o type unmatched selection is then created and made to associate with this region as shown in Figure 4(c)(v). The inal node is used here to indicate end o low o control. It may be noted that there is no path rom. A composition o unmatched selection is shown in Figure 4(c)(vi). Case 3 (K-out-o-N selection). In this case, K branches are merged and remaining N K are not merged such that K<N. It can be composed in the same way as in the previous two cases with a little modiication. For K branches, the exit node is a merge node. The remaining N K branches are with implicit inal node as exit node. Two separate regions can be composed corresponding to matched and unmatched parts ollowing Cases 1 and 2 o the selection construct, respectively. Figure 4(c)(iii) shows a situation where 3 out o 4 branches are merged. Figure 4(c)(iv) shows

8 8 ISRN Sotware Engineering Input: ragmentid: Fragment, a tag indicating the type o ragment curnode A Output: exitnode A 1: While! End Oragment do // end o current ragment 2: x = GetNextElement(); // Read the next element in the ragment 3: i x = EOF then // Termination condition 4: exitnode = curnode; 5: return exitnode 6: end i 7: case: x = message // x is a message element 8: InsertAtPos(i, x, L); 9: x = GetNextElement(); 10: while x = message do 11: InsertAtPos(i +1, x, L); 12: x = GetNextElement(); 13: end while 14: i x! = message then 15: unread(x); break; 16: end i 17: BN = CreateBlockNode(L) // Create a block node, BN with block o messages in partial order O; 18: ConnectEdge(curNode, BN); // Edge rom curnode to the next node BN 19: curnode = BN; 20: end case; 21: case: x = loop // x is a loop ragment 22: DN = CreateDecisionNode(x.guard) // Create decision node with predicate guard in x; 23: ConnectEdge(curNode, DN); 24: y = ProcessFragment(x, DN.TRUE); 25: ConnectEdge(y, DN); // Create back edge 26: curnode = DN.FALSE; //Outedge rom decision node 27: end case; 28: case: x = opt // x is an opt ragment 29: DN = CreateDecisionNode(x.guard) // Create decision node with predicate guard in x; 30: ConnectEdge(curNode, DN); 31: y = ProcessFragment(x, DN.TRUE); 32: MN = CreateMergeNode(); 33: ConnectEdge(DN.FALSE, MN); 34: ConnectEdge(y, MN); 35: curnode = MN; 36: end case; 37: case: x = break // x is a break ragment 38: DN = CreateDecisionNode(x.guard) // Create decision node with predicate guard in x; 39: ConnectEdge(curNode, DN); 40: y = ProcessFragment(x, DN.TRUE); 41: n= CreateFinalNode(); 42: ConnectEdge(y, n); 43: curnode = DN.FALSE; 44: end case; 45: case: x = alt // x is an alt ragment 46: DN = CreateDecisionNode(nil) // Create decision node with multioperands; 47: ConnectEdge(curNode, DN); 48: MN = CreateMergeNode(); 49: or each operand opd i x Algorithm 1: Continued.

9 ISRN Sotware Engineering 9 50: e i = guard(opd i ); 51: y = ProcessFragment(opd i, DN.e i ); 52: ConnectEdge(y, MN); 53: end or 54: curnode = MN; 55: end case; 56: case: x = par // x is a par ragment 57: FN = CreateForkNode() //Create ork node; 58: ConnectEdge(curNode, FN); 59: JN = CreateJoinNode(); 60: or each operand opd i x 61: y = ProcessFragment(opd i, FN); 62: ConnectEdge(y, JN); 63: end or 64: curnode = JN; 65: end case; 66: end while 67: exitnode = curnode; 68: return exitnode Function ProcessFragment(Fragment, A) Algorithm 1: Function ProcessFragment (Fragment: ragmentid, A: curnode). l 1 l 2 l 3 m 1 [c 1 ] D 1 [c 2 ] l 1 l 2 l 3 m 1 [c 1 ] D 1 [!c1] alt [c 1 ] [c 2 ] m 2 m 3 m 5 m 4 B 2 M1 B 2 opt [c 1 ] m 2 M1 m 6 m 3 m 4 (i) Transorming an alt ragment (ii) Transorming an opt ragment l 1 l 2 l 3 m 1 loop [c 1 ] m 2 m 3 m 4 D 1 [c 1 ] [!c 1 ] break [c 1 ] l 1 l 2 l 3 m 1 m 2 m 3 m 4 Bi [c 1 ] D 1 [!c 1 ] 1 (iii) Transorming a loop ragment (iv) Transorming a break ragment l 1 l 2 l 3 m 1 FN 1 par m 3 m 2 B 2 m 4 B 2 JN 1 m 5 (v) Transorming a par ragment Figure 3: Transorming ragments to their scenario graphs.

10 10 ISRN Sotware Engineering D 1 [else] L 1 D 1 [c 1 ] Entry edge Exit edge L1 FN 1 FN 1 X 2 B 2 Entry edge X JN 1 1 JN 1 Exit edge Bk (i) A loop and its composition (ii) An ITM (a) Creating composite node or a loop ragment (i) Synchronized ork and its composition (ii) An ITM (b) Creating composite node or a par ragment [g 1 ] D 1 [g 2 ] [g 1 ] Bi D 1 [g 2 ] [g 3 ] [g 4 ] B D B 2 B S 1 M 1 M B1 B 2 B 3 B 4 1 M 1 (i) A two-way selection (ii) A multiway selection and its composition D 1 [g 2 ] [g 3 ] [g 4 ] B 2 B 3 D 1 4 S 1 M 1 B 2 Entry edge Exit edge S 1 M 1 (iii) A K-out-o-N selection and its composition (iv) An ITM or K-out-o-N and matched selection D 1 D 1 [g 1 ] [g 2 ] [g 3 ] [g 4 ] S 1 B 2 B 3 B 4 B 2 B 3 B 4 Entry edge S 1 (v) An unmatched selection and its composition (vi) An ITM or unmatched selection (c) Creatingcomposite nodes or dierent types o selection ragments Figure 4: Creating composite nodes or ragments. the composite node creation o type K-out-o-N selection and their subsequent transormation to ITM Algorithm or Building an ITM. Building an ITM rom a given scenario graph is stated in the orm o pseudocode in algorithm BuildITM (Procedure 2). Initially, the scenario graph G is presented as input to the BuildITM algorithm. While traversing through the scenario graph, the graph G i is transormed to G i+1, i at least one region is ound. Otherwise, G i+1 is the same as G i and this condition terminates the algorithm. A lag RegionFound is set or this purpose to indicate i

11 ISRN Sotware Engineering 11 Input: G: The scenario graph in the orm A, E, in, F Output: G k :ITM Data: RegionFound: a lag indicates whether a region is ormed or not 1: RegionFound = TRUE // Initially assumes composition is possible 2: while Region Found do 3: G k = FormIntermediateGraph(G, RegionFound) 4: G = G k 5: end while 6: return G k // No more composition possible Algorithm Building ITM Procedure 2: Function BuildITM. there exists at least one composition (which means that G i+1 G i ). This is handled by the unction G i+1 = FormIntermediateGraph(G i, RegionFound) which transorms G i to G i+1. On each call o FormIntermediateGraph(), the unction ComposeRegion() receives the control node which is the current entry node and returns the exit node o the region located (Procedures 3 and 4). Since a nested construct has successive entry nodes without their corresponding exit nodes, the unction ComposeRegion() locates regions recursively. When all the control nodes are processed, the resulting graph G k is returned to the caller, BuildITM Generating Test Scenarios rom ITM. An ITM is a testable model having behavioral inormation o a system under test (SUT) corresponding to a use case. Alternatively, a path in the scenario graph can be mapped onto a test scenario. Thus, scenario graph can be used to ormally deine the test scenario o a sequence diagram as given hereinater. Deinition 6. AsequenceS = n 0, n 1,..., n q is a test scenario in a scenario graph, i n 0 = in, n q F and (n i, n j ) E, or all i, j, 0 i, j<q,wheree denotesasetoedgesandf denotes a set o inal nodes in a scenario graph. An ITM which is a reduced orm o a scenario graph encapsulates each o the control primitives in the orm o special node known as a composite node. A composite node may also be nested with zero or more composite node(s). It may be noted that an ITM is a chain o nodes rom the initial node to the inal node. This chain is termed as base path and denoted by t b. The base path denotes a sequence o nodes containing block nodes as well as composite nodes. Depending on the construct enclosed, there may be a number o paths enclosed in a region. A composite node is thus said to enclose a set o internal paths. A path beginning with an entry node in a region is termed as an internal path. The number o internal paths composed by each composite node can be derived rom the coverage criteria. In the ollowing, coverage criteria with respect to dierent cases are introduced. Next, an algorithm or test scenario generation that makes use o internal paths is presented Coverage Criteria. Let T be a set o test scenarios or a sequence diagram. T satisies the ollowing coverage criterion i the ollowing condition holds good. (i) Selection Coverage Criterion. For each selection node in an ITM, T must include one test scenario corresponding to each output branch o the decision node. (ii) Loop Adequacy Criterion. For each loop node in an ITM, one has the ollowing. (1) T must include at least one test scenario in which control reaches the loop and then the body o the loop is not executed (zero iteration path). (2) T must include at least one test scenario in which control reaches the loop and then the body o the loop is executed at least once beore control leaves the loop (more than zero iteration path). (iii) Concurrent Coverage Criterion. For each concurrent node in an ITM, T must include one test scenario corresponding to every valid interleaving o message sequences. The messages in a par ragment can be interleaved as long as the ordering imposed by each operand is maintained [7]. In this respect, a valid interleaving sequence is the one which maintains ordering o message sequences within an operand Test Scenario Generation Algorithm. Algorithm GenerateTestScenario has been proposed to produce a set o paths satisying each o the above-mentioned criteria (Procedure 5). The algorithm perorms a depth irst search in the control construct graph starting rom its entry node. An internal path set is associated through each composite node, to expand a path into a number o paths. In that case, any path rom the initial node to a composite node say, C j,issaid to be attached with a suix which is the set o all internal paths corresponding to C j. The ITM representation lends itsel to a simple method o test scenario generation. Initially, t b is the trivial scenario, since t b may contain zero or more composite node(s) with

12 12 ISRN Sotware Engineering Input: G: The scenario graph in the orm A, E, in, F RegionFound: a lag or deciding the termination criteria Output: G k :ITM Data: curnode:denotesthenextnodetobeinspected exitnode: Denotes the trailer node when the region is ormed 1: G k = G // Initially, G is the ITM 2: curnode = in // Start rom the initial node o G k 3: while curnode is not a inalnode do 4: i FindControlNode(curNode) then // curnode is not a control node 5: exitnode = ComposeRegion(G k, curnode) // Composing to be carried out at curnode 6: else 7: i exitnode = NULLthen // Ensures that no composition was carried out so ar 8: RegionFound = FALSE; 9: end i; 10 : break; 11 : end i 12 : curnode = exitnode; 13 : end while 14 : return G k Function FormIntermediateGraph(G, RegionFound) Procedure 3: Function FormIntermediateGraph. Input: G k : The input graph curnode: The current node to be inspected Output: exitnode: The trailer node 1: x = FindMinimalRegion(curNode) // Takes care o nested regions 2: i x = NULL then 3: exitnode = ReduceRegion(curNode) //Do the composition ollowing composition rules 4: Update(G k ) // Update G k with CCG at curnode 5: else // Indicates a nested region is ound 6: exitnode = ReduceRegion(x) //x is the entry node 7: Update(G k ) 8: exitnode = ComposeRegion(G k, curnode) // recursively repeat the composition 9: end i 10: return exitnode Function ComposeRegion(G, RegionFound) Procedure 4: Function ComposeRegion. or without nested composition. It may lead to many more test scenarios on exploring each test scenario successively. In each expansion, a composite node is replaced with one o its internal paths. The number o tests generated is to cover all the paths o an internal path set. Building a set o test scenarios can thereore be considered as replacing each o the composite nodes by each o its internal path. This procedure is carried out until we ind that every composite node is expanded. The algorithm GenerateTestScenario outlines this test scenario generation approach. 4. Illustration o STUSD In this section, the test scenario synthesis approach is illustrated using an example called Cell Phone System (CPS). It is considered that the cell phone being designed has keys or power on and o, digits 0 9, alphabets a z, and buttons, such as talk, cancel, scroll up, scroll down, and end. There are two actors. They are (a) users (customers) who subscribe and request the services and (b) administrators who manage the payment and subscription inormation. From the user s

13 ISRN Sotware Engineering 13 Input: ITM, an intermediate testable model o a given scenario graph with initial node, in. Output: T, a collection o test scenarios orming the test suite. Data: B, a set o base paths which is initially empty P j : a set o internal paths corresponding to a composite node, C j. 1: Generate base path, t b rom ITM 2: B = B t b // Add t b to the set o base paths 3: while B empty do 4: or path t i B do 5: Let t i = n 0, n i1, n i2,..., n ip,...n iq be a sequence o adjacent nodes in t i 6: or all n ij t i do 7: i n ij is not a composite node then 8: T = T t i // t i is ully expanded and it is added to the test suite T 9: Remove t i rom B 10: else 11: or composite node n ij t i do 12: Get internal paths corresponding to the node n ij 13: Let P j ={p 1,..., p m } denote m internal paths corresponding to the composite node n ij 14: or p i P j do 15: Replace the node n ij in t i with the internal path p i and let the expanded orm o t i be t i 16: B = B t i 17: end or // Add t i to B 18: end or 19: end i 20: end or 21: end or 22: end while Algorithm Test scenario generation rom ITM Procedure 5: Function GenerateTestScenario. perspective, dierent ways o interacting with the system are identiied. Each o the use cases is represented with a corresponding sequence diagram. The sequence diagram or Make Call use case is presented in Figure 5. The Make Call sequence diagram models the interactions taking place when the user hits a button. Then onwards, dierent variations and operational conditions are identiied depending on the key pressed. In the ollowing, the procedure involved in the construction o scenario graph and ITM is illustrated with respect to the Make Call use case. Following this, the test scenario generation rom the ITM is illustrated Scenario Graph Construction. The scenario graph G obtained rom the Make Call sequence diagram is shown in Figure 6. Here, the Boolean expressions on the outgoing edges o the decision nodes denote the guard conditions appearing on interaction ragments. Every block node records one or more messages. For example, the irst block node B1 denotes sequence o messages m1 and m2. Then the alt ragment is shown which is mapped onto a decision node with two outgoing edges D 1 to B 2 and to B 3,respectively. For key = cancel combination, there is an unconditional break ragment which brings the user screen to a menuscreen mode closing the interaction. This is shown by a block node, B 2 as the target o edge labeled key = cancel and a inal node. Similarly, the other combination key = digit is maintained as a block bode, B 3. In the same way, all the messages and ragments are parsed to produce the scenario graph ITM Construction. The working o BuildITM algorithm is traced or the sequence diagram shown in Figure 5. The scenario graph o Figure 6 is used as input G. Figure 7 gives the intermediate graphs produced and composite nodes. In these igures, we have sticked to circle notation or denoting nodes. To emphasize on composition procedure, each node is shown with its node identiier and any edge descriptor is ignored. A shaded node denotes a composite node. The composite node is labeled according to the type o composite node. That is, selection nodes are labeled using S i as node labels. For concurrent nodes X i is used as node label and or loop nodes L i is used as node label. The composition procedure starts looking or basic primitives in G classiying them into various types o composite nodes. A loop node named L1 and selection nodes named S1 ands2 arecreated

14 14 ISRN Sotware Engineering Figure 5: Sequence diagram o MakeCall usecaseincps. as shown in Figure 7(b). This orms the irst iteration and the resulting graph at iteration level 1 is called as G 1. In the second iteration, G 1 orms the input producing G 2 as output. In G 2,aconcurrentnodenamedX1 is identiied as shown in Figure 7(d). In this way, the composition procedure continues until it inds that all constructs are reduced. At this level, the inal ITM is ormed which is shown in Figure 7(l) Test Scenario Generation. As per test scenario generation algorithm, the irst step is to generate base path, which

15 ISRN Sotware Engineering 15 B 4 B 2 [key = cancel] D 1 [key = digit] B 3 D 2 [else] [lastkey! = call] B 5 [response = connection [response = invalidno] [response = NWBusy] D 3 Error] [response = connection Successul] B 6 B 7 B 8 B 9 [else] D 4 [status = terminate Call absent] [endkey! = end connection = active] B11 D 5 [else] D [endkey = end] [connection! = 6 D 7 active] [else] 6 B [else] 17 Figure 6: Scenario graph o MakeCall use case. is B = { in, B1, S5 } (see Figure 7(l)). In the next step, the composite node S5 is expanded. As the node type o S5 indicates an unmatched selection, all possible test scenarios corresponding to the selection coverage criterion arecovered.asaresult,s5 will be replaced with each o its internal paths. In this step, it gives rise to two paths into B. The irst o these contains sequences o basic nodes only. Thereore, it is moved into set, T. The second path contains a composite node named L1 ands4. L1 is then replaced with its internal paths conorming to loop adequacy criteria giving rise to two internal paths, D2 and D2, B4. Next, as per selection coverage criterion, our internal paths are produced or selection node, S4. The test scenarios are thus evolved iteratively rom the base path until B becomes empty. Table 1 shows ew iterations o the test scenario generation algorithm. In this table, the underlined nodes denote composite nodes which are expanded in the succeeding steps. 5. Experimental Results In this section, an experiment to investigate the eectiveness o generated test scenarios is presented. Four use cases are considered in the proposed experiment and the test suites or each o these are obtained using the proposed approach. In the ollowing, the use cases considered in this experiment are listed Subject Programs. The our use cases we considered in our experiment are Credit Card Payment, Paper Registration, PIN Validation, and Make Call. Each o these use cases has several control primitives and accordingly their sequence diagrams exhibit moderate complexity. Further, use cases were airly chosen so as to include dierent variations and combinations o control primitives. The use cases are the ollowing: (1) Credit Card Payment use case in Online Shopping System (OSS), (2) Paper Registration use case in Conerence Management System (CMS), (3) PIN Validation use case in Automatic Teller Machine (ATM), (4) Make Call use case in Cell Phone System (CPS). The objective o the proposed experiment is to observe ault detection ability o the generated test suite. For this, a set o mutation operators (stated in Section 5.2) are considered. A mutation operator induces small syntactic change [24] to the programs. A mutant program or mutant is produced by applying a single mutation operator only once to the original program. Applying the mutation operators, a set o mutants are generated. The implementation corresponding to the above-mentioned use cases is in Java and considered as the subject programs. The subject programs we considered are moderately sized Java programs ranging rom 200 to 500 lines o code. These lines o code indicate the unctional part o the program where the aults are speciically seeded. It excludes code corresponding to user interace portions, input-output handling, API inteace, and so orth. The additional details o these subjectprograms are given intable Fault Model. The ault model o proposed automatic test synthesis technique is described here or mutation testing.

16 16 ISRN Sotware Engineering in in D 1 D 1 2 B 2 B 3 D 2 B 4 B 5 D 3 B 6 B7 B 8 B 9 D 4 B11 0 D 5 8 FN D 6 D 7 M 1 6 M 1 7 in D 1 B 2 B 3 L 1 D 3 B 6 B 7 B8 B 9 2 B 5 1 D 5 FN 1 D B 2 B 3 L 1 B 5 D 3 B 6 B 7 B 8 B 9 1 D 5 X 1 D X 1 FN (d) ITM in iteration level 2, G 2 (e) Composite node X 1 in iteration 2 in JN 1 S 1 S 2 JN 1 JN1 S 1 S 2 D 1 B 2 B 3 L 1 B 5 (a) Scenario graph, G (b) Iteration level 1, G 1 D 3 L 1 D 7 D 2 S D 6 1 S 2 M M 1 B B 6 B7 B 8 B 9 D L 2 D 5 (c) Composite nodes L 1, S 1 and S 2 created during iteration 1 8 L 2 X 1 in () ITM in iteration level 3, G 3 (g) Loop node L 2 in iteration 3 D 1 in B 2 B 3 L 1 D 4 D 1 D 1 B 5 S B 2 B 3 B 2 B 3 D S 5 3 L 2 L 1 D 3 in L 1 B 6 S 4 B7 B B B B 6 5 B7 B B 9 8 B 5 S 3 S 4 S 3 S5 S 4 (h) ITM, G 4 in iteration level 4 (i) Selection node, S 3 in iteration 4 (j) ITM, G 5 in iteration level 5 (k) Selection node, S 4 in iteration 5 (l) Final ITM, G 6 (m) Selection node, S 5 Figure 7: Composition procedure or building ITM.

17 ISRN Sotware Engineering 17 Table 1: Generating test scenarios or Make Call. Step Set o base paths, B Set o test scenarios, T 1 { in, B1, S5 } 2 { in, B1, D1, B2,, in, B1, D1, B3, L1, B5, S4 } 3 { in, B1, D1, B3, L1, B5, S4 } { in, B1, D1, B2, } 4 { in, B1, D1, B3, D2, B5, S4, in, B1, D1, B3, D2, B4, B5, S4 } { in, B1, D1, B2, } 5 { in, B1, D1, B3, D2, B5, D3, B6,, in, B1, D1, B3, D2, B5, D3, B7,, in, B1, D1, B3, D2, B5, D3, B8,, in, B1, D1, B3, D2, B5, D3, B9, S3, in, B1, D1, B3, D2, B4, B5, D3, B6,, in, B1, D1, B3, D2, B4, B5, D3, B7,, in,b1,d1,b3,d2,b4,b5,d3,b8,, in, B1, D1, B3, D2, B4, B5, D3, B9, S3 } { in, B1, D1, B2, } 6 { in, B1, D1, B3, D2, B5, D3, B9, S3, in, B1, D1, B3, D2, B4, B5, D3, B9, S3 } { in, B1, D1, B2,, in, B1, D1, B3, D2, B5, D3, B6,, in, B1, D1, B3, D2, B5, D3, B7,, in, B1, D1, B3, D2, B5, D3, B8,, in, B1, D1, B3, D2, B4, B5, D3, B6,, in, B1, D1, B3, D2, B4, B5, D3, B7,, in, B1, D1, B3, D2, B4, B5, D3, B8, } 7 Subject program name Table 2: Details o subject programs. Number o classes Number o methods Lines o code Credit Card Payment Paper Registration PIN Validation Make Call A ault can be detected when the test scenarios are applied to the system under test. Since the test cases can be used to reveal aults during execution o the code, mainly two types o aults are identiied known as interaction aults and message sequence aults. The interaction aults are the results o simple changes to the source program. Previous studies [25 27] have investigated the ault detection eectiveness o these general purpose mutation operators. The message sequence aults are associated with control constructs o the language. In order to inject aults into the control constructs, message sequence aults are investigated in this paper. Various mutation operators are used to cover these aults or inding the ault detection eectiveness o proposed test cases Mutation Operators. The ollowing eleven mutation operators are considered [28, 29]. (1) Language Operator Replacement (LOR). It replaces an arithmetic, logical, or relational operator by another operator rom the same group. It also includes insertion or deletion o unary and logical operators to i, while statements, and so orth. (2) Literal Change Operator (LCO). It increases or decreases numeric values. For Boolean literals, it changes true to alse or alse to true. (3) Method-Name Replacement Operator (MRO). This operator replaces a method name with other method names that have the same parameters and return type. (4) Parameter Change Operator (PCO). This operator changes the order, size, and type o parameters in method declarations or invocations. (5) Type Replacement Operator (TRO). Thisoperatorreplaces a type with compatible types. (6) Variable Replacement Operator (VRO). This operator replaces a variable name with other similar or compatible types. (7) Control-Flow Disruption Operator (CDO).Thisoperator is used to disrupt normal control low by changing break, continue, or return statements. (8) Statement Swap Operator (SSO). It swaps statements in a block such as, statements inside one switch block with another switch, and so orth. (9) Statement Delete Operator (SDO). It deletes one statement in a block such as, in the body o a synchronised method. (10) Loop Change operator (LCO). This operator increases or decreases the intended number o loop iterations by applying the changes to the loop initialization, loop expression, or an update statement. (11) Concurrency-Related Operator (CRO). This operator deletes a call to the wait or notiy method. It can also be used to remove the synchronized attribute rom a method in Java.

18 18 ISRN Sotware Engineering The mutation operators are put into two groups based on the type o aults they cover. The irst six mutation operators are in Group I and this group o mutation operators covers interaction aults that are o general nature which can be applied or the variables, types, classes, expressions, or methods in the source program. In order to directly mutate the control constructs o the source program in Java that handle loops, threads, i-then statement, and so orth, the Group II operators numbered rom 7 to 11 are used. The type and number o mutants produced depend on the source code. Table 3 lists the type and number o mutants generated or dierent use cases Metric or Evaluation. The objective o the proposed experiment using mutation testing is the generation o a test set that can distinguish the resulting output o the mutants rom the original program. In order to evaluate the eectiveness o generated test sets, mutation score is used. The mutation score M or a test suite T is the ratio o distinguished (also known as killed) mutants over the total number o mutants Subject Test Suites. For each subject program mentioned in Section 5.1, sequence diagrams o these use cases are drawn with MagicDraw 16.8 [30] and the diagrams are exported in XML ormat. Following the STUSD methodology discussed in Section 3, subject test suites are constructed. This required instantiating the scenarios with speciic values. Using dynamic domain reduction procedure [31], a easible domain is mapped to each variable in the sequence diagram. The domain analysis or variables was carried out or this purpose to describe operational domains. A valid test input rom the domain is chosen or each o the test scenario. During test execution, any changes in the output are recorded. In order to support this, the subject program is instrumented in such a way that each method returns its method identiier only when the method produces the correct response. By making use o mutation operators, aults are injected in the subject programs. For example, in the implementation o Make Call use case, 61 mutant programs are created with each mutant containing one o the 61 aults. The test suites are executed on each o the mutants. The method identiier is then used to track any deviation in the method execution rom the expected response. This has solved the test oracle problem which was crucial or evaluating the generated test suite. The programwise results or all subject programs with respect to each test suite are shown in Table Analysis o Results and Its Limitation. For each subject program, Table 4 lists a number o mutants generated along with number o mutants killed. Dierent mutants injected under each type o ault are given in Table 3.Inorderto clearly speciy the generated mutants and their killing rate, mutants are shown under two groups. First group reerred to as Group I includes mutants o generic nature as discussed in Section 5.2. Although mutants in Group I try to inject aults and exercise dierent parts o the source program, these mutants cannot directly cause aults into the control constructs. In addition, mutants numbered 7 11 labelled as Group II exercise dierent parts o the source program and cause aults into the statement block such as loop and ithen-else. Intuitively, assuming that the model covers the required behavior, the aults that are injected in those part o the code can only be detected. This means that aults in remaining part o the implementation, i not covered by the model, cannot be killed. For example, in Make Call and PIN Validation, additional aults based on Binder s Modal class test [32] are injected. An object o modal class can accept messages only in a particular state which is reerred here as valid state and rejects the messages in any other state reerred as invalid state. For each modal class under test, the state o the object beore test is then checked against the state o the object ater the test [33]. In order to track this, the state o each object is speciied while the message was received. Following this, the Modal Class Faults (MCFs) are created as ollows. (i) Valid state o the receiving object: this ault is caused to check that the messages are received in the valid state o an object. (ii) Invalid state o the receiving object: this ault is caused to check that the messages received in the invalid state o an object are rejected. At present, aults under MCF category cannot be detected by the proposed approach. Four aults o type MCF are seeded in Make Call subject program and it is observed that the proposed test cases are not able to distinguish these aults. In Table 4, the variations in the ault detecting ability o the subject test suites are due to aults in MCF category. Nevertheless, the path coverage investigated in this experiment is eective at ensuring adequate coverage o the model. This is indeed correlated to the ault detection capability as path coverage is the strongest criteria. These variations among the test suites or a given model and its implementation suggest that achieving lesser coverage may not be appropriate. However, the limitations are due to the modal classes. In order to overcome this, it is required to speciy invariants on classes and their attributes in OCL. This inormation can then be used to validate when the constraints are violated during test execution. Intuitively, a test suite that covers all the test paths o a model requires more testing eort. Based on mutation analysis, however, it achieves adequacy o the test suite. Using ault detection eectiveness, the experimental results have conirmed this. In order to generate test cases, a sequence diagram o arbitrary control low presents challenges due to various types o control primitives and their nesting. The test cases together cover all the coverage criteria and are adequate as conirmed by mutation testing results. 6. Related Work In UML, scenario-based models and state-based models are regarded as two prominent ways to speciy behavioral requirements [34]. Considering the relevant research on

19 ISRN Sotware Engineering 19 Table 3: Mutants or subject programs. Sl. No. Mutation operator Number o mutants or each subject program Make Call Credit Card Payment Paper Registration PIN Validation 1 LOR LCO MRO PCO TRO VRO CDO SSO SDO LCO CRO Total Subject programs Number o killed mutants under Group I (M I ) Table 4: Mutant killing results or subject programs. Number o killed mutants under Group II (M II ) Mutation score (M) Test suite size Make Call Credit Card Payment Paper Registration PIN Validation state machines, there exist some encouraging results. The algorithms and tools or synthesis o state machines rom multiple scenarios are described [35 37]. However, exploiting the conjunction o scenarios to synthesize test scenarios has not been addressed till now. The state machines represent the behavior o individual objects (intraobject) whereas scenario-based models represent interaction among a set o objects (interobject). Hence, the state- and scenario-based speciications are complementary perspectives to model behavioral aspects o a system [36]. In this regard, scenariobased speciications captured by UML interaction diagrams are to be reviewed. Among the interaction diagram-based approaches proposed or test case generation, the proposed survey reveals that interaction overview diagrams and timing diagrams have not yet contributed signiicantly to test case generation. The communication diagrams although similar to sequence diagrams use none o the structuring mechanisms like combined ragments. So, communication diagrams can only correspond to simple sequence diagrams. In this regard, a brie survey o test generation using sequence diagram is discussed hereinater. Among sequence diagram-based test generation techniques, it is worth mentioning that previous research uses sequence diagrams o UML 1.x [32, 38 41]. Binder describes general test requirements to develop test cases rom a sequence diagram [32]. In Basanieri and Bertolino approach [38], test cases are derived rom UML use case and sequence diagrams. The test cases are obtained corresponding to message sequences rom the sequence diagram by ollowing the temporal order o messages. In this way, starting rom sequence diagrams corresponding to subuse cases, the test cases are incrementally derived or the entire system. By consulting class diagram or method and its possible input values, test speciications are then derived. A use case test suite collects all test cases o a given use case. By incrementally constructing test suites, a test rame is deined to hold all use case test suites o the system. Fraikin and Leonhardt approach [39] discuss an approach known as SeDiTeC that uses sequence diagrams to test Java programs. To acilitate testing in an early stage in development, a test stub concept is proposed. This allows to generate stubs or the classes o the system under development when all methods are not implemented. Another approach is proposed by Cheng et al. known as generic tester [40] or testing distributed systems using sequence diagrams. A generic testing scheme is proposed or handling more than one standard o communication speciication in an implementation. A class diagram that supports interace deinitions o all modules along with sequence diagrams is input to the generic tester. According to the method call in a sequence diagram, input data values are generated and validated against the data types in a class diagram. In the approach proposed by Briand and Labiche [41], various UML artiacts that are produced at the development stage are included or deriving test requirements. The sequential constraints between use cases are expressed using activity diagrams. The activity diagram is then transormed into a directed graph rom which use case sequences are extracted. These sequences representing execution paths are then augmented with test-scale inormation by assigning

20 20 ISRN Sotware Engineering actual parameters with symbolic values. In the next step, each use case is described using a sequence diagram in which OCL notation is used or the description o guard conditions. However, the aorementioned approaches [32, 38 41]are not capable o modeling most o the control sequencing lows in their input models. For example, the early termination o scenarios known as breaking scenarios is not possible to handle in UML 1.x approaches. In addition, parallel and choice o selection behavior could not be speciied. Also, there is no acility or expressing nested lows in UML 1.x models. Consequently, there is no urther scope to study how model complexity aects test case generation in these approaches. Fortunately, the problem o complex control lows can be expressed adequately in UML 2.0 approaches. In the ollowing, UML 2.0 approaches are compared with the proposed work. UML 2.0 sequence diagrams have been used in literature or testing UML design artiacts [13, 42]. In design-testing approach, Pilskalns et al. [13] discuss an approach to ind inconsistencies between behavioral view speciied by a sequence diagram and structural view speciied by a class diagram. In their approach, an aggregate model is deined that uses Object Constraint Language (OCL) expressions and combines the inormation rom structural and behavioral views. From a sequence diagram modeled with synchronous calls and interaction operators, alt, loop, and opt, the testing approach is described to generate and execute the tests. For detecting dynamic aults, the tests are conducted to the implementation. However, dynamic aults are limited in inding invalid values to arguments o a method call. In this regard, it is unclear how behavioral view speciically helps in detecting design aults that can be propagated into implementation. In the validation approach proposed by Dinh-Trong, test inputs are derived rom UML class and sequence diagrams [42]. The symbolic execution is applied to generate path constraints where paths are selected to satisy test adequacy criterion in the sequence diagram. However, there is no emphasis on interaction ragments in their approach. There are other approaches to generate test cases or testing implementation instead o validating the sotware model. These are discussed hereinater. Cartaxo et al. present test case generation or eature testing o mobile phone applications [14]. The basis or their approach is UML 2.0 sequence diagrams. A eature is speciied as a smallest part o the service requirement. The input model is transormed to a labeled transition system rom which test cases are generated or eature testing. The transition system works on the basis o annotations and they restrict the message exchanges between only two entities user and system. The input models are ad hoc in their approach and represent only repetitive and conditional sequences without using ormalism such as combined ragments. Due to this semantic gap, the models lack expressiveness o the language. Nebut et al. present test case generation rom use cases along with other ormalism such as contracts [15]. For each use case parameterized with the actors, contracts are speciied using preconditions and postconditions. To express these contracts, they make use o irst, order logical expressions as their language and combine it with predicates and logical operators. By deining contracts or each use case, they build a transition system known as Use Case Transition System (UCTS) that can represent all valid sequences o the use case. These are known as test objectives and constitute the irst phase o their approach. In the second phase, they transorm test objectives to test scenarios. For this phase, they attach sequence diagram as the additional artiact to obtain sequences o message calls on the system under test. As requirements are captured by means o contracts, the sequence diagrams ocus on interaction between system and actors describing the expected exchange o messages using system level sequence diagrams resulting in system testing. For this, they depict each scenario using a separate sequence diagram. The complexity o building editor tool to express declarative contracts demands high precision and rigor in their approach. Javed et al. [16] propose a model-driven approach using model transormation technology to test sotware applications. As a irst step, they transorm a sequence o method calls in a sequence diagram into an xunit model using model-to-model transormation tool, Tekat. Tekat is an Eclipse Modeling Framework (EMF) model transormation engine that executes horizontal (model-to-model) transormations on sequence diagram. In the second step, model-totext transormations are applied using MOFScript tool. At this step, the tester needs to provide a ile deining packages, and so orth, or compiling and executing the generated test cases. This ile known as code header ile along with test data ile which speciies parameter values and expected return values o method calls is provided to generate JUnit test cases. In a similar way, Dai [17] discusses the transormation o UML models using UML 2.0 proile or the testing called the UML 2.0 Testing Proile (U2TP) to support model-driven testing. The testing approach proposed by Javed and Dai [16, 17] has not considered interaction ragments into their test synthesis approach. There have also been approaches which use sequence diagrams or control low analysis [43]. However, their analysis does not ocus on multiple scenarios and their dependency. Compared to the previous approaches, the proposed approach strictly ollows the standard syntax and semantics o combined ragments. Adhering to the semantics, various combinations o nesting can be recognized within ragments. The approach proposed in this paper recognizes breaking scenarios as special type o regions (unmatched constructs). It is noteworthy to observe that none o the approaches studied the problem o unmatched and nested constructs in their input models. 7. Conclusions In this paper, a procedure to generate test scenarios using UML 2.0 sequence diagram has been proposed. Existing test scenario synthesis techniques rom sequence diagrams limit their applicability on speciying and transorming a single scenario or generating inormation about test cases. Consequently, ragments and/or their nesting are not included

21 ISRN Sotware Engineering 21 into test synthesis. These techniques can easily be automated as their input models do not exhibit much complexity. However, exploiting the expressive power embedded in sequence diagrams o arbitrary control low presents some challenging problems while deriving scenarios conorming to a set o coverage criteria. A methodology has been proposed in this paper towards the automation o this procedure. For this purpose, the sequence diagrams representing valid behaviors o the system are analyzed. This includes scenarios that explore boundary tests as they represent valid tests o the system. Representing the structure o a sequence diagram with scenario graph and its simpliied model, ITM has many advantages. The scenario graph provides a graphical representation o the messages among all participating lielines during the lie time o the system. The hierarchical structure o ITM makes it possible to generate test cases based on simple path concatenation technique instead o exhaustive graph search techniques. This has been acilitated by the introduction o separate control low graph or each ragment. The process also leads to maintainable and reusable models. Moreover, the proposed approach can be used as a reerence model or managing a sequence diagram with nested ragments. The two-phase approach proposed in this paper can also be easily tailored to synthesize test cases rom other UML models. Due to the incremental nature o our approach, the analysis phase which is based on speciic UML models needs to maintain changes whereas the generic synthesis phase can easily be applied to generate test cases rom the resulting model. Future work includes translating abstract test cases into executable test scripts or a test execution environment. Future work will also consist in extending the approach to maintain model-based traceability techniques that can assist in mapping requirements with generated test cases. It may also be helpul to support changes to design artiacts or creating relationships between requirements, design, generated test cases, and code. This problem may be especially important due to the iterative nature o sotware development process. Reerences [1] I. Jacobson, Object-Oriented Sotware Engineering: A Use Case Driven Approach, Addison-Wesley, [2] I. Jacobson and P. Ng, Aspect-Oriented Sotware Development with Use Cases, Addison Wesley, [3] A. Cockburn, Writing Eective Use Cases, Addison-Wesley, [4] P. Metz, J. O Brien, and W. Weber, Speciying use case interaction: types o alternative courses, Journal o Object Technology, vol. 2, no. 2, pp , [5] X. Bai, W.-T. Tsai, R. Paul, K. Feng, and L. Yu, Scenario based modeling and its applications, in Proceedings o the 7th International Workshop on Object-Oriented Real-Time Dependable Systems, [6] B. Selic, What s new in UML 2.0? Tech. Rep., IBM Rational Sotware, April [7] UML. UML 2.3 Superstructure-Final Adopted Speciication, Object Management Group, May 2010, spec/uml/2.3. [8] F. J. Lucas, F. Molina, and A. Toval, A systematic review o UML model consistency management, Inormation and Sotware Technology, vol. 51, no. 12, pp , [9] M. Elaasar and L. Briand, An overview o UML consistency management, Tech. Rep. SCE-04-18, Department o Systems and Computer Engineering, Ottawa, Canada, [10] S. Uchitel and M. Chechik, Merging partial behavioural models, in 12th ACM SIGSOFT International Symposium on the Foundations o Sotware Engineering, pp , November [11] R. Mizouni, A. Salah, S. Kolahi, and R. Dssouli, Merging partial system behaviours: composition o use-case automata, IET Sotware, vol. 1, no. 4, pp , [12] D. Bell, UML s sequence diagram, Technical Library, IBM Rational Sotware, February [13] O. Pilskalns, A. Andrews, A. Knight, S. Ghosh, and R. France, Testing UML designs, Inormation and Sotware Technology, vol. 49, no. 8, pp , [14] E. G. Cartaxo, F. G. O. Neto, and P. D. L. Machado, Test case generation by means o UML sequence diagrams and labeled transition systems, in IEEE International Conerence on Systems, Man, and Cybernetics, pp , October [15] C. Nebut, F. Fleurey, Y. Le Traon, and J. M. Jézéquel, Automatic test generation: a use case driven approach, IEEE Transactions on Sotware Engineering, vol. 32, no. 3, pp , [16] A. Z. Javed, P. A. Strooper, and G. N. Watson, Automated generation o test cases using model-driven architecture, in 29th International Conerence on Sotware Engineering and the 2nd International Workshop on Automation o Sotware Test, May [17] Z. Dai, Model-driven testing with UML 2.0, in Proceedings o the 2nd European Workshop on Model Driven Architecture, [18] Z. Micskei and H. Waeselynck, The many meanings o UML 2 Sequence Diagrams: a survey, Sotware and Systems Modeling, vol. 10, no. 4, pp , [19] B. Cornelissen, A. Van Deursen, L. Moonen, and A. Zaidman, Visualizing testsuites to aid in sotware understanding, in 11th European Conerence on Sotware Maintenance and Reengineering, pp , March [20] D. Harel and I. Segall, Visualizing inter-dependencies between scenarios, in 4th ACM Symposium on Sotware Visualization, pp , September [21] N. G. Pan-Wei, Hunting or Use-Case Scenarios, TheRational Edge, Lexington, Mass, USA, [22] F. E. Allen, Control low analysis, ACM Sigplan Notices, vol. 5, no. 7, pp. 1 19, [23] A. Nayak and D. Samanta, Model-based test cases synthesis using UML interaction diagrams, ACM SIGSOFT Sotware Engineering Notes, vol. 34, no. 2, pp. 1 10, [24] A. J. Outt, Investigations o the sotware testing coupling eect, ACM Transactions on Sotware Engineering Methodology, vol. 1, no. 1, pp. 5 20, [25] M. R. Lyu, Z. Huang, S. K. S. Sze, and X. Cai, An empirical study on testing and ault tolerance or sotware reliability engineering, in Proceedings o the 14th International Symposium on Sotware Reliability Engineering, November 2003.

22 22 ISRN Sotware Engineering [26] S. Ali, L. C. Briand, M. J. Rehman, H. Asghar, M. Z. Z. Iqbal, and A. Nadeem, A state-based approach to integration testing based on UML models, Inormation and Sotware Technology, vol. 49, no. 11, pp , [27] A. Paradkar, Case studies on ault detection eectiveness o model based test generation techniques, in 1st International Workshop on Advances in Model-Based Testing, May [28] S. Kim, J. Clark, and J. McDermid, The rigorous generation o Java mutation operators using HAZOP, in Proceedings o the 12th International Conerence on Sotware and Systems Engineering and their Applications, pp. 9 19, Paris, France, December [29] M. Delamaro, M. Pezze, and A. M. R. Vincenzi, Mutant operators or testing concurrent Java programs, in Proceedings o the Brazilian Symposium on Sotware Engineering, pp , Rio de Janeiro, Brazil, [30] MagicDraw, Magicdraw home page, 2010, [31] A. J. Outt, Z. Jin, and J. Pan, The dynamic domain reduction procedure or test data generation, Sotware-Practice and Experience, vol. 29, no. 2, pp , [32] R. V. Binder, Testing Object Oriented Systems: Models, Patterns and Tools, The Addison-Wesley Object Technology Series, Addison-Wesley, [33] R. M. Hierons, K. Bogdanov, J. P. Bowen et al., Using ormal speciications to support testing, ACM Computing Surveys, vol. 41, no. 2, article no. 9, [34] Y. Bontemps and A. Egyed, Scenarios and state machines: models, algorithms, and tools: a summary o the 4th workshop, ACM SIGSOFT Sotware Engineering Notes, vol. 30, no. 5, pp. 1 4, [35] D. Harel and H. Kugler, Synthesizing state-based object systems rom LSC speciications, International Journal o Foundations o Computer Science, vol. 13, no. 1, pp. 5 51, [36] D. Harel, H. Kugler, and A. Pnueli, Synthesis revisited: Generating statechart models rom scenario-based requirements, in Formal Methods in Sotware and Systems Modeling, pp , Springer, [37] J. Whittle and P. K. Jayaraman, Synthesizing hierarchical state machines rom expressive scenario descriptions, ACM Transactions on Sotware Engineering and Methodology, vol. 19, no. 3, article no. 8, [38] F. Basanieri and A. Bertolino, A practical approach to UMLbased derivation o integration tests, in Proceedings o the Sotware Quality Week, November [39] F. Fraikin and T. Leonhardt, SeDiTeC-testing based on sequence diagrams, in Proceedings o the 17th IEEE International Conerence on Automated Sotware Engineering, pp , [40] F. T. Cheng, C. H. Wang, and Y. C. Su, Development o a generic tester or distributed object-oriented systems, in IEEE International Conerence on Robotics and Automation, pp , September [41] L. Briand and Y. Labiche, A UML-based approach to system testing, Journal o Sotware and Systems Modeling, pp , [42] T. T. Dinh-Trong, S. Ghosh, and R. B. France, A systematic approach to generate inputs to test UML design models, in 17th International Symposium on Sotware Reliability Engineering, pp , November [43] V. Garousi, L. C. Briand, and Y. Labiche, Control low analysis o UML 2.0 sequence diagrams, in 1st European Conerence on Model Driven Architecture Foundations and Applications,pp , 2005.

23 Journal o Advances in Industrial Engineering Multimedia The Scientiic World Journal Applied Computational Intelligence and Sot Computing International Journal o Distributed Sensor Networks Advances in Fuzzy Systems Modelling & Simulation in Engineering Submit your manuscripts at Journal o Computer Networks and Communications Advances in Artiicial Intelligence Computational Intelligence & Neuroscience Advances in Artiicial Neural Systems Advances in Sotware Engineering International Journal o Computer Games Technology Computer Engineering Advances in Advances in International Journal o Human-Computer Interaction Biomedical Imaging International Journal o Reconigurable Computing Journal o Journal o Electrical and Computer Engineering Robotics