Development of a Robust Parser for Extracting Artifacts during Model-based Testing from UML Diagrams

Transcription

1 International Journal of Software Engineering and Technology Development of a Robust Parser for Extracting Artifacts during Model-based Testing from UML Diagrams Oluwatolani Oluwagbemi and Hishammuddin Asmuni Department of Software Engineering Universiti Teknologi Malaysia Johor Bahru, Malaysia tolapeace@gmail.com, hishamasmuni@gmail.com Abstract The foundation of any software testing process is test case generation. If test cases are poorly generated, model-based software testing results becomes unreliable or misleading. In model-based software testing, test cases are generated from any modeling tool that contains user s requirements. To generate test cases from modeling tools, a parser is required to read, extract, interpret and display parsed requirements or artifacts which are executed to generate test cases. Existing model-based testing techniques lacks parsers that are capable of reading, extracting and interpreting all diagrams contained in a modeling tool at runtime. This has caused flexibility problems during test case generation. Consequently, this research aims to develop a scalable parser that can aid automatic test case generation from all UML diagrams at runtime. Index Terms Artifacts, modeling diagrams, test cases, parser, requirements, scalability I. INTRODUCTION In model-based testing, test cases are derived from the modeling diagrams used to represent the requirements of stakeholders [1]. These modeling diagrams consist of use case, sequence, activity, class, collaboration, deployment, state chart and component diagrams. A model-based software testing technique compares a system under test (SUT) with stakeholder s requirements represented in any of the software development modeling languages like unified modeling language (UML), ArgoUML, Rational Rose or Magic Draw in order to ensure requirements conformance [2,3]. For modelbased testing to take place, a parser is required to extract artifacts from modeling diagrams which are executed to generate test cases. Model based testing (MBT) consist of three basic flows of procedural events [4] described as follows: (i) the modeling tool used in representing stakeholder s requirements (ii) the parser required to extract artifacts from the modeling diagram and (iii) a test case generation algorithm Generating test cases is considered to be very important because, it is the fundamental activity in model-based software testing process [5]. There are many existing techniques utilized in software testing process. Whatever technique is being utilized, the major activity of a software testing process is considered to be test case generation [6]. These are used to derive test scenarios of the system under development in order to conduct conformance testing. The reliability of test results depends on the type of coverage criteria and the robustness of the test case generation algorithm. Kaur and Vig [6] identified three major techniques for software testing as (i) Search-based software testing, (ii) Finite state machine and (iii) Model-based testing; while Anand et al. [1] identified five major techniques used for software testing as (i) Symbolic execution and program structural coverage testing, (ii) Model-based testing, (iii) Combinatorial testing, (iv) Adaptive random testing, and (v) Search-based testing. However, the focus of this research is on model-based software testing technique. II. RELATED WORKS Li et al. [5] developed a new test case generation model for activity diagrams using extension theory technique (Extenics). They used the Euler circuit algorithm to automatically generate test case in a reduced form while maintaining good adequacy criteria that is capable of detecting more software defects. The authors in [7] proposed an approach for generating test cases from behavioural UML diagrams (sequence and activity). They achieved their aim by transforming the diagrams into graph and developed an algorithm to generate test cases from the graph. Their approach reduced the numbers of generated test suits while achieving good test coverage criteria. Several authors [8-11] have also attempted to develop test case generation techniques that catered for activity, use case and state chart diagrams respectively. Shirole et al. [12] worked on the development of test cases for object oriented software. Genetic algorithm was used to achieve their aim while a parser was developed with JAVA to extract all possible information from the saved.mdl file extension of the UML class diagram. They used the depth first search algorithm to generate test cases. Also, in [13], the authors developed a technique for generating test cases for object diagrams while in [14], the authors developed techniques to generate test cases from three different UML diagrams at runtime. Furthermore, the technique proposed in [15] employed activity path coverage criterion to identify synchronization and loop faults from activity diagrams. In 43

