Appendix B. Model-Driven Architecture (MDA) at Eclipse

The OMG has defined a set of standards for use in what it calls Model-Driven Architecture (MDA). Although the approach of MDA is more or less the same as most other approaches to a general model-driven software development, MDA requires technologies that implement the stated OMG standards. The Modeling project provides support for many of these standards, so using the Modeling project for MDA is definitely an option. However, where standards compliance is not a requirement, or where you need a capability for which no implementation yet exists, the Modeling project provides a range of alternatives.

As stated in its charter,

When the OMG introduced MDA to the world in 2001, Eclipse was an incipient community. In the past seven years, MDA and Eclipse have experienced success while concurrently undergoing changes in focus, positioning, and applicability to the world of software development. Eclipse is no longer “just a Java IDE,” and MDA is now based on a more complete set of specifications, making it much more well defined than seven years ago.

Although the Eclipse Modeling Project makes little mention of MDA proper, it is nonetheless supported to a large degree, as discussed shortly. In fact, Eclipse has significantly contributed to the success and realization of MDA, providing an open source platform and de facto reference implementations for many of the MDA specifications. Unfortunately, this has been done with minimal collaboration with the OMG. Improved collaboration likely will increase the success of both organizations as they strive to increase the adoption of model-driven development.

Implemented Standards

The Eclipse Modeling Project is a top-level Eclipse project that is logically structured into projects that provide abstract syntax definition, concrete syntax development, Model-to-Model Transformation (M2M), and Model-to-Text Transformation (M2T). Additionally, the Model Development Tools (MDT) project focuses on providing implementations of industry-standard metamodels and exemplary tools for developing models based on those metamodels. This range of functionality provides its community with a full range of model-driven software development (MDSD) capabilities, many of which conform to published MDA specifications.

Although the top-level Modeling project is the primary location for MDA-related activity at Eclipse, other projects within Eclipse have modeling-related technology and specification implementations. For example, the Software Process Engineering Model (SPEM) [4] is implemented as part of the Eclipse Process Framework (EPF) [5] project, while BPMN diagramming [18] is provided by the SOA Tools project [19].

It’s also worth pointing out that the Eclipse Modeling Project provides alternative technologies for several of the OMG’s MDA specifications. These are discussed shortly because they are popular technologies with strong user communities. In most cases, their implementations precede the corresponding OMG specification.

Altogether, these projects fulfill most of the MDA vision, while certainly fulfilling general MDSD and domain-specific language (DSL) tooling requirements. The following is a list of the relevant MDA specifications and their implementation status within Eclipse. This is not an exhaustive list of MDA specifications, but these are the most relevant within the current scope of the Eclipse Modeling Project.

Meta-Object Facility (MOF)

We cannot overstate the importance of having a common underlying metamodel, provided by the Meta-Object Facility (MOF) [11] specification. MOF—or, more specifically, EMOF (Essential MOF)—is closely aligned with the Ecore metamodel of the Eclipse Modeling Framework (EMF) [12] and forms the basis of most Modeling project technologies.

The topic of aligning the Ecore metamodel with the EMOF specification has been ongoing for years and will likely continue because the implications of alignment are not trivial. EMF is such a popular technology used within many Eclipse projects and commercial products that changing its structure and API is not a viable solution. As has been discussed, updating the EMOF specification to align with Ecore might be a better solution.

Although EMF forms the bedrock of nearly every Modeling project, room for improvement still exists. Discussions are ongoing in the areas of large-scale models, metamodel enhancements, alternative persistence mechanisms, and so on. When considering the evolution of EMF and all Eclipse open source projects, it’s important to keep in mind that it is contribution based. EMF itself consists of a small team that must maintain and preserve its current client base.

Unified Modeling Language (UML)

Unified Modeling Language (UML) [6] is implemented within the UML2 component of the Model Development Tools (MDT) project [8] and currently conforms to the 2.1 version of the specification. This implementation of the UML2 metamodel is based on EMF and has been part of Eclipse for quite some time.

Diagramming capabilities for the UML2 metamodel implementation are now provided by the MDT project’s UML2 Tools component. These diagrams are generated using the Eclipse Graphical Modeling Framework (GMF) project, itself an example of model-driven software development using Eclipse technologies.

Both the metamodel and diagramming components provide support for the definition of UML Profiles. Profiles play an important role in MDA and in the definition of UML-based DSLs. Although no UML Profiles are available at Eclipse today, they could be implemented and provided to the community in the future. Ideally, a catalog of profiles and other MDA artifacts would be contributed to and maintained by the community for general consumption.

Object Constraint Language (OCL)

Object Constraint Language (OCL) [9] is an important element of Model-Driven Architecture (MDA) and is used in several Modeling projects. OCL is provided as a component of the Model Development Tools (MDT) project, with a complementary OCL Tools component coming in the near future. The OCL implementation conforms to the 2.0 version of the specification and has bindings to both Ecore and the UML2 metamodel implementations.

Diagram Interchange (DI)

