A brief overview of relevant OMG specifications and Eclipse projects.

Using the OMG Structured Metrics Metamodel and MoDisco to Facilitate the Eclipse Development Process
Hugo Bruneliere, R&D Engineer, AtlanMod Team (INRIA & EMN)
Frederic Madiot, Mia-Software
Jordi Cabot, AtlanMod Team (INRIA & EMN)

Many OMG standards play a key role as core components of Eclipse-based tools. Here, we explore an additional collaboration relationship between Eclipse and the OMG: using OMG standards to improve the actual Eclipse tool development process. In particular, we will describe how the current Structured Metrics Metamodel (SMM) implementation in MoDisco can help developers of new Eclipse projects to comply with the requirements stated by the Eclipse development process for Simultaneous Releases, such as Helios.

Eclipse Reusable Modeling Assets
Miguel A. de Miguel, Professor, Universidad Politecnica de Madrid

MDA Tool Component (MDATC) is work in progress in the Analysis and Design Task Force at the OMG. MDATC looks for solutions for the integration of different OMG modeling standards (e.g. QVT, MOF2Text, MOF, RAS and UML). MDATC support will unify tool tailoring techniques, by providing a common tailoring and packaging unit. When the notion of MDA Tool Component is standardized, the connection between MDA Tool Components and their host tools will be uniformly defined, thus allowing the customer to consider his MDATC as tool-independent assets supporting his MDA specific approach.

The Eclipse Reusable Modeling Asset (ERMA) framework is an implementation of the MDATC reviewed submission for the Eclipse Modeling Tools package. ERMA includes; ERMA modeling language and editors; the ERMA RAS Profile; ERMA RAS Repository; ERMA services and ERM runtime libraries.

A Metamodeling Approach for Integrating OWL2 and SysML
Nicolas Rouquette, Principal Computer Scientist, Jet Propulsion Lab

At JPL, our strategic roadmap for model-based systems engineering involves a semantic integration between ontologies of systems engineering such as JPL's State Analysis methodology. Since parametric characterizations of system state and behavior are an important part of systems engineering, it is essential that the meaning of parameter-rich systems engineering models remains invariant over their representation in the languages involved. Whereas SysML is the obvious language of choice for representing descriptions of systems, other specialized languages are better suited than SysML for particular tasks. The general modeling challenge is one of bridging the semantic gap between languages specialized for different but related purposes. Since it is unlikely that a single modeling language will adequately address all of the systems engineering needs, it is therefore imperative that we provide mechanisms to integrate languages that have enough descriptive overlap so that language-specific representations of same thing can be semantically related to one another and their unity and integrity verified whenever these representations change.

At Eclipse, the Model-To-Model (M2M), Model-To-Text (M2T) and Generative Modeling Tools (GMT) projects provide many options for language integration using different kinds of transformation techniques. The technologies differ share a common trait as establishing a syntactic correspondence between a patterns in a source model and a patterns in target model. This leads to a sensible suggestion to a syntactic integration between the modeling stack based on MOF with the semantic web stack based on RDF. In this presentation, we will show using OWL2 and SysML why such a syntactic mapping is an open invitation to semantic confusion due in a significant part on insufficient rigor in ontology or metamodel development and propose a approach to clear up this semantic fog.

Generating Specification Documents from Models Using BIRT
Maged Elaasar, IBM

The current process of producing OMG specifications, which typically document relevant normative models, is very tedious and error prone. This is mainly due to the manual effort involved in editing the documents, keeping them in sync with the models and maintaining a consistent style. A good percentage of issues logged against OMG specifications can be classified as consistency related and thus addressing this problem alone promises tremendous gains in the quality of the specifications and the productivity of the task forces looking after them. Fortunately, tools exist that can help with producing documents from structured models. Eclipse’s Business Intelligence and Reporting Tools (BIRT) is one such tool. Using BIRT, one can visually create a specification document template that is linked to an MOF (EMF)-based model data source. The template would extract relevant data from models, like abstract syntax details, documentation and diagrams and format them in the expected way. Since most normative models at OMG are created using UML tools (e.g. RSM), a special UML profile can be designed and applied to the models to help structure them for processing by the template. This presentation describes an initial attempt at designing such a template using BIRT and reports on the successes and challenges faced so far. The template is being used to produce the Diagram Definition revised submission document.

Papyrus, the Eclipse Solution for Modeling and Profiling with UML2
Arnaud Cuccuru, Senior Researcher, CEA LIST

A number of tools supporting UML are available from a variety of sources. However, these are generally proprietary solutions whose capabilities and market availability are controlled by their respective vendors. This can be problematic for industrial users, who may require highly-specific tool capabilities as well as long-term support which, from a vendor perspective, often extend beyond the point of commercial viability. Consequently, some industrial enterprises are seeking open-source solutions for their UML tools. Eclipse may be the most important open-source modelling initiative, gathering in its modelling project a complete set of tools dedicated to support model-based development. Papyrus is the Eclipse open-source project for graphically editing UML2 models. It offers very advanced support of UML profiles that enables users to define editors for DSMLs (Domain Specific Modeling Languages) 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 gives it the same look and feel as a native DSL editor. This presentation will firstly to show the capability of Papyrus in terms of denoting UML2 models. Secondly, we will explain and demonstrate how far Papyrus can support DSMLs using the UML2 profile concept and a very advanced set of configuration possibilities. We then illustrate the demonstration on two representative examples of UML2 profile, MARTE and SysML.

Programming in UML: Why and How
Ed Seidewitz, VP MDA Services, Model Driven Solutions

