comment="po2">
An Ecore model of application data can also be defined at runtime
(without requiring code generation) by using the Ecore API (application
programming interface) or by loading it from a persistent form. A
dynamic implementation of the EObject reflective API provides the same
runtime behavior as that for a generated implementation. EMF treats all
model instances the same, regardless of whether they are defined
statically (i.e. generated) or dynamically.
OVERVIEW OF RSA METAMODEL INTEGRATION
As mentioned previously, RSA includes a set of EMF metamodels
(UML2, EJBs, data, etc.). EMF provides a basic language (Ecore) and a
set of services for working with instances of these models.
The visualization and metamodel-integration services component of
the RSA architecture allows different domain-specific models to be
visualized and integrated. The primary purpose of this component is to
allow for the integration and dynamic mapping of elements from a source
metamodel to a different target metamodel. This set of services allows
any EMF metamodel to be mapped to, and therefore be integrated with,
another EMF metamodel.
This component is required because metamodels from standard
specifications such as UML are usually closed systems. UML elements can
only have relationships to other UML elements; therefore, to reference
non-UML elements from a UML model, one needs some way of mapping the
element to a concept that UML understands. In RSA 6.0, the services
provided by this component allow EJB, Java, and C++ elements to be
visualized and integrated into UML models.
As an example, in Figure 3 an EJB called 'Customer' can
be dragged onto a UML diagram and visualized by using UML component
notation. The same EJB can reference a data table called
'Customer'. This reference crosses a metamodel boundary. The
data table is itself referenced from a UML2 use case called
'UpdateCustomer'. This reference also crosses a metamodel
boundary. The CustomerLocal Java interface that is exposed by the EJB
and a legacy C++ class called 'LegacyCPPSystem' that is also
traceable to the use case are also shown in the figure. These
relationships also cross metamodel boundaries.
[FIGURE 3 OMITTED]
The key concept underlying this ability is called a visualization
reference, that is, a URI that uses the vizref schema and can represent
a domain element or an association between elements. These references
support the ability to specify a mapping and extra properties that
should be applied to the target when the reference is resolved.
If a domain element is visualized on a diagram or referenced from
an element from a different metamodel, all that is persisted (i.e., made
persistent) is a reference to the domain element, which consists of a
URI with a vizref schema that includes the following fields:
VizRefHandler (its creator), target language kind (what it maps to),
supporting vizrefs, and other properties. The data stored in a vizref is
completely defined by the person who implements the domain mapping.
This sounds fairly complicated, but it actually is not. The
following examples of visualization references illustrate this. In order
to duplicate these examples, one simply drags various Java elements onto
an RSA diagram and then opens up the .dnx or .emx file with a text
editor.
In the first example, a Java class named com.ibm.demo.JavaSubclass
in a project named TraceDemoJava is visualized as a UML class. We
therefore have a vizref, with a type of uml:Class, containing the class
name, package name, and Java file name properties. There is also a
supporting vizref (composite) to the Eclipse project in which the Java
file resides. A Java project is mapped to uml2.Model.
In the second example, the relationship between Java classes named
JavaSubClass and JavaSuperclass (an "extends" relationship) is
represented as a composite vizref of type uml : Genera1ization
containing two supporting vizrefs that represent the Java class
(JavaSubclass) and its superclass (davaSuperclass).
We use composite visualization references in order to improve
performance. These references allow us to reuse reference objects in
memory and thus greatly improve the performance of refactoring
operations.
In light of the previous discussion, in the following section we
examine how RSA leverages this technology to provide a new, better
integrated workflow when dealing with a mix of general UML2 models for
design- and domain-specific models for construction or implementation.
The easiest way to do this is to compare the workflows of past Rational
tools with those of RSA.
COMPARISON OF RATIONAL ROSE AND XDE WITH RSA
Modeling tools such as Rose and XDE are used for many different
purposes. For the purpose of this paper we examine three categories of
use: (1) visualizing, understanding, and documenting existing code; (2)
creating new designs and converting them into implementations; and (3)
forward engineering (i.e., the process of transforming UML model
elements into source-code files). The first category of use is a very
common use of modeling tools and is often the one first used when a
developer is introduced to modeling. The second category of use occurs
when the tools are used to create new designs, possibly reusing elements
from existing implementations. These new designs are then converted into
initial implementations. In some cases, some users may iteratively add
to the model and regenerate the implementation. The third category of
use occurs when the tool is used in a true forward-engineering
model-driven development fashion. In this case, the model becomes the
"code" for the user, and the implementation that is derived
from the model becomes a derived artifact.
In the following, we review each of these three common usage
categories and compare how they are performed in Rose and XDE as
compared with RSA.
Visualization
One of the main reasons people want to create diagrams of an
existing implementation is to either help them understand it or to help
them communicate it to others. UML is useful for this. For the code
segments from the AutoWorld sample project shown in Figure 4, one may
want to create a diagram, also shown in Figure 4, showing the
inheritance relationships between the various entity beans that are
found in this project. (The AutoWorld sample is available in XDE and
RSA.) In order to create this diagram in XDE, it is necessary to first
"reverse engineer" the code into a model by right-clicking on
the AutoWorld Project in the Navigator and selecting the Reverse
Engineer option. This operation creates a model called "Java 1.3
Code Model" with the content shown in the model explorer in Figure
5.
[FIGURES 4-5 OMITTED]
As the figure shows, XDE reverse-engineers a great deal of detailed
information into the UML model, and therefore, navigating through the
content found in the model explorer is not as easy as navigating in the
project explorer shown in Figure 4. Once the reverse-engineered version
of the four desired KIBs in the XDE model has been located, a new
diagram can be created, and the EJBs can be dragged onto it to create
the visualization shown in Figure 5.
The XDE diagram in Figure 5 also is not quite as precise as the one
in Figure 4. It lacks the key indication on the 'id' field of
the Vehicle EJB, and because XDE is not aware of the domain-specific
WebSphere * Application Server 5.x extension that allows EJB
inheritance, it was necessary to draw the diagram by using the bean
implementation classes instead of the logical EJBs.
In comparison, to create this diagram in RSA, one simply selects
the desired EJBs in the project explorer and then selects
"Visualize" and "Add to New Diagram" from the
context menu. The diagram in Figure 4 was captured from RSA. In RSA, it
is also possible to simply use the "Browse Diagram" or
"Topic Diagram" support and completely skip the
diagram-creation step by selecting the EJBs in the project explorer and
selecting "Visualize" and "Browse In Diagram." This
functionality allows users to visualize elements in diagrams and
navigate through their domain-specific and UML models without persisting
the diagram itself, similar to the way one uses a Web browser.
Thus far, the differences could be attributed to "UI
trickery." Examining the files that are created (the .mdx/ .mdl
file of XDE/Rose versus the . dnx/. emx file of RSA), however, reveals a
very significant difference. In Rose and XDE, the UML objects are
persisted; therefore, a redundant copy of the information is stored in
the Rose and XDE model. In RSA, the UML objects are not persisted, and
the views simply use the "visualization reference" mechanism
that we described previously to reference the EJB or Java elements
directly. As a result, the XDE file we obtained was 2.5 MB, whereas the
RSA file was 25 KB.
To simulate what happens in a real team environment, we can update
the source code or deployment descriptor. For example, we add a
container-managed persistence (CMP) field (fuelConsumption:int) to
Vehicle by using the deployment descriptor editor. In XDE, we need to
select the model in the model explorer and select
"Synchronize" (or "Reverse Engineer") from the
context menu. The code model is synchronized, and then the diagram is
updated. In RSA, the diagram is updated automatically as soon as we
persist our changes into the Java source files or deployment descriptor.
In Rose and XDE, this scenario becomes much more complicated in a
real team environment. If two different users are updating the source or
the UML models, then, because of the duplication of information between
models and source, during a merge session it is necessary to reconcile
the model changes and code changes separately.
The preceding example, though simple, showed that referencing
non-UML instead of reverse-engineering into UML allows RSA to integrate
its notation and presentation model (UML) with underlying
domain-specific technologies without duplicating information. In this
particular example, RSA leveraged the existing EJB EMF models that are
available in RSA to provide first-class modeling of EJB concepts without
requiring the use of intermediate UML code models and profiles.
Creating new designs and reusing existing elements
Users often want to model a new system without having to fill in
all the implementation details. It is also helpful to be able to use
elements from an existing implementation. In the following example, we
use an existing Java interface called ExistingJavaInterface and an
existing Java class called ExistingJavaClass to represent elements from
an existing implementation* The NewClass UML class represents our new
UML design. The desired outcome is illustrated in the diagram shown in
Figure 6.
[FIGURE 6 OMITTED]
In order to use the existing Java elements in Rose and XDE, one
must first reverse engineer the existing Java code into a reference UML
code model. This model is shown in Figure 7 as "Java 1.3 Code
Model." It is also required to import a model of the Java software
development kit (SDK) (jdk_min) for any Java types we wish to use, such
as java.lang.String. A new UML class, "Class1", is created in
a new diagram and model, the existing elements are dragged into it, and
relationships are created that reference the UML version of the
interface. The result is illustrated in the diagram portion of Figure 7.
[FIGURE 7 OMITTED]
In order to draw the diagram in Figure 6 with RSA, one simply drags
the existing Java interface and class into a diagram from the explorer
and then draws the UML implementation and aggregation relationships
directly from the UML class to the Java elements. It is not necessary to
reverse engineer the existing elements into a UML model.
The ability to create a UML implementation relationship that
references a Java interface is again accomplished by using a vizref, as
shown in:
client="_hVc0d8AbZW50w">
href="vizref:///#jsrctype^vcore.target
=uml2.Interface^name
=ExistingJavalnterface[jcu^name
=ExistingJavalnterface.java[jpack^name
=com.ibm.existingsystem
[jsrcroot^srcfolder
=[project^vcore.target
=uml2.ModeI^ic
=ArticleExamples]]]]"/>
If the new design in XDE or Rose is satisfactory, the new class can
be forward engineered into a Java implementation. If one wishes to
retain the UML model, it is necessary to keep this model in sync with
the code from this point on, as we described in the previous section.
In RSA, the UML-to-Java transformation can be used to generate an
implementation for the new class. (In RSA and other new Rational
products, such as Rational Software Modeler and Rational Systems
Developer, the term "transformation" is used for a process
that transforms elements of one model into elements of another model.)
If the "Replace UML Elements" option is selected as part of
the transformation configuration, the reference on the diagram for
"NewClass" will be updated to reference the newly created Java
class. In this way, the diagrams always stay in sync with the code. As
part of the transformation, the diagram is updated as shown in Figure 8
to include a direct reference to the new Java class.
[FIGURE 8 OMITTED]
Forward engineering using the UML model
A user with a forward-engineering model-driven development approach
treats the UML model as the only persistent artifact in the process. All
other artifacts are considered derived from the UML model. The model is
transformed to the target domain and executed.
Although RSA introduces improved support for UML patterns and
transformations to help users who take this approach, there is no
significant difference between the capabilities and usage of RSA versus
the capabilities and usage of Rose and XDE. One still models in UML and
then does one-way transformations into the target domain.
In some of these cases, users are creating large UML profiles and
storing a great deal of extra information in models in order to avoid
having to reconcile changes between external artifacts and the UML
models. In the section "Future of RSA," we discuss some new
options for creating a custom domain-specific modeler as an option for
replacing large profiles on UML models.
WebSphere Business Modeler integration example
The second main example that we examine is the Websphere Business
Modeler (WBM)-to-RSA integration that is now available. WBM models are
stored in a format called Business Object Model (BOM). BOM is similar to
parts of UML2 but has significant differences and enhancements to
address the needs of business process modelers.
In the past, integration between IBM business modeling tools and
IBM software modeling tools was one way in nature. The business modeler
exported the model to UML, and then, the UML modeler simply imported the
model into the UML tool. No traceability was maintained, and keeping the
models in sync was almost impossible. For example, if one wanted to use
a WBM 5.x model and XDE together, it was necessary to export to UML from
WBM and then import into XDE.
In RSA, the WBM models can simply be opened. Once the model is
opened as a read-only UML model, links can be created to elements in
this model from other UML models, enabling the business model to be used
as a "contract model" for developing a new system or a set of
services. If the WBM model is updated, changes are immediately reflected
in the UML version, thereby removing the duplication and traceability
issues that existed in previous integrations. This functionality allows
the user to create models that have elements from both the BOM metamodel
and the UML metamodel, providing the same expressiveness as previous
tools without their issues.
How does this work? RSA registers a custom EMF resource
implementation that loads a WBM resource and dynamically maps its
contents to UML elements. Proxies from UML elements (in other models) to
WBM elements, when resolved, cause the correct WBM resources to be
loaded. For example, the XMI segment in Figure 9 shows a portion of a
persisted UML model that contains a class named "Class1" which
has an implementation dependency on an interface from another (WBM)
model. The reference is persisted as a URI comprised of the resource
name (resources. XMI) and the unique identifier of the element in that
resource (BLM-df04d4826b07b524c236754b558965ac).
The XMI segment in Figure 10 shows a portion of the WBM model that
contains the element referenced by the class in the UML model--a role
named "Rolel" with an identifier of
BLM-df0dd4826b07b524c236754b558965ac.
When the UML resource is loaded, its contents are created in
memory, including Class1, and a proxy is created for the reference to
the role in the WBM model. The first time an attempt is made to access
the implemented interface, the proxy is resolved: the resource
containing the referenced element (resources. XMI) is added to the
resource set, the custom resource implementation is used to convert its
contents to UML elements (the WBM role is converted to a UML interface),
and the proxy is replaced with a reference to the element with the
referenced identifier (i.e., the interface).
FUTURE WORK ON RSA
IBM Rational is continuing to develop and enhance the capabilities
described in this paper for future versions of RSA. One of the key
technologies that will make it easier to add new DSL support to RSA is
currently being developed in open source on eclipse.org under the
Eclipse Graphical Modeling Framework (GMF) project.
Eclipse GMF project
The Eclipse GMF project, as described in the GMF tutorial, (13) has
the goal of providing an open domain-specific graphical modeling
toolkit. Tool developers will be able to use this toolkit to design and
generate a custom graphical modeling tool from an EMF model of a domain.
The toolkit will also be usable to provide extended or custom notation
support for existing metamodels such as UML.
The GMF project consists of two major components. The first is a
runtime component that helps provide a common platform for developing
graphical DSM tools that are extensible and integrated with one another.
The second is a set of tools that will make it easy to create a set of
graphical figures and map them to a domain model expressed in EMF.
The IBM RSA development team is a key contributor to the runtime
components section of the GMF project. Many of the components underlying
RSA 6.0 were donated to the project in order to seed its capabilities
and to help ensure that any modeling editor generated with the GMF tools
or built directly on the GMF runtime will be consistent with RSA's
existing graphical editing capabilities and can be easily integrated
with other GMF-based modeling tools.
RSA enhancements for lightweight metamodel integration
Although the GMF project will go a long way toward simplifying the
process of building domain-specific editors by providing the ability to
define visualizations without requiring the entire domain to be mapped
to UML, there are still many circumstances when the ability to integrate
various metamodels is desired. For example, in the Java modeling example
earlier, one might have built a custom DSM editor for Java instead of
using the visualization and metamodel integration services from RSA.
Although using GMF would allow Java interfaces to be drawn or visualized
on diagrams, it would not have enabled support of the use case where a
new UML class extends an existing Java interface. In other words,
relationships or references across elements from different metamodels
could not be created.
In order to address this, the RSA team is working on a more
lightweight version of visualization and metamodel integration services
that will allow models to be integrated without having to share common
visualizations.
CONCLUSION
As the examples in this paper have demonstrated, the RSA 6.0
product shows significant progress by IBM Rational in supporting the
ability to model in different DSLs. This allows users familiar with a
domain to quickly obtain value from visualizations based on these
models.
In the section "Future work on RSA," we briefly discussed
some new technologies that will make it easier for tool developers,
partners, and advanced customers to develop their own integrated DSM
capabilities.
Several examples, such as the one displayed in Figure 3, illustrate
another key focus in RSA, namely, the integration of DSM capabilities
with general UML modeling and transformations. Because of this
integration, RSA allows the user to enhance domain-specific diagrams by
adding links to use cases, interactions, and collaborations. This
capability increases and supplements the expressive capabilities of the
tool and leverages UML and RSA's rich capabilities, without having
to reproduce them in each DSL.
Accepted for publication February 16, 2006.
CITED REFERENCES AND NOTE
(1.) Unified Modeling Language (UML), Version 1.4.2, ISO/ IEC
19501, International Organization for Standardization, (April 13, 2005),
http://www.iso.org/iso/en/CatalogueDetailPage.CatalogueDetail?
CSNUMBER=32620.
(2.) Unified Modeling Language (UML): Superstructure Specification,
Version 2.0, Object Management Group, Inc. (May 7, 2004),
http://www.omg.org/cgi-bin/doc?formal/05-07-04.
(3.) For a list of articles and publications on domain-specific
modeling, see http://www.dsmforum.org/publications. html.
(4.) J. Greenfield, K. Short, S. Cook, S. Kent, and J. Crupie,
Software Factories: Assembling Applications with Patterns, Models,
Frameworks, and Tools, Wiley Publishing, Inc., Hoboken, NJ (2004).
(5.) P. P. Chen, "The Entity-Relationship Model--Toward a
Unified View of Data," ACM Transactions on Database Systems (TODS)
1, No. 1, 9-36 (1976), http://bit.csc.lsu. edu/~chen/pdf/erd.pdf.
(6.) Extensible Markup Language (XML) 1.0 (Third Edition), World
Wide Web Consortium (W3C) Recommendation (February 4, 2004),
http://www.w3.org/TR/REC-xml/.
(7.) XML Schema Part O: Primer Second Edition, World Wide Web
Consortium (W3C) Recommendation (October 28, 2004),
http://www.w3.org/TR/xmlschema-0/.
(8.) E. Christensen, F. Curbera, G. Meredith, and S. Weerawarana,
Web Services Description Language (WSDL) 1.1, World Wide Web Consortium
(W3C) Note (March 15, 2001), http://www.w3.org/TR/wsdl.
(9.) K. Hussey, Getting Started with UML2, eclipse.org (August 4,
2005), http://www.eclipse.org/uml2.
(10.) F. Budinsky, D. Steinberg, E. Merks, R. Ellersick, and T. J.
Grose, Eclipse Modeling Framework, Addison-Wesley, Reading, MA (2004).
(11.) Meta-Object Facility (MOF) 2.0 Core Specification, Object
Management Group, Inc. (March 10, 2004), http://www.
omg.org/cgi-bin/doc?ptc/03-10-04.
(12.) XML Metadata Interchange Specification, Version 2.0.1, Object
Management Group, Inc. (May 5, 2006), http://
www.omg.org/docs/formal/05-05-06.pdf.
(13.) R. C. Gronback, GMF Tutorial, eclipse.org (January 22, 2006),
http://wiki.eclipse.org/index.php/ GMF_Tutorial.
* Trademark, service mark, or registered trademark of International
Business Machines Corporation.
** Trademark, service mark, or registered trademark of Object
Management Group, Incorporated, Sun Microsystems, Incorporated, or the
Eclipse Foundation, Incorporated in the United States, other countries,
or both.
Daniel Leroux
IBM Software Croup, Rational, 770 Palladium Drive, Ottawa, Ontario,
Canada, K2V 1C8 (dleroux@ca.ibm.com). Mr. Leroux is a Senior Technical
Staff Member and senior development manager with IBM Rational Software.
He has been with IBM Rational Software for eight years and has held
various management and development roles for the Rational modeling
family of products. Over the last four years, he has led the
architecture and development of the Rational Software Architect/Modeler
product line.
Martin Nelly
IBM Software Group, Rational, 1090 Katella St, Laguna Beach, CA
92651 (nally@us.ibm.com). Mr. Nally is an IBM Distinguished Engineer who
joined IBM in 1990 with 10 years' prior industry experience. He was
the lead architect and developer for IBM VisualAge/Smalltalk and lead
architect and overall development manager for IBM WebSphere Studio. His
current title is Chief Technical Officer, IBM Rational Software.
Kenneth Hussey
IBM Software Group, Rational, 770 Palladium Drive, Ottawa, Ontario,
Canada, K2V 1C8 (khussey@ca.ibm.com). Mr. Hussey is a senior software
developer for IBM Rational Software. He is a committer (i.e., a
developer with write access to the source code repository) on the EMF
project and lead of the UML2 project, both of which are open-source tool
subprojects at Eclipse.
Figure 9
XMI segment illustrating a UML model with a dependency
on a WBM model element
name="Class1"
clientDependency="_dd3b4DBNEdq_
sa2-mTt1NA">
client="_bV9UMDBNEdq_sa2-mTt1NA">
href="resources.XMI#BLM-df04d4826b07b524c23675
4b558965ac"/>
href="resources.XMI#BLM-df04d4826b07b524c23
6754b558965ac"/>
Figure 10
XMI segment containing a referenced element in a WBM model