Concurrency coverage criteria for activity diagrams

Mahesh Shirole, Computer Engineering & Information Technology Department, Veermata Jijabai Technological Institute, Matunga, Mumbai 400 019, India. Email: mrshirole@it.vjti.ac.in Abstract Existing coverage criteria for Unified Modeling Language (UML)‐based system design have used mostly structural constructs and sequential‐behavioural coverage criteria. However, concurrent‐behavioural coverage criteria are not sufficiently explored. The basic path coverage criteria, in UML‐based system design, do not distinguish between non‐interleaving and interleaving execution paths in concurrent activity diagrams. Herein, the main contribution is to present a new set of coverage criteria, based on activity‐ interleaving paths for concurrent activity diagrams. For this, first, we modified the definitions of basic path and basic path coverage criterion, and then we defined the interleaving activity path, interleaving activity path coverage, and total activity path coverage criteria. It is observed that the proposed coverage criteria explore most of the concurrency behaviours to uncover concurrency errors. They help to uncover different types of concurrency errors like synchronization, data‐race, and deadlock.


| INTRODUCTION
With the advent of multi-core architectures, concurrency plays a significant role in design and development of state-of-art software systems. Software testing used for estimating quality and reliability of software under test, is becoming more challenging. The difficulty of concurrent program testing is intensified due to concurrency features such as non-determinism, synchronization, and inter-process communication [1]. As implementation of concurrent designs leads to possibly exponential concurrent behaviours (execution interleaving) at run-time, a proper selection of coverage criteria is a key factor for efficacy and efficiency of the testing efforts.
Concurrent programs lead to potentially non-deterministic interleavings at runtime. This mainly seems to be caused by programmers inability to move away from a flat imperative programming style that was never meant for implementing concurrent behaviour. Threads, semaphores etc. are operating system-specific additions that were added to programming languages that follow a linear execution path. Programmers may fail to obey locking discipline required for the said new operating system-specific additions, this leads to run-time problems. To ease of understanding, one can model concurrent behaviour at a higher level of abstraction, for example using activity diagrams. At that level, a more natural way of specifying such behaviour, using fork/join constructs, is available. From these models, code is ultimately generated in an imperative programming language, in which concurrency issues can occur due to unexpected interleavings.
Concurrency errors are difficult to uncover by traditional testing methods alone, specifically traditional structural testing. Traditional structural testing focuses on structural element coverage: statement, branch, and basic path, which constitutes sequential behavioural coverage criteria. Since, concurrent software system involves execution interleaving inside concurrency constructs, testing of concurrent systems is challenging to uncover concurrency errors. Recently, researchers are exploring on test scenarios generation based on concurrent activity diagrams to explore concurrent behaviour of the system [2][3][4].
In traditional code-based testing, source code is arranged first into a control flow graph (CFG). Then, coverage criteria based on CFG constructs, are defined by node-coverage, transition coverage, branch coverage, and path coverage [5]. Some of the coverage metrics are also based on the data flow information through CFG such as def-use, def-predicate-use, and def-all-use [6]. These coverage criteria are strong enough to test the traditional structural testing goals because control flow and data flow in CFG are deterministic.
However, traditional structural coverage criteria are not appropriate for concurrent systems because these criteria do not specify requirements on concurrent structural elements and concurrent behaviour. Coverage criteria can be classified in two types: (i) structural element coverage criteria, and (ii) behavioural coverage criteria. Structural element coverage criteria are defined on independent elements of either a code or a model. A behavioural coverage criterion is defined on a sequence of structural elements that define a complete behaviour or a functionality of the system. In a concurrency setting, tasks from different threads are executed simultaneously at runtime thereby generating a sequence/arrangement of intermixed tasks from participating threads called as an interleaving path, which represents a concurrent behaviour. Thus, concurrent systems need concurrent behavioural coverage criteria in addition to structural coverage criteria.
Unified Modeling Language (UML) design models promote early test case generation using different design artefacts. UMLbased testing techniques derive test requirements and coverage criteria from UML design diagrams. UML designs represent sequential and concurrent behaviours of the system. For activity diagrams, a set of coverage criteria are defined in literature: activity, transition, basic path coverage [7], and simple path coverage [8]. However, concurrent behaviour coverage criteria have not been discussed, in detail, for activity and sequence diagrams, which represent concurrent behaviours of systems [9].
In this work, we have attempted to answer the following research questions: R1 Are existing coverage criteria sufficient to understand concurrent behaviour by fork-join constructs in an activity diagram?
R2 Can the concurrent coverage criteria be proposed for exploring interleaving within a fork-join construct of an activity diagram?
The main contribution is to propose behavioural coverage criteria for concurrency testing based on concurrent activity diagrams. We have extended code-based concurrency coverage criteria to UML activity diagrams. We have presented interleaving activity path coverage (IAPC) and total activity path coverage (TAPC) criteria. The interleaving coverage criteria are inspired from thread-pair-interleaving as in Lu et al. [10]. In addition, we have redefined the basic path to distinguish between non-interleaving and interleaving execution paths for concurrent activity diagrams.
Herein, Section 2 presents a brief overview of the related work. Section 3 includes a motivating example having interleaved activities. Section 4 discusses existing coverage criteria. Section 5 presents the proposed concurrency coverage criteria for concurrent activity diagrams. Section 6 discusses the results. Finally, Section 7 provides the conclusion.

