Extending Component Contracts with Decisions

4 Defining a High-Integrity Product Line Model

4.6 Extending Component Contracts with Decisions

Feature model-based product line approaches often maintain a direct relationship between optional features and variation points with the product line assets. Our approach introduces a level of indirection into the variability model via the use of decisions [122]. Decisions provide a more granular means of describing variability, and these variability decisions are typically in the context of the implementation rather than the user-oriented view provided by the feature model. Significantly, this approach can be used to construct components before a complete understanding of the product line scope is available. These component decision points relate directly to variation points within the internals of the component. These variation points identify model elements that should be included or removed from the component when associated decisions are resolved.

Relationships can be established between features in a feature model and the component decisions, enabling feature-driven selection and traceability to be implemented. The

Component SPARK Class SPARK Operation SPARK Contract {Abstract} Ada Body Ada Contract {Abstract} * 1 * 1 1 1 * 1 * 1 Component SPARK Class SPARK Operation SPARK Contract {Abstract} Ada Body Ada Contract {Abstract} * 1 * 1 1 1 * 1 * 1

102 Trusted Product Lines – PhD Thesis S G Hutchesson

provision of a level of indirection between a feature model and an implementation via a

decision model has been demonstrated before [122] and is supported in prototype and

commercial software product line environments. However, our approach is significantly different and novel in that it makes variability decisions first-class model elements and contains them within the components exhibiting the variability. In this way, variability decisions are prominent in the component designer’s mind at the point of component design, and can be verified alongside the component design and implementation, for example via peer review. In addition, components containing variability can be shared between multiple product lines and the mapping between variation points and variability decisions is maintained.

The approach introduces the concept of decision contracts. The component contract is augmented by a model element termed a decision. The decision is a public attribute of the component contract. The decision attribute contains a set of possible resolutions to the decision, known as options. When a component is deployed, part of the action of deployment is to resolve each decision in the public decision contract. This involves choosing an available option for each of the published decisions. A meta-model defining this approach is shown in Figure 47. It clearly shows how the decision forms part of the component contract, and how decisions are related to modelling elements identified as variation points. In this way, the component contains and publishes the available variability in a concise manner, making the component reusable across product lines in a much more straightforward manner than would be the case if the variability were defined separately.

FIGURE 47META-MODEL DESCRIBING COMPONENTS CONTAINING DECISION CONTRACTS

Component Deployed Component

Contract {Abstract} Deployed Contract {Abstract} Modelling Element {Abstract} Variation Point Selection Criterion Decision Option Decision Resolution Selection Option * 1 * 1 1..* 1 1 1 * 1 * 1 * 1 1 1 1 * Binds To 1 * 1 * Resolves 1 * Selects * 1 1..* 1..* 0..1 1 Selects * 0..1 * 0..1

Component Deployed Component

103 Trusted Product Lines – PhD Thesis S G Hutchesson

Component variability is realized via the use of «PL variation point» stereotypes within the component model. Variation point stereotypes can be applied to any relevant meta-model element. Each variation point stereotype contains a “select when” attribute; this attribute holds an expression in terms of component decisions. Evaluation of this expression determines whether the associated meta-model element is included in the product instance model. The set of model transformations that evaluate these expressions and produce a product instance are discussed in the next chapter.

4.6.1 Variability & Variation Points

Variation Points identify places in architecture and the set of components where product- to-product variability is allowed. In general, component variability can be realised using a number of different variation techniques, and the selection can be made at different stages in the development lifecycle (known as the “binding time”). In our approach, most variability is resolved at code generation time, where model-to-model and model-to–text transformations produce the instantiated product (as described in Chapter 5).

Our instantiation mechanism ensures that only the functionality required in the specific product is to be deployed. It is not advantageous to carry round additional functionality as:

 Functions not required but resident in the executable will need to be deactivated. Any deactivation mechanisms will need to be specified and verified as required by DO-178B/ED-12B.

 Product Line assets may contain data that is proprietary to specific customers, however the product line may be instantiating a product for that customer’s competitor organisations (e.g. for avionics applications the product line may be instantiating products for both Boeing and Airbus applications, and contain airframe-specific information). Given that customers may have a right of audit and scrutiny over the development processes and artefacts it should be possible to provide development assets that are free from competitor’s protected information.

 Embedded systems can be resource constrained (e.g. the amount of available PROM space for program storage), so it can be advantageous to remove unnecessary code.

