Diverse Transformation, Contracts and Implementation

We reviewed the literature with regard to different types of model transformation approaches in Chapter 2. In particular, we recognised the two approaches for realizing variability in product lines via model transformation: reductive and additive transformations (shown again in Figure 92).

FIGURE 92REDUCTIVE/NEGATIVE (A) AND ADDITIVE/POSITIVE (B) VARIABILITY EXTRACTED FROM [57]

The transformations currently implemented in our approach (as described in Chapter 5) are reductive, and make use of stereotyped model elements to identify variation points in a UML design model, and the use of text pre-processing to remove unwanted variation in text regions (for example code bodies). However, there remains a potential for common- mode transformation error leading to false-positive static analysis results. This prompted an investigation into whether multiple diverse transformations would lead to a more credible analysis.

This revised approach takes advantage of the properties of both reductive and additive transformations and utilises them with programming languages whose syntax and semantics allow for the separation of contract (interface) and implementation, for example SPARK. This approach is not limited to SPARK however; it is applicable to any language that allows separate contract and implementation.

In general, the component contract specification is declarative; it defines properties that are expected to hold in the implementation of the component. For product line components these contractual properties can have common and variable parts, reflecting the intended variability across the product line. The declarative nature of these contracts makes them ideal for using a positive variability approach. This would involve the declaration of the common part of the contract, then providing additional contract “advice” which is associated with each of the decision options in the decision contract. Given a product configuration (a specific set of decision outcomes) an additive transformation can then construct the product specific component contract.

180 Trusted Product Lines – PhD Thesis S G Hutchesson

The detail of the implementation can be created separately to meet the product line contract, but for an imperative language such as Ada (which underpins the SPARK language) this is most easily achieved using negative variability – identifying text regions within the source code that are included or removed when the associated decision options are selected or deselected. A reductive transformation can then be used to generate the product-specific implementation.

Finally a static analysis can be performed to demonstrate conformance of the implementation to the contract. This analysis can be as rigorous as the form of the contract and power of the analysis tools allows. This approach is illustrated in Figure 93.

FIGURE 93VERIFYING EQUIVALENCE VIA STATIC ANALYSIS FOLLOWING THE DIVERSE TRA NSFORMATION OF CONTR ACT AND IMPLEMENTATION

The potential for using SPARK analysis as a means of demonstrating that properties have been preserved following an instantiation transformation is very attractive, however we have seen in the previous section that due to the common transformation used for both code and annotation, this evidence is relatively weak. It was decided to investigate whether the annotations could be modelled or encoded in a different form, and whether an alternative transformation approach could be used.

It is clear that SPARK information flow annotations are declarative – ordering is not important – and therefore should not be subject to the “point of injection” problems of positive variability. It was also apparent that the information flow effect of decisions in a component could be isolated very easily for the examples we studied. Therefore, it was

181 Trusted Product Lines – PhD Thesis S G Hutchesson

concluded that rather than modelling annotation variation as negative variability associated with a code sub-procedure, it should be modelled as positive variability associated with the decisions in the components decision contract. Each outcome in each decision would have its associated effect on the information flow within the component explicitly stated. The information flow for a given instantiated sub-procedure would be the combination of the common information flow for that sub-procedure and the set of flows for the decision options selected.

To test this we created a Domain Specific Language (DSL) to capture the positive variability of annotations, and ease the implementation of the compositional transformation. The DSL and associated tools were created using the Eclipse Modeling Project tool XText [130]. The optional annotations for the IgniterControl example discussed earlier can be stated in the new positive variability language are as follows:

selecting AUTO_RELIGHT_SELECTED as TRUE { operation IgniterControl.run {

abstract{

derives IIgniters.ignitionCmd from IAutoRelight.igniterCmdAutoRel;

} } }

selecting QUICK_RELIGHT_SELECTED as TRUE { operation IgniterControl.run {

abstract{

derives IIgniters.ignitionCmd from IStarting.igniterCmdQuickRel;

} } }

