In-Depth

UML overhaul winding up

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."

Most   Popular