Template-based model generation

Abstract

Given their vital roles in model-based software engineering, the performance of model-related operations (MOs, such as model transformations) must be systematically tested. However, how to produce a set of large input models that conform to structure-related constraints presents a major challenge to such test. This paper proposes a template-based approach to efficient model generation. Firstly, a DSL is provided to describe templates that specify how to generate a valid model that conforms to structure-related constraints. Secondly, a folding semantic is defined to convert templates into a wrapper metamodel. Thirdly, a wrapper model is generated using the existing model generators (e.g., a random model generator) according to the wrapper metamodel. Fourthly, an unfolding semantics is specified to translate the wrapper model into the desired test input. This paper also presents five case studies to evaluate the proposed approach, and the results demonstrate that such approach can generate large models based on structure-related constraints and facilitate the performance testing of MOs.

Appendices

Appendix A: Well-definedness rules

This appendix lists the basic well-definedness rules of our template language. These rules are programmatically implemented and used to check whether a template model is syntactically well defined. These rules are expressed in a set of OCL invariants as follows:

Rule 1. A template cannot extend itself:

Given a Template, we define a query that collects all the TemplateNodes declared in this template or inherited from the super templates as follows:

Given a TemplateEdge, we define two queries that collect the source and the target TemplateNodes as follows:

Rule 2. A TemplateEdge must connect to the TemplateNodes that are defined in the same template:

Rule 3. If a TemplateEdge starts from a NestedNode, then a complete set of source Mappings must be defined. if a TemplateEdge ends with a NestedNode, then a complete set of target Mappings must be defined:

In Rule 3, the operation isComplete is defined as follows:

Rule 4. For a Mapping, the TemplateNode of the Mapping should be declared in the Template:

Rule 5. If we define a reversedNestedNode in a host Template, the referred templates of the reversedNestedNode must be the possible containers of the host Template:

Rule 6. A SimpleNode must refer to a concrete class:

Rule 6. The reference a TemplateEdge refers to must be consistent with the source and the target of the TemplateEdge:

Appendix B: Details of structured process model generation

1.1 B.1: Templates for structured process

The following templates were used to generate a structural process model (complying with UML activity diagram). From now on, the keyword nested can be omitted in the template definition for the sake of simplicity.

Fig. 44

Wrapper metamodel for generating structured processes

1.2 B.2: Wrapper metamodel for structured process

From the templates above, a wrapper metamodel was automatically derived as shown in Fig. 19.

1.3 B.3: Correctness

We present the proof of the correctness for the templates presented in Appendix B.1.

We consider a model, which conforms to UML activity diagram, is a process fragment iff it does not contain any InitialNodes and FinalNodes.

According to the wrapper metamodel in Fig. 19, any wrapper model conforming to the metamodel can be viewed as a tree, where the edges are containment relationships. The root node of the tree must be an instance of $\mathbb {I}_{template}^{class}(TModel)$. The root node must contain exactly one child node that is an instance of $\mathbb {I}_{template}^{class}(Tprocess)$. If we ignore the two nodes, the remainder of the wrapper model (namely the tailored wrapper model) is also a tree.

Now we prove that for any tailored wrapper model M, unfolding M will always result in a structured process fragment by using mathematic induction.

Assume that tm is the template model presented in Appendix B.1. Let |M| be the size of M.

When $|M|=1$, M contains a single element that must be an instance of $\mathbb {I}_{template}^{class}(TAction)$. According to the template TAction and the unfolding algorithms, the result of unfolding M is an CallAction, which is a structured process fragment.

We assume that when $|M|\le k$, unfolding M results in a structured process fragment.

For the case $|M|=k+1$, if we remove the root node $n_r$ of |M|, we get a set of subtrees $\{M_1,\ldots ,M_i\}$. According to Algorithm 7, $\mathbb {U}_{\llbracket tm \rrbracket }(M)$ is equal to

