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.
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.
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:
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.
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).
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:
The initial committers for this project are:
The following individuals, organizations, companies, and projects have expressed interest in this project:
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 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 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.
|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
(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)|
|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|
Back to the top