Realization

From IDMPP

(Difference between revisions)
(→Build Configuration Resolution Demonstrator)
(→Megamodeling & Model Driven Cartography)
Line 19: Line 19:
== Megamodeling & Model Driven Cartography ==
== Megamodeling & Model Driven Cartography ==
 +
 +
 +
'''Megamodeling tool'''
 +
 +
 +
During the project, several new features have been developed for the megamodeling tool, the main ones are presented here.
 +
 +
'' Model transformation management''
 +
 +
One of the use case studied in the context of the IDM++ project provide several requirements for the megamodeling tool. The use case was focused on the management of a bridge between two rule languages IRL (Ilog Rule Language) and DRL (Drools Rule Language). To be able to deal with DRL rules within the Ilog solutions, the bridge was not a simple transformation between two metamodels but was required to generate also several other models and configuration files needed by the target business rules management system. As it can be seen on Figure 1, this bridge involves seven metamodels and twenty four operations. These operations can be categorized as follows:
 +
* External: of BOM and VOC by JRules from the Java Classes definitions.
 +
* Injection: input files for DRL, BOM, VOC and optionally IRL.
 +
* Transformations:
 +
** Refactoring: endogenous model transformation for DRL and IRL
 +
** Augmentation: growing endogenous model transformation for BOM, VOC, B2X and Rule Project.
 +
** Translation: exogenous model transformation for DRL2IRL, IRL2BAL and BAL2BRL.
 +
**XML-ification: a special kind of exogenous model transformation toward XML, for B2X, BRL and Rule Project.
 +
* Extraction: toward ad-hoc files for IRL, BOM, VOC and BAL, and toward XML for B2X, BRL and Rule Project.
 +
 +
[[Image:DRLIRL.png‎|400px|middle]]
 +
 +
Figure 1 - The rule interoperability use case complete process
 +
 +
To support this use case, three extensions to the global model management tool have been developed within the project.
 +
 +
The first one is focused on the management of ATL transformations. This management involves two aspects:
 +
* The representation: a metamodel for the ATL extension has been designed. It provides the different concepts (such as module, libraries or parameters) needed for the representation of ATL transformations as a model/metamodel in AM3.
 +
* The execution: the global model management extension of AM3 offers an extension point allowing executing transformation in the tool. The ATL integration offers an implementation of it for ATL transformations. It offers also a way to automatically generate traceability links during its execution. Thanks to this, a metamodel can now contain not only information about the “static” parts of the MDE project but also about the “dynamic” ones
 +
 +
