UML diagram-driven test scenarios generation based on the temporal graph grammar

Abstract

Model-based software architecture verification and test scenarios generation are becoming more and more important in the software industry. Based on the existing temporal graph grammar, this paper proposes a new formalization method of the context-sensitive graph grammar for aiming at UML activity diagrams, which is called the UML Activity Graph Grammar, or UAGG. In the UAGG, there are new definitions and parsing algorithms. The proposed mechanisms are able to not only check the structural correctness of the UML activity diagram but also automatically generate the test scenario according to user constraints. Finally, a case study is discussed to illustrate how the UAGG and its algorithms work.

1. Introduction

As the complexity and scale of software and hardware systems increase in many fields, such as the IoT(Internet of Things)[1-2], the finance[3-4] etc., the concurrency of these systems is becoming more and more important. It makes the software architecture essential for describing and testing the software system. There are multiple types of model views to describe the software architecture.

At present, many Architecture Description Languages(ADLs) have been proposed[5-10]. Although the ADLs are specialized formal languages supporting modeling and reasoning on software architectures, their popularity and usage by practitioner is very low[11]. While, the Unified Modelling Language(UML)[12] is a common specification and the standard modeling language[13]. The UML activity diagram is one of UML standard models, which is very popular for describing software requirements and the dynamic behavior of the software systems[14].

Since the formal method is the application of mathematical logic to describe the model of the software system, it has very high reliability and accuracy. Therefore, many studies use the method of a formal theorem to verify and check the correctness of UML activity diagrams[15-16]. While, a number of researchers use Petri net method to describe and verify the UML activity diagram. Störrle[17] mapped various elements of the UML activity diagram into executable Petri nets. Heuer et al.[18] extended the dynamic syntax and semantics of the Petri net, and based on this Petri net, the activity diagram was formally described. Tariq et.al[19] proposed an approach for formal analysis and simulation of the UML behavioral models using Coloured Petri Nets(CPN).

At the same time software testing is closely related to the software development process. Whether it is traditional software testing methods or automated software testing methods, generating test scenarios is one of the most critical issues. At present, many researchers have used UML modeling to represent the system and to test the software. Researchers have done a lot of research on test scenarios generation based on UML models. Yan et al.[20] proposed a test scenarios generation method based on UML sequence diagram models. In the literature [21], there is an approach to generate the test scenarios using UML use case diagrams. Among these studies [22]-[25], UML state diagrams are used, and algorithms for generating test scenarios are also proposed. In the process of generating test scenarios, it is also meaningful research how to use optimization methods[26-27] to improve efficiency.

In fact, with the wide application of visual graph languages such as UML, BPMN, and control flowcharts, etc., a framework for formal definition and analysis of visual languages plays an increasingly important role. Obviously, for this definition and analysis of visual languages, graph grammars[28] provide an intuitive but formal method. Just as string grammars are very important to string languages, graph grammars are also an indispensable theoretical tool for visual languages[29].

Nowadays, there are many research results on graphic grammar and its application. Rekers and Schürr[30] proposed a context-sensitive graph grammar in 1997. This graph grammar is called Layered Graph Grammar (LGG). Then, based on the LGG, Zhang et al.[31] proposed another context-sensitive graph grammar. This grammar is called Reserved Graph Grammar (RGG), which not only introduces a marking mechanism in the graph grammar to distinguish different edges, but also proposes selection conditions to restrict the production. The RGG's[32] application range is wider. There are Visual XML Schemas[33] and Generic Visual Language Generation Environments[34].

Zeng et al.[35] proposed a context-sensitive Edge-based Graph Grammar (EGG). Based on the EGG, a new attempt of transformation between BPMN and BPEL[36] was provided. For traditional graphic grammars, although they can verify the correctness of the graph structure, they cannot analyze and process temporal semantics. However, graphs with temporal semantics are widely used in many fields. In order to expand the application range of the graph grammar, an attempt of introducing temporal mechanism into graph grammar was proposed. This new graph grammar was called Temporal Edge-based Graph Grammar (TEGG)[37]. So, we will extend the TEGG, make it more convenient to formally verify the UML activity diagram and further generate test scenarios.

