Multi-Platform MDE Workbench Architecture 1 ...

Multi-Platform MDE Workbench Architecture Daniel Exertier, Benoît Langlois, Olivier Cault Thales – Engineering & Process Management {daniel.exertier, benoit.langlois, olivier.cault}@thalesgroup.com Abstract A growing expectation from the users of a Model Driven Engineering (MDE) workbench is to have a unified engineering environment that is oblivious of the specificities of the used modelling tools. This issue is key for large industrial organisations such as Thales, where mastered, proven, robust and stable engineering methods and practices cannot easily and safely rely on commercial modelling tools that continuously emerge, evolve and disappear. This paper addresses the multi-platform MDE workbench architecture solution that gives the workbench the ability to be modelling-tool independent, that is to be able to substitute a modelling tool by another at any time. This achievement is presented through a set of lessons learned we have acquired in terms of development cost evaluation, architecture benefits and drawbacks, implementation main difficulties, constraints on the production chain and impacts on the development team. An insight is finally given of what the extension of the multi-platform workbench architecture to other engineering domains can bring for defining and implementing interoperability at engineering disciplines level instead of tool level and obtaining platformindependent engineering ecosystems.

1. Introduction 1.1. The platform-independent architecture for MDE workbenches Developing a Model Driven Engineering (MDE) workbench with a high Return On Investment (ROI) for an organisation implies that it must provide a unified engineering environment across the development teams as well as high added-value tools that maximise automation of engineering tasks, while being impervious to underlying modelling tools market evolution. These stakes are reached through the definition of a platform independent architecture that abstracts underlying modelling platforms through adaptation and modelling standard usage, e.g. EMF [1], UML2 [9][2]. MDE Workbench API UML Modeler Adapter

PLM Adapter

UML Modeler

PLM platform

UML Modeler Repository

EMF Repository

PLM Repository

Figure 1. MDE Workbench platform-independent architecture

Abstraction is achieved by providing a series of adapters [3], that can be generated using software factories.

1.2. Induced benefits of the multi-platform MDE architecture This architecture and production scheme provide additional multiple benefits for the system/software development industry: • Maintenance: only one MDE workbench to maintain for all modelling platforms; clear separation of concerns; • Robustness: adaptation absorbs weaknesses of the underlying modelling tool; • Migration: model on a platform is read through a standard business API and re-written to another platform through the same API; • Semantic bridging: mapping can be defined at business level and bridges generated on top of standard API; • Evolution and modularity: engineering viewpoints can be integrated on demand at business level together with their dedicated engineering tools; • Economies of scale: new MDE tools are de facto ready for all supported platforms while new supported platforms de facto support all already developed MDE tools.

2. Context Meeting time-to-market expectations for complex software developments in an evolving environment implies new generation of tools and a fitted software development process. The adoption of MDE, with abstraction levels managing traceability from platform-independent models (PIM) down to platform-specific models (PSM) [8] and generated code, allows capitalizing on domain models (e.g., aeronautics) and developing transformations towards technical platforms (e.g., Java on CORBA middleware). However, a major weakness with this approach is that MDE tooling implementation sees business code invaded with low-level underlying modelling tool specific code. To avoid this, we promote two complementary principles. Principle 1. Definition of a two-level architecture: an infrastructure that focuses on technology, wraps modelling tools technical mechanisms (e.g., model storage, versioning) and takes non-functional decisions; and a superstructure that focuses on business. The challenge is to progressively raise the infrastructure level in order to reduce and ease the development of the superstructure. The adoption of Domain-Specific Languages (DSLs) at the superstructure level contributes to this. Principle 2. Automating software development: productivity, flexibility and customisation of large-scale developments implies intelligent software production. Further than code generators, we have developed a software factory tool for industrialising production of software artefacts (e.g., code, documentation, frameworks, tools) from models and meta-models, particularly dedicated to MDE workbench developments.