UML Diagram Interchange (DI) [16] is not currently provided at Eclipse, but it has prompted many questions from the community regarding its implementation, particularly with the introduction of UML diagramming from the MDT project.

The team that designed and implemented the notation model for the GMF runtime found this specification to be insufficient. It has been suggested that the DI specification be revised to align with the GMF notation model because the original version of the specification was not broadly adopted and because GMF is so popular.

A related topic is the Diagram Definition RFP [24], which itself was inspired by the mapping that GMF provides between Ecore models, their notation elements, and their tooling. This RFP will help bridge the current gap in modeling specifications from the OMG.

XML Metadata Interchange (XMI)

XML Metadata Interchange (XMI) [13] is supported by EMF and is used by the UML2 project and others. EMF also can read serialized EMOF models, in addition to several other format import options, including XML Schema Definition (XSD).

MOF Query/View/Transformation (QVT)

Query/View Transformation (QVT) [14] is part of the M2M project [15] and currently provides an implementation of the QVT Operational Mapping Language (OML). The QVT Relations and Core languages are also being implemented within M2M.

The M2M project provides another model-to-model transformation technology with its Atlas Transformation Language (ATL) component. ATL was a contender among responses to the QVT RFP and has fostered a large and successful community of its own.

MOF Models to Text Transformation Language

MOF2Text is being implemented within the MOFScript [26] component of the Generative Modeling Technologies (GMT) project. This is a recent specification and implementation in an area that has no shortage of alternative technologies.

Java Emitter Templates (JET) [27] originated as EMF’s code-generation framework and borrows heavily from Java Server Pages (JSP). JET is undergoing an update to enhance its capabilities, and it resides within the M2T project.

Xpand [28] is an increasingly popular template-based M2T component that provides an alternative syntax and expression language to JET. Xpand provides additional extension capabilities and continues to be enhanced via community contributions.

JET and Xpand are well used within the community. Although MOF2Text is relatively new and unproven, the benefits it might offer likely will prompt the reimplementation of existing templates. Nonetheless, a MOF2Text contribution exists within the Modeling project for those looking for a specification-compliant M2T solution.

Human-Usable Textual Notation (HUTN)

Human-Usable Textual Notation (HUTN) [17] is not currently implemented, but it relates to the proposed Textual Modeling Framework (TMF) project [30] within Modeling. A great deal of interest in tooling for the support of textual concrete syntaxes for modeling languages has arisen, particularly as the interest in DSLs and “language workbenches” [28] has grown.

The TMF proposal states that it will allow for the definition of concrete textual syntaxes for abstract syntaxes defined using EMF. A full-featured textual editor will be generated, likely targeting the capabilities of the proposed IDE Meta-Tooling Platform (IMP) [31] project. Therefore, TMF will provide complementary concrete syntax to the graphical concrete syntax that the Graphical Modeling Framework (GMF) project provides.

Business Process Modeling Notation (BPMN)

The SOA Tools Project at Eclipse provides Business Process Modeling Notation (BPMN) diagramming, mainly for the purpose of generating BPEL [34]. The diagramming is based on GMF, and the underlying model is based on EMF, thereby making this project compatible with other Modeling technologies.

Because BPMN provides no well-defined metamodel, the introduction of the Business Process Definition Metamodel (BPDM) [32] will hopefully lead to a new contribution of this capability at Eclipse. As standards-based model implementations, the implementation of the BPDM metamodel and BPMN diagramming for working with these models would fall within the scope of the MDT project.

Software Process Engineering Metamodel (SPEM)

As mentioned, the Eclipse Process Framework supports Software Process Engineering Metamodel (SPEM) [4]. Although SPEM is mentioned in the list of MDA specifications, no real requirement specifies its use in the application of MDA. Within Eclipse, currently no connection exists between EPF and the Modeling project, aside from the fact that the SPEM metamodel is implemented using EMF.

Working Relationship

To date, very little formal communication has taken place between the OMG and the leadership of the Eclipse Modeling Project regarding a working relationship. Lately, the most promising discussions have been with respect to a series of symposia, to be held at EclipseCon [35] and during OMG technical meetings. The focus of these events will be to discuss individual specification implementations and ways the two organizations can strive for more constructive cooperation.

The current situation raises a number of questions about the nature of the relationship, which hopefully these meetings can address. The relationship could remain informal, with no explicit commitment or expectation that implementations found in the Modeling project must represent so-called “reference implementations” of OMG standards, as described in OMG Specification and Products [3].

In the past, specifications such as UML have suffered from interoperability issues among vendors who had different interpretations or implementation goals. The introduction of XMI, well-defined compliance levels, DI specification, and so on were meant to improve the situation but have largely failed to deliver and now compound the problem. Developing a reference implementation in parallel with the specification can identify ambiguities and defects earlier and can serve the larger community by delivering a platform upon which to implement commercial products.