Based on the TEGG, this paper proposes a new context-sensitive graph grammar for UML activity diagrams, called UML Activity Graph Grammar or UAGG in short. In the UAGG, formal definitions are introduced for the characteristics of UML activity diagrams. Similarly, two types of productions are also provided. Then, new algorithms are designed to verify UML activity diagrams and generate test scenarios. Finally, there is a case study to explain how the proposed algorithms work.

The rest of the paper is organized as follows. Firstly, Section 2 briefly introduces the basic concepts of the TEGG. Section 3 elaborates the formal definitions of the UAGG with the introduction of new mechanisms, such as an attribute set, new E-productions, and so on. Based on the UAGG, Section 4 provides steps and algorithms to realize the verification of UML activity diagrams and the generation of test scenarios. Section 5 illustrates a case study on a UML activity diagram. Finally, Section 6 concludes the whole paper.

2. Preliminaries

The TEGG mainly analyzes temporal semantics. In order to better understand the TEGG, the basic concepts are briefly introduced below.

Definition 2.1 A node n based on a label set L_n can be denoted as n ≡ (lab, Natts), and there are the following conditions:

• L_n can be expressed as L_n = T∪​​. T represents a label set of N_T, and ​​ represents a label set of N_N, while N_T represents a set of terminal nodes and N_N represents a set of non-terminal nodes;

• lab ∈ L_n, representing the label of n;

• Natts is a set of attributes owned by node n.

Definition 2.2 An edge e based on a label set L_e can be denoted as e ≡ (lab, n_s, n_t, Eatts), and there are the following conditions:

• L_e is a set of edge labels;

• lab ∈ L_e, representing the label of e;

• n_s is a node defined in Definition 2.1, meaning the source node of e;·

• n_t, is a node defined in Definition 2.1, representing the target node of e;

• Eatts is a set of attributes owned by edge e, while Eatts = Eka∪​​ .

Usually, there are three graph operations. The first type of graph operation is called L-application, also called deduction. The second one is called R-application, also called reduction. Then, the last one is called T-application. There is the literature [37] for more details about the TEGG.

3. Formalism of the UAGG based on the TEGG

UML activity diagrams are mainly used to describe the workflow and concurrent behavior of the system and show the various sequential activities performed by all participants. Although activity diagrams have an intuitive and straightforward description, it cannot guarantee the correctness and reliability of the established model. It is more challenging to provide a useful basis for future software testing. In order to solve these problems, there are the formal definitions of the UAGG based on the TEGG.

Definition 3.1 A node n based on a label set L_n can be denoted as

n ≡ ( id, name, lab, type, Natts ), and there are the following conditions:

• L_n and lab ∈ L_n are the same as those defined in Definition 2.1;

• id ∈ {0, 1, 2, ...k }, representing the identification of the node n to distinguish different nodes;

·name, representing the name of the node n;

• type, indicating which categories this node belongs to, while type = { Initial, Final , Activity, ComponentActivity, Fork , Join, Branch, Merge, Object } . These values represent an initial activity node, a final activity node, a basic activity node, a component activity node, a concurrency fork node, a concurrency join node, a conditional fork node, a conditional join node and an object node in UML activity diagrams respectively;

• Natts is a set of attributes owned by node n, which includes key temporal attributes and non-key attributes for UML activity diagrams.

In order to show more vividly the node status corresponding to different values of the temporal attribute in a node, the following notations are used. In addition, each node also has non-key attributes, including Test_Path, Final_Weight, and Rand_Weight. The Test_Path attribute is mainly used to save the generated test path. The Final_Weight and Rand_Weight attributes are used to save the two weights of the node, which will be described in detail later.

Fig. 1. Nodes with waiting and completed statuses

Definition 3.2 An edge e based on a label set L_e can be denoted as e ≡ ( id, name, lab, type, n , n , Eatts ), and there are the following conditions:

• L_e, lab ∈ L_e, and Eatts are the same as those defined in Definition 2.2;

• id ∈ {0, 1, 2, ...k }, representing the identification of the edge e to distinguish different edges

• name, representing the name of the edge e;

• type, indicating which categories this edge belongs to, while type = {Controlflow}. The value represents a control edge in UML activity diagrams;

• n_s and n _t are nodes defined in Definition 3.1, representing the source and target node of e respectively.

Definition 3.3 A uml-activity graph UAG based on a label set L can be denoted as UAG ≡ ( N, E, l, p, q ) , , and there are the following conditions:

• N is a set of nodes defined in Definition 3.1;

• E is a set of edges defined in Definition 3.2;

