ECMFA 2015 MoNoGe metamodel extension

Editor's Notes

• #2: Good morning. I’m Jokin from Atlanmod research group, in the Ecole des Mines of Nantes. I’m going to present the paper “On lightweight metamodel extension to support modeling tools agility”
• #3: -(Context)In many cases, companies (both solution providers and users) have to adapt their model-based infrastructure because of changing requirements or technological constraints. This usually comes with a range of potential issues including traceability, coherence or interoperability ones regarding both the modeling artifacts and data conforming to them. This is particularly true for modeling tools that heavily rely on their core supported MM(s). Indeed, such MMs may need to evolve over time and new/other ones may have to be additionally supported by these tools. -(Problem)Compatibility with already existing models must be preserved,but new models conforming to new MM versions have to be considered too. Both cases should be addressed, ideally in such a way that the effort implied by the corresponding modifications to the tools as limited as possible.Thus, there is a clear need for adaptability and flexibility in modeling tools/environments. (e.g. the OMG MOF Extension Facility (MEF) is still an ongoing RFP). -(Solution)We clain that this agility requires lightweight MM extension capabilities having several properties that we will see later
• #4: This work has been done in the context of the MoNoGe French collaborative project. It is intended to face up current limitations and the lack of standard solutions in the topic of MM extension
• #5: Modeling tools have to evolve quite frequently. Related changes can concern several different aspects: UI can be modified, new features can be added or previous ones removed, tool’s core can be restructured, etc. In all cases, it is important for software providers to be able to adapt their tools as easily as possible when implementing these modifications. Core modification of such environments generally implies the adaptation of these MMs and related tooling features. - Modelio is a concrete example of a modeling tool implementing popular standards such as UML, BPMN, SysML, etc. Users frequently need to reuse pieces of these standards and create extensions related to domain-specific solutions for System, Enterprise Architecture or Requirement modeling (for instance). Thus, already supported MMs need to be modified to reflect some changes: new complementary concepts could be added, previously existing ones could be updated or even filtered if not relevant anymore.
• #7: -original MM is an already existing MM that has a life on its own (e.g. is integrated in various tools/solutions, has models that conform to it, etc.) -MM extension is the definition of an extension that is, partially or completely, relying on concepts coming from original MM(s) or from other previously extended MM(s). -extended MM is the result of the application of one (or several) MM extension(s) onto original or already extended MM(s). -existing/legacy model is an already existing model that conforms to an original MM, but not necessarily to the extended MM(s)
• #8: -Genericity. The extension approach should not be linked to a particular MM, tool or implementing framework. Relying on the same base mechanism, MM extensions should be defined on any MM and should be exchangeable between different modeling environments. – Non-intrusiveness. Defined extensions should not directly modify original MMs but rather complement them in an external manner. – Persistence & Interoperability. Extensions should be specified, stored and shared in a user-comprehensive format, but also be easily machine-readable for reusability purposes. For separation of concerns (cf. also Non-intrusiveness), they should be persisted separately from MMs.
• #9: - Compatibility/conformance preserving. Models should not be altered when extensions are defined on their respective MMs: prior MM conformance should always be preserved. Backward conformance is also interesting: models that conform to a given extension could “forget” elements brought by this extension (e.g. default values could be used). – Transparency. From user and tooling perspectives, an extended MM should be presented and manipulated as any regular MM. Models can conform to extended MM and dedicated tooling can directly rely on them. – Dynamicity & synchronization. MM extensions can be applied and removed. Corresponding models and tooling should be able to react/adapt accordingly in order to preserve consistency and usability (notably concerning compatibility and conformance). – Runtime computation. (Parts of) Models conforming to an extended MM could be computed at runtime, i.e. from predefined expressions at extension-level (e.g. queries on the original MM). Related models and tooling should reflect the result of such computations.
• #10: A MM extension specification consists in a set of atomic extension operations These operators can be combined later on to express more complex changes. Our definition of these operators is not linked to any particular technical environment and therefore could be adopted by all modeling frameworks. FILTER and not DELETE. We want our extension mechanism to be as less intrusive as possible. Thus, we do not want to actually delete elements but rather hide them when asked for. Filtering is applied on cascade (e.g. in the case of generalizations or derived properties)
• #12: A textual DSL has been designed in order to make available the previously introduced extension operators via a textual concrete syntax very close to our MM extension terminology. This syntax is intended to be intuitive and easy-to-learn for people already familiar with (meta)modeling. Having genericity and portability in mind, it has been defined independently from any particular MM or modeling framework/environment.
• #14: The overall structure to declare an extension includes its name, the MM(s) it extends and a prefix and the list of applied operators (as well as the MM elements they are applied to)
• #15: Once extensions are defined, we need to provide a modeling infrastructure able to understand and deploy them as part of a normal modeling process. Our Eclipse/EMF implementation first comprises a dedicated editor for the textual DSL so that users can create their own MM extensions at development time. These extensions are then managed and processed using the architecture shown in Figure. A Base Operators API consumes, in addition to the original MM, the user textual definitions of the extension. Then, there is a M2M transf., to produce the appropriate data required by the Virtualization API to realize the MM extension. There are different options for linking (meta)models together. We rely on model virtualization techniques to interconnect (meta)models together transparently on an on-demand basis. A virtual (meta)model is a (meta)model that do not hold concrete data but rather kind of proxies to original (meta)models, making it relevant in a lightweight MM extension context. Extended (meta)models can be manipulated as any EMF (meta)models in Eclipse, by other existing EMF-based technologies relying on the standard EMF The described architecture and Eclipse/EMF implementation globally satisfy the expected characteristics: - generic as extensions can be defined and then applied on top of any MM. Keeping the DSL tooling independent from the other components makes the overall extension mechanism even more generic, as defined extensions can be reused by different modeling environments. - interoperable: extension declarations are persisted separately from original MMs and thus can be shared easily between various modeling tools using the same base extension mechanism. - The EMF Views non-intrusive and transparent approach, as well as its extensible architecture, made it a natural good candidate for our extension mechanism and offers concrete support to these important properties. - Synchronization is ensured because the “virtual” extended (meta)models simply hold proxies to the real data actually contained in different (meta)models. - compatibility and conformance are also preserved as original MMs are not actually modified. - partial runtime support is also available via the use of an automated matching engine connected to EMF Views. Source code and screencasts of the current implementation are available online
• #16: DCNS wants to evolve their existing DoDAF (U.S. Department of Defense Architecture Framework) models and related tooling support to NAF (NATO Architecture Framework) The goal is notably to enable the automatic reuse of existing DoDAF models in a NAF context. -FunctionType property is added to SystemFunctionSymbol -SASymHasFromArrow and SASymHasArrow properties are removed
• #17: DSL for specifying MM extensions is independent from any specific modeling tooling, framework or environment. This way, related MM extension mechanisms can be implemented on different technological platforms In contrast with the Eclipse/EMF solution, the Modelio-based one relies on a more generative approach. Thus, there are two very distinct phases 1- Firstly, there is a so-called development phase where the extension declaration is processed and transformed into a UML Class model, that is then transformed into a Java implementation model. This later is further processed by a Java code generator to produce a corresponding MM extension Jar to be loaded in Modelio. 2- Secondly, there is a runtime phase where the packaged MM extension is actually deployed within Modelio. This results in the modification of the Modelio original MM with content from the deployed extension,