| RELATED WORK
There are several heuristic means to measure the quality of test suites like fault detection, mutation analysis, or coverage criteria. Among these, coverage criteria are commonly used and popular heuristic means to measure the quality of the test suite [11]. For UML behavioural models, several researchers have proposed coverage criteria as per their interpretations and requirements.
For activity diagrams, a set of coverage criteria are defined in the literature based on activity, transition, basic path [7], and simple path [8]. These defined coverage criteria include structural element coverage, sequential (non-concurrent) behaviour and concurrent behaviour coverage criteria. However, concurrent behaviour coverage criteria are not explored in detail to address concurrency errors.
Linzhang et al. [7] have presented basic path coverage for activity diagrams. In their approach, an activity diagram is traversed from the initial activity node to the final activity node by a depth first search (DFS) with all activities and transitions visited where loops must be visited at most ones. These paths represent a potential single sequence of computational logic (functional requirement). These paths are used for structural testing to satisfy the sequential (non-concurrent) behaviour of software or models. This coverage criterion is not related to concurrency testing, and it does not process or includes any concurrency construct.
Rountev et al. [18] have presented control-flow-based coverage criteria for UML sequence diagrams. Their criteria are generalizations of traditional control-flow criteria, such as branch coverage and path coverage. They are defined in terms of the sequence of messages exchanged among the set of collaborating objects. An inter-procedural restricted controlflow graph (IRCFG) is used to define family of test coverage criteria. They have presented All-RCFG-Paths and All-RCFG-Branches coverage criteria for sequence diagrams.
Mingsong et al. [8] have generalized basic path coverage for concurrency notion in activity diagrams. If each activity in the path occurs only once, then such a path is a basic path of the activity diagram. The diagram composed by all the basic paths of an activity diagram is called basic activity diagram [8]. They have proposed to restrict to one representative path among all concurrent execution interleaving paths having the same partial order as a simple path from the basic activity diagram.
Kundu and Samanta [17] have presented basic path and activity path coverage criterion for activity diagrams. They have presented basic path coverage criterion, where they have suggested checking loop conditions for true and false paths. For concurrent activity diagrams, they have presented activity path coverage criterion, where they have suggested selecting of concurrent path generated from DFS-BFS algorithm.
Ferreira et al. [15] have presented a state machine model coverage analysis tool. Their tool supports coverage analysis of Modified Condition/Decision Coverage (MC/DC) and boundary-value criteria of the guards of the state machine. It analyzes the coverage of the model that is achieved by a given test suite. For better visual understanding of coverage, it is represented by colouring the elements in the model. Kosmatov et al. [16] have presented data-oriented model-based coverage criteria, by formalizing boundary testing heuristics. A test selection algorithm for a given boundary coverage criterion is presented. Their algorithm generates test sets by minimizing and maximizing cost functions. These criteria are used to measure the coverage of test cases generated from formal specification models like B, Z and UML/OCL.
For sequence diagrams, a set of coverage criteria are defined, namely message, message sequence path coverage [14], and all message path coverage [19].
Although, existing UML-based coverage criteria are sufficient for non-concurrent systems, there is a need to define the concurrent behavioural coverage criteria for UML design (both activity and sequence diagrams) to address concurrency errors. These criteria enables designing test suite early in the software development to uncover concurrency errors.