3. The UML modelling tool adapters example The infrastructure allows modelling tool independence and to focus development efforts only on business, i.e. MDE tooling development. In our implementation, the adaptation layers that unify model management and realise the communication with some specific UML modelling tool are produced automatically using a factory tool. By separating concerns, two adaptation layers are produced: one for adapting the MDE business engineering concepts to the standard UML2 language, and one for adapting the standard UML2 concepts to the target UML modelling tool specific metamodel and API. APIs of engineering concepts and standard UML2 concepts are EMF compliant.

1st Tier: Client

MDE USER INTERFACE (assistance, commands, services)

2nd Tier: Application

MDE APPLICATION (automations, transformations, checks)

EMF MDE API EMF UML2 API 3rd Tier: Platform Abstraction

4th Tier: Repository

MDE Workbench

MDE to UML2 ADAPTER UML2 to Modeler UML ADAPTER

Modeler Utility ADAPTER (UI, Conf. Mgt., etc.)

UML Modeler

Targets: • Objecteering • RSM/RSD/RSA • Rhapsody

UML Modeler Repository

Figure 2. The MDE Workbench architecture for UML platforms

The main development tasks to produce an adapter then consist of developing a dedicated factory, i.e. defining the adapter code generation rules, and modelling the mapping between the concepts of the upper metamodel and the lower metamodel. 3.1. Metamodel mapping A mapping is defined for each adapter, i.e. one between the domain engineering metamodel and the UML2 metamodel, and one between the UML2 metamodel and each targeted UML tool metamodel. Each mapping must be explicit and this for each metaclass, meta-attribute and meta-relationship. There are three possible mappings: 1) concept mapping is direct (see the following figure), 2) concept mapping is indirect and needs a mapping resolution between two metamodels (e.g., there is no UML2 tool meta-class for a standard UML2 meta-class, but some semantic mapping is still possible), 3) concept mapping is semantically impossible and the implementation will need to be manually developed. Engineering domain (MDE business concepts)

UML2 metamodel & UML extensions (UML elements, stereotypes)

This figure exemplifies a mapping where Requirement, an engineering business concept from an engineering domain metamodel, is mapped on the UML2 Class with the “eng.Requirement” stereotype. This mapping is used to specify the “MDE to UML2 Adapter” in the previous figure.

Figure 3. Example of metamodel mapping

3.2. Adapter production factory In order to automate the production of adapters, a factory tool consumes a couple of metamodels (e.g., [engineering domain metamodel, UML2 metamodel], [UML2 metamodel, UML2 tool X metamodel]), a metamodel mapping that specifies the mapping between the two metamodels, and a set of patterns dedicated to the generation of a type of adapter. A pattern provides the factory tool a generic practice aiming at producing target code from information in the input metamodels and metamodel mapping model. The generated adapter code is designed so that it can be extended by manual code if necessary. For model management, an adapter provides at least the CRUD (Create / Read / Update / Delete) operations. Metamodels Metamodel mapping Adapter patterns

Adapter

Factory Tool

Adapter extension Figure 4. Automation of adapter production

4. Lessons learned The paradigm of multi-platform MDE workbench is now proven and implemented, and a number of lessons have been learned from our experience. 4.1. Lessons learned for multi-platform development cost evaluation Defining an architecture preserving platform independence as long as possible in its implementation induces specific choices and strategies. Core rules for multi-platform development 1. At First, it is fundamental to choose the right pivot metamodel, meaning the reference standard or the closest to it, for compliance and durability reasons. For UML2, we selected the Eclipse UML2 metamodel: it is 99% OMG-compliant, it simplifies the OMG UML2 metamodel by reducing redundant classes and it is implemented by existing operational tools. 2. In order to validate the multi-platform architecture, it is better to develop first the simplest adapter, i.e. targeting the tool with best UML2 standard level of compliance. It gives a development and testing reference for the next adapter developments. 3. Mapping between metamodels, i.e. between the engineering domain and UML2 metamodels and between the UML2 and the tool UML2 metamodels, is key. It must be unambiguous and exhaustive. This time-consuming and meticulous analysis task rapidly gives an indication of the further adapter development costs (see below). 4. The testing phase must exhaustively ensure that the tool adapter provides the expected behaviour. Automated testing is mandatory. Evaluating the complexity level and validating the cost of multi-platform development The development cost of a new adapter is mainly determined by the degree of compliance of the tool metamodel with the pivot metamodel. The table below shows the degree of compliance we measured for three (voluntarily unnamed) UML2 tools we experimented, while the following figure depicts the exponential development cost when divergence increases. Above 40% of non-compliance with the standard, the cost of unification through adaptation becomes too high. In such a case, possible decisions are the following:

• • •

Reducing the adaptation scope by eliminating unused metamodel parts or exotic classes / properties / associations; Developing by iterations from the most expected parts; Not supporting the tool. UML2

Classes Attributes Associations

250 100 470

Eclipse-based UML2 tool

UML2 Tool 1

UML2 Tool2

99%

70%

40%

Table 1. Degree of compliance of a tool UML2 metamodel against the pivot UML2 metamodel

On the X-axis, the degree of divergence of a tool metamodel with the pivot metamodel; on the Y-axis, the cost factor for developing a tool adapter. The cost factor is the ratio between the cost for developing a tool adapter and the cost for developing a 100% compliant tool adapter.

200

UML2 tool 2

180 160 140 120 100 80 60 40

UML2 tool 1

Eclipse-based UML2 tool

20 0 0%

2%

5%

10%

20%

30%

40%

50%

Figure 5. Development cost profile according to tool divergence to pivot UML2 metamodel

In addition to the tool divergence to a pivot metamodel, an additional cost factor is introduced by the tool divergence to the chosen reference standard API. For example, the standard way for creating a new model element is to create the model element and append it to a container. However, we had to work with a modelling tool mixing the two services (i.e. providing a create-and-append service). Creation had then to be simulated to give the illusion of a standard model element creation. In order to prevent structuring impacts on projects using a unified API, it is necessary to: • Choose the right pivot syntax and semantics of the multi-platform API. We selected the EMF (Eclipse Modelling Framework) generated API. • Check that every pivot service syntax and semantics of the UML2 to Modeller UML adapter can be implemented using the corresponding service(s) of the modelling tool API. Tool-specific behaviours must also be considered during the design phase, such as notification mechanisms that can differ, undo function that may not be supported or only partially, memory management (e.g., lazy-loading of model, unloading). The main benefits of a multi-platform development are: • Clarification of APIs and separation of concerns: efforts are concentrated either on the development and maintenance of a specific adapters, or on business logic. For example, experts of the platform (e.g. tool vendor consultants) address platform specific issues only in the dedicated adapter. • Automation: ability to produce adapter API and its implementation with a factory tool. • Readability: MDE business layer code becomes more readable because, for example, it is free of UML and UML tool specific code. • Eased Maintenance: large amounts of information are maintained in metamodels, mapping models and generation patterns rather than in code.

•

•

•

Eased development and evolution: it is not necessary to know all the targeted platform technologies to develop a MDE tool. The MDE to UML2 adapter is fully generated, the UML2 to Modeller UML adapter is mainly generated, depending on the tool metamodel and API quality. Some MDE business logic may be generated from metamodels and DSL information at metamodel level. Cost effective support of a new UML modelling tool candidate: only the UML2 to Modeller UML adapter needs to be generated/developed, the MDE business logic and adapter to UML2 being de facto reused as they are. Common pattern (reusable practices) between adapters can be elicited. Use of innovative technologies: they attract motivated and gifted engineers.

