In-Depth
UML overhaul winding up
- By Richard Adhikari
- April 1, 2002
The Unified Modeling Language (UML) has become the notation of choice among
application developers by and large, but all agree it has much room for improvement.
The next version of the technology, UML 2.0, scheduled for official completion
by April 2002, will address many of the problem areas.Some unnecessary features
may be trimmed. UML will be brought in line with other Object Management Group
(OMG) technologies, which will move it beyond notation to construction; enhanced
diagram interchange capabilities will be added, as will better support for component-based
software development.
Another upcoming standard will allow designers to assign action semantics to
objects in UML models, and UML will be extended to include the SDL methodology
and development language, which is widely used in the telecommunications industry.
The basics
UML evolved from three leading object methodologies -- Booch, Jim Rumbaugh's
Object Modeling Technique (OMT) and Objectory -- and added in "good ideas
from other methods," said Cris Kobryn, chief technologist at Telelogic,
Irvine, Calif., and chair of the OMG analysis and design task force.
But that synthesis created enough overhead that UML is "rather large and
complex, and even the experts have some difficulty remembering all the features
associated with it," Kobryn said. It was time to overhaul UML to make it
"easier to learn, apply, customize and implement," he noted.
The overhaul of UML is divided into three areas: infrastructure, superstructure
and the Object Constraint Language (OCL), according to Kobryn. Infrastructure
is the foundation; superstructure consists of "more advanced constructs
built on the basic constructs -- things like components, component-based development,
workflow, business process modeling and interactions for modeling complex behavior,"
he explained.
The OCL is a constraint language that users may employ to specify "any
type of constraints that might apply to a model," Kobryn said. Constraints
can fall into any of several classes as required by the user. A business constraint
could be that a customer can have only one billing address; a performance constraint
might be that, for a fault-tolerant system, failover recovery should take a
specified amount of time. UML working groups use constraints within UML to define
that the language is well formed, Kobryn said.
Simplifying UML
The complexity of UML is essential because "it needs to be able to model
all kinds of systems; so there's a certain level of complexity inherent in it,"
said Jim Rumbaugh, a Rational Fellow at Rational Software Corp., Cupertino,
Calif. However, the working groups around UML 2.0 will "eliminate some
of the unnecessary features and simplify some things that were unnecessarily
complicated," he added.
One class of candidates for elimination is thinly defined stereotypes. "Things
got in there because we couldn't agree on what to do with them," Rumbaugh
said. Duplicate concepts are another target for elimination. "There seem
to be a lot of concepts with similar meanings -- events and signals -- or in
large-scale structuring features we have packages and components and subsystems,"
Rumbaugh said. "At some point you have to kick the real anal-retentive
people out of the room and say 'Yes, these two are slightly different but the
average modeler won't care.' If the experts keep arguing about what something
means, then the users won't get it."
UML will be brought into line with other technologies from the OMG such as
the Model Driven Architecture (MDA) and Meta Object Facility (MOF). The MOF
will standardize a repository for UML models. "You'll be able to generate
code from the UML," said Grover Righter, vice president of technical strategy
at Kabira Technologies Inc., San Rafael, Calif. "Everyone wants to construct
applications directly from models now."
Making UML fully compatible with MOF will eliminate the need for mapping from
one to the other. "The mappings were 95% compatible, but the task of mapping
was somewhat painful," Rational's Rumbaugh said. UML 2.0 will also have
a feature that allows changes to be made to meta models in the Common Warehouse
Metamodel (CWM) at the user level. This will allow users to employ the meta
model facility to extend UML, Rumbaugh said.
While UML 2.0 and MDA have the same roots -- the desire to construct applications
-- a hierarchy exists between them. "The MDA includes UML as its topmost
design component, but UML doesnÕt include MDA," Kabira's Righter
said.
Diagram exchange
One of the RFPs issued for UML 2.0 deals with diagram exchange, which UML currently
lacks. "One of the things that's absolutely heinous about UML is that it
comes with XMI [XML Metadata Interchange]," said Cameron Skinner, chief
architect, application development tools at San Francisco-based Embarcadero
Technologies Inc. That is because XMI, which the OMG specifies as a way to transfer
meta data across different platform vendors, cannot transfer UML notational
diagrams between tools, so any layout information in the meta data is lost when
it is exported. "Layout and how a diagram looks is a big part of what makes
developers' tools effective, and yet that's the part that doesn't transfer today,"
Skinner said. UML's current inability to handle diagram interchange restricts
users from moving models between different vendors' tools to conduct a comparative
analysis, said Telelogic's Kobryn. In August, a final submission on XMI will
be made to solve this problem, added Embarcadero's Skinner.
Component-based development
Jim Duggan, an analyst at Gartner Inc., Stamford, Conn., said UML's support
for component-based development is weak. "A lot of emphasis has been placed
on describing components, but there's no way of telling whether a component,
either at the design stage or after it's been completed, is a good component
in the engineering sense, so you could define figures of merit," he said.
Structured programming, for example, has metrics to measure whether a component
is strongly or lightly structured, but "there's virtually no metrics at
all for components in UML 1.x," Duggan said.
Support for component-based development is "an area that needs straightening
out because its definition in UML 1 was somewhat opaque," noted Rational's
Rumbaugh.
Telelogic's Kobryn said UML 1.x does support component-based development but
"we want to make it more straightforward to model components, and that's
one of the major requirements for UML 2.0."
Embarcadero Technologies' Skinner went a bit further: "It's not that you
can't do component-based application development in UML now, it's just that
you need a lot of other things," he said. For example, COM developers may
want to model an interface with attributes and put it into a COM IDL file, but
"UML says an interface can't have attributes," Skinner said.
With UML 2.0, the OMG is "trying to create a real generic component-based
infrastructure that can handle the various approaches to component-based development.
COM developers and JavaBean or EJB developers want to be able to do different
things, and UML 2.0 wants to be able to give you the choice," he said.
Action semantics
UML 2.0 will have action semantics added so developers can construct complete
applications directly from UML without using third-generation languages (3GLs)
such as Java and C++ to define behavior, Kabira's Righter said.
"Under UML 1.x, it is possible to model decision control but not express
exactly what to do based on a condition," he said. "UML is fabulous
for data definition and state definition, but doesn't have enough power to do
entity relationships that are dynamic, or behaviors or conditionals. That's
why people have been embedding 3GLs into their UML," Righter said.
The action semantics that will be added to UML 2.0 will not be a single syntax;
there will be industry-specific action syntaxes, Righter said. This is similar
to what is happening in XML, where industry-specific XML dialects are evolving.
Kabira has developed an action syntax, osIDL, that, together with UML, will
let users generate "anything you want -- COBOL, Java, C++ and assembly
language," Righter said. "You can use a single action semantics language
and, from it, you can do UML applications in varied fields like telecommunications,
fighter-pilot control applications or energy control systems."
Bringing in SDL
Rational's Rumbaugh said UML 2.0 will extend its scope to embrace other methodologies
and languages. One such methodology and development language is SDL, which is
widely used in the telecommunications domain, Rumbaugh said. So, UML 2.0 will
include the concept of structured objects, which are objects that have parts
and can be built up hierarchically. This is a concept from SDL.
"There's been a bit of rivalry with SDL and we want to make SDL people
happy by incorporating many of their good ideas," Rumbaugh said. UML had
been proposed to SDL users, but "they said there are things missing. We're
hoping to plug a lot of the holes by picking up SDL features like sequence diagrams
strongly based on Message Sequence Charts and structured objects so SDL users
will be able to migrate to UML 2.0," Rumbaugh said.
Message Sequence Charts (MSCs) are an ISO standard, and Rumbaugh's working
group will "propose that we use MSCs as either an upgrade to, or replacement
for, UML's existing sequence diagrams," Rumbaugh said. This heralds a more
open mindset among UML proponents.
"When UML 1 was developed, there was a certain amount of 'Not Invented
Here' syndrome. I think we're a little more open now to wider experience given
that UML is quite successful, and I think we're prepared to accept good ideas
wherever they come from," Rumbaugh said.
While the new features of UML 2.0 are important, the most crucial factor is
the willingness of the people behind the standard to help it evolve and embrace
other technologies. That open attitude is the only way UML can prove of real
benefit to developers and avoid fragmenting the market as so many standards
have done before.
For related articles, please see "UML
and IIOP," "Six degrees
of UML problems" and "The
Tao of UML 2."