| A MOTIVATING EXAMPLE
A behaviour represented by an activity diagram is a path from the start node to the end node. There are typically many possible paths between the start node and the end node of activity diagrams, and each path representing a different behaviour of the system at run-time. For testing concurrency errors, one may need to test as large as n! execution interleavings to detect a concurrency error, where n is the degree of parallelism [20]. A degree of parallelism is represented by the number of activities inside a fork-join control structure for concurrent activity diagrams. Non-interleaving execution (sequential execution), where tasks from a single thread are executed from the start node to the end node, always follow a fixed path for a given input. While interleaving execution (parallel execution), where tasks from two or more threads are intermixed randomly from the thread start to the thread end (fork-join) thereby generating different paths for a given input.
We consider an example of a bank amount transfer transaction through an automated teller machine (ATM), as shown in Figure 1. This example is selected to illustrate sequential (non-interleaving) and interleaving execution behaviours. The ATM system communicates with the bank server for different transaction types: deposit, withdrawal, amount transfer, and balance inquiry. When a bank customer arrives at an ATM station, he/she inserts a plastic card encoded with the personal account number containing the customer's name and account information. Then the customer enters his or her personal identification number. The customer selects the desired transaction from the list of options to complete his/her transaction, further in the sequence; the customer's request is processed by the system. For example, if the customer requests for a money-transfer transaction and enters the destination account number and amount then the system checks the balance in the customer's account. If the account balance is sufficient, money is transferred to the other account at bank server. The transaction information and new balance are printed on the receipt and the customer's ATM card is returned. A scenario captured in the figure represents concurrent transaction processing from different ATMs transferring amount between two accounts.
Test case generation from UML designs is governed by the intermediate representation (IR) to which diagrams are transformed. In this approach, we first translate an activity diagram into an IR called activity CFG, which is CFG-like representation suitable for graph traversal algorithms, as shown in Figure 2.
The activity diagram shown in Figure 1 represents four different behaviours: (a) invalid user, (b) valid user with exit action, (c) valid user with insufficient balance, and (d) valid user with sufficient balance. Among these behaviours, fourth behaviour, i.e. a valid user with sufficient balance has a concurrency construct, which leads to six different interleaving paths. The scenarios represented for the said behaviours are discussed based on intermediate graph representation.
Therefore, there are total nine test scenarios representing sequential and concurrent behaviours. All the nine behaviours are listed as follows:

F I G U R E 1 An activity diagram for ATM Transfer Transactions
For non-concurrent programs, there is no notion of a context/thread switch among the parts of the same program. Concurrent programs have more than one threads, control flow from one thread to another is known as context/thread switch. In a test scenario of a concurrent behaviour, a context switch is represented by a keyword CS below the arrow, like a 7 → t 14 CS a 8 . The fourth behaviour has six interleavings: B 1 4 , B 2 4 , B 3 4 , B 4 4 , B 5 4 , and B 6 4 , where a superscript indicates an interleaving number and a subscript indicates a behaviour number.

