Software Development
February 2004

Despite its enhanced focus on architecture-oriented diagrams, gaping holes in UI development and data modeling remain, making me wonder: Who needs the OMG?

By Scott W. Ambler

At last ... the OMG𠏋 long-awaited release of UML 2.0! Why has this version lurked on the horizon for so long? Three simple words: Model Driven Architecture (MDA). Most of the work put into UML aimed to increase its precision and consistency, so vendors could develop complex modeling tools that presumably will decrease our reliance on programmers. Having seen integrated computer-assisted software engineering (I-CASE) tools crash and burn in the 1980s, and considering the shallow pool of expert modelers, I hold little hope for MDA. Unfortunately, these are the cards that the IT industry has dealt itself, so we𠑥l have to live with this version of UML for awhile. Here𠏋 what𠏋 new.

Something for Your Stakeholders

Use case diagrams haven㦙 changed. Activity diagrams, however, have been completely overhauled. The OMG seems to increasingly recognize that activity diagrams should be used for business process modeling instead of object modeling, so they𠐔e begun inching toward a combination of traditional data flow diagrams (DFDs) and flow charts. They𠆫e no longer specializations of state machine diagrams, and thus are more flexible. New notation and semantics have been added to model the transformation of objects between activities as well as for event signaling. Unfortunately, they still reflect their object heritage in the fact that objects passed between activities are depicted as object boxes (consistent with other UML diagrams) on the transition lines. Personally, I prefer the much more concise notation used on DFDs㻡 simple label on the line. Activity diagrams clearly still need to evolve, but they𠆫e definitely moving in the right direction.

Architecture, Anyone?

UML 2.0 boasts a major improvement in its greater focus on architecture-oriented diagrams: component diagrams, deployment diagrams and package diagrams. Component diagrams have evolved, but deployment diagrams haven㦙 changed and should still be used to interrelate the software, hardware and middleware components. Package diagrams have now been officially added and should still be used for high-level overview diagrams or to depict your source code𠏋 package structure (for example, Java code is organized into packages).

In the past, component diagrams were promoted as detailed design diagrams, and the UML User Guide (Addison-Wesley, 1999) absurdly advised that we use them for data or user interface modeling, reflecting the 婫verything is a component� mindset of the time. Other methodologists𡟙ncluding me in Process Patterns (Cambridge University Press, 1999), and Peter Herzum and Oliver Sims in Business Component Factory (Wiley, 2000)珦uggest using component diagrams for application and even enterprise architecture. The OMG seems to have adopted this philosophy.

[click for larger image] Component Diagram Evolution In UML 2.0, components are now simple boxes with a component stereotype, either the 弎andaged box� visual stereotype or the <<component>> textual stereotype.

UML component notation has improved, as you can see in �Component Diagram Evolution�, which shows both a UML 1.x component diagram and a UML 2.0 component diagram. The most noticeable difference is the component notation itself: Components are now simple boxes with a component stereotype, either the 弎andaged box� visual stereotype or the <<component>> textual stereotype.

The second notation difference concerns interfaces. A socket notation has been added to indicate a required interface: In 鏠omponent Diagram Evolution,� the Student component requires the Access Control interface, which is provided by the Security component. The combination of the required interface notation and the traditional lollipop notation is often referred to as ball-and-socket notation. This notation is also used on UML deployment and class diagrams.

Detailed Design Diagrams

The good news? Class diagrams, the mainstay of most object system designs, are little changed㻡 few new stereotypes and the ball-and-socket interface notation are about it. Sequence diagramming notation is also basically the same, although the addition of interaction frames in UML 2.0 makes it a little more robust. An interface frame is depicted as a rectangle with an operator box in the top left corner; the �Sequence Diagram� uses an interaction frame to model an if statement. Interaction frames have one or more sections, separated by dashed lines, and are used to model if/switch logic, loops and parallel logic. The sequence diagram also depicts the traditional way of modeling a loop using an iteration marker, an asterisk, to indicate that the use case logic is potentially invoked several times. This notation for looping is still valid in UML 2.0.

[click for larger image] Sequence Diagram This diagram uses an interaction frame to model an if statement. It also depicts the traditional way of modeling a loop using an iteration marker, an asterisk, to indicate that the use-case logic is potentially invoked several times.

Collaboration diagrams were renamed communication diagrams, and state chart diagrams are now state machine diagrams; however, the notations for these two diagrams, along with object diagrams, haven㦙 changed significantly. Communication diagrams are equivalent to UML sequence diagrams and are typically used when you need a bird𠏋-eye view of collaborating objects. State machine diagrams are used to explore objects and components that exhibit complex and different behavior, depending on its current state. For example, you can withdraw money from an active account, but not an overdrawn one珳ifferent states, different behavior. UML object diagrams are used to explore the relationships between instances of objects, although I seldom use them.

Timing diagrams, for exploring the changes in state over time of an object or component, have been added. Although business application developers will rarely need them, I suspect that the real-time community may find them very useful.

What Were They Thinking?

I find little use for two new diagrams in UML 2.0. The first is the composite structure diagram, which is used to show the objects involved in a collaboration. I𠐔e heard that this is good for describing design patterns, but frankly, I think that a combination of class diagrams and sequence diagrams is more effective: They show greater detail, and developers are already familiar with them. The second questionable addition is the interaction overview diagram, which depicts a collection of interaction frames with flow between. It𠏋 too complex to sketch effectively on a whiteboard, and although a CASE tool vendor could do something interesting with it, gut feel tells me that this will be a low priority. I suspect that these two diagrams will receive scant attention in coming years.

The OMG Just Doesn㦙 Get It

Why is the release of UML 2.0 a non-event? Because it doesn㦙 address any of UML 1.x𠏋 gaping holes. Every single system that I𠐔e ever built implements business rules and a user interface, and uses a database to persist objects鎆et these three issues still haven㦙 been addressed. Yes, a business rules working group exists within the OMG, so I hope we𠑥l see something in UML 2.1. However, UML still doesn㦙 address user interface development, a serious problem when you consider that the user interface is the system to most users. Several methodologists𡟙ncluding Craig Larman, Jim Connalen, Geri Winters and myself𤪔ave suggested approaches to user interface flow modeling (storyboarding) using UML, but no official effort to develop a common profile exists.

UML𠏋 lack of a data modeling profile is of particular concern to me, and several unofficial efforts are underway. IBM Rational has published its own data modeling profile (but unfortunately it𠏋 constrained by their toolset). Oracle includes UML data modeling in JDeveloper 10i, but at press time they hadn㦙 published a publicly available profile for that work. I maintain a profile, which is effectively open source㻡nyone, OMG member or not, may contribute. Several tool vendors are looking at it, and some are contributing, so it leads me to question whether the IT industry even needs the OMG to develop UML anymore𡟙f we can develop software in an open-source manner, why can㦙 we also create a standard modeling language? Needless to say, I鏆 like to see a similar effort for user interface modeling, or, for that matter, other forms of modeling, to help prove my point.

UML and agility are orthogonal concepts鎆ou can be agile using UML or non-agile; it𠏋 up to you. My advice is to keep your modeling efforts simple, inclusive, cooperative and focused on value. Agile models are just barely good enough, and I𠐔e found that UML models can be just as agile as non-UML models. The vast majority of models are sketches done on whiteboards that are quickly discarded once they𠆫e no longer needed, and that𠏋 perfectly fine. Modeling, including but not limited to UML, is an important part of any agilist𠏋 toolkit.

Editor𠏋 Note: The two diagrams are modified from The Object Primer, 3rd Edition: Agile Model Driven Development with UML 2, to be published in March 2004 by Cambridge University Press.