• l : N ∪ E → L is a mapping from N and E to L, and L can be expressed as L = L_n ∪ L_e;

• p : E → N and q : E → N are mappings from E to N, indicating the source and target node of an edge.

In the UAGG, the concepts of a sub-graph, two isomorphic graphs, redexes, a T-production, and the graph operations R-application and T-application are similar to the corresponding concepts of the TEGG. Then, the introduction of these concepts will not be repeated. For UML activity diagrams, the T-productions shown in Fig. 2.

Fig. 2. A group of T-productions defined for the UML activity diagrams

In order to check the structural correctness of UML activity diagrams and reduce concurrent processes in these diagrams, the concept of a new E-production in the UAGG is given as follows.

Definition 3.4 An E-production p_E is the expression \(\overline{U A G}_{L}\) ⇔ \(\overline{U A G}_{R}\) , denoted as ( \(\overline{U A G}_{L}\), \(\overline{U A G}_{R}\), Con, Fun), where

• \(\overline{U A G}_{L}\) and \(\overline{U A G}_{R}\) are uml-activity graphs with dangling edges;

• (\(\overline{U A G}_{L}\).M = \(\overline{U A G}_{R}\).M)∧(M ⊂ {0,1,2,...});

• Con is conditions which can be satisfied;

• Fun is a group of functions that are executed when the Con can be satisfied and this production is used.

According to the above definition, the E-productions for UML activity diagram analysis are shown in Fig. 3.

Fig. 3. A group of E-productions defined for the UML activity diagrams

4. A method of UML activity diagrams verification and test scenarios generation based on the UAGG

4.1 Steps of UML activity diagrams verification and test scenarios generation

In order to formally verify UML activity diagrams and further generate test scenarios, this section proposes an algorithm for this purpose based on the UAGG. The main steps of the algorithm are designed as follows, which not only check the structural aspect but also generate test scenarios of UML activity diagrams. The pseudo-codes of the algorithm are shown in Fig. 4.

Fig. 4. A new parsing algorithm

Step 1, initializing. This step mainly transforms a given UML activity diagram g into a host graph of the UAGG, which is done by the function initialize( UMLActivityDiagram g ).

Step 2, verifying the structural correctness of the UAGG host graph. This step is mainly implemented by the function graphStructureParsing( ) which has three parameters. The first parameter represents the UAGG graph G, the second one represents the UAGG E-productions, and the last one indicates whether to enable the conditions of E-productions in Fig. 3. If the structure of G is correct, jump to step 3. Otherwise, return the NULL and end the algorithm. A further description of this function will be introduced in Section 4.2.

Step 3, generating test scenarios with the UAGG. This step is mainly implemented by the function generateTestScenarios( ), which also has three parameters. The first parameter represents the UAGG grammar graph G, the second one represents the productions including E-productions and T-productions, and the last one represents the user constraints on the generation of test scenarios. A further description of this function will be introduced in Section 4.3.

4.2 Steps of UML activity diagrams’ structure verification

A UAGG host graph of a UML activity model can be obtained through the first step in Section 4.1. In the algorithm provided in Fig. 4, the function graphStructureParsing( ) completes the function similar to the traditional graph parsing algorithm. It is designed to check the given graph's structure correctness through R-applications with E-productions presented in Fig. 3. The pseudo-codes of the function graphStructureParsing( ) are provided in Fig. 5.

Fig. 5. The function of graphStructureParsing( )

The function graphStructureParsing( ) is to reduce the UAGG host graph g according to the E-productions ePros. When selecting the E-production, it will combine the parameter isCondition to determine whether to enable the conditions of this E-production in Fig. 3.

In fact, the function findRedex(Graph g, Productions pros, Boolean isCondition) is mainly used to realize the process of finding redexes in the host graph g. If the parameter isCondition is true, then additional conditions of the productions need to be met when selecting and determining the production. And if the parameter is Condition is false, then there is no need to satisfy its conditions when selecting and determining the production additionally.

There are two stacks GraphStack and ERedexStack in the function graphStructureParsing( ). The GraphStack is used to store graphs, while the ERedexStack is used to store corresponding redexes of the graphs respectively.

4.3 Steps of test scenarios generation

