Sphinx

The project has been created.

Introduction

Sphinx is a proposed new open source project under the Eclipse Model Development Tools (MDT) subproject to provide an extensible platform that eases the creation of integrated modeling tool environments supporting individual or multiple modeling languages (which can be UML-based or native DSLs) and has a particular focus on industrial strength and interoperability.

This project is in the Proposal Phase (as defined in the Eclipse Development Process) and this document is written to declare its intent and scope. This proposal is written to solicit additional participation and input from the Eclipse community. You are invited to comment and/or join in the development of the project. Please send all feedback to the eclipse.modeling.mdt forum.

Background

Model-based design (MBD) and Model Driven Software Development (MDSD) have become very popular and are increasingly used in software and systems development. They were introduced in the IT industry first, leading to the definition of Unified Modeling Language (UML). Subsequently, they penetrated vertical domains and were applied to embedded software and systems development. Being a generic modeling language, UML needs to be extended/specialized to fit into these specific domains. For that purpose, there are mainly two alternatives which are usually called the heavy-weight and the light-weight approach. The former involves the definition of Domain-Specific Languages (DSL), i.e., full meta-models which are implemented independently of UML, while the latter leads to the definition of UML extensions/specializations using the profile concept. From an end user perspective, both approaches eventually yield the same result that is to say a dedicated modeling language for a specific domain or/and for some particular concerns. SysML (Systems Modeling Language), and MARTE (Modeling and Analysis of Real-Time and Embedded systems) are two of the most important standardized UML profiles. There are destined to adapt UML to systems engineering and the real-time and embedded domain respectively. Examples of "native" DSLs are AUTOSAR (AUTomotive Open System ARchitecture) which is an industry standard in the automotive domain, and the AADL (Architecture Analysis & Design Language) standard which has its origins in the avionics industry.

While offering significant advantages from a conceptual point of view, MBD and MDSD still suffer from a major shortcoming: there is no satisfying out-of-the-box tool support. Tools for UML often don't provide sufficient support for profiles and tools for DSLs offer most of the time a rather poor user experience and/or are not yet very mature. It has therefore become a common practice that organizations intending to use MBD and MDSD either develop their own modeling tools or make substantial customizations of existing ones in order to obtain appropriate tool support for the modeling languages they want to rely on.

The Eclipse ecosystem at large and the Eclipse Modeling Project (EMP) in particular provide many useful frameworks and building blocks for creating such tool support and are therefore a great deal of help in this context. However, experience has shown that the matter of creating an integrated modeling tool environment for a given modeling language means much more than just putting existing Eclipse components together. What is still missing is some sort of "umbrella" framework which provides the necessary glue and guarantees that Eclipse components can be consistently integrated in higher level modeling tool environments. As a result, all effort related to this part needs to be spent repeatedly in every modeling tool development project and makes that the latter frequently become major endeavors demanding considerable investment. This is especially true when modeling tools are required to handle large models. A dreaded amount of effort goes into investigating and optimizing the interplay of involved Eclipse components and making sure that user expectations in terms of scalability and robustness are met.

Another challenge is that modeling tools are rarely used in isolated contexts. The question is much more about how to support to complete model-based/model-driven development processes which may consist of various stages and may involve different modeling languages at each state. Until now, there is simply no guarantee that Eclipse-based modeling tools from different vendors can effectively work together and be complemented by special purpose in-house modeling tools. Setting up integrated tool environments which smoothly support the modeling languages required by a given development process and link and synchronize them with each other therefore remains a largely unresolved issue.

Scope

Sphinx is a project providing a modeling tool platform for Eclipse that eases the development of IDE-like tool support for modeling languages used in software and systems development.

The objectives of the Sphinx project are:

  • /O1/ To provide an open and extensible platform enabling rapid creation of integrated modeling tool environments (IME) for individual or multiple modeling languages;
  • /O2/ To ensure that the resulting modeling tool support yields industrial strength scalability and robustness out-of-the box;
  • /O3/ To support a domain- and vendor-independent interoperability layer (backbone) for off-the-shelf and in-house modeling tool components supporting the same or different modeling languages which users can easily combine to create individually tailored continuous modeling tool chains;
  • /O4/ To support controlled and coordinated management either of individual modeling tool components (e.g., update, upgrade, addition, removal, activation, deactivation, etc.) or of entire modeling tool chains (e.g., coordinated switchover to new versions of multiple mutually-coupled modeling tool components, reverting to old modeling tool chain configurations in case of problems or when needing to work on retired projects).