The main drawbacks of a multi-platform development are: • The multi-platform MDE paradigm has a cost: choice of pivot metamodel, evaluation of the complexity to develop an adapter, definition of the production chain. The first adapter development is expensive. • Scalable adapter factories are needed: factories producing adapters must support large metamodels (a set of 1,000 meta-classes becomes very common for large-scale workbenches). This supposes tools supporting 1) large and complex mapping metamodel (bidirectional mapping; n to m model elements mapping), and 2) numerous and complex patterns (several hundreds). Performance is a redhibitory criteria (time for building a new adapter must be less than 15-20 minutes). User-friendly interfaces should be provided to ease the development of these technically complex factories. • While some UML tools have a precise and public metamodel, others do not have: the major risk is to deduce an inconsistent or incomplete metamodel from observation. • Managing complexity of adapters: the more a tool diverges from the pivot metamodel and API, the more complex is the adapter and expertise needed. • Performance monitoring is required: benchmarking and tuning must be performed to ensure that the multi-adapter architecture impact on MDE commands performance is acceptable. 4.2. Lessons learned from the infrastructure & superstructure separation Principle 1 enacts a separation between technology aspects and business aspects into an infrastructure and a superstructure, clearly separating two kinds of development activities for MDE workbenches. But, taking benefit of the MDE principles themselves, one can provide in the infrastructure much more than pure technical logic, that is to say some business logic that can be technically produced from information modelled at the metamodel level, lessening the effort required for superstructure development. The MDE workbench infrastructure consists of: • Multi-platform model management, • Non-functional services management (e.g., versioning, transaction), • Services of the MDE Application layer that can be automatically deduced from the metamodel and information modelled at the metamodel level (e.g. model checking, standard diagram generation and update), • Basic components providing factorised services, frameworks and tools to meet recurrent needs of the MDE Application layer (e.g., reporting, utilities) and the MDE User Interface layer (e.g., a framework for Human-Machine Interaction – HMI). As a consequence, the MDE workbench infrastructure is transversal to the multi-tier architecture presented in Figure 2, providing the whole Platform Abstraction tier, as well as parts of Application and Client tiers. Its role is to provide any MDE workbench or tool a backbone. And in fact not only a backbone, but a whole skeleton with some organs and flesh.

The MDE workbench superstructure is business-centred and consists of: • The MDE Application and MDE User Interface components, • Tools that extends the infrastructure in order to realize a specific MDE workbench (e.g. model information transformation and refinement, modelling assistance and orchestration, interoperability services). As a consequence, the MDE workbench superstructure implements the engineering method processes and rules. For example, a user command that is provided only in certain engineering phases activates a modelling service that automatically performs a sequence of model transformations of the superstructure level that rely themselves on model management services implemented at the infrastructure level. Benefits gained from the infrastructure / superstructure separation are: • Abstraction: o The infrastructure encapsulates technology and tools as much as possible. o The encapsulation allows to iteratively provide additional non-functional aspects in the infrastructure. o Superstructure designers and developers can concentrate only on business developments. o Most of the infrastructure can be generated, reducing maintenance cost, especially when metamodels or architectural decisions evolve. o Abstraction level can be raised by automatically producing more and more infrastructure parts from the information modelled at the metamodel level. • Separation of concerns: o The infrastructure separates concerns (e.g. model management, model check) and provides clearly separated sets of services. o Infrastructure separation of concerns eases the superstructure separation of concerns (e.g. model information transformation and refinement, modelling orchestration), facilitating collaborative work with low overlap. • Reusability and adaptability: o High value infrastructure services can be customized by extension. • Definition of an architectural style: o The infrastructure provides a framework to the superstructure, either for manual and automated developments. o The infrastructure de facto sets architectural principles for superstructure development, avoiding the architecture erosion effect. o Designers and developers are guided in their development activities. • Definition of MDE workbench families: o An infrastructure defines the common part of a series of workbenches, with its architectural style and ergonomics charter. Drawbacks of the infrastructure / superstructure separation are: • Platform Abstraction tier becomes the bottleneck of the developments activities: a smart iterative development process must be defined. • The infrastructure must be stable early in the development process: all superstructure developments depend on it and any infrastructure modification impact on manual development is costly. • Adapting to platform-dependent ergonomics is expensive: user interfaces and model rendering (e.g., model diagrams, model query visualisation, reports), i.e. the ergonomic aspects, are usually highly tool specific and abstracting them may be very complex. 4.3. Lessons learned from the multi-platform engineering paradigm In fact, multi-platform model management is only a specific issue for a multi-platform MDE workbench that must also address model viewing, model transformation, user

