Eclipse Sphinx

Scope

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

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.

Releases
Name Date
0.13.1 2022-09-30
0.13.0 2022-06-06
0.12.0 2021-12-01
0.11.2 2021-08-25
0.11.0 2017-06-28
0.10.1 2016-09-28
0.10.0 2016-06-22
0.9.2 2016-02-26
0.9.1 2015-09-25
0.9.0 2015-06-24
0.8.1 2014-09-26
0.8.0 2014-06-25
0.7.0 2013-06-26