Rational software architect: a tool for domain-specific modeling.

INTRODUCTION

The development of the Unified Modeling Language ** (1) (UML **), standardized by the Object Management Group, Inc. (OMG **) in 1997, was an important step in focusing efforts to create a single object-oriented modeling language. An industry of services, consultants, and tools has sprung up around UML, and tools from IBM Rational* are among the market leaders. In 2005, a major revision of UML, UML Version 2.0 (2) (also called UML 2), was created, expanding the scope of concepts described in the UML standard.

One of the reasons for UML's success is that it contains abstractions for many standard object-oriented modeling concepts, such as class diagrams, state-machine diagrams, use-case diagrams, and sequence diagrams, with which users can describe the architecture, design, and even implementation of software systems. Despite this richness, users sometimes want to capture information in models not provided for in UML. For this purpose, UML provides the concept of a UML profile. UML profiles allow the definition of stereotypes, which are designed extensions of UML elements that allow users of UML to annotate UML elements with extra information. Stereotypes provide a simple but powerful mechanism for extending and adapting UML. If users want to model something that is not exactly the same as a UML concept, they can often find a UML concept that is close to what they want and customize it with a stereotype. Because UML tools support the concept of a stereotype, users can create their own UML modeling extensions and still exploit UML tools to display and edit their models.

This use of stereotypes to extend UML and UML tools is a good example of the value of reuse; defining a whole new modeling language and toolset would usually be prohibitively expensive. Still, the definition of stereotypes is not adequate if one needs to define a concept for which there is no similar UML concept. There are also cases where users need more control over the behavior of the modeling tool than can be achieved by customizing a UML modeling tool with stereotypes. Models that define concepts different from the standard concepts in UML are sometimes called domain-specific languages (DSLs) or domain-specific modeling (DSM) languages. Some DSLs describe concepts that are specific to a particular technical domain but outside the scope of UML. Other DSLs describe concepts unique to a particular application or solution domain. Many articles and books have described the value of DSM languages (3) or "software factories" (4) for particular domains.

Although UML is a powerful force for unifying modeling concepts within the object-oriented domain, there are many modeling languages from other domains, some of which predate UML. The entity-relationship (E-R) model, (5) first proposed in 1976, inspired some of the ideas that found their way into UML, but E-R modeling itself has also continued to be successful, especially in the relational database domain. There are enough differences between the E-R model and the concepts it inspired in UML, such as support for explicit keys, that E-R modeling has never been subsumed by UML. More recently, the Extensible Markup Language (6) (XML) and Internet standards have created modeling languages such as XML Schema (7) (XSD) and Web Services Description Language (8) (WSDL). XML Schema is a language for modeling XML data, and WSDL models the interfaces to Web services.

Recognizing the need for supporting the development of DSLs, and the continuing and emerging importance of non-UML standard modeling languages, the designers of Rational's next-generation modeling tools set out to make sure the tools could support a broad range of modeling languages equally. RSA supports the same UML extension capabilities as the previous Rational modeling tools, Rational Rose * and Rational XDE * (Extended Development Environment). These extensions enable users to quickly create UML profiles to address domain-specific concerns, but unlike the previous tools, RSA offers other means for integrating non-UML standard modeling languages and DSLs.

Rational Rose and XDE relied on reverse engineering and round-trip engineering to create UML from domain models such as Enterprise JavaBeans ** (KJBs **), Java **, and C++. (Reverse engineering in this context is the process of converting source code files into UML model elements. Round-trip engineering, found in XDE and Rose, allows the user to synchronize the contents of a UML model with a set of source code files.) A domain-specific profile was used in order to visualize, model, and reference existing domain models. This led to significant redundancy between the UML models and the domain models, and many issues related to synchronization of these artifacts. Users had to create large UML "library" models for referencing existing domain-specific libraries; for example, with Rational Rose, using a type from the standard Java library requires importing the Java library package into a model.

Unlike these previous tools, the modeling capabilities of RSA allow users to visualize and integrate models and model elements from different domain formats without having to create, store, and synchronize reverse-engineered versions of these models transformed into UML models. Because RSA's internal model representations are based on EMF metamodels (a metamodel is a model that defines another model), this task is made easier. RSA includes EMF representations for UML2, EJBs and C++, among others. (For an example of an EMF-based model, see Reference 9, which provides an overview of the open implementation of the UML2 metamodel underlying RSA.) RSA integrates these metamodels, allowing them to reference one another by leveraging EMF and the RSA-specific extensions to EMF for DSM. These extensions are called the visualization and metamodel integration services. These services have many capabilities, including allowing the user to leverage existing artifacts when designing new systems with UML.

A quick overview of the metamodel integration capabilities of EMF and RSA follows. We then describe two different ways that RSA provides visualization and integration of a domain-specific model. The first is through the use of the visualization technology; the second is through the use of a custom EMF resource implementation. Like all new technologies, there are areas of these solutions that still need to be improved. Adding modeling support for a new DSL in RSA 6.0 is very code-intensive and requires the use of many proprietary extension points. We also discuss new technologies that will be incorporated into future versions of RSA to further improve this integration.

OVERVIEW OF EMF

EMF, the Eclipse Modeling Framework, (10) is a key infrastructural element of many IBM products. It offers a simple, pragmatic approach to modeling and metamodeling. Based on proven technology (available since 2002), it can be used to generate code that is typically written repeatedly, allowing developers to focus on more complex aspects of the systems they are developing.

EMF consists of an underlying metamodel (called Ecore, for EMF's "core" model, as shown in Figure 1) and tools for importing and generating code from source models in various formats. It includes an efficient runtime model, persistence and validation frameworks, utilities for modeling and recording changes, user-interface-independent support for viewing and editing data, and much more.

[FIGURE 1 OMITTED]

The source model for an EMF project contains a description of an application's data, including objects and their attributes, relationships, operations, and constraints--essentially the basic concepts from the Meta Object Facility (11) (MOF **). It can be in any of several formats (effectively different views of the same information), including annotated Java interfaces, UML, XML Schema, or Ecore itself. Given a source model, EMF can generate Java implementation code (including user interface code), XML schemas, and Eclipse plug-in artifacts. The generated code includes efficient support for change notification, bidirectional handshaking, type-safe enumerations (i.e., those that do not permit assigning to an object a value of the wrong type), and reflection, based on the EObject interface. Reflection is the ability to query the metamodel for its classes and their structural features and thus navigate objects in a generic fashion.

Every EMF-generated application model is an instance of the EMF metamodel, Ecore. For example, an application model of a simple purchase order is shown in Figure 2. Here, PurchaseOrder and Item would be instances of EClass; shipTo, billTo, and productName would be instances of EAttribute; and items would be an instance of EReference.

[FIGURE 2 OMITTED]

"Persisted data" (i.e., data made persistent) in EMF is referred to as a resource. EMF provides a generic, customizable XML or XML Metadata Interchange (12) (XMI **) resource implementation, but other resource implementations (e.g., those backed by a database) are possible. Data can be spread over a number of resources, each of which is identified by a Uniform Resource Identifier (URI). A collection of related resources is known as a resource set; EMF uses proxies to represent references between objects in different resources within a resource set. EMF uses these proxies to support on-demand loading of referenced resources.