The second extension is dedicated to the management of [http://www.eclipse.org/gmt/tcs/ TCS] projections . As for the ATL transformations, a metamodel extension has been defined for the projection representation and an implementation of the execution extension point have been provided for TCS.
 +
 +
The last one, consisting in the management of a set of transformations as a single one,  allowed to give some structure to complex bridges like this one. Now, the megamodeling tool supports the definition and execution of composite transformations. It allows an easier identification of the clusters in the transformation process and thanks to this it improves the reusability of the different part of the transformation chain. As an example, in this rule interoperability use case, four composite transformations can be identified, from DRL to IRL’, from IRL’ to RP, from BOM to B2X and form BAL to BRL.
 +
 +
 +
'' AMW. Model weaving integration and navigation between DSLs''
 +
 +
In the Pet Store use case presented in the project we considered a snapshot taken during the software development cycle of a simplified Pet Store application: all the artifacts developed at this time were models built using various DSLs. These models were of course interrelated (see Figure 2), and ways to represent those links were needed.
 +
 +
[[Image:petstore.png‎|400px|middle]]
 +
 +
Figure 2 - Example of links between model and model-elements in the PetStore use case.
 +
 +
The links between the different models can be categorized in two different levels:
 +
* Model level links are only established between models,
 +
* Model-Element level links are only established between elements, which are located inside models.
 +
Each link between models (i.e., a model level link) may be refined into a set of links between elements of these models (i.e., model-element level links).
 +
 +
Within AM3, the representation of the model level links is supported using the different relationships between the entities, but the support of the links between model element (stored in weaving models) had to be integrated in the tool as well as ways to navigate all these links.
 +
 +
To this aim, an extension dedicated to the management of AMW models has been provided.  This extension gives support to the definitions of weaving relations between models and their representation in the corresponding weaving models.
 +
 +
Additionally, we had to support the navigation of this of weaving links to be able to navigate from an element in one model to the related elements in another model. This has been done by adding two views to the AM3 user interface. The first one allowing showing and opening the models linked to the selected one, and the second view doing the same job at the model element level. These views are shown on Figure 3. 
 +
 +
[[Image:model.png‎|400px|middle]][[Image:modelelement.png‎|480px|middle]]
 +
 
 +
Figure 3 - Model level link and model element level link views.
 +
 +
This feature is very useful in AM3, since it allows for example to see what the impact in case of model modifications is. It can also be used to navigate the traceability links generated by transformations, for example in the rule interoperability use case.
 +
 +
'' Model Intent''
 +
 +
One thing which is often missing in modeling framework is the notion of “role” associated to a model. This notion introduced in the [http://www.springerlink.com/content/dxnv5664202h8468/ work of Rick Salay from the University of Toronto] aims to offer to the user the possibility of defining his models according to the intended goal, making the intent/role of the model explicit. Since this idea appears to be very important for the management and understanding of a MDE project, it has been decided (in collaboration with them) to integrate this feature into AM3. Now, designers can predefine the model “slots” that will be needed along a MDE project indicating the role of each model in the process and its intent, all this before starting the specification of the actual models. This helps a lot in the planning of the project and in the evaluation of its advancement. Figure 4 presents the metamodel of the extension that has been designed.
 +
 +
[[Image:ModelIntent.png‎|500px|middle]]
 +
 +
Figure 4 - Metamodel extension for model role definition.
 +
 +
'' Megamodel content visualization''
 +
 +
As a complement to the standard AM3 user interface, several visualizations of the megamodel contents have been designed to improve the understandability since we realized that for complex scenarios the standard tree-based representation provided by Eclipse was not adequate.
 +
 +
The more interesting visualizations are focused on the visualization of complex transformation chain like the one presented in the rule interoperability use case. Figure 5 presents one of these visualizations where the red boxes represent the composite transformations, the blue arrows the transformations and the black boxes the metamodels used.
 +
 +
[[Image:vizu.png‎|800px|middle]]
 +
 +
Figure 5 - Example of visualization on the rule interoperability use case.
 +
 +
 +
'''Model-Driven Cartography'''
 +
 +
The specializations have been implemented in a model driven cartography tool called [http://code.google.com/a/eclipselabs.org/p/portolan/ Portolan], which has been build on top of the concepts developed in AM3. This proximity between AM3 and Portolan implies an easy conversion of AM3 megamodels into Portolan visualization models. Portolan offers easy ways to produce visualization of complex systems using modeling techniques such as projections and transformations. It provides also a predefined support for several visualization tools such as [http://www.prefuse.org Prefuse] for graph rendering, Google maps views for geographical locations and other kinds of views such as tables. The views generated are easily customizable using model transformations and are automatically integrated within the graphical user interface of Portolan. Of course, as for every visualization tools, it is needed to have a clear view of what the user need to see and to choose a visualization support which fit with this purpose. As an example, it is often preferable to see a huge amount of strongly interrelated entities in a table rather than in a graph, because the effort needed to understand the graph will be too important. This is the mere reason why Portolan is able to deal with many visualization supports and why new ones can easily be added using its extension mechanism.
 +
 +
'' Company information system''
 +
 +
We worked on the definition of a cartography application for information systems. The aim of the work was to facilitate the comprehension of all the tools used by the different groups and departments of a company and the possible relationships between them, especially in terms of possible import/export format of each tool. The lack of this global view made difficult to decide whether a given tool could be replaced by a different one since there was no way to know the possible impact of this change if the new tool had a different set of features.
 +
To solve this kind of problems, AtlanMod proposed to create a cartography of their information system using Portolan to explicitly represent the tools and their possible interoperabilities. To this aim, several kinds of visualizations have been provided such as:
 +
* Graphical view of the tools that are supporting different format of data (BPMN, UML...).
 +
* Graphical view of the format used with bridge between them if they exist.
 +
* Graphical view showing the users and the tools.
 +
* Maps with the location of the users of the different tools
 +
* Graphical global view presenting the tools with their users and there input/output data format. This global view is shown on Figure 6.
 +
 +
[[Image:tools.png‎|600px|middle]]
 +
 +
Figure 6 - Global view of the Information System in Portolan.
 +
 +
''Plug-ins configurations''
 +
 +
The plug-ins configuration specialization of Portolan is devoted to help in the main IDM++ use case focused on the management of Eclipse build configuration. For this use case, the need was to provide a visualization that would facilitate the work of the engineers working on the plug-ins integration. To reach this goal several visualizations have been realized:
 +
* Graphical view of the plug-ins grouped by repositories,
 +
* Graphical view of the plug-ins grouped by features,
 +
* Graphical view of the plug-ins with higlighted user interface plug-ins,
 +
* Graphical view of the features involved in the build (shown on Figure 7).
 +
 +
Of course all the standard features of Portolan such as the highlighting the dependency path between two selected plug-ins remain available for all these views. An example of high-lighten dependency path can be seen on the figure below with the path between org.eclipse.emf.facet.all.features and org.eclipse.emf.facet.infra.feature.
 +
 +
[[Image:EMFFacetFeatures.png‎|700px|middle]]
 +
 +
Figure 7 - View of the EMF Facets features involved in the build.

Revision as of 12:06, 20 September 2011


Contents

Build Configuration Resolution Demonstrator

The use case aims to show that the MDE technology and the solver technology can be used to solve software engineering problem. The size increase of the software has leaded the computer science to introduce the concept of components. A component is a reusable piece of software which is combined with other components to implement another software component. The use of components by another implies the declaration of a dependency from the using component to the used component. The dependency can be constrained by a version range. For example: the version 1.2 of component A has dependency to the component B having a version upper than 2.3 and lower to 3.1. We meet more and more software products that are composed of huge number components, for example the yearly release of Eclipse (Helios) contains 11974 components and 80080 dependencies. To define a build configuration for such kind of software is a complex problem that cannot be solved in an acceptable time by regular algorithms.

The use case shows the use of MDE and solver technology to generate an Eclipse build configuration conforming to the dependencies constraints and to additional constraints.

OCL++

SPL & Optimization

Megamodeling & Model Driven Cartography

Megamodeling tool


During the project, several new features have been developed for the megamodeling tool, the main ones are presented here.

Model transformation management

One of the use case studied in the context of the IDM++ project provide several requirements for the megamodeling tool. The use case was focused on the management of a bridge between two rule languages IRL (Ilog Rule Language) and DRL (Drools Rule Language). To be able to deal with DRL rules within the Ilog solutions, the bridge was not a simple transformation between two metamodels but was required to generate also several other models and configuration files needed by the target business rules management system. As it can be seen on Figure 1, this bridge involves seven metamodels and twenty four operations. These operations can be categorized as follows:

  • External: of BOM and VOC by JRules from the Java Classes definitions.
  • Injection: input files for DRL, BOM, VOC and optionally IRL.
  • Transformations:
    • Refactoring: endogenous model transformation for DRL and IRL
    • Augmentation: growing endogenous model transformation for BOM, VOC, B2X and Rule Project.
    • Translation: exogenous model transformation for DRL2IRL, IRL2BAL and BAL2BRL.
    • XML-ification: a special kind of exogenous model transformation toward XML, for B2X, BRL and Rule Project.
  • Extraction: toward ad-hoc files for IRL, BOM, VOC and BAL, and toward XML for B2X, BRL and Rule Project.
Error creating thumbnail: /rrs.fs/www/mir-data/publish/x-info/idmpp/bin/ulimit4.sh: line 4: /usr/bin/convert: No such file or directory

Figure 1 - The rule interoperability use case complete process

To support this use case, three extensions to the global model management tool have been developed within the project.

The first one is focused on the management of ATL transformations. This management involves two aspects:

  • The representation: a metamodel for the ATL extension has been designed. It provides the different concepts (such as module, libraries or parameters) needed for the representation of ATL transformations as a model/metamodel in AM3.
  • The execution: the global model management extension of AM3 offers an extension point allowing executing transformation in the tool. The ATL integration offers an implementation of it for ATL transformations. It offers also a way to automatically generate traceability links during its execution. Thanks to this, a metamodel can now contain not only information about the “static” parts of the MDE project but also about the “dynamic” ones

The second extension is dedicated to the management of TCS projections . As for the ATL transformations, a metamodel extension has been defined for the projection representation and an implementation of the execution extension point have been provided for TCS.

The last one, consisting in the management of a set of transformations as a single one, allowed to give some structure to complex bridges like this one. Now, the megamodeling tool supports the definition and execution of composite transformations. It allows an easier identification of the clusters in the transformation process and thanks to this it improves the reusability of the different part of the transformation chain. As an example, in this rule interoperability use case, four composite transformations can be identified, from DRL to IRL’, from IRL’ to RP, from BOM to B2X and form BAL to BRL.


AMW. Model weaving integration and navigation between DSLs

In the Pet Store use case presented in the project we considered a snapshot taken during the software development cycle of a simplified Pet Store application: all the artifacts developed at this time were models built using various DSLs. These models were of course interrelated (see Figure 2), and ways to represent those links were needed.

Error creating thumbnail: /rrs.fs/www/mir-data/publish/x-info/idmpp/bin/ulimit4.sh: line 4: /usr/bin/convert: No such file or directory

Figure 2 - Example of links between model and model-elements in the PetStore use case.

The links between the different models can be categorized in two different levels:

  • Model level links are only established between models,
  • Model-Element level links are only established between elements, which are located inside models.

Each link between models (i.e., a model level link) may be refined into a set of links between elements of these models (i.e., model-element level links).

Within AM3, the representation of the model level links is supported using the different relationships between the entities, but the support of the links between model element (stored in weaving models) had to be integrated in the tool as well as ways to navigate all these links.

To this aim, an extension dedicated to the management of AMW models has been provided. This extension gives support to the definitions of weaving relations between models and their representation in the corresponding weaving models.

Additionally, we had to support the navigation of this of weaving links to be able to navigate from an element in one model to the related elements in another model. This has been done by adding two views to the AM3 user interface. The first one allowing showing and opening the models linked to the selected one, and the second view doing the same job at the model element level. These views are shown on Figure 3.

Error creating thumbnail: /rrs.fs/www/mir-data/publish/x-info/idmpp/bin/ulimit4.sh: line 4: /usr/bin/convert: No such file or directory
Error creating thumbnail: /rrs.fs/www/mir-data/publish/x-info/idmpp/bin/ulimit4.sh: line 4: /usr/bin/convert: No such file or directory

Figure 3 - Model level link and model element level link views.

This feature is very useful in AM3, since it allows for example to see what the impact in case of model modifications is. It can also be used to navigate the traceability links generated by transformations, for example in the rule interoperability use case.

Model Intent

One thing which is often missing in modeling framework is the notion of “role” associated to a model. This notion introduced in the work of Rick Salay from the University of Toronto aims to offer to the user the possibility of defining his models according to the intended goal, making the intent/role of the model explicit. Since this idea appears to be very important for the management and understanding of a MDE project, it has been decided (in collaboration with them) to integrate this feature into AM3. Now, designers can predefine the model “slots” that will be needed along a MDE project indicating the role of each model in the process and its intent, all this before starting the specification of the actual models. This helps a lot in the planning of the project and in the evaluation of its advancement. Figure 4 presents the metamodel of the extension that has been designed.

Error creating thumbnail: /rrs.fs/www/mir-data/publish/x-info/idmpp/bin/ulimit4.sh: line 4: /usr/bin/convert: No such file or directory

Figure 4 - Metamodel extension for model role definition.

Megamodel content visualization

As a complement to the standard AM3 user interface, several visualizations of the megamodel contents have been designed to improve the understandability since we realized that for complex scenarios the standard tree-based representation provided by Eclipse was not adequate.

The more interesting visualizations are focused on the visualization of complex transformation chain like the one presented in the rule interoperability use case. Figure 5 presents one of these visualizations where the red boxes represent the composite transformations, the blue arrows the transformations and the black boxes the metamodels used.

Figure 5 - Example of visualization on the rule interoperability use case.


Model-Driven Cartography

The specializations have been implemented in a model driven cartography tool called Portolan, which has been build on top of the concepts developed in AM3. This proximity between AM3 and Portolan implies an easy conversion of AM3 megamodels into Portolan visualization models. Portolan offers easy ways to produce visualization of complex systems using modeling techniques such as projections and transformations. It provides also a predefined support for several visualization tools such as Prefuse for graph rendering, Google maps views for geographical locations and other kinds of views such as tables. The views generated are easily customizable using model transformations and are automatically integrated within the graphical user interface of Portolan. Of course, as for every visualization tools, it is needed to have a clear view of what the user need to see and to choose a visualization support which fit with this purpose. As an example, it is often preferable to see a huge amount of strongly interrelated entities in a table rather than in a graph, because the effort needed to understand the graph will be too important. This is the mere reason why Portolan is able to deal with many visualization supports and why new ones can easily be added using its extension mechanism.

Company information system

We worked on the definition of a cartography application for information systems. The aim of the work was to facilitate the comprehension of all the tools used by the different groups and departments of a company and the possible relationships between them, especially in terms of possible import/export format of each tool. The lack of this global view made difficult to decide whether a given tool could be replaced by a different one since there was no way to know the possible impact of this change if the new tool had a different set of features. To solve this kind of problems, AtlanMod proposed to create a cartography of their information system using Portolan to explicitly represent the tools and their possible interoperabilities. To this aim, several kinds of visualizations have been provided such as:

  • Graphical view of the tools that are supporting different format of data (BPMN, UML...).
  • Graphical view of the format used with bridge between them if they exist.
  • Graphical view showing the users and the tools.
  • Maps with the location of the users of the different tools
  • Graphical global view presenting the tools with their users and there input/output data format. This global view is shown on Figure 6.
Error creating thumbnail: /rrs.fs/www/mir-data/publish/x-info/idmpp/bin/ulimit4.sh: line 4: /usr/bin/convert: No such file or directory

Figure 6 - Global view of the Information System in Portolan.

Plug-ins configurations

The plug-ins configuration specialization of Portolan is devoted to help in the main IDM++ use case focused on the management of Eclipse build configuration. For this use case, the need was to provide a visualization that would facilitate the work of the engineers working on the plug-ins integration. To reach this goal several visualizations have been realized:

  • Graphical view of the plug-ins grouped by repositories,
  • Graphical view of the plug-ins grouped by features,
  • Graphical view of the plug-ins with higlighted user interface plug-ins,
  • Graphical view of the features involved in the build (shown on Figure 7).

Of course all the standard features of Portolan such as the highlighting the dependency path between two selected plug-ins remain available for all these views. An example of high-lighten dependency path can be seen on the figure below with the path between org.eclipse.emf.facet.all.features and org.eclipse.emf.facet.infra.feature.

Error creating thumbnail: /rrs.fs/www/mir-data/publish/x-info/idmpp/bin/ulimit4.sh: line 4: /usr/bin/convert: No such file or directory

Figure 7 - View of the EMF Facets features involved in the build.

Retrieved from "https://web.imt-atlantique.fr/x-info/idmpp/index.php?title=Realization"
Workshop