5.3 Validating Domain-Specific Properties of Software Models
5.3.2 Extending the Transformation with Success and Negative Success Conditions to Validate
The method extending the transformation with additional transformation rules (SCs and NSCs) to validate domain-specific properties automatically creates transformation rules that implement SCs and NSCs, and performs the validation. The original model transformation definition is extended with
generated transformation rules. As a result, the extended transformation performs the required validation. This method supports the validation of domain-specific properties (Figure 5-3).
With SCs and NSCs, we can define output model related domain-specific requirements. Now we discuss how to generate the necessary validation rules for different types of SCs/NSCs. First, we provide the definitions of the Validation transformation rule and the Validation point, and then introduce the different scenarios of the transformation extension. Next, we provide a method to generate validation transformation rules from SCs/NSCs (Section 5.3.2.1). Finally, we discuss the topic of extending model transformations with generated validation transformation rules (Section 5.3.2.2). We introduce algorithms for generating validation transformation rules, as well as extending model transformations with these rules.
Definition (Validation transformation rule). A validation transformation rule validates one or more output, model-related, domain-specific properties.
The exact points in a model transformation, where certain SCs and NSCs should be validated, are defined by validation points.
Definition (Validation point). A validation point designates a transformation rule in a model transformation control flow and refers an SC or an NSC that should be validated following the selected model transformation rule.
Figure 5-4 Extending model transformations with validation transformation rules: (a) Original model transformation, (b) Transformation extended with an intermediate SC, (c) Transformation extended with a final
SC, (d) Transformation extended with an intermediate NSC, (e) Transformation extended with a final NSC.
Figure 5-4 introduces the scenarios in which model transformations can be extended with validation transformation rules implementing SCs and NSCs. In Figure 5-4a, the original model transformation, which has two transformation rules executed in a sequence, is presented. In Figure 5-4b, the transformation is extended with a new validation transformation rule. The new rule is inserted after Rule1 and in the case of successful validation, according to the original control flow, it is followed by Rule2. In the case of failed validation, the transformation process stops with error. The scenario depicted in Figure 5-4c is similar to the previous one, but in this case, the validation transformation rule is inserted as the last (final) rule of the transformation. Scenarios shown in Figure 5-4d and Figure 5-4e are similar to the scenarios b and c, but differ in that the NSCs are implemented by validation transformation rules.
Therefore, if a match can be found and the conditions of the NSC hold, the transformation should terminate with error, otherwise the control flow continues.
Definition (Validate Success Condition). A transformation T validates a success condition SC for an input model H if executing the transformation T for the input model H results in an output model M that satisfies the conditions defined by the success condition SC.
Definition (Validate Negative Success Condition). A transformation T validates a negative success condition NSC for the input model H if executing the transformation T for the input model H results in an output model M that does not satisfies the conditions defined by the negative success condition NSC.
Definition (Validated model transformation). A model transformation T is validated if output models generated by transformation T satisfy a set of success conditions and/or negative success conditions.
Figure 5-5 Extending model transformations with complex validation: (a) Original transformation, (b) Transformation implementing an optimized transitive closure, (c) Transformation extended, with several
transformation rules, (d) Transformation extended with a sub-transformation.
In order for a model transformation be able to validate the conditions defined by SCs and NSCs, the SCs and NSCs should be implemented by transformation rules and should be inserted into the transformation control flow. Different SC and NSC types require different treatment to prepare for transformation validation.
1. Constraint-based SC/NSC. A method (algorithm) is required that generates validation transformation rules from constraint-based SCs/NSCs.
2. Pattern-based SC/NSC. The pattern of this type of SCs/NSCs can be used as both the LHS and the RHS of the appropriate validation transformation rule.
3. Hybrid SC/NSC. The pattern of this type of SCs/NSCs can be used as both the LHS and the RHS of the appropriate validation transformation rule. The constraints should be propagated to the LHS of the validation transformation rule.
4. General SC/NSC. We know that a general SC/NSC can be constraint-based, pattern-based, or hybrid. General requirements that can be expressed with a single pattern or constraint can be treated according to the previous points. In the case of more complex validation issues, e.g. one that requires several rules to be implemented, different methods should be applied. Some examples include traversing an inheritance hierarchy, within a UML class model, or identifying whether an output model contains a directed loop.
These situations should be handled with several transformation rules, in which aggregated behavior provides the required validation. In this case, we extend the original transformation
with several transformation rules or with a sub-transformation (if the control flow language provides the feature of the hierarchical control flows). The structure of this scenario is introduced in Figure 5-5. The original model transformation contains two transformation rules.
Figure 5-5b depicts a transformation in which the execution of a loop implements an optimized transitive closure traversing algorithm. In Figure 5-5c, our original transformation is extended with the validation implementing the transitive closure in inline mode. Figure 5-5d provides the same functionality while calling a sub-transformation. In this case, the validation is implemented in the form of a separated model transformation.
5.3.2.1 Generating Validation Transformation Rules
We use the algorithm GENERATEVALIDATIONTRANSFORMATIONRULE to generate validation transformation rules from constraint-based SCs/NSCs. The input parameter (condition) of the algorithm is an SC or an NSC. The algorithm creates a pattern with a single node, in which the metatype corresponds to the context type of the constraint (line 2-3). The algorithm traverses the navigation paths of the constraint. For each navigation step, the loop creates a new node and links it to the actual pattern (line 4-7). Next, based on the pattern, a transformation rule is created: both the LHS and the RHS of the rule is initialized with the pattern (line 8). The original constraint is propagated to the LHS of the rule (line 9). The constraint is propagated to the node that is created based on the context type of the constraint. Finally, the generated validation transformation rule is returned.
Algorithm. Pseudo code of the GENERATEVALIDATIONTRANSFORMATIONRULE algorithm 01: GENERATEVALIDATIONTRANSFORMATIONRULE (Constraint condition) : TransformationRule 02: RuleNode ruleNode = CREATERULENODE(condition.ContextType)
03: Pattern pattern = InitializePattern(ruleNode)
04: for all NavigationStep navigationStep in condition do
05: Node node = CREATENODE(navigationStep.DestinationNode.MetaType) 06: LINKNODE(pattern, node)
07: end for
08: TransformationRule rule = CreateTransformationRule(LHS = pattern, RHS = pattern) 09: PROPAGATECONSTRAINT(rule.LHS, ruleNode, condition)
10: return rule
Figure 5-6 introduces three constraints and their corresponding validation rewriting rules created by the algorithm GENERATEVALIDATIONTRANSFORMATIONRULE. The context type of the constraints is Server for all of the example constraints. In the case of constraint serverLoad, the path Server - ThreadPool - Thread should be traversed. Similarly, the paths covered by the constraint largeThreadPools are Server - Tier, Server - Tier, and Server - ThreadPool - Thread. In the case of constraint serverQueueThreadNumbers the traversed paths are Server - ThreadPool - Thread and Server - Queue.
Validation transformation rules validate output, model-related, domain-specific properties thus, they instantiate the output metamodel. Note that the LHS and the RHS graphs of the generated validation transformation rule have the same pattern. Given this structure a validation rule does not insert or delete any node or edge from the output model. The only difference between the LHS and RHS of the generated rule is the constraint that is propagated only to the LHS.
Based on the pseudo code of the algorithm GENERATEVALIDATIONTRANSFORMATIONRULE, we can state that the validation transformation rule generated with algorithm GENERATEVALIDATIONTRANSFORMATIONRULE does not modify the output model. Furthermore, we can conclude that validation transformation rules generated with algorithm
GENERATEVALIDATIONTRANSFORMATIONRULE are not necessarily valid partial instances of the output metamodel.
Figure 5-6 A Algorithm GENERATEVALIDATIONTRANSFORMATIONRULE: (a) Constraint serverLoad and the generated rule, (b) Constraint largeThreadPools and the generated rule, (c) Constraint
serverQueueThreadNumbers and the generated rule.
5.3.2.2 Extending Model Transformations with Validation Transformation Rules
We use the algorithm EXTENDTRANSFORMATIONWITHVALIDATIONRULES to extend the control flow model of the transformation with the generated validation transformation rules. The input parameters of the algorithm define the transformation T that should be extended, a condition list containing SCs and NSCs, and the list of the validation points where SCs and NSCs should be validated. The algorithm creates a flow final node (line 2) then, using a loop, processes the validation points (line 3-25). For each validation point, the SC or NSC condition is selected from the conditionList (line 4). Next, based on the representation type of the condition (ConstraintBased, PatternBased, or Hybrid), the algorithm creates a validation transformation rule. In the case of ConstraintBased representation type, using the constraint of the condition, the validation rule is created with algorithm GENERATEVALIDATIONTRANSFORMATIONRULE (line 6-7). Otherwise, for conditions with representation type PatternBased and Hybrid the validation rule is created based on the pattern of the condition (line 10). Both the LHS and the RHS of the new validation rule is initialized with the pattern of the condition. For Hybrid type conditions, the constraint of the SC or NSC is propagated to the LHS of the validation rule (line 12-14). Then the algorithm assigns the new rule to the transformation T (line 15), and arranges the necessary flow edge modifications (line 16-24). During the creation and rearrangement of the flow edges, we differentiate the success type of the conditions, i.e. SCs and NSCs are handled in a different way. Figure 5-7 illustrates this part of the algorithm. In both of the cases the new validation rule is inserted after the transformation rule selected by the validationPoint. The difference is in the type of the flow edges beginning from the validation rule. In the case of SCs, a Fail type edge goes to the flowFinal and Success type edges points to the original target rules or to the end rule. Contrarily, in the case of NSCs, a Success type edge goes to the flowFinal and Fail type edges point to the original target rules or to the end rule. Finally, the extended transformation definition is returned.
Algorithm. Pseudo code of the EXTENDTRANSFORMATIONWITHVALIDATIONRULES algorithm 01: EXTENDTRANSFORMATIONWITHVALIDATIONRULES (Transformation T, List conditionList, List validationPointList) : Transformation
03: for all ValidationPoint validationPoint in validationPointList do
04: Condition condition = conditionList.Get(validationPoint.ConditionReference) 05: TransformationRule validationRule = NULL
06: if (condition.RepresentationType == RepresentationType :: ConstraintBased) then 07: validationRule = GENERATEVALIDATIONTRANSFORMATIONRULE(condition.Constraint) 08: else
09: // executed for PatternBased and Hybrid type conditions
10: validationRule = CREATETRANSFORMATIONRULE(LHS=condition.Pattern, RHS=condition.Pattern) 11: end if
12: if (condition:RepresentationType == RepresentationType :: Hybrid) then 13: PROPAGATECONSTRAINT(validationRule.LHS, condition.Constraint) 14: end if
15: T.AddTransformationRule(validationRule)
16: if (validationPoint:SuccessT ype == SuccessType :: SC) then 17: CREATEFLOW(validationRule, flowFinal, FlowType :: Fail)
18: MODIFYFLOWS(validationPoint.TransformationPoint, validationRule, FlowType :: Success) 19: else
20: // executed for NSCs
21: CREATEFLOW(validationRule, flowFinal, FlowType :: Success)
22: MODIFYFLOWS(validationPoint.TransformationPoint, validationRule, FlowType :: Fail) 23: end if
24: CREATEFLOW(validationPoint.TransformationPoint, validationRule, FlowType :: Success) 25: end for
26: return T
Figure 5-7 Algorithm EXTENDTRANSFORMATIONWITHVALIDATIONRULES: (a) A success and a negative success condition of the transformation, (b) Validation points, (c) Generated validation transformation rules (RuleSC and
RuleNSC), (d) The stages of the transformation control flow extension.
Figure 5-7 introduces the whole process of the transformation validation. Figure 5-7a defines a success and a negative success condition that are stated against the transformation. In Figure 5-7b two validation
points are introduced. These validation points define where and which conditions should be validated.
Figure 5-7c1 depicts the validation rule created based on condition ConditionSC and Figure 5-7c2 shows the validation rule created based on condition ConditionNSC. In Figure 5-7d1 the original transformation is presented. Figure 5-7d2 shows the state after extending the transformation with a flow final and the validation rule RuleSC. The flow edge between RuleSC and Rule3 is followed in the case of successful validation, otherwise the control follows the new edge starting from RuleSC and pointing to flow final node. Finally, Figure 5-7d3 presents the state of the control flow after extending it with the validation rule RuleNSC. The flow edges are connected in a different way: in the case of satisfying the conditions of NSC the successful edge is followed that points to the flow final, otherwise the control is passed to Rule2.
The following statements and consequences summarize statements related to (i) the presented algorithms, (ii) the transformations processed with these algorithms, and (iii) the models resulted by the extended transformations.
‒ Assume an input model H, a model transformation T, and a success condition SC. A validation transformation rule VR is generated from SC with the algorithm GENERATEVALIDATIONTRANSFORMATIONRULE. Model transformation T is extended with the algorithm EXTENDTRANSFORMATIONWITHVALIDATIONRULES, using the validation point VP{T.LastTransformationRule, SC, SuccessType::SC}. The resulted transformation is T’. If the transformation T validates the success condition SC for the input model H, then transformation T’ also validates the success condition SC for the input model H. Transformations T and T’
generate the output models M and M’ respectively.
‒ Assume an input model H, a model transformation T, and a negative success condition NSC. A validation transformation rule VR is generated from NSC with algorithm GENERATEVALIDATIONTRANSFORMATIONRULE. Model transformation T is extended with algorithm EXTENDTRANSFORMATIONWITHVALIDATIONRULES using the validation point VP{T.LastTransformationRule, NSC, SuccessType::NSC}. The resulted transformation is T’. If the transformation T validates the negative success condition NSC for the input model H, then transformation T’ also validates the negative success condition NSC for the input model H.
Transformations T and T’ generate the output models M and M’ respectively.
‒ Assume an input model H, a model transformation T, a success condition SC and a validation point VP{T.LastTransformationRule, SC, SuccessType::SC}. Based on the success condition
SC, a validation rule VR is generated with algorithm
GENERATEVALIDATIONTRANSFORMATIONRULE. The transformation T is extended by algorithm EXTENDTRANSFORMATIONWITHVALIDATIONRULES, applying the validation point VP. The resulted transformation is T’. If the transformation T’ finishes successfully for input model H, generating the output model M’, then the original transformation T validates the success condition SC for input model H while generating the output model M.
‒ Assume an input model H, a model transformation T, a negative success condition NSC, and a validation point VP{T.LastTransformationRule, NSC, SuccessType::NSC}. Based on the negative success condition NSC, a validation rule VR is generated with algorithm GENERATEVALIDATIONTRANSFORMATIONRULE. The transformation T is extended by algorithm EXTENDTRANSFORMATIONWITHVALIDATIONRULES applying the validation point VP. The resulted transformation is T’. If transformation T’ finishes successfully for input model H generating the output model M’, then the original transformation T validates the negative success condition NSC for input model H while generating the output model M.
‒ Assume that a transformation T terminates for an input model H. Applying the algorithm EXTENDTRANSFORMATIONWITHVALIDATIONRULES we extend the transformation T with one or more validation transformation rules. The resulted transformation is T’. Transformation T’
terminates for input model H.
We can see that these types of rules (do not perform modification) and this type of transformation extension (no additional loops and the inserted rules are performed once in a sequence) do not make the originally terminating transformation T non-terminating.
‒ Assume an input model H, a model transformation T, a success condition SC, a negative success condition NSC, and two validation points VPSC{T.LastTransformationRule, SC, SuccessType::SC} and VPNSC{T.LastTransformationRule, NSC, SuccessType::NSC}. The generated validation rules for SC and NSC are RSC and RNSC respectively. The transformation T is extended by the algorithm EXTENDTRANSFORMATIONWITHVALIDATIONRULES applying the validation points VPSC and VPNSC. The resulted transformation is T’. Transformations T and T’
are executed for the same input model H, the output models are M and M’ respectively. If the rules RSC and RNSC successfully validate the conditions, i.e. SC is present in the model and NSC cannot be found in the model, then the resulted output models M and M’ are identical.
Note that in the case of validation error the output models M and M’ can be different. The reason is that unsuccessful validation rules stop the transformation execution and all rules that follow an unsuccessful validation rule in the control flow model are not executed.
This section has discussed a way of validating graph rewriting-based model transformations. We have investigated the validation-related possibilities and have developed a novel approach for the verification and validation of output, model-related, domain-specific properties. We have provided algorithms for generating validation transformation rules and extend model transformations with the generated validation rules. Finally, we have provided several statements regarding the discussed algorithms, the transformations processed with these algorithms and the models resulting from extended transformations.