| EXISTING COVERAGE CRITERIA
Next, we consider the exiting coverage criteria for activity diagrams and consider the above example to appreciate the coverage. Linzhang et al. [7] defined basic path coverage for activity diagrams. Their basic path definition allows all distinct paths generated by the Depth First Search (DFS) method from the initial activity to the final activity. A set of basic paths must cover all transitions and action states. It has only restriction to the loop nodes, which may generate multiple paths. The restriction is to execute loops at the most once thereby generating only one path for the loop nodes. Kundu and Samanta [17] have illustrated the need of testing both the looping and non-looping paths for loop nodes.
Basic path coverage criterion defined in Linzhang et al.'s approach is as follows: Definition 1 Basic Path Coverage Criterion: Let BP be the basic path set of an activity diagram, tc be the set of test cases, for any p 1 ∈ BP, there must be at least one test case t ∈ tc such that when the software is executed using 't', the basic path 'p 1 ' of the activity diagram is executed [7].
A basic path represents an independent path from the start node to the end node of either a graph or a graph representation of an activity diagram. An independent path represents a potential single sequence of computational logic (functional requirements). A set of all such independent paths are used for structural testing to satisfy the sequential (non-concurrent) behaviour of software or models. In their definition of the basic path, processing of fork-join construct is not addressed. Hence, basic path coverage criterion is not related to concurrency testing, and it does not process or include any concurrency artefact.
For the motivating example's activity CFG in Figure 2, DFS method generates five paths from the initial activity to the end activity as follows. Paths p 1 , p 2 , and p 3 represent three sequential (non-concurrent) behaviours B 1 , B 2 , and B 3 respectively. Paths p 4 and p 5 represent behaviour B 4 , but behaviour B 4 is concurrent and paths p 4 and p 5 do not represent complete concurrent execution paths. The concurrent behaviour B 4 , which has six execution interleavings, is not distinguished from sequential behaviour in the above definition of basic path. Basic path definition does not give clear idea whether interleaving paths of concurrent behaviours are to be considered or not. Thus basic path coverage criterion does not give correct estimation of the coverage of paths in case of concurrent activity diagrams.
To overcome the issue of the concurrent behaviours, Mingsong et al. [8] have generalized basic path coverage using the partial order relation between activities inside the forkjoin construct of activity diagrams. They have proposed simple path definition based on the basic activity diagram, which is composed by all the basic paths of an activity diagram. Mingsong et al. have used improved DFS algorithm to take care of concurrency constructs thereby generating complete concurrent paths. Thus, all the paths generated by the improved DFS algorithm considers sequential behaviours and concurrent behaviours. The definition of simple path presented in their approach uses all sequential and concurrent paths generated from an activity diagrams. From all these paths they select distinct paths that have a different set of activities and their partial order. In other words, they select one representative path from a set of paths that have the same set of activities and the same partial order relation. Thus, simple path includes all basic paths as defined in Linzhang et al.'s approach for sequential behaviour and one representative path from all concurrent paths that have the same set of activities and the same partial order relation for concurrent behaviour.
Consider the following example to understand selection of one representative path among all concurrent execution interleaving paths having the same partial order as a simple path. Suppose threads T 1 ¼ {a 1 , a 2 } and T 2 ¼ {b 1 , b 2 }, where a 1 , a 2 , b 1 , and b 2 represent activities in the respective threads inside fork-join concurrency construct then paths are all execution interleavings. All these paths have same set of activities {a 1 , a 2 , b 1 , and b 2 } from threads T 1 and T 2 , and they have same partial order relations: a1⪯a2 and b1⪯b2, where symbol "⪯″ represents a partial order relation. Hence, all paths {s 1 , s 2 , s 3 , s 4 , s 5 , s 6 } have the same partial order. Any selected single representative path, say s 1 , is a simple path.
For the motivating example in Figure 1, following four simple paths of which three paths are {p 1 , p 2 , p 3 } that cover all behaviours B 1 , B 2 , B 3 , and the fourth path is p 4 0 , which covers concurrent behaviour B 4 .
The path p 4 0 is a representative simple path for all six interleaving paths. Kundu and Samanta [17] have presented activity path coverage criterion based on simple path coverage criterion where they suggest selecting a path generated by BFS algorithm as a representative paths rather than selecting any arbitrary path. Thus selection of a specific representative path among the set of simple path is resolved by considering activity path coverage criterion. BFS algorithm generates the number of paths in proportion to the factorial of number of threads. For example, if fork-join construct has two threads then number of paths generated by BFS algorithm would be 2! ¼ 2.
For the motivating example in Figure 1, activity path coverage criterion selects four paths of which three paths are {p 1 , p 2 , p 3 } and one representative path from following two paths.
Concurrency errors, such as deadlock, race condition, and atomicity violation, are not present in traditional sequential programming. A deadlock occurs when a chain of processes/ threads are involved in a cycle in which each process is waiting for resources/locks that are held by some other processes [21]. Data race happens when two or more threads access the same shared variable without proper synchronization, where at least one of the access is a write to the variable [22]. An atomicity violation occurs when an interleaved execution of a set of statements (expected to be atomic) by multiple threads is not equivalent to any serial execution of the same set of statements [23]. A serializable execution behaviour (scenario) is the one that always leaves the shared variables in consistent state.
As discussed in Shirole and Kumar [24], execution interleavings are divided into four classes: serialize, blocked, datarace, and non-data-race interleavings based on the execution behaviours that may uncover a specific class of concurrency errors. But, a simple path coverage criterion selects only one test scenario, which falls into any single class among the above classes of execution interleavings. Moreover, an activity path coverage criterion selects only one test scenario that falls either in blocked interleavings if thread are dependent or in no-datarace interleavings if threads are independent. Hence, selecting any single interleaving path may not cover all the above concurrent behaviours. Moreover, there is no specific general thumb rule to select specific interleaving that addresses all the above classes. This demands more number of test scenarios for testing concurrent systems.
Although, concurrency has been addressed by the simple path coverage criterion. A complete distinction between sequential and concurrent behaviours, has not been considered. This distinction will help test management team to allocate separate resources towards sequential and concurrent behaviours for testing. Sequential behaviours will allow to have completed structural testing and the concurrent behaviours will allow to have concurrency testing separately. One may exclude the concurrency interleaving paths from the testing SHIROLE AND KUMAR -47 schedule based on testing goals 80% coverage (stopping criteria) in rush delivery schedules. To avoid such slippage, there is need of distinction of the sequential and concurrent coverage criteria.