selecting CHECK_WATER_INGESTION as TRUE { operation IgniterControl.run {

abstract{

derives IIgniters.ignitionCmd from IEngineEvents.igniterCmdWaterIngest;

} } }

The language allows for multiple operations to be annotated per decision option, and for abstract and concrete annotations to be provided if required.

This approach has the advantage that it collects together all the annotations that are associated with the decision option into one place. This makes it much easier to review the effect that the selection of a decision option is intended to have on a component, and makes it much easier to spot mistakes in that information flow contract. It brings the declaration of the information flow to where conceptually it should be in the component – the contract.

Once a component has been deployed and the decision options selected, the instantiation annotation is an additive composition of the common information flow per operation, and

182 Trusted Product Lines – PhD Thesis S G Hutchesson

the annotations for the selected options. This approach has two clear benefits over the text transformation described earlier:

 The total effect of a decision option on the information flow of a component is clear, held in one place and can be peer reviewed and verified in its entirety.

 The information flow for an instantiated component is generated by a different transformation to the component itself. Diversity of transformation means that a successful information flow analysis of the instantiated component provides stronger evidence that the component has been transformed correctly.

This, then, offers the possibility of avoiding common mode failures in tools, and obtaining greater benefit from the product line approach.

7.2.1 Transformation of Behavioural Contracts

So far, we have only considered the use of contracts that describe the intended data and information flow within a component. Languages such as SPARK allow the intended behaviour of components to be modelled as part of the contract. Tool support is provided to enable a formal proof to be performed to show that the component implementation matches its contract specification.

The strongest form of evidence that a component has been transformed correctly would be to use the diverse transformation approach described in the previous section, coupled with a contract that includes a behavioural specification. A formal proof that the transformed component matches its (diversely) transformed specification would provide evidence at least as strong as testing of the component that the transformation had not introduced error into the product.

A fully-worked example of the transformation and proof of behavioural specifications is beyond the scope of this thesis, however the concepts are similar to those we illustrate above.

7.3 Conclusions

We began this chapter with the understanding that a transformation approach to the deployment of product line assets was viable for high-integrity systems, but may not have the level of assurance needed to deliver the full cost-benefits available to commercial product lines. This was due to the need to re-verify the transformed asset to show that errors had not been introduced during the transformation. The level of investment needed to develop a “trusted” transformation has been shown to be prohibitive in most circumstances, and potentially impossible without developing the technology “from scratch”.

We have investigated the possibility of using static verification of the transformed asset to assure its correct transformation, and have shown that this may provide credible evidence that error has not been introduced. In addition the credibility of this evidence may be enhanced by the use of diverse transformations to transform contract and implementation, with their conformance being demonstrated automatically. Finally we have postulated that

183 Trusted Product Lines – PhD Thesis S G Hutchesson

a contract containing formal behavioural specifications may provide evidence of correctness as strong as function test of the transformed component.

The ability to trust that a transformation has preserved properties of the source model and has not introduced errors into the transformed asset is key to ensuring a Trusted Product Lines approach is cost effective. We have outlined how static verification may be used to provide assurance in the correctness of transformation. Whilst a complete process has not been demonstrated, there is enough experience of the successful uses of SPARK [131] to have confidence in the viability of the approach.

We can contrast the approach outlined here with other approaches to verifying the correctness of model transformation, particularly

 Correctness of transformation by construction

 Testing of transformations

Whilst in general these approaches will increase the quality and reliability of transformations, they would not (in isolation) be acceptable means of compliance with the objectives of DO-178B/ED-12C for qualified development tools. A qualified development tool needs to be developed to the same level as the software it is used to develop. We would need to define “Level A” development and verification processes for the model transformation environments, including, for example, test coverage metrics for the transformation definition languages to ensure there is no “dead transformation code”. As most transformation environments are open-source, it is very difficult to obtain evidence from their development process to substantiate a tool qualification argument. Therefore, we will continue to rely on the verification of the output of the transformation rather than trust the transformation itself for some time yet.

184 Trusted Product Lines – PhD Thesis S G Hutchesson