interaction, etc., in a durable way. Considering the model viewing aspect for instance, diagram manipulations also require a unified dedicated API, as all modelling tools have different proprietary interfaces. This is also the case for model transformation because several model transformation engines exist. For any homogeneous category of problems, the issue is to find a unified representation able to be supported by heterogeneous platform solutions. To cope with this, two complementary techniques are adopted: • Technique 1. Development of adapters. As for the UML2 adapters described before, an optimal pivot metamodel and API unifies each category of processing (e.g., model transformation, diagram management, documentation, HMI) over tool or proprietary solutions, and a dedicated adapter is developed for each target platform. • Technique 2. DSL-driven development at metamodel level. A DSL (Domain-Specific Language) is a specialized language, which serves to accurately describe a domain of knowledge, and, combined to a transformation function, raises the abstraction level of software and eases software development [6]. A DSL editor edits a DSL description, for instance for editing diagram specifications, model transformations or documentation descriptions, all this at metamodel level. A generator, using platform-specific generation rules, then transforms the DSL description into a target form (e.g., textual / graphical /tabular… notations, model, framework, tool). But using these techniques does not diminish the fact that a MDE workbench depends on heterogeneous engineering domains, each with its own language, practices, conventions and tools. For instance, UML2 has its own metamodel, representation, best practices, and modelling tools; performance analysis of system or software have its own engineering methods and environments; documentation needs a documentation metamodel, different sets of documentation generation rules description to target different documentation formats, etc. The stake is then to develop a workbench architecture allowing collaboration of engineering domains. For targeting durable developments of workbenches, constant concerns are: • Enacting and applying workbench architectural principles; • Selecting durable pivot metamodels and making engineering domains collaborate; • Maintaining workbench consistency while integrating new engineering domains, by maintaining consistency or compliance of metamodels / frameworks / tool versions; • Developing by iterations: validating the main structure of the workbench and refactoring engineering domains when necessary. 4.4. Lessons learned for tooling Principle 2 enacts automation of software production for improving software productivity, quality, flexibility and addressing large-scale developments. In order to also face complexity and scalability of adapters and DSLs, it has become mandatory to industrialize workbench production. For this reason, we have developed a software factory tool [5] , as defined in [4], to manage DSLs, automate and tailor the production of software for the MDE workbench. This factory, developed on Eclipse, is in fact a MDE workbench for defining and producing (multi-platform) MDE workbenches. 4.5. Lessons learned for the development team Multi-platform MDE workbench development introduces new practices and responsibilities for the development team, as presented in the following table, implying that the learning curve for each one of them must be managed. We can notice that developments by technical/engineering domains leads to better partition responsibilities among the team, which has its advantages, e.g. creation of experts on technical/engineering domains, separation of concerns easing the definition of

development activities and work breakdown (for sub-contracting tasks to off-shore development teams for example), and its drawbacks, e.g. creation of development silos. A CTOR Architect

Designer

Developer