There is a critical step to extract test scenarios from UML activity diagrams in test case generation. However, the concurrency modules in the activity diagram make the problem of extracting the basic test scenarios more complicated. The concurrency module of UML activity diagrams always starts at the concurrent fork node. It ends at the concurrent join node, which meets the characteristic of a single node as input or output.

Therefore, based on the UAGG, this paper proposes the algorithm generate test scenarios( ) which will analyze the UAGG host graph according to the constraint conditions of the productions and users to generate the test scenarios. The specific steps of the algorithm are as follows:

Step 1, making pretreatment for a given graph of the UAGG. Firstly, the primary implementation is to find all the concurrent modules in the UAGG host graph and then assign an initial value to the state of the first concurrent fork node of each outermost concurrent module.

Step 2, assign a random value to the Rand_Weight attribute of each node in each concurrent module. Then, for all concurrent modules, use the graphTemporalParsing( ) function with T-productions, T-applications and other operations to calculate the Final_Weight attribute value of each node. Thus, the intermediate graph is generated.

Step 3, further using E-productions to reduce the intermediate graph generated above until all the concurrent modules are reduced to the corresponding single node.

Step 4, further executing the graphStructureParsing( ) function with E-productions to generate a test scenario.

Step 5, determining whether the user constraints are met. If the user has no additional constraints, this algorithm ends and the test scenario is obtained. If the user has additional condition constraints, check whether the test scenario generated in Step 4 meets the conditions. When the conditions are met, the algorithm ends. When the conditions are not met, go to Step 2 and continue execution.

The above process can be expressed with pseudo-codes, as shown in the following figure.

Fig. 6. The function of generateTestScenarios( )

4.4 Computational complexity

The computational complexity of the algorithm in Fig. 4 is a critical issue. While, it is analyzed in this section.

Theorem 4.1. For a given UML activity diagram, the time complexity of the algorithm in Fig. 4 is \(O\left(p s^{2} \cdot n^{2 \cdot m}+2 \cdot\left(\frac{p s}{m !}\right)^{n} \cdot\left(n^{n} \cdot n !\right)^{m}\right)\), where n is the numbers of nodes in a host graph of the UAGG, ps is the number of productions, and m is the maximum number of nodes among all productions’ right graphs.

Proof. Assuming k₁, k₂, k₃ and are time complexity of functions initialize( ), graphStructureParsing( ), and generateTestScenarios( ) respectively. According to the algorithm steps, its time complexity k can be calculated by the following equation:

k = k₁ + k₂ + k₃

It is sure that the complexity of the function initialize( ) is O(n). In addition, for the function graphStructureParsing( ), assuming l₁ is the maximal iterations number of the lines 3–27, l₂ is that of the lines 6-11, l₃ is that of the lines 9-10, and l₄ is that of the lines 13-24. Then, assuming k₄ and k₅ are the time complexities of the function findRedex( ) and RApplication( ) respectively. So, the complexity of function graphStructureParsing( ) is as follows^[37]:

\(\begin{aligned} &k_{2}=O\left(l_{1} \cdot\left(l_{2} \cdot\left(k_{4}+l_{3}\right)+l_{4}+k_{5}\right)\right) \\ &=O\left(\left(\frac{p s}{m !}\right)^{n} \cdot\left(n^{n} \cdot n !\right)^{m}\right) \end{aligned}\)

For the function generateTestScenarios( ), assuming is the maximal iterations number of the lines 9–24, k₆, k₇, k₈, and k₉ are the time complexities of the function findAllConcurrentModel( ), initializeFirstNode( ), initializeRandWeightOfNode( ) and graphTemporalParsing( ) respectively. In order to find all concurrent subgraphs, it is necessary to traverse all nodes in the UAGG graph. Therefore, the time complexity of findAllConcurrentModel( ) is O(n+e), while e represents the edges in the UAGG host graph. The function initializeFirstNode( ) is used to initialize the first node of the concurrent module, so k₇ ≤ O( n + e ). Similarly, k₈ ≤ O(n + e). For the function graphTemporalParsing( ), there is k₉ ≤ O(ps²·n^2·m+1) according to the reference[37]. Obviously, for the obtained test scenario containing n nodes, the time complexity of the function isSatisfyConstraints( ) is O(n), while l₅ ≤ n⋅(n − 1) = n² − n. So, the complexity of the function generateTestScenarios( ) is:

