In-Depth

Six degrees of UML problems

• By Richard Adhikari
• April 1, 2002

1. Coupling to the business process. "Our client base wants something that lets them talk to the business user in his language. If that's the case, UML notation and object modeling seem to be a pretty draconian approach because they begin with use cases; and, sometimes, use cases arenÕt the most appropriate way of starting off," Duggan said.

2. Coupling to components. "The component architecture is one where even proponents of UML feel pretty strongly that there are a variety of ways you could do components in UML at the 1x level, none of which was particularly strong," he noted.

3. Round-tripping between code and class is very poor in UML. "Generation requires very specific integration to an IDE and, depending on which side of that practice you're standing on, you could either say it's a great idea to simultaneously generate code or it's horrible. But it requires patterns for development and design," Duggan said.

4. Lack of smooth coupling between modeling notations in UML and the actual IDE code. "TogetherSoft and Embarcadero built a tight coupling so you could jump back and forth between modeling notations and the code; that's really an extension beyond UML," Duggan said.

5. The lack of a physical design. "While UML has logical design and the object design is at the conceptual level, you don't have UML-related physical design. You still have a transition to a different design technique, and you have to go back and forth across this notational boundary, which is annoying," Duggan said. Rational, with Rose Data Modeler, and Embarcadero offer solutions for this, he added.

6. Group support. "This one is more implementation than notation -- UML modeling tools tend to be flat file-based, not repository-based," Duggan said. "In practice, Rational Rose led you to lots of problems in terms of whether you had a current representation of the model or there was another version somewhere, and versioning of models became a problem."