Artículo 2. Objetivos generales

The specialisation of SPLE for the specification of dataflow blocks needs some substantial tooling and adaptation in order to be usable as requested in REQ-5, REQ-6, REQ-7, REQ-8 and REQ-9.a. For more complex specifications, we might also need to refine the structural features to, for example, include more elements like data types attached to structural features or constraints that limit the allowed values for those data types. The resulting number of products in the product line would increase drastically making the specification difficult to manage and analyse.

5.6 Two complementary approaches

Use of SPLE methodologies and formalisms allows to improve the variability management and solves part of the problems raised in the UML + OCL specification proposal. However, it does not allow to handle completely our domain specification problems. We saw in this section two possible specification methodologies and formalisms. First, UML + SPLE profile + OCL allowing for an accurate specification of blocks structures along with block semantics and variability management at a certain granularity. It suffers from the complexity of the UML model impacting the implementation of automatic verifications. Second, SPLE allows for an accurate management of variability issues but its expression power is very limited regarding the structural and semantics specification of blocks.

5.6.1 Methodology proposal

An accurate specification formalism for our purpose would inherit from concepts taken from both ap- proaches. We will illustrate a possible framework for the specification of the Delay block, using SPLE + UML + OCL. Our proposed methodology relies on the splitting of the block specification into 4 phases. Each phase is purpose oriented. In the first phase, the variability is analysed (REQ-9.b and REQ-9.c) by using SPLE and feature modeling, the block structural features are elicited, relations between them are provided. The overall complexity of the block is analysed. The second phase aims at matching the previ- ously specified features to UML classes and to generate an UML model. This transformation can either be manual or generated, the advantage of the automatic generation is obviously about time gain but it is also about the standardisation of the produced output. In the next phase, the block specification is constrained by providing OCL constraints for data types and dimensions of structural features (REQ-1, REQ-2, REQ-3, REQ-4, REQ-5). Finally, the semantics specification can be provided for each generated semantics instance (REQ-6).

Automatic verification of the specification properties (REQ-7), semantics correctness (REQ-8) and typing verification of expressions (REQ-9.a) can be done by developing transformations based on both the feature model and the UML + OCL elements.

5.6.2 From SPLE analysis to UML model

Using the extended feature modeling [84], it is possible to provide additional informations for each feature. We suggest to attach to each feature a UML class name taken from the generic block specification model of Section 5.4.1. We provide a table for such a mapping in Table 5.43.

By following this mapping table, we can generate an UML model from the Delay block feature model. Such UML model would be the same as the one provided previously for the Delay block specification in Figure 5.38. We provide it here for reference in Figure 5.44. The advantage of generating the UML model from the feature model is to keep the variability management at the feature model level and to use the UML capabilities for the detailed modeling of the block structure and semantics. In this setting, the specifier can then use OCL for structural constraints of the block feature values and data types and use any action language listed in Section 5.4.3 for the semantics specification.

When the block specification is done, it is then possible to extract the valid products from the UML model according to the extracted models of the feature model.

5.6. TWO COMPLEMENTARY APPROACHES

SPLE feature Mapped UML class

DelayBlock Block ScalarInput_SimpleDelay SequentialSemantics ScalarInput_ListDelay ScalarInput_SimpleDelay_Reset ScalarInput_ListDelay_Reset u_input Input ic_scalar_input ic_vector_input v_output Output ic_scalar_parameter Parameter ic_vector_parameter ic_mode_parameter delay_parameter reselt_algo_parameter m_memory Memory reset_memory

Table 5.43: Mapping from Delay block feature mode elements to UML classes

5.6.3 Limitations of the methodology

On the specification part, this proposed approach fits the needs. As we have shown, it allows for an accurate modeling of the specification variability, structure and semantics. But it suffers from major drawbacks related to the tooling development required for the verification of block specification: first, the SPLE to UML transformation and then the specification verification.

SPLE to UML transformation

The first transformation is simple and straightforward. Its verification should be easy regarding its com- plexity, a simple traceability checking is enough and can even be done to some extend reliably by proof reading if the number of elements in the specification is not too big. As we saw previously with the Delay block example, the feature model can become quickly quite complex leading to difficulties in the transfor- mation verification. This transformation target is an UML model, it should produce correct UML models and thus rely on an already existing UML implementation which have the drawback of being dependent of a specific platform or on the OMG-specified XMI format for the UML serialisation [5]. The second option is better as it allows to rely on common well accepted normative documents but need a consequent development. Of course current implementations of UML relying on this normative format is the sim- plest solution. While it is doable to implement this approach one needs to take care of the under-specified nature of the XMI format leading to incompatibility issues between tools.