| PROPOSED CONCURRENCY COVERAGE CRITERIA
In an activity diagram, two types of execution paths are available: non-interleaving paths (which consist of activities, decisions, iterations, and merges) and interleaving paths (which consist of activities, decisions, iterations, merges, forks, and joins). Non-interleaving paths have a total order from the start activity to the end activity, and their execution represents a single trace. Interleaving paths have a partial order from the start activity to the final activity inside fork-join; and their execution represents different interleaving sequences. A basic path definition discussed by Linzhang et al. [7] does not distinguish between non-interleaving and interleaving paths for concurrent activity diagrams. Similarly, although simple path and activity path coverage criteria distinguish between noninterleaving and interleaving paths for concurrent activity diagrams, they still consider non-interleaving and interleaving paths under single coverage criterion. For concurrent activity diagrams, distinction between paths and their respective coverage criteria will help to effective effort estimation and test management for sequential and concurrency testing. Herein, we distinguish interleaving and non-interleaving paths. Hence, we redefine basic path and basic path coverage criterion for only non-interleaving paths of activity diagrams. In addition, we also introduce new interleaving activity path and IAPC criterion for concurrent activity diagrams.

| Proposed basic path coverage criterion
Traditional structural testing aiming for coverage of structural elements and sequential (non-concurrent) behaviours. To cover sequential behaviours and elements, we only consider activities, decisions, iterations, and merges of activity diagrams as nonconcurrent constructs. Activity diagrams either include nonconcurrent constructs and/or concurrency construct, that is fork-join. To eliminate ambiguous interleaving paths from structural testing, one should consider only non-concurrent constructs of activity diagrams. Thus, with this restriction basic path can be redefined as follows.

Definition 2 Basic Path: A path from the start activity to the end activity traversed by DFS method through non-concurrent constructs of an activity diagram, is called the basic path of the activity diagram, if all activities occurs once except some activities, like loop condition which occurs once or twice, in the path.
This revised new definition of basic path based on Linzhang et al. [7], which explores only non-interleaving paths of activity diagrams with or without concurrency constructs. Also satisfies Kundu and Samanta [17]'s condition of testing both the looping and non-looping paths for loop nodes. Thus, in basic path all activities barring the loop, should be visited once. In the loop condition, this needs to be visited once (in case of non-looping) or twice (in case of looping). Basic path coverage criterion based on this new definition of the basic path is defined as follows.

Definition 3 Basic Path Coverage
Criterion: Let P be the set of basic paths of an activity diagram, and TS be the set of test scenarios generated from the activity diagram. The test set TS satisfies basic activity path coverage, if and only if, ∀ p ∈ P, ∃ t ∈ TS such that when the software is executed using 't', the basic path 'p' of the activity diagram is executed.
The revised basic path coverage criterion is applicable for both non-concurrent activity diagrams and concurrent activity diagrams outside fork-join constructs. It includes all paths generated by DFS method for non-concurrent activity diagram. Whereas, it includes all paths generated by DFS method excluding concurrency construct parts of concurrent activity diagram.
For the motivating example in Figure 1, there are three basic paths that cover behaviours B 1 , B 2 , and B 3 by the proposed basic path coverage criterion. The fourth behaviour B 4 is excluded as it includes a concurrency construct. The behaviour B 4 results in interleaving paths that is addressed by IAPC. The proposed basic path coverage criterion eliminates ambiguous interleaving paths and selects only sequential behaviours. Thus helping the test team on defining structural testing goals.