Sphinx does not aim at providing finished integrated modeling tool environments for any specific modeling language. Instead, it will be focused on common infrastructure that is typically required when developing such tool environments. This infrastructure will all the same be of strictly generic nature and in no way depend on the modeling language(s) to be supported.

It is also important to note that the intention of Sphinx is not to reinvent or replace any existing parts of Eclipse, in particular the various components of the Eclipse Modeling Project (EMP). Sphinx will rather leverage many of those and build upon them. The mission will be to provide the glue and additional things that are necessary to orchestrate these components in a consistent manner and to realize accustomed integrated tool environments supporting one or several modeling languages at reasonable effort and cost.

A good part of the ideas and code contributions behind this modeling tool platform descend from the research project EDONA funded by the French government.

Description

Initial components

Sphinx will initially define APIs and provide implementations for the services described in the following. Components realizing these services already exist and will be contributed along with the creation of this project (see Code contributions).

  • Workspace Management: This component is built on EMF, EMF Transaction, and Eclipse Platform. It provides services for managing the lifecycle and editing domains of model instances that need to be centrally provided and shared in the workspace of Sphinx-based modeling tool applications. Included features are:
    • Mapping of workspace resources to editing domains;
    • Thread-safe loading, reloading, and unloading of shared model instances;
    • Management of dirty state and thread-safe saving of shared model instances;
    • Automatic synchronization of shared model instances with changes on workspace resources.
  • Navigator View and Editor Sockets: This component is built on EMF, EMF Transaction, Eclipse Common Navigator Framework, Eclipse UI Forms, and GMF (later on also Graphiti, see Future components). It provides common logic for creating explorer views, form editors, and graphical editors operating on shared model instances in Sphinx-based modeling tool applications. Included features are:
    • Thread-safe operation on shared model instances in the workspace rather than on individually loaded resources;
    • Dirty state indication (asterisk on view/editor tab) and save button enablement according to dirty state of underlying shared model instance;
    • View/editor-relative undo/redo context management for operations on model elements and workspace resources;
    • Model-oriented editor behavior, i.e., rather than always having to open a complete resource containing model elements in an editor, editors can be opened on individual model elements coming from the same or different resource;
    • "Link with Editor" capability, "Show In" capability, drag & drop, and view state saving and restoration for model elements in explorer views;
    • Advanced filter capabilities for model elements, Properties view content , and palettes in graphical editors;
    • Advanced graphical editor support (multi-editor and multi-diagram support, palette customization, preferences);
    • Support for creating links between model elements from different modeling languages.
  • Validation Runtime Extensions: This component is built on EMF, EMF Transaction, EMF Validation, and Eclipse Platform. It provides extended runtime-level services for validating models or model fragments in Sphinx-based modeling tool applications and visualizing validation results. Included features are:
    • Manual (on-demand) and automatic (on-the-fly) validation;
    • Validation problem marker management;
    • Model-oriented Validation view (alias Problems view);
    • Validation label decorator for model explorer view.
  • Compare & Merge Integration: This component is built on EMF, EMF Transaction, EMF Compare, and Eclipse Compare Support. It provides extensions enabling model-based compare/merge operations to be carried out on shared model instances in Sphinx-based modeling tool applications. Included features are:
    • Thread-safe operation on shared model instances in the workspace rather than on individually loaded resources;
    • Thread-safe automatic merge operations;
    • Comparison/merge of individual model elements or fragments (instead of complete resources only);
    • Model-oriented dirty state management and editor-relative undo/redo contexts.
  • EMF Runtime & Eclipse Platform Extensions: This component is built on EMF, EMF Transaction, and Eclipse Platform. It provides common runtime-level enhancements such as description of meta-models, description of shared model instances including their scopes, meta-model compatibility services, as well as a couple of performance optimizations and utilities. They are used by all other Sphinx platform components and are also available to Sphinx-based modeling tool applications.

Future components

