Realization

From IDMPP

Contents 1 Build Configuration Resolution Demonstrator 2 OCL++ 3 SPL & Optimization 4 Megamodeling & Model Driven Cartography

Build Configuration Resolution Demonstrator

The use case aims at demonstrating that MDE techniques and Logic/Optimization approaches, implemented in the solvers, can nicely work together to solve software engineering problem. A global framework has been developed and applied with two different optimization techniques.

The increasing complexity of software systems has leaded to separate each system functionality into components, which contain data and functions semantically related. Each component is then loosely coupled with the others, and knows them by means of their interfaces which represent what a component does. These two capabilities increase the reusability of components and allow creating new services by assembling different other components.

A plug-in, is a set of software components, which can be assembled with other plug-ins for creating new plug-ins. The relationship between two plug-ins is depicted as a dependency, which can be constrained by a version range. For instance, having two plug-ins A and B, where A has a dependency on B, we could constrain the dependency accepting plug-ins with a version number greater than 2.3 and less then 3.1 (A → B[2.3,3.1] ). More and more software products are composed of huge number plug-ins, for example the yearly release of Eclipse (Helios) contains 11974 plug-ins and 80080 dependencies.

The definition a build configuration for such kind of software has thus became a complex problem that cannot be solved in an acceptable time by regular algorithms. The use case shows how MDE and solvers technologies interact each other in order to generate an Eclipse build configuration conforming to the dependencies constraints and to additional constraints.

OCL++

OCL++ (OCL for satisfaction [OCL(s)] and optimization problems [OCL(o)]) is an adaptation of OCL (Object Constraint Language) and it represents a CP interpretation of OCL. It is used in Model Search [next sub-section] to constrain and complete the output models

OCL has been extended with multi-class invariants, which allow defining constraints on more than one Object (Context).

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: example of multi-class invariants

OCL++ can be used for model verification and testing, models/services/components composition and configuration and search-based model transformation. OCL++ can deal with heterogeneous technologies and approaches like SAT solvers, Prolog, CSP, etc and it allows exporting them into a MDE context.

OCL++ is divided in layers:

• Core: arithmetic, comparison and navigation expressions

• OCL Collections: select, iterate, collect, allInstances (compatible with OCL)

• Multi-context: OCL with multi-class invariants

Model Search Approach

Model Search combines models and constraint programming approaches into a single fully automated model-driven and integrated operation. The notion of constraints is closely tight to MDE. Engineers have been using constraints to complete the definition of metamodels for a long time, as illustrated by the popular combination UML/OCL. Constraints can be, for instance, checked against one given model in order to validate it.

Model Search deals with the concept of weak conformance (or ε-conformance) representing the open world assumption in the MDE context. Initially, the input models conform to a relaxed metamodels. A metamodel is called relaxed when all its constraints are removed:

• minimum cardinalities are set to zero

• attributes become optionals

• predicates are removed

the CP solving process aims at finding a finite and complete constrained model using OCL++ expressions and the constraints coming from the metamodel. Figure 2 illustrates the execution chain of a generic process based on the model search methodology for a configuration scenario.

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: model search process

The configuration process interacts across two technical spaces (TS). The MDE technical space and the grammar-ware technical space. A technical space is based on a different metametamodel, and it provides a set of principles, representation format and tools. The input meta-model MMIN defines the concepts of a configuration application. The input model MIN conforms to MMIN and it may be empty or incomplete. The constraint language metamodel MMCT defines the concepts of the constraint language. The model MCT defines a set of constraints over the input metamodel (MCT applies to MMIN). The transformation Input2Config takes as input the input meta-model and the set of constraints and it produces a configuration model MCONF, which conforms to a configuration meta-model MMCONF. This metamodel depicts the concepts of the configuration engine. Typical configuration engines define the constraints and the meta-models in a single model. Thus, Input2Config must also merge the models. The configuration model is extracted into a textual (or XML) file, which is read and executed by the engine. The engine produces the set of valid solutions in its own format (Configuration action). Each solution is injected into a solution model MSOL, which conforms to a solution meta-model MMSOL. Note that MMSOL and MMIN maybe equal. Finally, the solution may be re-injected, and reconfigured incrementally.

8-Queens Problem and Model Search/OCL++

Model Search/OCL++ can be applied on Constraint Programming problems. The n-queens problem is the problem of placing eight chess queens on an 8×8 chessboard so that no two queens attack each other. Thus, a solution requires that no two queens share the same row, column, or diagonal.

In the example we want to find a solution for the 8-queens problem, so then, the input model will contain 8 elements representing Queens:

Figure 3: Metamodel and input model for the 8-queens problem

The constraints of this problem can be modeled by means of some OCL++ expressions

An output model on the twelve possible ones could be:

Service Product Line (SPL) and Model Search/OCL++

Model Search/OCL++ can be applied also on SPL problems. SPL is a software system that shares a common set of features of an application domain, which acts as a basis to produce a set of products. The specificities of each product are defined by features satisfying the needs of a particular application. These features contain explicit variation points and constraints, which will guide the production of the final products. Each combination of variation points may be used for producing a distinct product. Consider for instance a SPL for producing software executed in watches. We want to generate 5 different kinds of watches: 1) one simple watch, 2) one with alarm, 3) one with sound alarm, 4) one with sound and visual alarm and 5) one with visual alarm. In other words, the metamodel define classes, attributes, methods, etc.

However, not all combinations of methods are allowed. The derived models should respect the following constraints, which are implemented using OCL++ language:

• the DisplayTime and Start methods are mandatory

• if there is a Start, there is a Stop

• if there is a StartAlarm, there is a StopAlarm

• if there is a StartSoundAlarm, there is a StartAlarm

• if there is a StartVisualAlarm, there is a StartAlarm

The execution of these rules produces models representing a product with specific features.

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

SPL & Optimization

The main goal of product line development is to factor the work associated with a set of models. In order to achieve this goal, we build a generic model representing a product line of systems and use this model to produce different product models.

The Model-Driven Engineering (MDE) approach for product line development generally consists of the three main phases as described below in Figure 1:

1. Domain analysis phase: the application domain which covers all derivable products is analyzed. From this analysis, the requirements common to all products are distinguished from the ones that are variable (variation points).

2. System product-line model (PLM) construction phase: according to the requirements extracted from the analysis of application domain, model representing the family of systems is constructed where commonalities and variation points are taken into account.

3. System derivation phase: from the constructed model for family of systems, the model of a given system is derived. In this phase the system designer must fix all variation points (by selecting variable elements in the PLM) to achieve specific system in question.

Figure 1: Generic process of product line development

Sequoia [4-7], developped at CEA LIST, has been used to:

- Express variability in a model: identifying variable elements and expressing relationships among them

- Ensure variation consistency in a same view or among several views

- Derive a system family model by using decision models.

In a real configuration problem context, the problem space is an important element, in fact the decision model cannot be generated because of the huge computation of all configurations.

In order to find solutions, an optimization problem domain has been applied. Now Sequoia uses an algorithm from optimization problem in order to calculate a set of products in a given time. Finally, the view of a global decision model can now be generated and used to obtain a product.

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.