| Interleaving activity path coverage criterion
Concurrent activity diagrams represent two types of the behaviours: parallel computing and concurrent computing. In parallel computing multiple small tasks that are independent to each-other execute simultaneously to complete a tasks. In this case, all threads are independent and their any execution interleaving will not result in concurrency errors except synchronization at join. In concurrent computing two or more threads executes simultaneously but they have some dependency among them that result in restricting some of the execution interleaving paths. Concurrent computing leads to concurrency errors if the implementation does not include required restrictions on some of the interleaving paths by imposing appropriate synchronization primitives. In a nutshell, multiple (independent) sub-tasks execute simultaneously to complete a task in parallel computing while multiple dependent tasks execute simultaneously to complete a task in concurrent computing, and this may lead to concurrency errors. Thus, for concurrent activity diagrams generating test set for concurrency error is a challenging task. The simple path definition by Mingsong et al. [8] selects one representative path among all interleaving paths having the same set of activities and the same partial order relation. The simple path coverage criterion is suitable for parallel computing, where a single interleaving test scenario is good enough to test synchronization at join and the execution of all parallel tasks. However, this criterion is not sufficient for testing concurrency errors. This implies that for concurrency testing there is need of more number of test paths. In other words, a test suite should have at least one representative test scenario from each behaviour presented in the study by Shirole and Kumar [24] to uncover concurrency errors like data races, data inconsistency, and deadlocks. Besides these facts, it is not clear in advance which interleaving paths will lead to the specific concurrency behaviour; therefore, it is necessary to explore maximum number of the test scenarios for concurrency testing.
In code-based testing, Lu et al. [10] have proposed interleaving coverage criteria hierarchy for concurrent programs to systematically explore the interleaving space, and thereby effectively expose concurrency bugs. Similarly, we have proposed IAPC and TAPC criteria for UML-based testing derived from Lu et al.'s [10] coverage criteria hierarchy. We first define interleaving activity path and then IAPC criterion.

Definition 4 Interleaving Activity Path: A path from the start activity to the end activity through concurrent constructs of an activity diagram, is called the interleaving activity path if the path includes concurrent activity interleaving due to the fork-join construct and all activities occurs once except some activities, like loop condition which occurs once or twice, in the path.
Interleaving activity path occurs only in concurrent activity diagrams. These type of paths have three sub-paths: 1) a sequential prefix path, 2) a sequential suffix path, and 3) an interleaving sub-path, which has same set of activities and same partial order, between prefix and suffix sub-paths. For the motivating example in Figure 1,  An IAPC criterion requires that all activity interleavings due to the fork-join construct of a concurrent activity diagram be covered. Some paths, which are blocked, execute partially as oppose to the other paths. For example, all interleaving paths B 1 4 , B 2 4 , B 3 4 , B 4 4 , B 5 4 , and B 6 4 are covered by the new IAPC criterion of Figure 1. This new coverage criterion covers only fourth behaviour B 4 , which includes concurrency construct, whereas behaviours B 1 , B 2 , and B 3 are excluded. As compared with simple path IAPC criterion selects large number of test paths that will increase a chance of uncovering concurrency errors.

| Total activity path coverage criterion
A non-concurrent activity diagram consists of only basic paths. A concurrent activity diagram consists of either interleaving activity paths and basic paths or only interleaving activity paths. Therefore, the TAPC criterion is proposed for concurrent activity diagrams which is a collection of both basic and interleaving paths.

Definition 6 Total Activity Path Coverage Criterion: Let TP be the union of the set of basic paths and set of interleaving activity paths of an activity diagram, and TS be the set of test scenarios generated from the activity diagram. The test set TS satisfies total activity path coverage, if and only if, ∀ p ∈ TP, ∃ t ∈ TS such that the test scenario 't' visits every activity and every transition of the path 'p' according to the order specified by p.
In the case of non-concurrent activity diagrams, number of total activity paths is the same as the number of basic paths. TAPC criterion covers all paths of the Figure 1,  paths. In TAPC, both the non-interleaving and interleaving paths are combined. But complete coverage of the interleaving paths is not possible for large activity constructs, due to exponential increase in the number of paths. Thus, for exploring different concurrent behaviour, we need to find as many paths as possible. The scenarios including data races, data inconsistency and deadlocks are not known in advance, therefore higher coverage of interleaving paths may uncover some of these concurrency errors.

| RESULTS AND DISCUSSION
We have analytically carried the coverage analysis of different types of concurrent activity diagrams. The test sets are generated from the activity diagrams. For this, first, an activity diagram is translated to an IR, a CFG-like structure, which we have named as 'Activity CFG'. Then, we have generated test scenarios from the IR using the standard, though modified, DFS [25] and DFS-BFS [17] algorithms. Then, we have executed these test scenarios.

