9.1 Synchronizing Composed Security Models with Reuseware
9.1.2 Applying the Approach
For the THALES scenario most of the prerequisites to apply PREP were already met. All involved artifacts were represented as object-oriented models and respective EMOF- based metamodels for UML and the Security DSL were available. In addition, the arti- facts required by Reuseware (e.g., composition programs) were also models as Reuseware itself was created according to the principles of MDSD [192]. Thus, no further activities were required to prepare the involved artifacts for the implementation of PREP.
Change Propagation
In Chap. 6, the running example used to introduce the PREP approach was ISC-based composition system for state machines. There, we observed that ISC makes heavy use of thecopy operator when composing models. Elements from the input models are copied and reconnected to form the output of a model composition. We have also seen that propagating deletions and updates is rather easy if sufficiently detailed trace information is available. We had implemented support for traceability during our general investiga- tions on RTE for ISC in [187]. Thus, deletions and updates of security-related model elements in the integrated system view were enabled by our earlier work. Whenever a security element was deleted or updated, the respective original element in the RIO model was changed accordingly.
The situation is different for deletions and updates that refer to the structure of the system. As shown in Fig. 9.1, one of the composition programs—the one used to create the Security DSL core model—is derived. To propagate changes back to UML models, the transformation realized by this composition program must be taken into account. But, since the composition program is obtained by a higher order transformation— a transformation that creates a transformation—propagating changes as sketched in Sect. 6.4.1 was not possible. Thus, THALES decided to exclude automatic handling of these modifications from the scenario. If the creation of the Security DSL core model would be implemented using a different transformation instead of employing Reuseware’s metacomposition, one could extend the scenario to handle these kinds of changes.
Besides deleting and updating model elements in the integrated model, the scenario did also require support for adding new elements. For example, developers should be able to add new information about the impact of a system failure or associate new risks to system components in the integrated model. As discussed in Sect. 6.4.1 there can be multiple options how to propagate such additions. Multiple valid places where to add the new elements in the source models can exist.
In the THALES scenario, this was not the case. As it turned out during our investiga- tions, there is a clear distinction between elements that belong to the Security DSL core model and the ones that belong to the ROI model. We were able to split the metaclasses
9 Evaluation
+
Security DSL Integrated Model Deletions, updates, additions of RIO elements Additions of structural elements (e.g., system instances, channels) Security DSL Core ModelSoS instance, channels, system instances
Security DSL RIO Model
Security risks, impact, objective UML System Models Security DSL Additional Architecture Model manual propagation
Figure 9.3: Change backpropagation in the THALES scenario.
of the Security DSL into these two disjoint sets. Thus, whenever an element is added to the integrated model, the decision where to put this new element can be made by ex- amining the type (i.e., the metaclass) of this element. The scenario exposed type-based skeleton selection (cf. Sect. 4.1).
A summary of the change propagation strategy for the THALES use case is depicted in Fig. 9.3. Here one can find the models that were already introduced in Fig. 9.1, but also one new model—the Security DSL additional architecture model. The models are connected similarly as in Fig. 9.1. The Security DSL core model is derived from the UML system models and in a subsequent step composed with the ROI model. The result of this composition is the integrated security model. Change backpropagation paths are depicted by dashed arrows. As described above, deletions and updates on ROI elements (i.e., elements that are instances of metaclasses that belong to the ROI part of the security metamodel) are propagated to the ROI model. Also, additions of such elements are propagated in the same way.
The aim of the newly introduced model—the Security DSL additional architecture model—is to capture additions of model elements that encode system structure. For example, if a new communication channel is added to the integrated model, this is reflected by creating a channel in the additional architecture model. The reason for in- troducing this model was that propagating changes to the UML models was not possible. But, to enable additions of structural elements anyway, the new model was introduced. In practice, this requires to manually propagate additions from the architecture model (cf. Fig. 9.3) to the UML model, which THALES considered to be a feasible solution.
9.1 Synchronizing Composed Security Models with Reuseware
Replay
Replaying propagated changes in the THALES use case was quite easy to achieve. Since all transformations and compositions were fully automated, new versions of the inte- grated security model could be derived simply by executing the model composition on the changed input models. Since the use case did not require to evaluate multiple valid propagations, one does not even need to isolate the involved models. As there is always exactly one way to propagate a change, we simply perform this propagation and obtain a new integrated security model by executing the composition once again.
Synchronization Fitness Functions
PREP employs two important functions to control the selection of the most appropriate set of models after a change is applied by the user and propagated by the RTE system. The first function is called consistency fitness function and responsible to calculate the degree to which models are considered to be consistent. In the THALES case study even partially inconsistent models were not acceptable. Therefore, the consistency fitness function needed to be designed such that it returns 1 exactly if the composition of the input models yielded the expected, existing output model.
If we denote the UML system model as u, the ROI model as r, the additional archi- tecture models as a, the integrated model as i, and the multi-staged composition that is realized by Reuseware as compose, a corresponding consistency fitness function can be defined as follows:
consistent(u, r, a, i) =
1, if compose(u, r, a) = i 0, otherwise
As in any other scenario where partial inconsistency is not allowed, this function is very simple. Moreover, the second function required by PREP—the conservation fitness function—is trivial. Because there is a distinct correlation between the type of newly added objects and the model they must be propagated to, multiple propagation options can never arise. There is always only exactly one way to propagate a change, which renders the conservation function obsolete. For completeness reasons we can define it to be a constant:
conserved(u, r, a, i, u0, r0, a0, i0) = 1
9.1.3 Discussion Applicability
Using PREP in the THALES use case was quite successful. According to THALES, being able to make changes to the integrated model of the system was an important issue
9 Evaluation
that needed to be resolved to ensure the practical applicability of model composition. Since all involved artifacts were readily available as models conforming to EMOF, PREP could directly be applied. Moreover, once the relations between all involved models were clarified and it became clear how changes must be propagated, it took only a few days to implement the propagation strategy.
The support for RTE that was established in this scenario using PREP is not complete. Some modifications that users can apply to the integrated model cannot be handled automatically. While this seems to be a serious restriction from a conceptual point of view, it was not considered as a blocking factor by THALES. The partial support for editing and synchronizing models that was achieved, has been a huge step forward from a practical perspective. In addition, this restriction was caused by the metacomposition that was part of the use case rather than implied by PREP itself.
Gained Benefits
The model synchronization that was established in the THALES use case allows modelers to change the derived integrated system model within certain boundaries. Modelers can freely add and modify information that is purely related to aspects of security. Adding new structural elements to the modeled system is also possible, but requires manual adjustments of the UML models. This manual propagation is not mandatory, but required if the new structure shall be reflected in the UML models. Changing existing structural elements is not possible.
In summary, partial support to edit the integrated system model was gained by ap- plying PREP. This is not completely satisfactory, but already a huge step forward, given that the THALES use case involved complex models provided by an industrial research partner. Thus, the feedback provided by THALES was very positive and the Reuseware Composition Framework including its support for RTE was elected the best tool in the MODELPLEX project.
Discovered Drawbacks
Beside the limitations w.r.t. the supported set of change operations, we also discovered other problematic points. First, change propagation is performed on the level of abstract syntax, but modelers use concrete syntax and respective editors to change models. Thus, we experienced the loss of layout in graphical editors after propagating changes. Also, some editors did not gracefully handle model changes. In particular, newly added ele- ments were not automatically shown and in other cases editors forced a reload of the complete model after each change. This disturbs the editing process heavily.
EMF and the graphical editors that are built on top of its infrastructure do already aim at providing consistent editing processes. However, we observed that manual additions made to generated editors perished this idea in the THALES use case. Having editors