2 [16], the authors invented a new technique for deriving test cases from UML activity diagrams with the help of gray-box testing technique. Test scenarios were generated within a particular coverage criterion to avoid explosion of path in the loop while the authors in [17] presented a test case generation approach from activity diagrams which haphazardly generate numerous arbitrary test cases but a program was implemented to trace those arbitrary generated test cases by simple path coverage criteria so as to obtain a reduced test suit that meets the test adequacy criteria. Finally, the authors in [18] developed a test case generation model for branch testing using genetic algorithm. III. PROBLEM DESCRIPTION The precise challenges been faced by existing model-based test case generation systems using UML diagrams can be summarized as follows: (i) Lack of parser that is capable of extracting artifacts from all UML diagrams at runtime; (ii) Lack of adequate test coverage criteria There are absences of techniques that are capable of reading, extracting and interpreting artifacts from all UML diagrams at runtime. This is a challenge because, if a project requirement is modeled with a particular diagram that does not tally with the underlying diagram of a test case generation system, testers will be forced to either convert the diagram employed in modeling user s requirements to the default diagram of the test case generation system or boycott the testing phase. When the former is executed, there will be high possibility of misrepresenting requirements during the conversion which can lead to the generation of vague or incomplete test cases. Table 1 shows the modeling tools and the number of diagrams that some of the existing works have utilized in generating test cases at runtime. From the literature, the highest number of diagram that existing techniques can generate test cases at runtime from is three [14]. Therefore, to enhance flexible and efficient test case generation process, what is needed is a parser that is capable of extracting artifacts from all UML diagrams at runtime. Table 1 Description of Existing Techniques Authors Diagram used at runtime Tool used [13] Object Rational Rose [14] Sequence, Use case and Magic draw class diagram s [16] Activity UML [19] State charts Magic Draw [20] Use case and sequence UML diagrams [21] Sequence UML [22] Sequence UML [23] Activity UML [24] Activity UML [25] Sequence and class Rational Rose [26] Activity UML Also, existing test case generation algorithms lack robust test coverage criteria during test case generation. Consequently test cases are randomly generated based on haphazardly selected artifacts [6].This problem has led to the development of incomprehensive or incomplete test cases which are eventually misleading during requirements conformance testing. As software systems become more critical for business revolutions, the software development process is becoming more agile, distributed and challenging. Business organizations are now beginning to search for software developers or software development companies with proven software testing capabilities because, they cannot afford to loss competitive edge to other players in the market or industry due to faulty software systems. Again, since testing consumes a substantial amount of the development time, it is indeed imperative to develop an automatic test case generation algorithm for model-based testing which supports the commencement of the software testing process immediately after the design phase of the system life cycle or as soon as the modeled requirements becomes available. This is especially necessary as the quest for robust systems development that will meet global requirements for centralized and distributed systems is on high toll. Therefore, testing is crucial to enhance user satisfaction and reduce support cost. IV. PROPOSED METHOD The method implored in this research for parsing artifacts is based on trees as abstract data types. A tree is a special type of graph that contain no cycles. A tree T is defined as a set of nodes V with one node designated as the root node, and a list of edges E connecting the nodes without creating cycles. The edges connect parent nodes to child nodes. When two nodes are connected by an edge, the node closer to the root node is called the parent and the other node is called the child. The height of a tree is the number of edges from the root to the most distant leaf node. If a node is not the root and not a leaf node then it is called an internal node. In the context of this research, a requirement is designated as node while the attributes describing the functionalities of each requirement are considered to be edges. Requirements and their attributes are represented in any of the UML diagrams. The proposed technique accepts input only in XMI format. As mentioned previously, this research utilized the ArgoUML tool due to the fact that, it is open source. Therefore, the diagram is first exported to XMI format within the modeling environment of the tool (from File Export XMI). It is worthy to note that, different modeling tools store their modeled artifacts in various formats. For example, rational rose stores its artifacts in.mdl format while ArgoUML stores its artifacts in XMI format. After exporting in XMI format, the proposed technique converts the artifacts into a tree by identifying the requirements with specific xmi:id as nodes and the xmi:dref as edges, which stands for the attributes associated with each node (Figure 1). 44