The components that have been realized so far provide only a small subset of services which are essential for building integrated modeling tool environments. Much other functionality is necessary and useful and will be added to Sphinx later on. Potential future Sphinx components include but are not limited to:

  • Model query and indexing service for significantly improving performance and memory consumption based on EMF Query 2;
  • Model repository and database persistence support based on CDO and MFT;
  • Connector for documentation and report generation with BIRT;
  • Socket for Xtext-based textual editors and Graphiti-based graphical editors supporting thread-safe operation on shared model instances in the workspace, model-oriented dirty state management, and editor-relative undo/redo contexts;
  • Code generation interfaces supporting existing M2T languages and runtimes (e.g., Xpand, MTL, JET);
  • Model to model transformation interfaces supporting existing M2M languages and runtimes (e.g., Xtend, QVT, ATL);
  • Model search & replace using EMF Search;
  • Model variant handling services using EMF Feature Model;
  • Task focused modeling through integration with Mylyn;
  • Dedicated communication facilities to enable effective collaboration on modeling tasks in distributed teams (e.g. by using Google Wave protocol from ECF);
  • Build system supporting mixed model-based and file-based processing (e.g., model validation, code generation, code compilation) and performing incremental, full, or continuous builds (could possibly use parts of B3).

Relationship with other Eclipse Projects

  • Sphinx will be built on top of the Eclipse Platform and EMF.
  • Sphinx will also use complementary components of the Eclipse Modeling Project (EMP). EMF Transaction, EMF Validation, EMF Compare, and GMF will be needed immediately. Others like EMF Query 2, CDO, BIRT, Xtext, Graphiti, parts of M2T and M2M, EMF Search, MTF, EMF Feature Model, etc. are likely to be required later on.
  • Sphinx will integrate services, examples and ideas from the backbone of Papyrus. The latter already has a service-oriented architecture and will provide an important set of contributions to the Navigator View and Editor Sockets component of Sphinx (see Initial components for details).
  • In order to enable smooth integration of modeling tools created with Sphinx with complementary non-modeling tools used in software and systems development, Sphinx will make use of related Eclipse projects and components where applicable. For example, CDT could be leveraged for linking modeling with implementation by enabling navigation, validation, quick fixing, auto completion, etc. across the two. Other candidate projects are JDT, Mylyn, ECF, and B3.
  • Sphinx will make contributions to the Eclipse projects and components it is using as appropriate. Such contributions may consist of bug fixes, performance optimizations, API extensions, or utility enhancements.
  • Sphinx has conceptual kind of relationships to the IDE Meta-tooling Platform (IMP) and Tigerstripe projects:
    • Since its beginnings, Eclipse has been shipped with rich integrated tool support (IDEs) for various programming languages. IMP is a project providing building blocks which are necessary to create additional IDEs for programming languages that are not yet supported under Eclipse. Introducing a similar kind of meta-tooling platform for modeling languages, the Sphinx project represents a perfect analog to IMP for the modeling world.
    • Tigerstripe is a set extensible set of modeling tools targeting the telecommunications vertical domain. It encompasses an implementation and graphical editing support for a DSL derived from UML2 which is dedicated to model-based design of communication systems. It also supports model-driven development through extensible generation of application code, APIs, specifications or documentation. Tigerstripe therefore represents an example of a concrete modeling tool environment for which Sphinx could provide the meta-tooling. Even if this does not become the case in practice, it could still make sense to investigate if the two projects could benefit from each other.

Organization

Mentors

Proposed initial committers

The initial committers for this project are:

  • Stephan Eberle (Geensys, France), lead
  • Sébastien Gérard (CEA LIST, France), lead
  • Ali Akar (Geensys, France)
  • Yannick Didierjean (Geensys, France)
  • Romain Sezestre (Geensys, France)
  • Dao Hoang (GATe Technolgy, subsidiary of Geensys in Vietnam), testing
  • Paul Hoser (BMW Car IT, Germany)
  • Christian Knüchel (BMW Car IT, Germany), release engineering
  • Kenn Hussey (Independent, Canada)
  • Yann Tanguy (CEA LIST, France)
  • Cédric Dumoulin (Lifl, France)
  • Thibault Landre (Atos Origin, France)

Interested parties

The following individuals, organizations, companies, and projects have expressed interest in this project:

Code contributions

The initial code contribution will come from both the Artop and the Papyrus project. Both projects benefit from the research project EDONA which is funded by the French government and contributes a part of its results to Artop and Papyrus.