\(\begin{aligned} &k_{3}=O\left(k_{6}+k_{7}+l_{5} \cdot\left(k_{8}+k_{9}+2 \cdot k_{2}+n\right)\right) \\ &=O\left(p s^{2} \cdot n^{2 \cdot m}+\left(\frac{p s}{m !}\right)^{n} \cdot\left(n^{n} \cdot n !\right)^{m}\right) \end{aligned}\)

Combined with the above discussion, the time complexity of the algorithm is the following:

\(\begin{aligned} &k=k_{1}+k_{2}+k_{3} \\ &=O\left(p s^{2} \cdot n^{2 \cdot m}+2 \cdot\left(\frac{p s}{m !}\right)^{n} \cdot\left(n^{n} \cdot n !\right)^{m}\right) \end{aligned}\)

5. Case study and Comparison with related work

This section introduces a process model built by UML activity diagrams, and illustrates how this model is verified and test scenarios are generated using the steps presented in Section 4.1.

5.1 Case study

Fig. 7 shows the process of adding product information to the supermarket management system after the administrator logs in. There are ten activity nodes and six gateway nodes. Besides, this process includes two concurrent models.

Fig. 7. A business process described by the UML activity diagram

According to the algorithm introduced in Section 4.1, it can analyze this diagram as follows.

Step 1, executing the first steps, namely initialization. Through this step, we can get the host UAGG graph g shown in Fig. 8.

Fig. 8. A UAGG host graph g is corresponding to Fig. 7.

The graph g describes the node name with numbers given to each activity. The two columns in the following table are Activity Name and Node Name respectively. The Activity Name represents the name of the activity in Fig. 7, and the Node Name indicates the node in the graph g corresponding to the activity.

Table 1. The UAGG graph of adding product information activity diagram

Step 2, this step is the process of structural analysis of the above host graph. That is to verify whether the structure is correct by executing the function graphStructureParsing( ) based on E-productions. If the host graph's structure is correct, jump to Step 3. Otherwise, return the error message and end the algorithm.

Step 3, this step is to generate test scenarios. It involves several processes described in Section 4.3, so we can further introduce this step as follows.

Step 3.1, making pretreatment for a given graph of the UAGG. Firstly, there are two concurrent modules in the graph g founded by the function findAllConcurrentModel(Graph g). The first fork node of the outermost concurrent module of these two modules is marked by the red dotted line box in Fig. 9, noted as Node 5. Then, assign an initial value to the state of the Node 5.

Fig. 9. An intermediate graph

Step 3.2, assigning a random value to the Rand_Weight attribute of each node in these two concurrent models, and assigning the value of the Rand_weight attribute in the Node 5 to its Final_weight attribute as shown in Fig. 9. Then, for all concurrent models in this graph, use the graphTemporalParsing( ) function with T-productions, T-applications and other operations to calculate the Final_Weight attribute value of each node. So, the intermediate graph is generated.

In the following content, \(C_{i}^{j}\) will be used to represent each redex, where j represents the number of the intermediate graph containing the redex, and i represents the number of the corresponding redex.

Firstly, the function graphTemporalParsing( ) will search for all redexes in the host graph according to the T-productions given in Fig. 2. In this process, because the condition of T-production A is met, the redex C₁¹ will be selected in Fig. 9 and replaced by T-application with the T-production A. At the same time, the Fun function of the T-production A will also be executed. So, Fig. 10 can be obtained.

Fig. 10. An intermediate graph after using T-production A

Secondly, the function continues to search for redexes based on Fig. 10. Since conditions f the T-production B are satisfied, the redexes \(C_{1}^{2}\), \(C_{2}^{2}\), \(C_{3}^{2}\), and \(C_{4}^{2}\) are selected and replaced by T-application with the T-production B. Then, its Fun function is activated and executed, which calculates the value of Final_weight of these redexes. Therefore, the Final_Weight attribute value of Node 6, 7, 8, and 9 is equal to the final_weight attribute value of Node 5 plus the Rand_weight attribute value of these nodes themselves respectively. So, Fig. 11 can be obtained.

Fig. 11. An intermediate graph after using T-production B

Then, the above process is repeatedly executed until the attribute Final_Weight of all nodes in the concurrent modules of the graph can be calculated. So, Fig. 12 can be obtained.

Fig. 12. An intermediate graph

Step 3.3, in this step the main realization uses E-productions to reduce the intermediate graph generated in the above Step 3.2, until the concurrent modules are reduced to a single node. More detailed analysis processes are given below.