SPECIFIC RESPONSIBILITIES • Selects pivot metamodels • Evaluates and validates complexity and risks of an adapter development • Defines the workbench architecture: infrastructure/superstructure foundations, relationships between tools, frameworks, DSLs, generators • Defines the complete production chain of the workbench • Specifies precisely the mapping between metamodels • Specifies the DSLs and generators • Specifies the infrastructure • Specifies the superstructure and the infrastructure extensions • Specifies inter-engineering-domain bridges • Realizes the DSL editors • Realizes the generators, i.e. the generation patterns, for each adapter and DSL, which cover the infra and superstructure layers • Realizes the superstructure and the infrastructure extensions • Realizes inter-engineering-domain bridges

Table 2. New responsibilities for the multi-platform MDE workbench development team

5. Towards platform-independent engineering ecosystems Engineering a software or a system encompasses other disciplines and tools, having their own target tools, such as requirements management, configuration management, change management, documentation management, etc., as well as safety engineering, performance engineering, messaging engineering, etc. By applying the same approach for the engineering disciplines and integrating them at business level (i.e. avoiding expensive and hard-to-maintain combinations of peer-to-peer technical bridges), fully integrated and collaborating workbenches can be obtained, going towards engineering ecosystems.

Engineering Ecosystem Req. Mgt. Services

Requirements Engineering Env.

MDE Services

MDE Workbench

Req. Adapter 1

Req. Adapter 2

UML Adapter 1

UML Adapter 2

Req. Mgt Tool 1

Req. Mgt Tool 2

UML Modeler 1

UML Modeler 2

Change Mgt. Services

Conf. Mgt. Services

Ch. Mgt. Adapter 1

Conf Mgt. Adapter 1

Conf Mgt. Adapter 2

Conf Mgt. Adapter 3

Change Mgt Tool 1

Conf Mgt. Tool 1

Conf Mgt. Tool 2

Conf Mgt. Tool 3

…

Figure 6. Platform-independent engineering eco-system example

Platform-independent engineering ecosystems allow high value unified organisationdedicated engineering logic to be implemented on top of interoperable engineering discipline services supported by substitutable COTS (Component Off The Shelf) tools.

6. Conclusion Multi-platform MDE workbench is an industrial operational concern, particularly for large-scale projects that must capitalize on durable and reusable development environments. We have illustrated the multi-platform principle for a MDE workbench targeting UML2 modelling tools and have generalised it. The objective is to build a complete MDE multi-platform workbench and then, given the benefits gained from this first experience, apply the architectural principles to non-MDE workbenches, i.e. for each single engineering discipline supported by some dedicated tools, and also recursively to the integrated engineering environment itself, making the engineering disciplines collaborate whatever the underlying tools are. Obtaining these unified multi-platform engineering ecosystems can be achieved progressively and iteratively. It has certainly a cost, but because it unifies engineering activities and environments across an organisation and over time, a high return of investment is expected.

References [1] Eclipse Modeling Project, http://www.eclipse.org/modeling/ [2] Eclipse, UML2, http://www.eclipse.org/modeling/mdt/?project=uml2#uml2 [3] E. Gamma, R. Helm, R. Johnson, J. Vlissides. Design Patterns: Elements of Reusable Object-Oriented Software, Addison Wesley, January 1995 [4] Greenfield, J., Short, K., Cook, S., and Kent, S., Software Factories, Assembling applications with Patterns, Models, Framework, and Tools, Wiley, 2004. [5] Langlois, B., Exertier, D., MDSoFa: a Model-Driven Software Factory, OOPSLA 2004, MDSD Workshop. [6] Langlois, B., Jitia, C.E., Jouenne, E., DSL Classification, Proceeding of the 6th OOPSLA Workshop on DomainSpecific Modeling. [7] Sảnchez-Ruỉz, A., Saeki, M., Langlois, B., Paiano, R., Domain-Specific Software Development Terminology : Do we All Speak the Same Language?, Proceeding of the 6th OOPSLA Workshop on Domain-Specific Modeling. [8] OMG, MDA Guide Version 1.0, omg/2003-05-01, 1st May 2003. [9] OMG, Unified Modeling Language: Superstructure, version 2.1.1, formal/2007-02-05.