The following table lists the types of variability provided for each Meta-Model element of interest when modelling SPARK components:

Meta-Model Element Variation Point? Comment Subsystem Yes - Manually

Subsystems can form part of a hierarchy with only certain subsystems being required for particular deployments. The subsystems that are not required do not form part of the

104 Trusted Product Lines – PhD Thesis S G Hutchesson

deployment set.

Class Yes Classes marked as variation points are to be removed from the deployment model automatically by the transformation if their selection criterion is not met.

Operation Yes Operations marked as variation points are to be removed from the deployment model automatically by the transformation if their selection criterion is not met.

Parameter No Operation parameters are not modelled as variation points. Operations that require varying signatures shall be modelled as alternate operations.

Attribute Yes Attributes marked as variation points are to be removed from the deployment model automatically by the transformation if their selection criterion is not met.

Types (Sequence, Record (Structure), Array, Enumeration)

Yes Types marked as variation points are to be removed from the deployment model automatically by the transformation if their selection criterion is not met.

Record (Structure) Element

Yes Record elements marked as variation points are to be removed from the deployment model automatically by the transformation if their selection criterion is not met.

Enumeration Literal Yes Enumeration literals marked as variation points are to be removed from the deployment model automatically by the transformation if their selection criterion is not met.

Associations Yes Associations marked as variation points are to be removed from the deployment model automatically by the transformation if their selection criterion is not met.

105 Trusted Product Lines – PhD Thesis S G Hutchesson

4.6.2 Encoding Variability

We have discussed the concept of decision contracts, and how they map onto variation points in the software architecture and the components. Here, we illustrate how this is realised in practice with an example component containing a decision contract and associated variation points modelled in UML. Figure 48 shows an expanded UML browser “tree” for a Product Line component named AComponent. The set of icons in the browser have been extended based upon the UML stereotypes used to implement the trusted product line meta-model. A Product Line component is modelled as a stereotyped UML package, and is indicated as in the browser. A Decision is modelled as a stereotyped UML enumerated type, and is indicated as . In Figure 48, we see that AComponent publishes two decisions, with Decision1 having two possible options, and Decision2 having three possible options.

FIGURE 48STRUCTURE OF A SIMPLE PLCOMPONENT WITH CONTAINING A DECISION CONTRACT

Figure 49 shows a class diagram representation of the two classes contained in

AComponent. Here we see that there is an association between the classes that model an

Ada “With” clause. The class diagram also shows that particular operations and attributes within the classes are decorated with «PL variation point» stereotypes to indicate that those model elements are optional. Similarly, the association between the classes is denoted as optional, again via use of the «PL variation point» stereotype.

106 Trusted Product Lines – PhD Thesis S G Hutchesson

FIGURE 49CLASS DIAGRAM ILLUSTRATING VARIATION POINTS

The conditions under which each variation point is selected are encoded in the “PL select when” expression. This is contained in a UML “tag” associated with the «PL variation point» stereotype. The “PL select when” expression is described in terms of the decisions and options published in the component’s decision contract.

This approach results in a combined product design and variability model - there is no separate orthogonal variability model (as discussed with respect to the CVL approach in section 2.3.3). The single-model approach was chosen primarily for ease of verification-by- review of the product line models. It was felt that it was more straightforward to manually review the correctness and completeness of the variability mark-up if the complete set of information was presented in a single, coherent model. However, this is essentially a presentation issue (conceivably multiple models could be presented in a coherent combined view); the ease of verification of differing model forms and view could be the subject of future research. Also, as was discussed earlier in section 4.6, this approach allows variable components to be self-contained and therefore enables their reuse across product-line instances; this would be complicated by the use of separate orthogonal variability models.

In document Trusted product lines (Page 101-106)