That said, the UML2 implementation at Eclipse is the de facto reference implementation for the UML2 specification, and its development exemplifies the model we would like to achieve with the OMG for all implemented standards within Eclipse. Only through communication and feedback between implementers and specification authors can our respective communities be best served.

Membership

Currently, the Eclipse Foundation is a member of the OMG, and the OMG is a member of the Eclipse Foundation. This is a start, but it raises the question of what level of interaction and commitment this brings, particularly because corporate members of each are often involved in and provide contributions to both of these organizations.

What are the best techniques for aligning standards organization activities with reference implementation project team activities? Should members be required to participate in both contribution areas, where applicable? What does it really mean for the Eclipse Foundation to be a member of the OMG, and vice versa? What role would the Foundation representative have within the context of the OMG, and how would this person coordinate with fellow members from the Eclipse community? What if members have competing goals? Are there new working models that would be more productive—and perhaps have never before explored in this context?

Specification Delivery

Specifications with defined metadata should be delivered in a serialized format, preferably XMI. The standard RFP template requires this for new specifications, but it has not been mandated or required for all specifications currently published by the OMG.

Graphical notations (concrete syntax) are typically provided by drawings and natural language descriptions. Although these are typically sufficient for describing the elements, they are not as precise as they could be and must be manually implemented for use in modeling tools.

The delivery of specifications in formats that are machine consumable, particularly if used as inputs to generative tooling frameworks, should be an obvious benefit to those involved in specification, implementation, and consumption of these technologies. This includes metamodel constraints, which should be serialized and interpreted by the underlying tooling. Currently, no standard way exists for EMF to define constraints (such as OCL) or interpret constraints on models even if they were provided.

The UML specification contains domain (abstract) syntax and semantics, OCL constraints, and graphical (concrete) syntax, accompanied by natural language description and mapping to the domain. It would seem reasonable for specifications to be delivered in a manner that describes the abstract model separately from the concrete syntax and that uses a mapping definition. This approach provides proper separation of concerns and supports the generation of graphical editors for various domain models.

As mentioned previously, the RFP for Diagram Definition should address the issue, which leaves the graphical notation definition issue. Should graphical notations be defined in term of a graphical definition metamodel, SVG, or another standard?

With respect to mapping definitions—for example, the myriad mappings from UML2 Profiles to Information Management Metamodel (IMM) (among others)—should QVT be provided as part of these specifications?

Specification Compliance

A generally provided set of conformance criteria must be met when implementing a specification. With improved collaboration between implementation and specification organizations, some level of minimum compliance level can be expected, to provide a proper reference implementation. In some cases today, implementations at Eclipse are well aligned, or nearly aligned, with OMG specifications. For example, the Eclipse UML2 project provides a compliant implementation of the UML 2.1 metamodel using the nearly EMOF-compliant Eclipse EMF project.

Should implementations be required to provide the highest level of compliance to defined specification acceptance criteria? Or is a “best effort” approach adequate? What actions can or should be taken to provide specification alignment or conformance?

Implementations Influencing Specifications

As indicated previously, in some cases, existing implementations are close to a specification yet are not fully compliant. With a large existing client base on a high-quality, open source implementation, why not align a specification with the implementation? For example, consider the previously mentioned case of EMF’s Ecore model being not quite aligned with the EMOF specification.

A precedent exists for this type of influence between an open source implementation and OMG specification in the UML. The DI and Diagram Definition RFP are two more areas where this type of cooperation can be mutually beneficial.

Most often, specifications are themselves driven from implementations, although typically from a commercial vendor. Wouldn’t an open source approach to implementations influencing specifications be a more equitable solution? This leads us directly to the next topic.

Open and Transparent Nature

In the case of Eclipse, contributions are done in the open, with an emphasis on meritocracy as the basis for achieving more responsibility within the community. Transparency is essential to the open source process at Eclipse, yet this is somewhat different from the specification development process at the OMG [21]. Perhaps this is an area in which the two organizations can influence one another.

If the development of a reference implementation were done in the open, it follows that the developing version of the specification itself must be available. Otherwise, there would need to be a serial process of first developing the specification, publishing it, and then implementing it, which eliminates the benefits of validating the specification while developing an implementation in parallel.

Can the process of developing standards be done in a more open and transparent manner, with an emphasis on addressing the needs of a developing reference implementation? Alternatively, could Eclipse support a model whose source is not open until it reaches a required level of alignment with ongoing specification work?

Future Outlook

In summary, the promise of MDA can be realized to a large extent today using the capabilities provided by the Eclipse Modeling Project. As MDA encompasses a collection of specifications that align well with the implementation goals of the Eclipse Modeling Project, the future of delivering a solid open source infrastructure for MDA tooling seems bright.

Practically speaking, many challenges remain before realizing the statement in the Modeling project’s charter related to its relationship with standards bodies such as the OMG. A relationship that is too informal will not likely yield the desired results, whereas a relationship that is strictly defined and enforced will likely limit the progress of implementation. The right balance will clearly benefit both of these organizations, their members, and, ultimately, the customers of standards-based commercial products.