Artop

Artop is based on Eclipse and provides common base functionality for creating modeling tools supporting the AUTOSAR standard. AUTOSAR is a design standard from the automotive industry focusing on the system architecture of control software for road vehicles, its deployment to networked ECU (Electronic Control Unit) devices in vehicles, and the configuration of the basic software in such ECUs.

Artop essentially encompasses implementations of the different releases of the AUTOSAR meta-model (alias DSL) plus a rich set of services and components for managing and processing AUTOSAR models. A particular characteristic of Artop is the capability of handling relatively large AUTOSAR models in an efficient way. Artop therefore corresponds in almost all aspects to what is intended to be done in the Sphinx project. The only conceptional difference is that Artop is still dedicated to one specific design standard and DSL (namely AUTOSAR) in one specific vertical domain (namely automotive). Another limitation is that Artop could not be made available under Eclipse Public License (EPL) because it contains material which is protected by AUTOSAR IP regulations and must be kept accessible to AUTOSAR members and partners only.

Sphinx can therefore be seen as a generalization of the Artop idea aiming at a modeling tool platform for arbitrary design standards and modeling languages in arbitrary vertical domains being available under EPL. Thanks to the architecture of Artop, this can be achieved quite quickly: An important portion of the services and components in Artop has been realized in a generic way and is located in a separate layer (Eclipse Complementary Layer, ECL). It has no dependencies to the other AUTOSAR-specific layer of the platform (Artop AUTOSAR Layer, AAL) which contains the AUTOSAR meta-model implementations plus some related services and is subject to AUTOSAR IP regulations. The idea therefore is to move the complete ECL layer from Artop to Sphinx and provide mature initial implementations for the components proposed above right away.

Papyrus

Papyrus is a component of the Model Development Tools (MDT) subproject aiming at providing an integrated, user-consumable environment for editing any kind of EMF model and particularly supporting UML and related modeling languages such as SysML and MARTE. Papyrus provides diagram editors for EMF-based modeling languages amongst them UML 2 and SysML and the glue required for integrating these editors (GMF-based or not) with other MBD and MDSD tools. It also offers a very advanced support of UML profiles that enables users to define editors for DSLs based on the UML 2 standard and its extension mechanisms. The main feature of Papyrus regarding this latter point is a set of very powerful customization mechanisms which can be leveraged to create user-defined Papyrus perspectives and give it the same look and feel as a native DSL editor.

Papyrus consists of a set of plug-ins which are based on the Papyrus core plug-in. This latter allows "nested editors" to be plugged in which may be based on different technologies (e.g., GEF, GMF). Papyrus core also supports multi-editor views (called sash windows) in which nested editors can be arranged side by side in tabs. The Papyrus core is designed to be open. It easily enables new nested editors to be added and transversal services to be made available to all nested editors. All model management facilities (e.g., loading, saving, synchronizing) are expected to be provided by external services. The main advantage of this architecture is its flexibility: it is possible to use the same nested editors in conjunction with different external services according to the usage context of Papyrus. Finally, another main point of Papyrus is that all nested editors share the same set of resources.

The possible main contribution of Papyrus to Sphinx will be its core plug-in (including its capability of connecting editors to external services, its sash window support, preferences support, filtering facilities and its model explorer). This way, Sphinx can benefit from a set of services that are already used to support UML editors and graphical editors for any other EMF-based modeling language.

Tentative Plan

Feb 2010: Proposal published and announced to Eclipse membership
Apr/Mai 2010: Initial code contribution from Artop and Papyrus project
Mai 2010: Start of architecture reconciliation between Artop ECL and Papyrus backbone
Sep 2010: First release of Artop and Papyrus based on Sphinx initial contribution
(and retirement of ECL layer at Artop and Backbone in Papyrus)
Oct 2010 - Feb 2011: Completion of architecture reconciliation between Artop ECL and Papyrus backbone,
Implementation of architectural and behavioral improvements,
Migration of Artop and Papyrus to consolidated Sphinx platform
Jun 2011: First release of Sphinx (a part of simultaneous release train)

Changes to this Document

Date Change
10-Mar-2010 Text modifications requested by the Papyrus project. Quotation of French research project EDONA which Sphinx is benefiting from in terms of funding. Updated Tentative plan Added two new interested parties: Bosch and OpenSynergy