(1) The function graphStructureParsing( ) first tries to search for all redexes in Fig. 12 with the E-productions given in Fig. 3. Considering Con of the E-production 2, it can be used to perform R-application operations, so that the value of nodes’ Lab in the concurrent modules can be changed from “T” to “S”. Then, Fig. 13(a) can be obtained.

Considering Con of the E-production 4, the redex \(C_{1}^{5}\) is selected and replaced by R-application, which is shown in Fig. 13(a). Its Fun is activated and executed, which calculates the value of Test_path of the redex. So, Fig. 13(b) can be obtained.

Fig. 13. (a). An intermediate graph with \(C_{1}^{5}\) ; (b). An intermediate graph after using E-production 4

(2) The above process is repeatedly executed until all the concurrent modules are reduced to the corresponding single node. And, the attribute Test_path of the corresponding single node is calculated. So, Fig. 14 can be obtained.

Fig. 14. An intermediate graph

Step 3.4, executing the graphStructureParsing( ) function without considering Con of the E-productions to generate a test scenario. More detailed analysis processes are given below.

(1) The function graphStructureParsing( ) first tries to search for all redexes without considering Con of the E-productions given in Fig. 3. Obviously, E-production 2 and 3 are satisfied and there are the redexes \(C_{1}^{7}\),\(C_{2}^{7}\),\(C_{3}^{7}\) and \(C_{4}^{7}\) which is shown in Fig. 15(a). Then, the redexes \(C_{1}^{7}\), \(C_{2}^{7}\), and \(C_{4}^{7}\) are replaced by R-application with E-production 2, while the the redex \(C_{3}^{7}\) are replaced with E-production 3. Its Fun is activated and executed, which calculates the value of Test_path of the redexes. So, Fig. 15(b) can be obtained.

Fig. 15. (a). A graph with \(C_{1}^{7}\), \(C_{1}^{7}\), \(C_{3}^{7}\), and \(C_{4}^{7}\); (b). A graph after using E-production 2 and 3

(2) The above process is repeatedly executed until a test scenario is generated. That is 1→2→3→4→5→9→6→10→12→8→11→7→13→14→15→16.

Step 3.5, determining whether the user constraints are met. If the user has no additional constraints, the algorithm ends and the test scenario is obtained. If the user has additional condition constraints, check whether the test scenario generated in Step 3.4 meets the conditions. When the additional condition constraints are met, the algorithm ends; when the additional condition constraints are not met, go to Step 3.2 and continue execution.

In Table 2, there are some test scenarios generated by the above steps. This table contains three columns. The first column represents the ID number of the test scenario, the second column represents user constraints, and the third column represents a generated test scenario.

Table 2. Test scenarios from the UAGG graph

5.2 Comparison with related work

Many researchers used UML diagrams to generate test scenarios in the literatures[38-42]. This section provides the comparison with these related works. Kundu et al.^[38] presented an approach of generating test cases from UML activity diagrams. They considered a test coverage criterion, called activity path coverage criterion. Pechtanun et al.^[39] proposed a method with AC grammar to generate test cases from UML activity diagram. In addition, this literature further illustrated the effectiveness of the method through four case studies. Patel et al.^[40] focused on two approaches to generate test cases form UML activity diagram. Jena et al.^[41] introduced a method to transform from a AFT generated by UML activity diagram to AFG. Then, the test paths are generated by traversing the AFG. By building an IOAD, Mahali et al.^[42] presented an approach to generate a minimum test suite with maximum coverage.

Table 3 compares some related works, which illustrates the approach proposed in this paper has several features. On the one hand, all test paths can be automatically generated through this approach. On the other hand, this approach is able to check the structural correctness of the UML activity diagrams.

Table 3. Comparison on the related work

6. Conclusions

This paper proposes a new graph grammar UAGG to verify and analyze UML activity diagrams based on the TEGG. In the UAGG, there are some new mechanisms which include new E-productions and a parsing algorithm and so on. According to the designed productions set, the algorithm proposed in this paper can not only verify the correctness of the UML activity diagrams’ structure, but also automatically generate test scenarios that meet user constraints. Finally, there is a specific case to explain how the proposed UAGG and its mechanisms works.

Our future research goal is to extend the application of generating test cases by the UAGG and develop the algorithms with a wider range of applications and higher efficiency.