Lightweight Metamodel Extension for Modeling Tools Agility
•
1 like•700 views
Full paper is available from https://hal.inria.fr/hal-01146802 Presentation associated to the paper presented at ECMFA 2015 (STAF'15).
Recommended
Recommended
More Related Content
Similar to Lightweight Metamodel Extension for Modeling Tools Agility
Similar to Lightweight Metamodel Extension for Modeling Tools Agility (20)
More from Hugo Bruneliere
More from Hugo Bruneliere (16)
Recently uploaded
Recently uploaded (20)
Lightweight Metamodel Extension for Modeling Tools Agility
- 1. © AtlanMod (atlanmod-contact@mines-nantes.fr)© AtlanMod (atlanmod-contact@mines-nantes.fr) On Lightweight Metamodel Extension to Support Modeling Tools Agility Hugo Bruneliere, Jokin Garcia, Philippe Desfray, Djamel Eddine Khelladi, Regina Hebig, Reda Bendraou and Jordi Cabot ECMFA 2015 @ L’Aquila, Italy Wednesday 22nd of July 2015
- 2. © AtlanMod (atlanmod-contact@mines-nantes.fr)© AtlanMod (atlanmod-contact@mines-nantes.fr) Introduction ● MDE in the industry o Various context, various purposes... ● Need for adaptation of model-based environments/tools o Traceability, coherence, interoperability, etc. ● Evolving and/or adding (new) metamodels o Cf. OMG MOF Extension Facility (MEF) RFP... ● More agility is required!
- 3. © AtlanMod (atlanmod-contact@mines-nantes.fr)© AtlanMod (atlanmod-contact@mines-nantes.fr) MoNoGe Project (French FUI #15) ● “ “New generation modeling tool” ● Partners: o Industrial - Softeam (leader), DCNS, Sodifrance o Academic - LIP6, ARMINES/Mines Nantes ● Duration: 30 months ● Total budget: 3,57M€
- 4. © AtlanMod (atlanmod-contact@mines-nantes.fr)© AtlanMod (atlanmod-contact@mines-nantes.fr) Industrial Motivation ● Minimizing cost/effort when evolving modeling tools o Metamodels are core artifacts (cf. related parsers, editors, generators, etc.) ● Example of the Modelio environment o Implementations of UML, BPMN, SysML, etc. o Parts reused and/or extended for domain-specific modeling (e.g. System, EA, Requirement) ● Need for more agile metamodel extension
- 5. © AtlanMod (atlanmod-contact@mines-nantes.fr)© AtlanMod (atlanmod-contact@mines-nantes.fr) Proposition/Contribution ● A generic lightweight metamodel extension approach for rapid and efficient adaptations of modeling tools o Base list of metamodel extension operators o Corresponding generic (textual) DSL o Architecture for an EMF-based implementation o DSL-compliant solution relying on Modelio
- 6. © AtlanMod (atlanmod-contact@mines-nantes.fr)© AtlanMod (atlanmod-contact@mines-nantes.fr) Metamodel Extension - Terminology
- 7. © AtlanMod (atlanmod-contact@mines-nantes.fr)© AtlanMod (atlanmod-contact@mines-nantes.fr) Metamodel Extension - Characteristics (1/2) ● Genericity o From any metamodel, modeling tool, framework or environment ● Non-intrusiveness o No modification of original (meta)models ● Persistence & Interoperability o Notably of metamodel extension (cf. our DSL)
- 8. © AtlanMod (atlanmod-contact@mines-nantes.fr)© AtlanMod (atlanmod-contact@mines-nantes.fr) Metamodel Extension - Characteristics (2/2) ● Compatibility/conformance preserving ● Transparency o From both tool and user perspectives ● Dynamicity & synchronization o E.g. at extension application/removal ● Runtime computation o Notably at model-level
- 9. © AtlanMod (atlanmod-contact@mines-nantes.fr)© AtlanMod (atlanmod-contact@mines-nantes.fr) Metamodel Extension - Base Operators (1/2) ● ADD (a new concept) o Create “from scratch” o Specialize (subtype) a concept o Generalize (supertype) concept(s) ● FILTER (an existing concept)
- 10. © AtlanMod (atlanmod-contact@mines-nantes.fr)© AtlanMod (atlanmod-contact@mines-nantes.fr) Metamodel Extension - Base Operators (2/2) ● MODIFY (an existing concept) o Add property to an existing concept o Filter property from an existing concept o Modify property (Filter + Add) o Add constraint to concept/property o Filter constraint from concept/property
- 11. © AtlanMod (atlanmod-contact@mines-nantes.fr)© AtlanMod (atlanmod-contact@mines-nantes.fr) Metamodel Extension - Proposed DSL (1/3) Operator Textual Syntax ADD - “From scratch” add class X ADD - Specializing add class Y specializing uml.A ADD - Generalization add class Z generalizing uml.B, uml.C FILTER filter class uml.D MODIFY (cf. next sub- operators) modify class uml.A { … }
- 12. © AtlanMod (atlanmod-contact@mines-nantes.fr)© AtlanMod (atlanmod-contact@mines-nantes.fr) Metamodel Extension - Proposed DSL (2/3) Operator Textual Syntax MODIFY - Add prop. add property propertyA type String MODIFY - Filter prop. filter property propertyB MODIFY - Modify prop. modify property propC attribute = "name", value = "propCbis" MODIFY - Add constr. add constraint consA “val” MODIFY - Filter constr. filter constraint consB
- 13. © AtlanMod (atlanmod-contact@mines-nantes.fr)© AtlanMod (atlanmod-contact@mines-nantes.fr) Metamodel Extension - Proposed DSL (3/3) ● Example of a simple DODAF extension
- 14. © AtlanMod (atlanmod-contact@mines-nantes.fr)© AtlanMod (atlanmod-contact@mines-nantes.fr) Metamodel Extension - Eclipse support ● https://github.com/atlanmod/monoge
- 15. © AtlanMod (atlanmod-contact@mines-nantes.fr)© AtlanMod (atlanmod-contact@mines-nantes.fr) Metamodel Extension - Eclipse support ● Short demonstration...
- 16. © AtlanMod (atlanmod-contact@mines-nantes.fr)© AtlanMod (atlanmod-contact@mines-nantes.fr) Metamodel Extension - Modelio support ● https://www.modelio.org/downloads/download-modelio.html
- 17. © AtlanMod (atlanmod-contact@mines-nantes.fr)© AtlanMod (atlanmod-contact@mines-nantes.fr) Metamodel Extension - Related Work (1/2) ● Metamodel Evolution approaches o Main effort on migrating related artifacts (more or less automated) o Original metamodels usually abandoned o Our solution: metamodel versions can coexist ● (UML) Profile or annotation mechanisms o Mostly limited to adding extra (meta)data o Our solution: more possible extension operations
- 18. © AtlanMod (atlanmod-contact@mines-nantes.fr)© AtlanMod (atlanmod-contact@mines-nantes.fr) Metamodel Extension - Related Work (2/2) ● Model Composition techniques o Creation of a single model by merging elements coming from several ones o Main issues on synchronization and scalability o Our solution: “new” & “old” models are the same ● Runtime-oriented solutions (e.g. EMF Facet) o (Meta)model extension via derived information o Our solution: new “materialized” data can be supported
- 19. © AtlanMod (atlanmod-contact@mines-nantes.fr)© AtlanMod (atlanmod-contact@mines-nantes.fr) Conclusion ● Lightweight metamodel extension mechanism based on a textual DSL ● Two alternative but DSL-compliant implementations o Eclipse/EMF-based architecture o Modelio solution ● Quite promising results so far (according to our MoNoGe partners)
- 20. © AtlanMod (atlanmod-contact@mines-nantes.fr)© AtlanMod (atlanmod-contact@mines-nantes.fr) Future Work ● DSL for metamodel extension o Polish current textual syntax + tooling o Study other possible syntax(es) - e.g. graphical ● Validation of extension application o E.g. coherence/consistency at model-level ● More complex extension algebra o Combination/composition of base operators...
- 21. © AtlanMod (atlanmod-contact@mines-nantes.fr)© AtlanMod (atlanmod-contact@mines-nantes.fr) Thanks for your attention! ● Questions? Comments? ● Contact persons: o Hugo Bruneliere - hugo.bruneliere@inria.fr o Jokin Garcia - jokin.garcia-perez@inria.fr
Editor's Notes
- 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”
- -(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
- 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
- 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.
- -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)
- -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.
- - 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.
- 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)
- 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.
- 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)
- 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
- 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
- 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,