SHIROLE AND KUMAR
-49 A modified DFS algorithm processes threads one after another inside fork-join construct thereby generating serializing test scenarios. In DFS-BFS algorithm, the DFS algorithm is used for non-concurrent parts of the activity graph, whereas the BFS algorithm is used for concurrent parts of the activity graph inside fork-join to generate test scenarios. The modified DFS and DFS-BFS algorithms run on the IR of activity diagram. An IR of a bank amount transfer transaction example (Figure 1) is shown in Figure 2. This IR is stored in a text file format for further processing, as shown in Figure 3.
We have considered four different applications with two threads each and different type of read and write access. Read and write access may lead to different behaviours based on the type of interleaving take place at run-time. Table 1 shows different application scenarios and their basic paths, interleaving paths, and their distribution in concurrent behaviours. The basic paths are calculated using the DFS algorithm for non-concurrent applications. The interleaving paths are calculated using the following equation: where m-number of threads, n i -number of nodes (activities) in thread 'i'. For example, if there are two threads inside the fork-join construct with first threads having three nodes and second thread having two nodes, then total interleaving paths are (3! þ 2!)/(3!2!) ¼ 5!/3!2! ¼ 10. If any thread has a decision node inside the thread then calculation for that thread shall be done considering the true path and the false path separately.
i. Airport check-in application: It has no read and write access inside fork-join construct, hence all the execution paths represent the parallel computation and show nondata-race behaviour. ii. ATM money withdraw application: It has read access inside fork-join construct. This read access is inside the decision node. The single read access leads to serializing behaviour and non-data-race behaviour. iii. ATM money transfer application: It is both threads have read and write access inside fork-join construct. Both the threads access different data. The read and write access in both threads lead to serializing and blocking behaviors. iv. Order processing application: It has read and write access by a single thread on different data. All read and write accesses by a single thread on different data leads to serializing and blocking behavior. v. Graphics utility application: It has read and write access by both threads on the same data. In this application, the first thread has write access and the second thread has write access followed by two read accesses. All interleaving paths represent data-race, blocking, and non-data-race behaviors.
Due to limitations of the UML notations to show the synchronization primitives, (critical regions) in the UML syntax, we have inserted the synchronization primitives in the IR. Synchronization primitives of critical-region-start and critical-region-end are achieved by including lock and unlock activities around the activities, where data-access is required. Addition of the synchronization primitives in the IR will facilitate the concurrent behavior analysis. Therefore, we have added these nodes in the text file. We have shown IR of the motivating example, where only fork-join construct is explored, as shown in Figure 4.
The inclusion of the critical region information results in increase in the number of interleaving paths and a chance to explore different concurrent behaviours. Without including the above information, it would be difficult to carry out the experiments that represent results leading to different concurrency behaviours, as discussed in the study by Shirole and Kumar [24].
To understand effect of the inserting data access information to shared objects, we have carried out analysis. To do this analysis, we have chosen the application which have data access to the shared objects, that is, read and/or write. Table 2 shows synchronization primitives inserted to the number of threads, number of total paths, basic and interleaving paths, and the concurrent behavior as shown by the interleaving paths. Results show that insertion of the synchronization primitives increases the number of interleaving paths, at the same time, it facilitates to uncover the concurrent behaviours like serializing, blocking, data-race and no-data-race, as shown in Table 2. In short, addition of synchronization primitives explores the change in behaviour of the generated test scenarios.
If one does not include the synchronization primitive information to the shared data then resulting paths will not show F I G U R E 3 An activity diagram graph text file format 50 -SHIROLE AND KUMAR TA B L E 1 Basic paths, Interleaving activity paths and their respective distribution in different concurrent behaviours [24] for application scenarios any concurrent behavior, and test manager will not get complete idea of the possible risk in the future. Test team may only work on structural and parallel computation testing.
To clarify, how the number of interleaving paths increase, we have demonstrated the calculation of number of paths for the ATM Money Transfer example. We have considered three cases as shown in Figure 4; the number of interleaving paths, in case, (a) no insertion of synchronization primitives: (4!/ 2!.2!) ¼ 6, (b) with synchronization primitives in single thread: (6!/4!.2!) ¼ 15, and (c) with synchronization primitives in the both thread: (8!/4!.4!) ¼ 70. Similarly, the calculation was carried out for other applications, as shown in Table 2. The analysis of the generated test scenarios is carried out using the approach presented in the study by Shirole and Kumar [24].
For ATM Money Transfer and Graphics Utility application scenarios, all the interleaving paths are categorized as data-race behavior. Similarly, all the interleaving paths are categorized as non-data-race behavior for the Order Processing application scenarios. The effect of inserting synchronization primitives activities, that is, critical-region-start (lock) and critical-region-end (unlock), in a single thread and both threads, are shown in Table 2. For the Order Processing application scenarios, only one thread has shared data access, therefore the analysis is carried out only up to a single thread, and the resulting interleaving paths are classified as serializing behavior. For the ATM Money Transfer and the Graphics Utility application scenarios, both the threads have shared data access, hence the analysis is carried for a single and two threads. For the ATM Money Transfer application scenario, inserting synchronization primitives to the single thread does not give any additional information. But, inserting synchronization primitives to both the threads result in exploring concurrent behaviors, namely serializing, blocking and nondata-race. Similarly, inserting synchronization primitives to both the threads result in exploring concurrent behaviors, namely blocking, data-race and non-data-race for Graphics Utility application scenarios.
We have carried out coverage analysis of the application scenarios discussed above for the existing and the proposed coverage criteria based on the test suite generated by the modified DFS [25] and the DFS-BFS [17] algorithms. Table 3 shows the result of percentage coverage results for the existing coverage criteria, namely basic path and simple path, and proposed coverage criteria, namely basic path, interleaving activity path, and total activity path. Total four test scenarios are generated by the modified-DFS and DFS-BFS algorithms for ATM money Transfer Transaction application. For clarity, we have shown only the part inside the fork-join construct based on the IR, as shown in Figure 4. The test scenarios generated by the modified DFS algorithm are: (b) interleaving activity path coverage:-completeness is not possible due to exponential test scenarios. However, selecting test scenarios that satisfy the concurrency behaviours discussed by Shirole and Kumar [24], will give concurrency behaviour completeness. To achieve this maximum number of paths need to be generated which may fall in different concurrency behaviours; (c) total activity path coverage:-it is combined coverage of both basic path and interleaving activity path coverage, hence complete coverage is not possible because interleaving activity path coverage is not possible to achieve completely. Applicability: (a) basic path coverage:-it is applicable for the both concurrent and non-concurrent application designs; (b) interleaving activity path coverage:-it is only applicable for concurrent application designs; (c) total activity path coverage:-it is applicable for the both concurrent and non-concurrent application designs. À Usability: (a) basic path coverage:-it is usable for the both concurrent and non-concurrent application designs; (b) interleaving activity path coverage:-it is only usable for concurrent application designs; (c) total activity path coverage:-it is usable for the both concurrent and nonconcurrent application designs. À Runtime Performance: (a) basic path coverage:-for this coverage, test scenarios are generated using existing DFS and DFS-BFS algorithms, hence the run-time performance O(V þ E), which is good; (b) interleaving activity path coverage:-for this coverage, test scenarios are generated using existing DFS and DFS-BFS algorithms, but number of test scenarios are not sufficient. A new algorithm need to be considered, which may explore the interleaving space. As interleaving space is exponential and the run-time performance is not good in this case; (c) total activity path coverage:-it is combined coverage of both basic path and interleaving activity path coverage. So run-time performance is good in case of non-concurrent activity design and concurrent activity design with no data access in any thread; and not good in case of concurrent activity design with data access on both threads. À Limitations: (a) basic path coverage:-no limitations as there are existing test scenario generators achieve 100 % basic path coverage; (b) interleaving activity path coverage:-currently there is no possibility of achieving 100 % interleaving path coverage with existing test scenario generators. Need to explore on test scenario generator that will increase the coverage; (c) total activity path coverage:-no limitation for non-concurrent activity design, however for concurrent activity designs there are some limitations. Some of the above issues are open research areas in concurrent system design.

| CONCLUSION
Clear distinction between sequential and concurrent execution behaviours of concurrent activity diagrams is indicated. To take account of distinct execution behaviours, we have redefined basic path coverage criterion, and presented new coverage criteria, namely interleaving activity path and TAPC for concurrent activity diagrams. IAPC criterion includes more interleaving test scenarios as compared to the simple path coverage criterion. The proposed coverage criteria satisfy concurrent behaviours, namely serializing, synchronization, blocking, and non-blocking. Thereby, the above proposed criteria increase the probability of uncovering concurrency errors. Distinction of non-interleaving and interleaving paths in concurrent activity diagrams helps to effective effort estimation and test management for sequential and concurrent testing. The future work may explore larger number of test scenarios that may cover different concurrent behaviours. TA B L E 3 Percentage coverage achieved for existing coverage criteria: basic path and simple path, and proposed coverage criteria: basic path, interleaving activity path (IAPC), and total activity path (TAPC) by the combined test suite generated by Modified DFS and DFS-BFS algorithms