$$\begin{aligned} \bigg (\bigcup _{1\le j\le i}\big (\bigcup _{n\in M_j}\mathbb {U}_{\llbracket \mathbb {I}^{-1}(type_{\mathcal {N}}(n) \rrbracket }^T(n)\big )\bigg )\cup \mathbb {U}_{\llbracket \mathbb {I}^{-1}(type_{\mathcal {N}}(n_r) \rrbracket }^T(n_r) \end{aligned}$$

which can be rewritten as

$$\begin{aligned} \left( \bigcup _{1\le j\le i}\mathbb {U}_{\llbracket tm \rrbracket }(M_j)\right) \cup \mathbb {U}_{\llbracket \mathbb {I}^{-1}(type_{\mathcal {N}}(n_r) \rrbracket }^T(n_r) \end{aligned}$$

The size of $M_j$ ($1\le j\le i$) is smaller than or equal with k. Unfolding $\{M_1,\ldots ,M_i\}$ will result in a set of structured process fragments, according to the induction hypothesis.

Now consider unfolding $n_r$. Depending on the type of $n_r$, we have the following cases:

• $type_{\mathcal {N}}(n_r)=\mathbb {I}_{template}^{class}(TSequence)$ (Fig. 20a). This means $n_r$ has two subtrees $M_1$ and $M_2$. Assume that unfolding $M_1$ and $M_2$ results in two structured process fragments $f_1$ and $f_2$. According to template TSequence, a ControlFlow will be created from the SimpleNodec (i.e., $\mathbb {U}_{\llbracket c \rrbracket }^N(n_r)$) during unfolding $n_r$. Afterward, SimpleEdges e1 and e2 will be instantiated through connecting the ControlFlow to $f_1$ and $f_2$ (i.e., $\mathbb {U}_{\llbracket e1 \rrbracket }^E(n_r)$ and $\mathbb {U}_{\llbracket e2 \rrbracket }^E(n_r)$). Since the remainder of the template TSequence (e.g., the reversedNestedNodeproc and the SimpleEdgee3) does not involve the constraint of a structured process, we can ignore them in this proof. According to the EndpointBindings associated with e1 and e2 and Algorithms 3 to 5, we know that the source of the ControlFlow will be connected to the exit node of $f_1$, and the target of the ControlFlow will be connected to the entry node of $f_2$. Thereby, $f_1$ and $f_2$ are strung together as a new sequence structure, namely $f_{1+2}$. Obviously, $f_{1+2}$, i.e., $\mathbb {U}_{\llbracket \mathbb {I}^{-1}(type_{\mathcal {N}}(n_r) \rrbracket }^T(n_r)$, is also structured. The entry node of $f_{1+2}$ is the entry node of $f_1$, and the exit node of $f_{1+2}$ is the exit node of $f_2$.

• $type_{\mathcal {N}}(n_r)=\mathbb {I}_{template}^{class}(TChoice)$ (Fig. 20b). This means $n_r$ has two subtrees $M_1$ and $M_2$. Assume that unfolding $M_1$ and $M_2$ results in two structured process fragments $f_1$ and $f_2$. According to template TChoice, during unfolding $n_r$, a DecisionNode, a MergeNode, and four ControlFlows will be created from the SimpleNodes entry, exit, and c1 to c4 (i.e., $\mathbb {U}_{\llbracket entry \rrbracket }^N(n_r)$, $\mathbb {U}_{\llbracket exit \rrbracket }^N(n_r)$, and $\mathbb {U}_{\llbracket c1 \rrbracket }^N(n_r)$ to $\mathbb {U}_{\llbracket c4 \rrbracket }^N(n_r)$), respectively. Then, the SimpleEdges e1 to e8 will be instantiated (i.e., $\mathbb {U}_{\llbracket e1 \rrbracket }^E(n_r)$ to $\mathbb {U}_{\llbracket e8 \rrbracket }^E(n_r)$). Since the remainder of the template TChoice does not involve the constraint of a structured process, we can ignore them in this proof. According to the EndpointBindings associated with e2 and e4, and Algorithms 3 to 5, we can know that the target of the ControlFlowc1 will be connected to the entry node of $f_1$, and the target of the ControlFlowc4 will be connected to the entry node of $f_2$. Similarly, we can also know that the source of the ControlFlowc5 will be connected to the exit node of $f_1$, and the source of the ControlFlowc7 will be connected to the exit node of $f_2$. In this way, we construct a new choice structure (called $f_{1+2}$). Obviously, $f_{1+2}$, i.e., $\mathbb {U}_{\llbracket \mathbb {I}^{-1}(type_{\mathcal {N}}(n_r) \rrbracket }^T(n_r)$, is also structured. The entry node and the exit node of $f_{1+2}$ are the DecisionNode and MergeNode newly created, respectively.

• The cases of $type_{\mathcal {N}}(n_r)=\mathbb {I}_{template}^{class}(TParallel)$ and $type_{\mathcal {N}}(n_r)=\mathbb {I}_{template}^{class}(TLoop)$ are similar.

Fig. 45

Illustration of induction step $|M|=k+1$ (a) When $n_r$ is an instance of TSequence (b) When $n_r$ is an instance of TChoice

Therefore, the induction hypothesis also holds when $|M|=k+1$. For any tailored wrapper model M, unfolding M always results in a structured process fragment.

After examining the template TProcess, we know that instantiating this template is to create an InitialNode and a FinalNode, and to create two ControlFlows from the InitialNode to the entry node of body and from the exit node of body to the FinalNode, respectively. The NestedNodebody actually points to the root node of the tailored wrapper model, which will be instantiated as a structured process fragment. Hence, the instance of the template TProcess is a structured process satisfying all the conditions mentioned in Sect. 6.1.

Appendix C: Details of train model generation

1.1 C.1 Templates for Train Model

The following templates were used to generate the train models. All the templates were derived from the source code of Szárnyas’s train model generator.

1.2 C.2 Correctness

As mentioned in Sect. 6.2, the train model has six well-formedness constraints. To evaluate the model queries that are used to check the six constraints, we must generate a train model containing both the fragments that satisfy the well-formedness constraints and the fragments that violate them.

Due to the space limitation, we analyze RouteSensor and SwitchSensor only.

Fig. 46

Illustration of generating a train model

Assume that the wrapper metamodel contains a fragment as illustrated in the left part of Fig. 21. Then, it is not difficult to find that unfolding this fragment results in a model fragment as illustrated in the right part of Fig. 21. Obviously, this resulting fragment satisfies both RouteSensor and SwitchSensor.

According to template TRoute, we know that element y, whose type is $\mathbb {I}_{template}^{class}(TSwitch)$, in the wrapper model can be replaced by an element whose type is $\mathbb {I}_{template}^{class}(TSwitchError)$. After doing this, unfolding the new fragment will lead to the absence of the relationship elements that currently exists in the right part of Fig. 21. It is because the template TSwitchError does not contain a TemplateEdge for creating this relationship (e.g., e1 in TSwitch). The new resulting model will violate the constraint SwitchSensor.

Similarly, if we replace the element z, whose type is $\mathbb {I}_{template}^{class}(TSensor)$, in the wrapper model with an element whose type is $\mathbb {I}_{template}^{class}(TSensorError1)$, the result of unfolding will violate the constraint RouteSensor. It is because the template TSensorError1 does not contain a TemplateEdge for creating the relationship definedBy.

We can ask the core generator to generate a wrapper model M that contains instances of $\mathbb {I}_{template}^{class}(TSensor)$, $\mathbb {I}_{template}^{class}(TSensorError)$, $\mathbb {I}_{template}^{class}(TSensor)$ and $\mathbb {I}_{template}^{class}(TSensorError1)$. Unfolding M will result in a model that contains the fragments satisfying RouteSensor and SwitchSensor and the fragments violating RouteSensor and/or SwitchSensor.

Appendix D: Details of RBAC model generation

The following templates were used to generate the RBAC model.

Note that to produce correct models, we must add two extra constraints in our core generator, as follows: (1) $\{\mathbb {I}_{nested}^{reference}(u)\}$ is source-unique, where u is the NestedNode in WUserRole; (2) $\{\mathbb {I}_{nested}^{reference}(r)\}$ is source-unique, where r is the NestedNode in WUserRole.

If a reference r is source-unique,

$$\begin{aligned} \forall x(|dom_r(x)|\le 1) \end{aligned}$$

Please refer to our previous work [19,20,21] for more information about our core generator.

The correctness of the templates were explained in Section 7.

Appendix E: Details of statechart generation

The following templates were used to generate the statechart model.

Appendix F: Henshin rules

Fig. 47

Henshin rules for structured process model

The section presents all the Henshin rules used in our case study.

To generate a structured process model using Henshin, we defined the five graph grammar rules in Fig. 22.

To generate a train model using Henshin, we defined the nine graph grammar rules in Fig. 23. Note that these rules can only produce a correct train model but cannot inject errors. If we want to inject errors, we will have to define more rules.

Fig. 48

Henshin rules for train model

To generate a RBAC model using Henshin, we defined the five graph grammar rules in Fig. 24.

Fig. 49

Henshin rules for RBAC model

Fig. 50

Henshin rules for structured process model

To generate a statechart model using Henshin, we defined the five graph grammar rules in Fig. 25.