UML is now ubiquitous in the software industry for diagramming requirements and design. This provides a powerful common language for describing software both within and across development teams. However, once significant coding has begun, there often begins to be resistance to continuing to model, due to the difficulty of constantly keeping detailed models and code in sync. However, if UML models could provide a behaviorally complete representation of a software system, 100% of the system could be generated from the models. In effect, one would then be programming in UML. Indeed, the UML models would themselves become the "source code" at a higher level of abstraction, and the code generated from them would be the equivalent of the machine code (or VM bytecode) generated from today’s programming languages.

This presentation will discuss why it makes sense to program in UML, and why this is entirely complementary with continued use of UML models for requirements and architectural design. It will also describe how the concept of executable UML models is now being supported by some important OMG standards, including the recent Semantics of a Foundational Subset for Executable UML Models specification (which provides the basis for an effective virtual machine for UML model execution) and the currently in-progress work on a standard UML action language (which solves the difficulties of using graphical representation for detailed behavioral programming).

Ultimately, programmers using UML will need an Integrated Modeling Environment and related frameworks and libraries that are as rich (or richer!) in their support of development, testing, debugging and deployment as modern IDEs such as Eclipse are for traditional programming. And, with this, we may finally achieve the goal of a true "next generation" of higher-level programming in UML.

UML Eclipse Framework for Target Level Tools
Dominique Toupin, Developer Tool Manager, Ericsson

Source code level tools provide a rich set of features for debug, trace, unit testing, code coverage, profiling, static analysis, etc. Compared to source code tools, today’s UML-level tools have a very small subset of features. Looking specifically at debugging, UML-level debug features available today are at roughly the same level of sophistication as the source-code debuggers of the late 1970s. The use of UML Action Language (UAL) is aggravating these problems; if developers use UAL instead of C, C++ or Java, they lose access to those languages’ sophisticated debug/trace tools. Debugging UML with 30 years old debug features is hard to sell to software developers. They need features like reversible debug, post mortem, tracepoint, UAL stack examination, altering execution, UAL expressions, watchpoint, gobal breakpoint, etc.
This session will describe some desirable debug and trace features at the UML/UAL level, describe where a UML/UAL specification on mapping format would be useful for the instrumentation of model level elements. The last part of the presentation will hint at how Eclipse modeling tools, GNU debug/trace tools and a Linux target can be put together to create a reference implementation.

BPMN2 OMG Collaboration
Antoine Toulme, Intalio, Inc.
Gary Brown, Red Hat, Inc.
Tammo Van Lessen, Intalio, Inc.

BPMN stands for Business Process Model Notation and its version 2.0 is currently being standardized by all major industry players within the OMG. The most notable improvement made in version 2.0 is the definition of unambiguous execution semantics and a sound metamodel, which offers cross-vendor diagram interchange and interoperability for the first time. The BPMN2 component of the Model Development Tools project at Eclipse aims at implementing the BPMN 2.0 metamodel defined by the normative XML schema delivered by the BPMN 2.0 Finalization Task Force. In this paper, we will describe in detail the work started by the project, based on the Eclipse Modeling Framework. We will discuss the merits of an open source reference implementation for vendors and the OMG. We will discuss challenges encountered from the legal and workflow standpoint. We will provide recommendations for an effective collaboration between the specification committee and the open source community attempting to implement its reference implementation.

When a de Facto Standard Could Become a Reference Implementation
Etienne Juliot, Vice President, Obeo
Laurent Goubet, Obeo

The Acceleo project is an OpenSource project created in 2006 aimed at providing an easy-to-use tooling for code generation through the MDA approach. Acceleo 2.x is already a community driven project with a public repository, a website, ... It has become a real success with a vibrant community which shared generative modules for JavaEE, .Net, PHP, C and lots of professional success stories. When OMG tackled the standardization of an M2T syntax with the MOF Model to Text Language specification, commiters decided to rewrite Acceleo from scratch as an official Eclipse Foundation project, changing the syntax to the OMG standard while keeping the exemplary tooling and pragmatism of Acceleo.org.
With Acceleo 3.0 included in Eclipse 3.6, our new goal is to provide the de facto or reference implementation of the standard; however, some parts of the specification are still quite vague and ambiguous and collaboration with OMG isn't smooth. We discuss both the specification and the implementation, and gather overall thoughts on how to provide a long-term and successful communication channel between the Acceleo project and OMG representatives.

An Extensible Modular Approach to QVT
Ed Willink, Eclipse Modelling Project Team

The QVT specification evolved as a compromise between competing imperative and declarative perspectives for a transformation language. The intent was that the QVT Core (QVTc) language provided a common low-level language for both QVT Relations (QVTr) and QVT Operational Mappings (QVTo). Unfortunately the only QVT Core tool (OptimalJ from Compuware) was discontinued before it was fully functional. The QVTr language is specified using a single pass QVTr transformation from QVTr to QVTc. This is difficult to understand, and since it requires a working QVTr engine to realise QVTr, it is unlikely to be correct.

The Eclipse QVT Declarative (QVTd) project is adopting a new strategy using progressive transformation from QVTr via multiple QVTc levels to a Transformation Virtual Machine. QVTr will therefore be re-specified in QVTc. Two new intermediate QVTc-like declarative languages are introduced: QVT Unidirectional (QVTu), which simplifies QVTc by exploiting the desired transformation direction, and QVT Minimal (QVTm), which simplifies QVTu by normalising all constructs to the minimum necessary to express transformations. One new intermediate QVTc-like imperative language is introduced: QVT Imperative (QVTi), which simplifies QVTm to impose a simple procedural search strategy.

It will be shown how this not only creates a modular environment for realising QVTr, but also provides distinct interchange points for other declarative or imperative transformation languages, a further interchange point suitable for optimisation of composed transformation chains, and a final interchange point suitable for alternative transformation execution engines.