Automatic verification

The second tooling development phase is about the verification of the specification itself after it has been implemented as an UML model and extended with OCL constraints.

REQ-7.a advocates for the structural correctness of the specification. Such correctness can be partially checked in the UML model itself as it does enforce some structural correctness. Additional structural verification should be implemented using OCL constraints to be applied on the modified model after gen- eration.

REQ-7.b and REQ-7.c advocates for the completeness and disjointness of the specification. Such a ver- ification relies first on the ability to extract from the specification all the valid block configurations. Such extraction of products from an UML specification is handled in [162]. In this work, the variability infor- mations are extracted from the profiling informations of the UML model but the same informations can be extracted from the SPLE informations and the SPLE to UML transformation traceability informations.

5.7. SYNTHESIS

Figure 5.44: Delay block specification using UML + OCL

Once this product extraction done, it is then necessary to extract from the products the information for the completeness and disjointness assessment. We have provided in (5.1) and (5.2) the formalisation of such operations. Implementation of the verification can be done in many ways, we propose to translate the model elements (UML classes and references) and the OCL constraints to a formal domain such as SMT solvers, this approach was not implemented for UML + OCL but for a specific DSML presented in Chapter 6 and the verification approach from Chapter 7.

REQ-8 advocates the verification of the semantics specified for each possible block configuration. The structural configuration of the block is then the definition domain of the block containing its inputs, out- puts, parameters and memories along with their specification. Specified semantics should then be trans- lated to the same formal domain and verified. Again we propose to use SMT solvers and proof assistants to do this verification according to its formalisation in (5.3). This approach has been developed from a DSML presented in Chapter 6 and the verification approach in Chapter 7. The semantics specification language should be formalised in order to ensure its translation verification. This might not be easily done especially if the semantics specification language is a complex and expressive language like Java.

5.7 Synthesis

We detailed two propositions for both structural and semantics specification of dataflow blocks. Separated, each approach has a limited interest but their combinations showed interesting capabilities regarding ex- pressiveness and verification. These capabilities are diminished by the complexity of the elements under specification leading to potentially over-constrained specifications (UML models) or surcharged feature models. We thus propose to rely on the DSML-based approach inspired on the SPLE and feature modeling principles. DSML are simpler as they are domain focused and it is easier to control the language specifi- cation and content. This leads to a simplification of the implementation of verification procedures and their implementation verification. Finally tooling definition is also simplified as we can rely on MDE tech- niques and automatise parts of the development effort. We will refer to this DSML as the BlockLibrary specification language and will detail it along with its associated tools in the next chapters.

6

A Domain Specific and Product Line experiment for language

specification

As seen in Section 5, dataflow languages such as Simulink or Scade rely on polymorphic elements (blocks) with highly variable semantics. The high variability of these blocks makes the writing of precise and com- plete specifications as well as any implementation and verification based on it very challenging. In order to ease these activities, we advocate to specify dataflow blocks with a dedicated Domain Specific Modeling Language (DSML) based on Software Product Line Engineering (SPLE) principles and concepts.

In this chapter, we will first describe the domain on which our DSML must apply. Then in Section 6.2 we will describe a DSML based on a model driven approach: the BlockLibrary DSML. We will rely on the previously described Delay block for the elicitation and clarification of the specification language elements. The relation between SPLE methodologies and our specification metamodel will be shown in Section 6.3. Section 6.4 will detail how specific block configurations can be extracted from the BlockLibrary metamodel conforming models. Block specific semantics specification is detailed in Section 6.5. We will finally provide in Section 6.6 a formalisation for BlockLibrary verification properties.

6.1 Domain analysis

In the MDE methodology, a DSML definition starts from a domain analysis allowing to emphasize the key concepts of the domain and the relations between them. Relations are either structural (what are the properties of each concept, relations between concepts) or behavioral (related to the semantics of exe- cutable languages). From this analysis should emerge a metamodel along with, if it is required, additional OCL constraints.

6.1.1 Domain of study

The domain of study of our work is variable block specification for dataflow languages. A block specifica- tion is two-fold: a) the allowed structures of the block – or interfaces of the block – containing the allowed combinations of input ports, output ports, parameters and memories along with the allowed data types and values specification for each of these structural elements and; b) the semantics specifications that are attached to each possible block interface.

Structural elements specification should provide their allowed data types and values (REQ-[2|3|4].[b|c]). In order to do so, a data type must be provided for each StructuralFeature element of the block in- terface and logical constraints must enrich their specification.