Since its adoption in 1997, the Unified Modeling Language has been managed by the vendor-neutral Object Management Group (OMG). With origins in the work of computer scientists James Rumbaugh, Ivar Jacobson and Grady Booch, Rational Corp.’s famous "three amigos," UML has broken free from its proprietary roots to become an evolving public standard. OMG committees are now defining ways the next version of the language can facilitate the design of Web applications, enterprise application integration, real-time systems and distributed platforms (CORBA, DCOM and Enterprise JavaBeans). At press time, a UML 2.0 Request for Proposals was scheduled for September 2000, with the new UML 2.0 version available sometime in mid-2002. With so many new technologies competing for inclusion in the standard, however, is there a risk that UML will become bloated and unwieldy—or is it too late?
That was precisely the topic at CMP Media’s second annual UML World conference in New York on June 15, 2000, where a panel of industry luminaries discussed why and how the Unified Modeling Language needs simplifying. Software Development Technical Editor Roger Smith moderated the roundtable discussion among Cris Kobryn, cochair of the OMG UML Revision Task Force and the cochair of the OMG Analysis and Design Platform Task Force; Martin Fowler, chief scientist for Melrose, Mass.-based ThoughtWorks; Scott Ambler, president of Ronin International, a software services consulting firm; and Peter Coad, CEO of TogetherSoft Corp. The group focused on the UML change mechanism—namely, what the UML kernel is or should be and how to extend it.
All of the roundtable participants are renowned authors. Martin Fowler’s UML Distilled (Addison-Wesley, 1999) is now available in a second edition. Scott Ambler’s The Object Primer (Cambridge University Press, 2000) is also now in its second edition. Peter Coad’s most recent book is Java Modeling In Color With UML (Prentice Hall, 1999). Cris Kobryn’s recently published "UML 2001: A Standardization Odyssey" (Communications of the ACM, Oct. 99), describes the evolving UML standard, including the 1.4 specification, due out in the fall, and UML 2.0.
Software Development: Cris, what is the UML kernel and how can we extend it?
Cris Kobryn: You can look at the kernel as the substantive UML, that part that is used to model 89 percent of the common problems. These would be defined in the metalevel by metaclasses or other meta-entities with rich semantics, as opposed to those with sparse semantics. And the heuristic here is that there were some things in the UML specification—800 pages of wonderful stuff—that have a single sentence of semantics, while there were others that have tens of pages. You can write a parser that could tell you where to find the rich semantics, and it isn’t as controversial or as difficult as some would think.
The assumption of any good designer is that the next generation needs to subtract from the language, not to add to it. That is, a design is done when there is nothing more to add or take away. We need to practice this ancient principle of good design, as the majority of people don’t have time to do metamodeling.
Extension mechanisms for the 1.3 release are quite fixed, and are being defined in a more rigorous way in terms of profiles, separate from model libraries. In the future road map, we’re looking at metaclasses as first-class extensions. How effective is the Object Management Group’s UML process? The most objective proof is in the usage. The UML process is being used inside and outside OMG, being successfully applied to a wide range of application domains. The publicly available UML/OMG specification is also being proposed to ISO for fast-track standardization, and that is likely to happen next year. So it will probably be a legal international standard in 2001.
As far as the evolution of UML/OMG specification: A bunch of smart methodologists aren’t just splitting semantic hairs. The road map is well defined, and the 1.3 release is reasonably mature and fixes many bugs in the language. You shouldn’t confuse UML with the reference implementations your vendors provide, because a real problem facing our community is that the vendors have not successfully or correctly implemented the 1.1 release, let alone 1.3. And 1.4 should be out later this year. The 1.5 release likely will begin to plug the gap between 1.4 and 2.0, and the key things we are promised for the 2.0 release are a streamlined kernel, increased customizability and improved support for component-based development tools.
Specifically, the 2.0 release will architecturally streamline the kernel and be more in line with other OMG initiatives for meta data integration and repository, such as the meta-object facility. There will be increased support for component-based development, in particular, implementations that use EJB, CORBA components and COM+.
There will be improved support for model management, including layering assistance, multiple viewpoints and component frameworks. The consensus now is that model versioning is beyond the scope of the new release. Versioning and diagram interchange should be handled by another architectural initiative within OMG, namely the XMI initiative (the XML Metadata Interchange Format specification, or XMI, is a proposal for a standard for object data exchange over the Internet). You should be able to use XMI to interchange not only your model semantics but your diagrams.
To what extent will vendors support the major revisions? Well, we need to keep them on schedule. I think it’s painfully obvious that modelers want UML to be easier to learn and apply. They are frequently overwhelmed by UML’s complexity, and they’ve reported a wide range of bugs and usage issues, many of which are beyond the scope of a minor revision of the language. But users are frustrated by the lack of tool support and often confuse tool limitations with UML specification limitations, making it hard for them to criticize UML intelligently and accurately. UML vendors are market-driven. If users demand UML 1.3 or 1.4 or 2.0 support, vendors will provide it.
Scott Ambler: UML is simply a bunch of bubbles and lines, labels and semantics. And I’d like OMG to keep it that way.
Two days ago, I worked with Norm Kerth and Neil Pitman here at UML World on a one-day workshop called the UML DesignFest. For the first hour, Norm talked about why UML is important and described its main attributes. Then he described two assignments. We organized the room into groups and told them to go forth and model. Then the three instructors either pretended to be users and asked each group questions, or we acted as UML experts and helped them model. For the most part, we left the groups to their own devices. The groups were allowed to model in the morning and when they came back from lunch, they saw what the other groups had done, and learned from what everyone did. At the end of the day, we did a retrospective or evaluation, where the groups presented what they learned and what worked well.
This is the third time that Norm and I have worked on this workshop, and one thing concerned me. This year everybody did mostly the same thing: They used use cases, some sequence diagrams and some class diagrams. One group did an activity diagram after awhile, but that was the only difference. Last year, at the 1999 UML World conference, Norm and I taught the exact workshop—same notes, same presentation—but the groups had a much wider range of approaches and some even went outside the boundaries of UML. Some people used data models, which concerned me, but I’m open to that. They also used screen mockups, a very normal thing to do. This year, no one did screen mockups. These people were professional software developers; they were all very experienced; they knew what they were doing; but they didn’t think outside the bounds of UML.
Kobryn: Scott, did they do any metamodels?
Ambler: No, and that was a real problem. If they had only metamodeled, then things would have been fine. The students also commented that they needed a methodology, process or some sort of guidance on how to apply UML. UML, and rightfully so, is not a methodology or a process. But their comments do show support for software processes that actually meet the needs of real-world development. Notice I didn’t mention the Rational Unified Process (RUP).
I’m going to take a contrarian view and argue that UML isn’t complex enough. From my experience as a real-world developer, UML is not sufficient. I am constantly asking, what do I need to do to actually deliver application software? I don’t do a lot of embedded real-time work, other than business software, which I think is the majority of development done today. When I ask myself that question, I quickly discover that there are a few deliverables missing in UML—such as data models or user interface models—that I normally do everyday to deliver software. I need to understand the user interface and how I’m going to store data. And I don’t see these things in UML. Perhaps Cris could help address that in the UML 2.0 release.
I had an interesting experience during the DesignFest: One group was struggling with class modeling. I suggested that they use a strategy pattern, which they hadn’t heard of. To explain how the strategy pattern works, I drew an activity diagram for the logic. I used it more or less as a flow chart. One woman had never seen an activity diagram before even though she had been doing object modeling for two years—not surprising, since activity diagrams aren’t well covered in the literature. She was just amazed. She had been misapplying sequence diagrams to model the same sort of thing, and had to use several sequence diagrams to do what I was able to do in one activity diagram. She commented that it was worth the money that she had paid for the conference just to learn about this one deliverable.
We also learned to use the right tool for the right job. The right tool can be a white board or paper napkin, but other times, I prefer a full-fledged CASE tool. A good CASE tool can simplify and automate your use of UML if you’re smart about the way you use it.
Figure 1. Timeline: The evolution of the Unified Modeling Language within the OMG. |
SD: Should UML take user interface design or ergonomics into account?
Peter Coad: Scott, in my mind, is the champion in the literature and on the platform in saying that UML is a modeling language and there are other things one might do like user interface design to sketch it out. Jared Spool’s Web Site Usability: A Designer’s Guide (Morgan Kaufmann, 1998) is the classic work here, combining user interface design and things like class diagrams and sequence diagrams and features lists. Even in a class diagram and a low fidelity UI sketch, there is content going back and forth and methods you discover. Will you eventually sit inside of a UML model, do business-based things and have a (optimized) user interface? Does it have to be part of UML? I don’t see how that fits, but it is part of good engineering practice.
Ambler: I think there is a need for a profile for the Windows Navigation diagram or user interface flow diagram. We’re almost seeing it with some of the Web extension things anyway. If it could be extracted to UI stuff instead of Web UI stuff, then I think that would be better. I question the need for a Web profile, to tell you the truth.
Martin Fowler: I disagree. If different people are doing the same thing in incompatible ways, then you should try to unify it before you bring it into UML. I don’t see that happening yet with the UI design. There are a lot of interesting UI ideas floating around, but I don’t think we’ve reached a point where we want to drag them into the standard. Just because something is important doesn’t mean it has to be in UML.
SD: Peter, as a vendor, what do you think your role is in supporting different UML versions?
Coad: I’ve spent the last 10 years working with model builders and trying to build better models, so this is a subject near to my heart. I’m very grateful for the work that Cris and his crew are doing in terms of the metamodel, as well as giants in metamodeling like Brian Henderson-Sellers.
I really admire their work and that means that I want to be able to support it in as much detail as I can. So, we’ve endeavored to use software to simplify UML. One way we try to make things simpler is through a consistent user interface. When you start our product, TogetherJ from TogetherSoft, you choose what role you want to play, whether it’s as a business modeler, designer or developer. The product then configures based upon your role.
If someone is really into programming, he can actually learn some things about UML by starting with source code, what he is currently working on, and beginning to see that there is a higher level view in terms of diagramming. Our desire as a tool builder is to provide high-quality support for UML; consistency in the user interface helps.
I find that people primarily use one or two static diagrams in their development work, especially if they are new to UML. In our tool, however, we use deep parsing from source code to support more dynamic types of models, where we can generate sequence diagrams or an initial time-ordered sequence of object interactions.
A majority of developers still build in source code—working with linguistic rather than spatial intelligence. It’s this larger audience that we’re striving to reach, educating programmers to pay attention to design views. We’ve found that view management is critical. We use a diagram engine with an exposed API to allow users to decide which of the 10 or 12 UML diagrams they want to see at any given time. For example, you can take a JDBC scheme and reverse engineer 10 tables and flip them into Enterprise JavaBeans. If I flipped them into EJBs, the 10 tables turn into 40 symbols. By doing automatic filtering, I can drop it down to 10 domain-based diagrams. Therefore, this area of view management needs to include a regular expression language to have real control, so business analysts can focus on those things that are most important.
SD: Martin, I’m sure you have a unique angle here, since you’ve said that you weren’t all that high on UML tools. I’ve heard you say that you can do decent modeling with blackboards and chalk. But is UML getting too complex for that?
Fowler: UML definitely requires simplification. Although, I don’t necessarily think simplification is easy, both for technical and essentially personality reasons. Remember, UML is as big as it is because a bunch of methodologists had to each put in his favorite technique.
But as UML matures, not all good techniques need to be part of it. UML’s strength is that it allows people doing similar things to agree they’re doing similar things and use a common notation to express that. If people want to do something different, say like Doug Rosenberg’s robustness diagrams, I don’t think it needs to be swallowed into UML.
That still leaves UML somewhat large, and Cris has got a difficult job ahead of him, banging together heads to try to minimize the kernel. So, I’ll take a stab at it and propose a kernel. I’ve found in practice that there are three techniques that really count in UML: use cases, class diagrams and interaction diagrams. My kernel would begin around these three techniques. The rest can go into some kind of extension mechanism. So, I’ve gotten rid of a good bit of it already, but there is more. The really useful part of use cases is the textual description. Use case diagrams, I find, are handy but not essential. Let’s remove use case diagrams from the kernel, leaving use cases as a heading but without the diagram. That’s nice and small.
There are many notations that are valuable for specialized purposes, but what notation is valuable across most purposes? I think the notions of class, attributes, operations, associations and generalization are valuable. I can’t think of very much to take out of interaction diagrams. Perhaps collaboration diagrams could be dropped, because they aren’t used so much these days. The sequence diagrams do seem to be more commonly used. I’m feeling a bit aggressive, so, yes, let’s take the collaboration diagrams out. We’re left with a heading for use cases, a few bits of class diagrams and sequence diagrams. Small enough?
SD: But use case diagrams are popular. What about those who find that they are the best way to communicate with both managers and end users?
Fowler: I’m not saying you should only use the kernel I’m proposing. In fact, I’m not even saying that you should only use UML. Use whatever techniques work for you. When I think about the kernel, I ask, "What is the minimal amount I can teach someone to get him comfortable with the idea of modeling?" I don’t think anybody would actually model using only the kernel, not even me. But that’s my proposed minimum.
SD: Shouldn’t the tool vendors support more than the minimum?
Fowler: Every tool vendor should support the kernel and the various extension pieces of UML. And a buyer should be able to layer them over each other and get some idea of what he or she is buying.
Kobryn: How to split the kernel and its extensions might not be as difficult as people think. The UML metamodel is reasonably well structured. There are flaws, of course, but there are various cleavage planes. Are vendors compliant fully or partially with the foundation semantics, behavioral semantics, state machines? Are they separating semantics from notation? There are about a dozen, but vendors aren’t rating themselves and the users aren’t asking them to do so.
Coad: In order to get more people to use UML, OMG could provide a service by predefining profiles. UML users also need to be able to pick and choose what they want—to have greater ability to customize their tools.
SD: Would UML be better off in the hands of a benevolent vendor rather than OMG?
Kobryn: It would be hard to find a single, powerful entity that most people would accept. The very idea of a standard is that it needs to be shared. I’ve hoped I’ve made it clear that the OMG process seems to be working. It comes down to who is participating.
I want to encourage anyone who thinks that OMG and UML aren’t meeting his needs to please submit issues. We just knocked off 162 official issues for this latest release (1.3) and 458 issues for the previous one. Participate in the revision task forces, respond to the requests for information and requests for proposals. We hear you. We know you’re in pain, and we want to make it better. But I ask two things: One, when you have problems, please don’t give us abstract wish lists. Our rule has been for many years: Give us three concrete examples where you can’t do X. Send them to me, and I will make sure that they’re addressed. Second, chat with your vendors about the discrepancy between what is in the specification and what their tools support.
Fowler: UML went into OMG in the first place because it began with one vendor driving it and nobody else wanted that vendor to have control. That history brought us to the position where OMG is handling UML and they’re doing a reasonable job. I’m quite happy with sticking with OMG. I certainly can’t think of any vendor I’d like to hand it off to.
SD: Why do we need a kernel for UML? Why not let the best practices—the cream—rise to the top, or let the market decide?
Kobryn: In order for that to occur efficiently in terms of a metamodel architecture, you need something with profiles. Natural selection should determine what is in or out, but first we have to deal with some things that have very sparse semantics. We’re saying clean up the language—then let natural selection take over. Also, because we’re involved in the bowels of this hairy thing, some clean up has to occur architecturally as well as at the user level. The way to do this is through profiles around a core, similar to the UNIX kernel idea. Nothing different here: just good computer science, good software engineering and good modeling.
SD: If certain elements like the state diagrams and activity diagrams aren’t part of the kernel, won’t tool vendors find a way to adopt their own profiles in place of these elements?
Fowler: I don’t see tool divergence on something like state diagrams as a problem. The way I imagine it, state diagrams would be an extension of the kernel; they’re part of the standard. If you want to support state diagrams, you’ve got to do it as part of the UML standard. Again, the kernel isn’t the whole UML; the point is to pick out a small bit. Let the vendors start doing something incompatible and when the incompatibilities become a problem, then the UML people should kick in and say, "OK, let’s unify." UML started, remember, because lots of people were doing incompatible things and we unified them.
Kobryn: I agree with that, but also with the original point. Some of the richest semantics in UML have to do with state charts and activity graphs. We certainly wouldn’t throw the kid out with the bath water. State charts and activity graphs would either be put into a profile or a well-defined metamodel extension with a compliance point. So let’s be very clear: If you want to do something leaner and meaner, along the lines that Martin and Peter suggest, which I agree is a good incremental approach, you could still do this as an optional compliance point. But it needs to be well-defined and clear, so the user knows what he is getting when he buys a tool.
SD: What would each of you like to see in the new 2.0 release?
Ambler: I challenge the OMG to take more of a software engineering approach. Why don’t we first set the requirements for all of these new profiles we’re talking about? I’ve posted on my Web site, www.ambysoft.com, some fundamental requirements for a persistence profile that blows a possibly benevolent vendor’s profile right out of the water. This is my challenge to the OMG: Requirements first, then design.
Fowler: I don’t feel UML needs a lot of repairs at the moment. Extending XMI to allow diagrams to be transferred would be a good idea—those are both discussed as part of a request for proposals. I can’t think of anything else that concerns me. When it comes down to it, UML is just a diagramming notation and there are far more important things out there: good software design principles, understanding patterns, looking at software processes. The great thing is that UML has kind of settled one silly argument; we can now move on to more interesting stuff.
Coad: I’ve found that working with a team can lead to a collapsing of complexity. You work in more detail for awhile and things get simpler. I’m at a loss sometimes as to how to describe it: Good models have a music or a rhythm. It takes work to get there, but it’s a worthy activity. I’m grateful that we are at least striving to find that simpler set that rings true. In the 1600s, Blaise Pascal wrote, "I would have written a shorter letter, but I didn’t have the time." Maybe now is the time to consider the shorter letter form, which will help all of us in the teams we work with and lead.
Kobryn: We’re at a point where the kernel exercise won’t be a major effort, if we have the support of the community. Regarding requirements, there is a requirements document to be finalized in a few months that is fairly tight right now. It’s not prescriptive. It’s not dominated by any one vendor, and I would encourage everyone to review it. In terms of the public, I hope I’ve raised some awareness that UML is not necessarily what you’re exercising in your favorite modeling tool. Ask your vendors to at least clarify whether their products comply with UML 1.1 or 1.3 or beyond. Finally, I want to encourage you to participate directly. Send me specific problems you can’t model within the scope of the Revision Task Force and we’ll take a look at them. We’re not getting enough models where people can’t do something; we’re getting abstract, warm and fuzzy feelings. We’d like people who are having problems to sharpen those problems and put them in our faces. We have talented people who can help solve them.