e for its content.
Guidelines for Using Rational XDE with Rational ClearCase UCM
file:///C|/Documents%20and%20Settings/avaughan/Desktop/getstart/...20Using%20Rational%20XDE%20with%20Rational%20ClearCase%20UCM.htm
Guidelines for Using Rational XDE with
Rational ClearCase UCM
By Fridric Plante and Scott Darlington
Rational XDE Professional is a new integrated modeling and development environment from Rational
that offers many powerful capabilities. In this article we'll focus on the ability of teams to manage their
XDE models (expressed in the Unified Modeling Language, or UML) in the same way they manage their
source code. This can best be achieved by using XDE with Rational's market-leading software
configuration management (SCM) tool, Rational ClearCase. In particular, we'll present guidelines for
using XDE with ClearCase's Unified Change Management (UCM) features. UCM is Rational's process
that supports SCM best practices, and ClearCase is one of foundation technologies for it (the other being
Rational ClearQuest).
Rational XDE Professional comes in two editions: the Microsoft .NET Edition for developers using
Microsoft's Visual Studio .NET shell, and the Java Platform Edition for developers using IBM's
WebSphere Studio Workbench (based on the Eclipse open development platform). The information in
this article applies to both editions.
The topics we'll cover include:
q
some background information to set the scene

q
the pros and cons of model partitioning strategy, and guidelines for partitioning

q
the setup necessary for integrating XDE's compare/merge feature with ClearCase

q
workflows for adding XDE models to ClearCase

q
workflows recommended for when you're working with RTE artifacts

q
tips on merging models

We assume you're already familiar with XDE, ClearCase, and UCM. You can learn more about these
topics by perusing the many articles published on the Rational Developer Network.
Although this article focuses on using ClearCase's UCM features within XDE, many of the concepts
discussed, such as partitioning and merging models, apply equally well to developers using ClearCase
without UCM.
Background
This section first summarizes how XDE differs from Rational Rose, the other Rational tool that offers
file:///C|/Documents%20and%20Settings/avaugh...0XDE%20with%20Rational%20ClearCase%20UCM.htm (1 of 24) [4/8/2004 4:48:44 PM] file:///C|/Documents%20and%20Settings/avaughan/Desktop/getstart/...20Using%20Rational%20XDE%20with%20Rational%20ClearCase%20UCM.htm
UML modeling capabilities to development teams, and then sets the scene for the rest of the article by
presenting issues that are likely to arise in teams doing parallel development.
Differences from Rational Rose
Since many Rational XDE users will be familiar with Rational Rose, we'll look briefly here at how XDE
team support differs from that offered by Rose. In the following ways, XDE provides more advanced
SCM options than Rose does, making it even easier to do development while managing your models.
q
XDE can automatically check out files when they're modified. This means you don't need to check
out a file before making changes; you just open the file and start changing it, and the file is
checked out for you. A preference determines whether modified files are automatically checked
out or you're prompted to check them out (or neither).
q
XDE can automatically add newly created files to source control according to the convention of
the development environment in which it's running. The Java Platform Edition of XDE provides a
preference that determines whether new files are added to source control automatically or you're
prompted to add them to source control (or neither). The Microsoft .NET Edition of XDE will add
newly created files to source control automatically without prompting.
q
The automatic checkout capability works with the XDE's model/code synchronization tool,
automatically checking out source files when they're modified due to model changes (or vice
versa).
q
You can partition a model into finer-grained units than Rose allows. For example, diagrams can be
in their own storage units. Properly partitioning your model into storage units, as discussed later in
this article, is critical for successful development of models in large teams.
q
XDE supports references between models, making it easy to build large applications composed of
many models.
q
XDE has a compare/merge capability integrated into it, whereas Rose uses a separate application,
Model Integrator, to perform merges. Because XDE is performing the merge, you can examine the
merge result model in the Model Explorer as you resolve the conflicts, which you can't do with
Model Integrator.
q
The XDE compare/merge capability can handle merge conflicts of higher complexity than Rose's
Model Integrator for example, a conflict in which two of the files contributing to the merge
operation contain a model element that has been moved (to a different place in each file) and a
third contributor file has had that model element deleted.
q
XDE presents each contributor (and the merge result model) in its own tree, instead of using one
file:///C|/Documents%20and%20Settings/avaugh...0XDE%20with%20Rational%20ClearCase%20UCM.htm (2 of 24) [4/8/2004 4:48:44 PM] file:///C|/Documents%20and%20Settings/avaughan/Desktop/getstart/...20Using%20Rational%20XDE%20with%20Rational%20ClearCase%20UCM.htm
tree to hold all contributors. This makes it easier to compare the changes of each contributor.
q
A Differences Explorer enables you to look at either conflicts organized by difference or
differences organized by conflict, so you can work in the manner best suited to the task at hand.
Parallel Development with XDE
There are many ways to use XDE in a team environment, and each team needs to decide what works best
for them given how they choose to develop and how work is partitioned among them. While this article
isn't intended to provide an in-depth discussion of this topic, we'll present a few considerations to guide
your decision.
In general, it's a good idea to partition model elements to minimize concurrent changes. Concurrent
changes occur when two or more users modify the same storage unit at the same time. The second person
to check in or deliver the changed unit would overwrite the first person's changes. Since this is rarely the
desired result, the second person should merge the two changed units together. For this reason, ClearCase
will automatically detect this situation and initiate a merge when the second person checks in the changed
unit.
If the two sets of changes to the storage unit are in different areas of the model or code, the merge may be
considered trivial. That is, ClearCase examines the storage unit as it was before either set of changes was
made (often referred to as "the base contributor"), as well as the two changed versions of it; then, upon
seeing that the developers have changed different areas of the storage unit, it simply propagates each
developer's changes into a new, merged version of the storage unit. However, if there are cases where
both developers have made changes to the same place in the storage unit, those changes are said to
conflict and must be resolved by the developer encountering the conflict.
ClearCase will automatically involve the developer when necessary to resolve a conflict. To do so, it
starts the appropriate Type Manager component. For source code, this is typically ClearCase's own
compare/merge tool,
cleardiffmrg
; however, when the storage unit is an XDE model file, or some
part of a model, ClearCase starts up XDE so that the developer can resolve the conflict in the model. For
this to work properly, ClearCase needs to be told which files are to be handled by XDE. At present, this
requires a one-time setup operation on each developer machine and each ClearCase server (as described
later in this article).
You can control the frequency of concurrent changes by carefully planning how you partition your model
into controlled units and by establishing ownership over parts of the system. However, no matter how
well partitioned your model, concurrent changes will still occur and may require merging. The amount of
merging your team is willing to undertake will be one factor to consider when partitioning your model.
Here are some suggestions for determining how much merging your team should be performing:
q
Experiment with the compare/merge tool to see how it works, how it presents the various
file:///C|/Documents%20and%20Settings/avaugh...0XDE%20with%20Rational%20ClearCase%20UCM.htm (3 of 24) [4/8/2004 4:48:44 PM] file:///C|/Documents%20and%20Settings/avaughan/Desktop/getstart/...20Using%20Rational%20XDE%20with%20Rational%20ClearCase%20UCM.htm
contributors, and how different types of changes you make in the model appear at merge time.
Although a first encounter with compare/merge and the amount of information it provides can
seem intimidating, after using it for a few merges you'll learn how to interpret this information
more quickly.
q
Determine your comfort level with compare/merge and then anticipate the comfort level of the
other members of the team. Take this comfort level into consideration as you choose your software
development strategy.
q
Keep in mind that as the number of changes between merge sessions increases, the merge sessions
are likely to become m