3 modeling tool used in articulating user s requirements. After parsing requirements from a model, an output is generated. The output consists of a tree that contains nodes and edges. The tree is constructed based on the artifacts contained in the XMI file of a given modeling diagram (Algorithm 1). Fig. 1. Parsed artifacts from ArgoUML use case diagram in tree form Each requirement with their respective attributes is identified by the pseudo code described below: startrequirement(string rname, r = requirement" name Attributes atts) endrequirement(rname) The start and end requirement shows that, each requirement and its attributes should be visited once to extract all its artifacts. This cycle is completed for all the requirements and attributes contained in any ArgoUML diagram which are seven in number (Figure 2). ArgoUML Diagrams Use Case Class Sequence Collaboration State chart Activity Deployment Fig. 2. ArgoUML Modeling Diagrams Therefore, the first task in test case generation is to develop a parser that is capable of extracting artifacts from the 1. INPUT: 2. N = Artifacts from the ArgoUML diagram in XMI format. s: an ID of the start requirement d: an ID of the end requirement 3. T (V, E) be a tree graph with a set of V nodes and set of E edges; where V,E is the number of requirement and attributes respectively 4. PARAMETERS: 5. R (s,d), is a nonnegative number that stands for the artifacts where s start node and d is last node. 6. i, j; loop index, T (2, i) is array of vertexes source; T (3, j) is array of vertexes attributes. 7. T(3, j) is array of edges; T(3, i) is array of requirement. 8. For each node and edge VE (i, j) is arrayed of the shortest path from the origin to final node. 9. OUPUT: 10. R: Extracted artifacts. 11. INITIALIZATION: 12. // All nodes from first to last are examined for the edge s connected nodes//applying Rule // For each edge, do the operation in two steps as follows: 14. set ArtifactsArray[1... node-1] = ArtifactsArray(node) = n; Applying Rule BEGIN 16. for all N; 17. for j = first to last edge // j is set to be the artifacts at edges 18. for i = first to last node // i is set to be the artifacts at node 19. if (T(2, j) = i ) // k is set to be end of node of edges. 20. Artifacts = ArtifactsArray(i) + T(3i, j); 21. end if 22. end for 23. end for 24. for i = first to last edges 25. while (the origin (k) is the same in T ) 26. if (T(3, i,j) = ArtifactArray(i) ArtifactArray(j)// Applying Rule T(k) = T(2, i); Extract artifacts// else 28. i = i + 1; 29. k = T(i, j); 30. end if 31. end while 32. end for 33. END Algorithm 1. Artifacts extraction processes The rules enumerated below are considered to enhance the extraction process: Rule 1: If the current requirement is a node, the algorithm pauses and extracts artifacts. 45

4 Rule 2: If the artifacts of the current node have been extracted, the algorithm checks to ensure that, all the corresponding edges of that node (attributes) have been visited. Rule 3: The extracted artifacts are then represented in a tree form as output. Rule 4: The tree is then traversed to generate test cases. V. EXPLANATION OF ALGORITHMIC STEP (i) Input XMI Exported Diagram: The first step of the algorithm is to input the ArgoUML contents of any diagram used to modeled user s requirements in XML Metadata Interchange (XMI) format. XMI format is the standard format used for ArgoUML diagrams portability across different platforms. Thus, single combined XMI file for specified requirements are generated using ArgoUML tool. The XMI file contains all the information needed to interoperate between all the seven diagrams as shown in Figure 2. (ii) Extraction of Class Variables, Boundaries and Operations: The XMI file is traversed for entity declarations. For every diagram, the attributes associated with every entity are obtained (including their boundaries) and the functions as shown below: <UML:Entity xmi:id = nameentity <UML:Attribute xmi:dref = 'atts' (iii) Extraction of Artifacts: In this step, the artifacts in the diagram are extracted based on the node and edges (requirement and attributes). After matching their xmi:id and xmi:dref, one can view the parsed artifacts. By using this technique, artifacts are extracted based on full coverage criteria because all the nodes and edges in a modeling diagram are visited at least once for extraction purposes. However, for efficient execution of test case generations, the following must be fully established: (i) An adequate understanding of the software under test: Before model based testing process is initiated, the software requirements and design documents must have been ready and understood by all relevant stakeholders. (ii) A suitable modeling description of user s requirements: It is pertinent to unambiguously represent requirements using a suitable and formal modeling diagram. This will enhance the possibility of test case generations. If requirements are modeled with informal tools, the required communication standards used to extract information from such diagram will be unavailable hence, test case generations becomes impossible. (iii) Development of a parser: This is required in test cases generation because, it is responsible for extracting information from the formal modeling diagrams used to represent requirements. A parser can be developed in JAVA or C++ which is embedded in the test case generation system to extract relevant artifacts that will eventually be executed for generating test cases. (iv) Test case generation algorithm: This algorithm is required for implementing the test case generation system based on some coverage or selection criteria. Therefore, it becomes necessary to set some parameters during test case generation to optimize the generation process. However, adequate attention must be paid to scalability in order to generate comprehensive test cases. Therefore, whatever criteria are enforced during test case generations, the algorithm should have the capacity of generating test cases based on all the artifacts extracted from the diagram. (v) A validation approach: It is necessary to evaluate the generated test cases in order to determine its relevance and consistency ratio with respect to the software under test. To achieve consistency, robust algorithms are usually required and the relevance of generated test cases could be assessed via statistical tools. The input of a test case generation system consists of all the extracted information contained in the file path of a particular modeling diagram. A good test case generation system should be able to extract artifacts from any diagram D, used to represent stakeholder s requirements at runtime. Assuming n stands for the number of artifact in a modeling diagram, the next artifact can be represented by n+1 until k which marks the end of the artifacts in the diagram D. A scalable parser should be able to extract artifacts from n to k. However, to display the extracted or parsed artifacts; the following steps are executed: Step 1: The space V amongst requirement n+1 and n is computed with Equation 1: V ( n + 1, n) (i) Step 2: The task in Step 1 is extended to determine the remaining artifacts in the diagram that are yet to be visited. This will enhance the generation of comprehensive test cases. The equations reflecting these ideas are enumerated as follows: V ( n + 1, n) = V( n 1, k ) (ii) V ( n + 2, n) = V ( n + 2, k ) (iii) V ( n + 3, n) = V ( n + 3, k ) (iv)... =,..., (v)... =,..., (vi) D m, n = V m, n E m, n ; m, n (vii) From these equations, the activities involved in parsing requirements are manifold as depicted in the subsequent steps. Step 3: Acquiring both the source file and file path of any modeling diagram D used in representing user s requirements. 46

5 Step 4: Processing the parsed information (P) in XMI format, given with Equation (viii); n n V( n 1 V = ( n+ P( n, k ) = min max (viii) k s.t. i & j 1; i= 1 + ) j 1 ) Step 5: Ensuring that, all the artifacts have been visited and extracted from the diagram using Equation (ix). * * * P ( ) = V n+ 1 + V n+ k (ix) Step 6: Equation (x) is used to display parsed requirements. = + = * n * n * P n, k = min V n k i n max V (x) j 1 s.t. i & j 1; VI. IMPLEMENTATION The algorithm of the proposed technique has been implemented with Java programming language. Figures 3 show the snapshot of the interface used to extract artifacts from different diagrams at runtime. As a result, a software tester can utilize this tool to parse requirements from any modeling diagram to generate test cases. To use this tool, the software tester obtains the required diagram representing user s requirements and transforms the diagram into XMI by exporting the diagram in ArgoUML modeling environment. The tool receives the exported diagram in XMI format as and the necessary artifacts are extracted when the tester hits the Generate icon. At this level, the parser is automatically activated to read and interpret the extracted artifact which is displayed almost immediately. Fig. 3. Interface for extracting artifacts from ArgoUML diagrams All the extracted artifacts are displayed on the right hand side of the snapshot called Tree. The Regression icon is meant for re-extraction in an event where requirements evolve or changes are made to the underlying model. In order to ensure accurate test cases generation, the underlying artifacts that constitute a modeling diagram must be parsed in a precise, consistent and unambiguous manner otherwise; the resulting test cases may not produce the expected runtime behaviour of a system. The concept of a parser in the context of this research centers on reading artifacts of ArgoUML diagrams; interpret and convert them to another form based on some pre-defined sets of rules. In simulating the token flow during model execution, the parser attempts to scan through all the artifacts represented in the diagram to ensure that no artifact is unparsed. Unlike the conventional parsers, where artifacts are randomly extracted, which yields vague results. VII. EMPIRICAL VALIDATION The Automated Teller Machine (ATM) project requirements were adopted to validate and test the performance of the implemented algorithm. The ATM is meant to serve a customer at a time. To use an ATM, a customer is assumed to have obtained a valid card which is inserted into the machine to initiate any type of transaction. As soon as the card is inserted, a session is initiated which aims at verifying the card. If the verification is unsuccessful, the card is rejected but if it is successful, the card is accepted and the machine prompts the customer to insert his/her personal identification number (PIN) which is also verified by the bank. Once the PIN is verified, the customer will be required to perform the desired transaction. The card remains inside the machine until the customers confirms the completion of a transaction by terminating the process. In clear terms, the ATM machine is meant to provide the following sets of services which are also considered as the requirements. (a) Cash Withdrawal: A customer should be able withdraw cash within the confines of the stipulated amount. (b) Cash Deposit: A customer should also be able to deposit cash to any account connected to the card by inputting the amount to be deposited into the machine and a message is displayed upon successful or unsuccessful transaction as the case may be. (c) Money Transfer: A customer should be able to effect transfer of funds from one customer to the other. (d) Balance Enquiry: A customer should be able to check his/her balance at his/her own will. The requirements described above are considered to be the major requirements of the ATM project. Each requirement consists of attributes which further describes the specified requirements. Examples of attributes are enumerated below: (a) A customer will desire a secured system with good quality of service such as efficient cash withdrawals, deposits, transfers and balance enquiry. (b) A bank will desire to impose an interest rate when usage is not from its machine (c) Also, all pre and post conditions for a particular requirement to execute can be considered as attributes. To validate the system, requirements were drawn in five different modeling diagrams, which include, use case, activity, class, state chart, and deployment diagrams. The proposed 47

6 parser was efficiently able to extract and interpret artifacts from these diagrams at runtime which are executed to generate test scenarios or cases. Oluwagbemi and Asmuni/ IJSET Vol. 1, No. 2 (2014) VIII. EXPERIMENTAL RESULTS The case scenario involves the development of an automated teller machine. Figure 4-8 summarizes the general description and numbers of extracted artifacts from five modeling diagrams. The artifacts were extracted based on all the descriptive links of each diagram which is also one of the contributions of this technique. Fig. 7. Activity Diagram Fig. 4. Class Diagram Fig. 5. Use Case Diagram Fig. 6. State Chart Diagram Fig. 8. Deployment Diagram From Figures 4-8, the proposed technique was able to extract artifacts from all the descriptive links of the various modeling diagrams used in representing user s requirements. These descriptive links as depicted in the x-axis of all the figures has the capacity of enhancing the generation of comprehensive test cases. This is because; any requirement description not captured in one link can be found or captured in another. With this technique, robust software development process can take place since the testing will be conducted based on the generated test cases obtained from the extracted artifacts of the underlying model. During the experiments, it was discovered that, class diagram had the highest number of extracted artifacts (236 items) as shown in Figure 4. For the use case diagram, 19 items were extracted from various descriptive links as shown in Figure 5, while for the state chart diagram, 47 items were extracted (Figure 6). In Figure 7, the technique was able to extract about 37 items from activity diagram and for the deployment diagram, 56 items were extracted based on the user s requirements (Figure 8). In model-based testing, the robustness or completeness of the generated test cases depends on the coverage criteria (descriptive links) covered during the extraction of the artifacts. It is these extracted artifacts which are represented in a tree form that are traversed to generate test cases. Many authors have opined that, the foundation of any software testing process is test cases generation [5-8]. From this research, we can conclude by saying, the foundation of any test cases generation process in model-based testing is extraction of artifacts from the modeling diagram used to represent requirements. The extraction of artifacts is only achievable by the development of an efficient parser implemented in any of the object oriented programming 48

7 languages such as Java or C++. However, in this research, Java was utilized in implementing the parser described in Section IV. This research is important because, requirements can be modeled using any diagram and these diagrams have different semantics and nomenclatures. From Table 1, it is seen that, existing techniques can only parse requirements from 1 to 3 modeling diagrams at runtime. This means that, testing may not hold if a diagram used to model user s requirements do not fall within the particular diagram that the parser can extract artifacts from. However, with the proposed technique, testers can conveniently conduct testing from any diagram since it can cater for all the modeling diagrams at runtime; particularly, the ArgoUML diagrams which was the tool used to evaluate the performance of the proposed technique. IX. COMPLEXITY ANALYSIS The complexity of the model under test determines the success rate of the parsing process especially when it has to do with response or execution time. The analysis of the complexities associated with parsing requirements during model-based testing is described as follows: Supposing, a model that possess requirements is presented for parsing artifacts, each node of the model is visited once to extract its artifact into a stack, hence O(n). The contents of the stack are parsed and represented in a tree. Therefore, the stack has nxn entries, accessing the stack has time complexity O (n*n). So the time complexity of the model will be O (n 2 ). However, generating parsed requirements from a complex model with N nodes at the top level and other associated nodes k at the lower levels would result in (1+N(k+1)) nodes. A node for the top level consist of subsequent nodes which comprises of `E' edges and each edge may in turn have n sub-edges until `k'. The total edges will amount to m (E(n+k)) edges. Finally, the total number of nodes at the top-most level would be 1+N (k+1). Consequently, the total complexity would be O (1+N (k+1)) (n 2 ). However, space complexity is based on the size of the stack; meaning, the size of the stack depends on the number of nodes and edges. The space complexity of each node is O (n 2 ). For the final parsed requirements, complexity analysis for each node and edges are traversed and the resulting output will be the generated test cases. Let the number of nodes be `N' and edges be E; then, the time complexity is O (N+E). However, the complexity analysis of a model having N nodes and E edges at the top level and m sub-nodes as well as k sub-edges at the lower level will be O (1+m (k+1)) +n (N+E). X. CONTRIBUTION The last three decades have witnessed substantial research in model-based software testing domain. This section aims to articulate the contributions of this research, enumerated as follows: (a) Inadequate test coverage criteria: Existing techniques lack adequate coverage criteria when extracting artifacts for test case generation [5]. However, in this research, artifacts were extracted based on full coverage (transition and message path) criteria where all the nodes and edges of the XMI exported diagram represented in a tree form are visited to extract artifacts. Therefore, with this technique, comprehensive test cases can be generated as soon as the tree is traversed. (b) Inability of reading or extracting artifacts from all modeling diagrams at runtime: There are shortages of concepts as regards parsers that are capable of reading, extracting and interpreting artifacts from all ArgoUML diagrams at runtime. Therefore, a parser capable of extracting artifacts from all diagrams have been proposed and implemented. This will save testers the nightmare of re-drawing or re-modeling from one diagram to the other when the need arises. XI. CONCLUSION/LIMITATION A robust parser for model-based software testing was the focus of this research work. The proposed technique, pseudocode as well as the mathematical descriptions was implemented with Java programming language. This led to the generation of parsed requirements from various ArgoUML modeling diagrams at runtime. The tool was validated using published ATM project requirements where five different diagrams were drawn to model these requirements. The diagrams were then used to evaluate the performance of the proposed parser. The algorithm performed better that the existing ones in terms of being able to read and parser artifacts from five different modeling diagrams. This is an improvement over existing techniques. With the proposed technique, test cases generation becomes comprehensible since artifacts are parsed based on full coverage criteria and not randomly selected criteria. For the future work, we hope to look at the development of an execution algorithm required to convert or traverse the parsed requirements into test cases. Also, the interoperability or compatibility of this technique with other modeling tools such as Rational Rose, Magic Draw, Microsoft Visio among others is worthy of investigation. REFERENCES [1] Anand, S., Burke, E., Chen, T. Y., Clark, J., Cohen, M. B., Grieskamp, W., Zhu, H. (2013). An Orchestrated Survey on Automated Software Test Case Generation. The Journal of Systems and Software 86 (2013) [2] Aggarwal, M., & Sabharwal, S. (2012). Test Case Generation from UML State Machine Diagram: A Survey Third International Conference on In Computer and Communication Technology (ICCCT), pp [3] Ahmed, S. U., Sahare, S. A., & Ahmed, A. (2013). Automatic test case generation using collaboration UML diagrams. World Journal of Science and Technology, 3(1),

8 [4] Dalal, S., Jain, A., Karunanithi, N., Leaton, J. M., Lott, C. M., Patton, G. C., Horowitz, B. M. (1999), Model-based testing in practice, In: ICSE 99, May, pp [5] Li, L., Li, X., He, T., & Xiong, J. (2013). Extenics-based Test Case Generation for UML Activity Diagram. Procedia Computer Science, 17, [6] Kaur, A., & Vig, V. (2012). Systematic Review of Automatic Test Case Generation by UML Diagrams. International Journal of Engineering, 1(6). [7] Swain, S. K., & Mohapatra, D. P. (2010). Test case generation from Behavioral UML Models. International Journal of Computer Applications, 6(8), [8] Kim, H., Kang, S., Baik, J., & Ko, I. (2007). Test cases generation from UML activity diagrams. In Eighth IEEE ACIS International Conference on Software Engineering, Artificial Intelligence, Networking, and Parallel/Distributed Computing, SNPD 2007, Vol. 3, pp [9] Chen, M., Qiu, X., Xu, W., Wang, L., Zhao, J., & Li, X. (2009). UML activity diagram-based automatic test case generation for Java programs., The Computer Journal, 52(5), [10] Hasling, B., Goetz, H., & Beetz, K. (2008). Model based testing of system requirements using UML use case models, In st International IEEE Conference on Software Testing, Verification, and Validation, pp [11] Swain, R., Panthi, V., Behera, P. K., & Mohapatra, D. P. (2012). Automatic Test case Generation From UML State Chart Diagram, International Journal of Computer Applications, 42(7), [12] Shirole, M., Suthar, A., & Kumar, R. (2011). Generation of improved test cases from UML state diagram using genetic algorithm, In ACM Proceedings of the 4th India Software Engineering Conference, pp [13] Prasanna, M., & Chandran, K. R. (2009). Automatic Test Case Generation for UML Object diagrams using Genetic Algorithm Int. J. Advance. Soft Comput. Appl, 1(1), [14] Sawant, V., & Shah, K. (2011). Construction of Test Cases from UML Models, In Technology Systems and Management (pp ). Springer Berlin Heidelberg. [15] Kundu, D., Sarma, M., Samanta, D., & Mall, R. (2009). System testing for object- oriented systems with test case prioritization Software Testing, Verification and Reliability, 19(4), [16] Linzhang, W., Jiesong, Y., Xiaofeng, Y., Jun, H., Xuandong, L., & Guoliang, Z. (2004). Generating test cases from UML activity diagram based on gray-box method, In IEEE 11th Asia-Pacific Software Engineering Conference, 2004, pp [17] Mingsong, C., Xiaokang, Q., & Xuandong, L. (2006). Automatic test case generation for UML activity diagrams, In ACM Proceedings of the 2006 international workshop on Automation of software test (pp. 2-8). [18] Pachauri, A. (2013). Automated test data generation for branch testing using genetic algorithm: An improved approach using branch ordering, memory and elitism Journal of Systems and Software. [19] Kansomkeat, S., & Rivepiboon, W. (2003). Automatedgenerating test case using UML statechart diagrams, In Proceedings of the 2003 annual research conference of the South African institute of computer scientists and information technologists on Enablement through technology, pp [20] Sarma, M., & Mall, R. (2007). Automatic test case generation from UML models, In 10th IEEE International Conference on Information Technology (ICIT 2007), pp [21] Sarma, M., Kundu, D., & Mall, R. (2007), Automatic test case generation from UML sequence diagram, In International Conference on Advanced Computing and Communications, 2007, pp [22] Javed, A. Z., Strooper, P. A., & Watson, G. N. (2007). Automated generation of test cases using model-driven architecture, In Second International Workshop on Automation of Software Test, pp [23] Samuel, P., Mall, R., & Bothra, A. K. (2008). Automatic test case generation using unified modeling language (UML) state diagrams, IET software, 2(2), [24] Farooq, U., Lam, C. P., & Li, H. (2008). Towards automated test sequence generation, In 19th Australian Conference on Software Engineering, pp [25] Biswal, B. N., Nanda, P., & Mohapatra, D. P. (2008). A novel approach for scenario-based test case generation In International Conference on Information Technology, pp [26] Kundu, D., & Samanta, D. (2009). A Novel Approach to Generate Test Cases from UML Activity Diagrams, Journal of Object Technology, 8(3), [27] Hishammuddin, A. (2013) Development of a scalable parser for extracting artifacts during model-based test case generation process, in The 7th Malaysian Software Engineering Conference (MySEC 2013). 50