Solution Strategy

We have articulated the essential and accidental challenges posed by the desire to apply a Software Product Line approach to a set of high-integrity software systems. The following section describes the approach selected to develop the product line and create the product instances. We begin by discussing model transformation and how it may be used to instantiate products when using a model-based approach to software development.

We discussed the use of model transformation technology to instantiate product lines in Chapter 2; this included a discussion on the types/taxonomy of model transformations. Here we discuss the design of a set of endogenous, horizontal model-to-model transformations and a final model-to-text transformation that realise the complete product instantiation transformation.

5.2.1 Transformation Technology

In this section, we provide background on the model transformation tools chosen to implement the product line transformations. We briefly introduce and describe the “mechanics” of producing a transformation using the chosen environment; however, the novelty is in the design of the transformations that are encoded using this technique, and this is discussed in section 5.3 onwards.

We required a model-to-model transformation technology that had the following characteristics:

 Deterministic

 Declarative

 Endogenous

 Suitable for repeated application

 Extensible

 Can be augmented with a Model-To-Text transformation

A number of model transformation languages were available, or have been developed over the duration of the research project described in this thesis. Many of these languages, such as ATL (Atlas Transformation Language) , ETL (Epsilon Transformation Language), Operational QVT (Query/View/Transform), have concrete implementations based on the Eclipse Modelling Framework, requiring the underlying models to be MOF/EMF compliant. Whilst it is perfectly possible to implement the transformations described in this thesis using EMF-compliant tools, this was made difficult due to the constraints described earlier (requiring the research to be undertaken using the incumbent modelling tools in use in the sponsoring organisation, which made extensive use of the Artisan Studio UML tool.) Models developed in Artisan Studio are not easily interchangeable with the EMF framework (the provided XMI interchange being both unreliable and lossy with respect to the required model elements.)

Therefore the model transformation technology chosen to realise the product line instantiation was the ACS/TDK (Automatic Code Synchronisation/Template Development Kit) “4G” technology from Atego (formerly ARTiSAN). The ACS/TDK toolset provides the

124 Trusted Product Lines – PhD Thesis S G Hutchesson

basis for the model-to-text code generation and round-trip model and code development extensions to the ARTiSAN Studio UML environment. The “4G” version of ACS/TDK augmented this with the ability to perform Model-to-Model transformation.

The decision to use ACS/TDK 4G (hereafter known as TDK) was primarily driven by the need to develop an instantiation process that could be used for real on a large, multi-developer avionics project. ARTiSAN Studio was the incumbent modelling tool used on the projects that formed the baseline for the product line development activities and there was a substantial investment in tool licenses, existing product models and user knowledge. The previous projects used a UML to SPARK code generator that was implemented using OCS (On-Demand Code Synchronisation). OCS is a simple template-based Model-To-Text code generation engine. OCS scripts are developed in a language called SDL and are interpreted by the Studio environment on-demand. The customised OCS SPARK generator makes use of Ada and SPARK profiles which extend the UML class models to capture Ada and SPARK-specific concepts. This approach was used effectively on two large avionics projects (approximately 250K SLOC each). (The SPARK OCS generator was originally produced by ARTiSAN (now Atego), customised by Altran Praxis and subsequently by the author.)

However, OCS was not suitable for development of the product line transformation and code generation for a number of reasons. Firstly, the OCS product had been deprecated by Artisan and replaced by the ACS generator engine. Secondly, OCS had no model-to–model transformation capabilities. However, legacy OCS generators can be ported to/hosted within ACS-based generation schemes. This capability meant that it was easy to create the back end model-to-text transformation shown in Figure 60 from the OCS baseline and this had a degree of provenance from previous project use. The effort could therefore be spent on developing the product line transformation rather than replicating a pre-existing code generator.

In contrast to the interpreted-SDL approach of the OCS generator, ACS generators are compiled to Win32 DLLs and executed either on demand or as part of a continuous generation approach. ACS generators can run in the background during a modelling session and continuously generate code in response to changes in the source model. Round- tripping is also supported where model elements can be created in response to external changes to the source code. However, in the context of high-integrity software development, the generator is used exclusively in forward–engineering mode. (Back- documentation or reverse-engineering of design information from code is not an acceptable high-integrity development practise.)

A specific ACS generator DLL is produced by designing a generator model using the Studio UML tool (augmented with the TDK development kit). A special version of ACS is then used on the generator model to auto-generate the generator code and DLL.

125 Trusted Product Lines – PhD Thesis S G Hutchesson