The Comparing Modeling Approaches (CMA) workshop proposed in 2011 a set of criteria that allows modellers to understand, analyze, classify and compare various modelling approaches. Based on feedback gained from applying the criteria, the criteria and questionnaire document were revised and extended multiple times. In this paper, we suggest a change to the criteria that is aimed at improving the assessment of model composition. We argue that the definition of composition rule is ambiguous in the current document, and suggest to replace it with an easier and more useful criterion - the input specification. We propose an updated questionnaire and show how to apply it to three modelling approaches: AoURN, RAM, and UML.
The Bellairs modelling workshop and the follow-up Comparing Modeling
Approaches workshop at MODELS 2011 proposed a comparison criteria [
The rest of the paper is structured as follows. Section 2 discusses the issues
with the term “composition rule” and proposes an alternative criterion: the “input
specification”. Section 3 presents the updated questionnaire and section 4 applies
the updated questionnaire to some of the important composition operators of
UML, RAM and AoURN [
In section 2.2 of the most recent CMA comparison criteria [
On top of that, the criteria document also mentions that the distinction between rules and operators is not clear. We believe that especially the notion of composition rule is vaguely defined, and in the end not useful. At least so far we failed to understand how composition rules would help in comparing different modelling approaches, in particular since some example approaches in the document do not have rules for their operators.
To remedy this situation, we propose the following changes: 1. Revise the definition of composition: We suggest to change the definition of composition from “the act of creating new building blocks by using existing ones” to “the act of creating new or modifying existing modelling entities based on existing ones”. Be believe that this change is necessary in order to not exclude approaches that do not produce new entities, but modify the entities provided as input to the composition. 2. Use the following definition for composition operator : A composition operator is an operational model transformation that combines existing first class entities from one or several models to produce a composed model that contains the composed entities. The composed model may be one of the input models (in which case the operator might only modify existing entities), or it may be a new model (in which case all entities are created anew). The signature of a composition operator defines the interface for the model transformation. It clearly states the number and type of input model elements that are required to apply the operator, as well as the number and type of output model elements. 3. Replace the composition rule used in the document with input specification: An input specification specifies the input model elements to be used for a specific application of one or several composition operators.
From 2 and 3 above it immediately follows that a composition operator can only be executed if the inputs are specified. We believe that input specification is a good comparison criteria because compositional modelling approaches widely differ in how they specify the inputs to their operators. Some approaches specify the inputs separately from the operators, while others do not. There are approaches that have the input specification as part of their language / in their models, and other approaches specify the inputs elsewhere, for example when applying an operator in a tool. In addition, it is possible in some approaches to specify the input without performing the operator, and perform the operator later upon request. The next section explains how we redesigned the questionnaire to incorporate the suggested changes. 3
Based on the above, we updated the part of the questionnaire relating to composition. The new questions are aimed at determining the pronounced differences between modelling approaches supporting composition based on their composition operators and corresponding input specifications. The updated questionnaire is shown in Fig. 1. Questions A and K-U from the original questionnaire were omitted, since they weren’t modified and are not relevant to our proposed changes. The resulting questionnaire contains questions A-T, of which C-T are to be repeated for all composition operators identified in question B. Comments on the questions are given below: [Question A from original questionnaire] B. List the composition operator(s) supported by the modelling approach: C. To which language does the composition operator belong? D. What is the signature of the operator? E. Provide a brief textual description of the composition operator (i.e. its semantics).
F. Does the operator appear within a model (i.e., is the operator part of your language/metamodel)? [ ] Yes [ ] No G. Is the input specification for applying this operator part of a model (i.e., is the input specification for applying the operator part of your language/metamodel)? How is it specified?
[ ] Yes, how: _____________ [ ] No, where/how: _____________ H. If you answered "yes" for G, then answer the following: In your approach, is it possible to specify the inputs of the composition operator in a model without applying the operator? If yes, when is the operator applied? [ ] Yes, when applied: ________________ [ ] No I. Does the result of the composition contain one or more modelling elements that do not exist in the source models? [ ] Yes [ ] No [Questions J-T are the same as questions K-U from original questionnaire] – D. The signature of the operator specifies the types and the numbers of inputs – the formal parameters – that need to be provided for the operator to be applicable. The type of output should also be specified. At this point it is also possible to indicate if the operator can accept input model elements from different models or not. – E. The textual description should explain the semantics of the operator and mention any application constraints. – F. In some modelling notations, the operator itself is represented in the model. For example, in UML class diagrams, an association (i.e. the association operator) is represented in a model by a line. From a metamodel perspective, an association shown in a model is an instance of the Association metaclass. In Protocol Modelling (PM) on the other hand, composition of concurrent state machines using the CSP (Communicating Sequential Processes) parallel composition operator (|| ) is implicit. In other words, nothing in a PM model represents the || operator. Likewise, the PM metamodel does not define the || operator. – G. Before a composition operator can be applied, the input model elements must be specified. In other words, an actual parameter has to be provided for each formal parameter specified in the signature of the composition operator. Most of the time, an input specification for applying a composition operator can be specified in the model itself. For example, in UML class diagrams, an association line is drawn between 2 (or more) classes, which designate the inputs for the association operator. On the other hand one can also imagine a modelling approach that provides a tool that merges the properties (i.e. attributes and operations) of two classes to combine them into one class. In this case, the input specification for applying the “merge class” operator would be done by selecting the two classes that are to be merged. – H. In some approaches that allow to specify the inputs for an operator in the model, it is not necessary to apply the operator immediately when specifying the inputs, whereas in other approaches, the input specification is inseparable from applying the operator. For example, drawing an association line between two classes in UML specifies the inputs and immediately connects them with an association. In RAM on the other hand, it is possible to specify in an aspect model A that it instantiates an other aspect B without actually applying structural merge to combine the two models. The “aspect merge” operator can be applied, if the modeller wishes to visualize the combined structure of the two models, by hitting the “weave” button in the RAM tool. 4
In order to evaluate our proposed new definition, we applied the new composition criteria to the RAM composition operators, UML Association, UML Generalization and two of the AoUCM composition operators. 4.1
In RAM we identified four composition operators: aspect merge (RAM AM) merges two aspect models by merging the structural view and copying the message and state views from the lower-level to the higher-level aspect; message view inlining (RAM MVI) merges the message views of all operation invocations inside a message view into the former; message view advising (RAM MVA) integrates all aspect message views that a message view is affected by into that message view; state view composition (RAM SVC) composes all state machines belonging to the same class (i.e., a state view including all state machines) using CSP || composition semantics.
UML Association and UML Generalization are examples explained in the questionnaire. The operator of UML Association (UML A) creates a relationship between two classes, visually by drawing a line but also by modifying the affected classes adding information to them. Similarly, the UML Generalization (UML G) operator creates a relationship between two classes, visually by drawing an arrow but also modifying the sub-class.
In the Aspect-Oriented Use Case Maps (AoUCM) approach, we evaluated the generic control flow constructs (which represent any UCM control flow) and the pointcut-advice-mechanism. In that context we identified the control flow construct insertion operator (AoUCM CFI) and the aspect marker insertion (AoUCM AMI) operator. Control flow construct insertion inserts a control flow construct into the model and connects it to those workflow model elements that are used as input for the control flow construct. Aspect marker insertion inserts aspect markers into a workflow at the points where the pointcut pattern was matched, and binds the in and out paths of the marker to the start and end points of the associated advice aspect map. 4.2
* defined when operator applied ** user selection in the tool *** when weaving requested by user
This paper proposes changes to the parts of the CMA comparison criteria document and questionnaire that address composition. The work was motivated by the fact that when we applied the existing criteria to our approach we found the part on composition confusing. Some definitions were vague and hence we each interpreted them differently. Particularly, we found that definition of composition rule was not clear and the criteria document acknowledged the ambiguity. Additionally, the examples given in the paper did not help, as they sometimes even contradict each other. To remedy the situation, we suggest a more detailed definition of composition operator, propose to remove the composition rule, and to use input specification instead. We redesigned the questionnaire to reflect this change and applied our proposed criteria to three modelling approaches, AoURN, RAM and UML. Future work could address additional questions to address relationships between operators, i.e., operators that use other operators, which could be either independent or dependent operators (sub-operators).