Will UML 2.0 Be Agile or Awkward? The UML sits at an architectural crossroad. Will UML 2.0 resolve the problems of UML 1.x or will it succumb to the dreaded second-language syndrome?
he Unified Modeling Lan- methods such as eXtreme Pro- discussion is primarily concerned guage (UML) has been gramming (XP); and the conver- with the UML 2.0 Infrastructure T widely accepted throughout gence of visual modeling with and Superstructure RFPs that the software industry and success- visual programming techniques. together define the requirements fully applied to diverse domains Considering these trends, as well for the modeling language part of ever since it was adopted by the as numerous requests for UML the specification. Object Management Group improvements, it should not be The UML 2.0 major revision (OMG) in 1997. In those four surprising the OMG has decided represents both an excellent years, UML has become the de that UML 1.x is ready for a opportunity and a serious respon- facto standard for specifying soft- major revision. sibility for its language designers. ware architectures that increase in Consequently, the OMG has It is a chance for them to resolve value as we progress from simple issued four RFPs for UML 2.0: the shortcomings of UML 1.x design models to multiview an Infrastructure RFP concerned and make the language more cur- enterprise blueprints. Indeed, it is with restructuring the basic con- rent and precise. At the same becoming difficult to find a soft- structs and improving customiz- time, it charges them with the ware project with more than 10 ability; a Superstructure RFP to responsibility for improving the developers that does not employ improve more advanced con- language without succumbing to UML in some way to specify part structs such as components, scope creep and design-by-com- of the software architecture. activities, and interactions; an mittee compromises. For reasons While the UML has been Object Constraint Language RFP we will discuss, discharging this growing in popularity among concerned with increasing the responsibility for UML 2.0 will software developers, the software precision and expressive power of likely be challenging. methods and practices it supports UML’s constraint language; and a have also been evolving steadily. Diagram Interchange RFP to Issues and Opportunities Some of the relevant changes to address making model diagrams UML 2.0 offers us an opportu- methods and practices include interchangeable between tools nity to solve many of the major the maturation of component [2–5]. The four RFPs imply the issues associated with UML 1.x. architectures and methods; the UML 2.0 specification will likely Some of the problems commonly transition from heavyweight, rig- be decomposed into four separate cited include excessive size, gratu- orous methods such as the Uni- and complementary parts as itous complexity, imprecise
PAUL WATSON fied Process to agile, lightweight shown in the figure here. This semantics, non-standard imple-
COMMUNICATIONS OF THE ACM January 2002/Vol. 45, No. 1 107 Technical Opinion
reduce the UML’s size and com- Planned evolution of OMG UML. plexity. UML designers can learn a 2002 great deal from how the agile, (planned) informal methods (for example, «document» UML 2.0 XP, Feature-Driven Development, and Crystal) are causing their heavyweight, rigorous counterparts (for example, Unified Process) to «document» «document» streamline their techniques and UML 2.0 UML 2.0 Diagram processes. They can also learn how «document» Superstructure «document» Interchange UML 2.0 the Java and HTML/XML design- UML 2.0 OCL Infrastructure ers streamlined C++ and SGML, respectively. Like the Unified Process, the UML needs to prac- tice better parsimony and pragma- «document» Q2 2001 UML 1.4 tism. Perhaps the best place to Editorial revision start reducing UML is by defining without significant a concise and precise language ker- technical changes. nel. (By “kernel” I mean the 20% «document» of the language that is used to 1999 UML 1.3 specify 80% of the common soft- ware problems.) Defining a language kernel will make UML not only easier to «document» UML 1.2 learn, but to implement. The ker- 1998 nel can be used in conjunction with a mature profile mechanism (which includes metaclasses as «document» well as stereotypes) to define the 1997 UML 1.1 more advanced language features (adopted by OMG) such as the 80% of UML 1.x used only 20% of the time. They can mentations, limited customizabil- learn, apply, and implement. also facilitate language customiza- ity, inadequate support for com- After six years of working on the tion by vendors and users, so that ponent-based development, and UML specification and RFPs, I UML can be efficiently tailored inability to interchange model am still amazed at how frequently for different domains (for exam- diagrams. According to OMG’s experts need to consult the UML ple, financial services, health care, policies and procedures, these specifications regarding semantic telecom) and platforms (J2EE, substantive issues can only be and notational minutiae. If Zen .NET). addressed by a major revision to mind is beginner’s mind, then A concise and precise kernel UML. UML mind does not yet grok will likely accelerate the compli- It has long been recognized Zen. ance of UML implementations that UML 1.x is too large and Hopefully, the next major revi- with the specification, something complex, making it unwieldy to sion will allow us to significantly that is long overdue. More than
108 January 2002/Vol. 45, No. 1 COMMUNICATIONS OF THE ACM four years after the adoption of 2.0 will likely need to reduce dreaded syndrome in [1]: UML 1.1, no modeling tool ven- some of the impedance between dor has yet fully implemented it the object paradigm that under- An architect’s first work is apt to or any subsequent UML 1.x lan- lies UML 1.x and the component be spare and clean. ... This second guage specification! We need to paradigm that has evolved from it is the most dangerous system a man remedy this situation with UML and other sources. ever designs ... The general ten- 2.0, and an excellent way to Lastly, UML 2.0 needs to sup- dency is to overdesign the second system, using all the ideas and frills that were cautiously sidetracked on Web resources. the first one. The result, as Ovid Location Description says, is a “big pile.” www.omg.org/uml Contains links to OMG UML resources, such as specifications, articles, and related webs. Although the pathology of
www.uml-forum.com Contains links to the UML 2.0 Working Group this syndrome was first diag- and UML Revision Task Force webs, as well as nosed in large, complex software other UML resources. engineering projects, the malady www.telelogic.com/publications/uml_models/ UML Models and Methods column by author also manifests itself in other tech- that addresses timely issues related to UML nology endeavors such as soft- modeling techniques and methods. Includes ware language design. Here, we discussions of latest minor and major revisions. consider a variation of the dis- ease: the second-language syn- begin is by defining a kernel that port complete model inter- drome known to infect various can be efficiently implemented change, including notational programming language design and tested for compliance via the diagrams. Until this is accom- efforts such as those associated XML Metadata Interchange plished it will be impractical to with Ada, C++, and CLOS. (XMI) standard. effectively share models among I am not claiming that UML UML 2.0 must also make the competing modeling tools. 1.x is spare and clean; on the con- component concept a core con- trary, I consider the language struct that evolves throughout the Second-Language unwieldy and complex. (In fact, software life cycle, rather than an Syndrome one could argue UML 1.x suf- afterthought for the implementa- Since we understand most of the fered from second-language syn- tion phase, as it sometimes problems described here reason- drome during its initial appears in UML 1.x. Although ably well, one might think it unification process!) Despite this the recent revisions to UML 1.4 should be relatively straightfor- difference between UML 1.x and make it easier to distinguish ward to solve them with the the “architect’s first work,” I between components (for exam- UML 2.0 revision. However, we expect that second-language syn- ple, EJB Entity Beans, COM need to keep in mind that since drome will still be a serious prob- objects) and the artifacts associ- we are dealing with the second lem for UML 2.0 for two reasons: ated with them (for example, EJB major version of UML we will The requirements for the four JAR files, DLLs), a good deal of likely need to contend with the separate RFPs (contrast this with work remains before UML 2.0 second-system effect, also known one for UML 1.x) are so exten- can fully support component as the “second-system syndrome.” sive and ambiguous it will be dif- architectures and methods. In Frederick Brooks, Jr., first ficult to prevent scope creep, let order to accomplish this, UML described the pathology of this alone reduce features. And the
COMMUNICATIONS OF THE ACM January 2002/Vol. 45, No. 1 109 The UML 2.0 major revision represents both an excellent opportunity and a serious responsibility for its language designers. It is a chance for them to resolve the shortcomings of UML 1.x and make the language more current and precise.
record number of companies sub- the experiences of others as well mitting to these RFPs will likely as their own (see the table here). make UML 2.0 vulnerable to a Besides Brooks, they would be large number of design-by-com- well advised to learn from design- mittee compromises. ers of both elegant and baroque languages. (Please fill in your own Treatment and Prognosis favorite language choices here.) Fortunately, we have known What should we expect from how to effectively treat second- the final submission for UML 2.0? system syndrome and its vari- We should expect architectural ants since [1]: moderation (not to be confused with design-by-committee com- How does the architect avoid the promises) to prevail, and a more second-system effect? Well, obvi- agile and more extensible UML to ously he can’t skip his second system. result. If the UML 2.0 designers But he can be conscious of the fall short of this, we should start peculiar hazards of that system, searching for a new modeling lan- and exert self-discipline to avoid guage and expect natural selection functional ornamentation and to to take its course. c avoid extrapolation of functions that are obviated by changes in References assumptions and purposes. 1. Brooks, F. The Mythical Man-Month, Anniver- sary Edition. Addison-Wesley, Reading, PA 1995. Of course, exhorting others to 2. Object Management Group. OMG UML 2.0 Infrastructure RFP, document ad/00-09-01. exert self-discipline and to Sept. 2000. enforce architectural integrity in 3. Object Management Group. OMG UML 2.0 language design is much easier Superstructure RFP, document ad/00-09-02. Sept. 2000. than practicing it ourselves. This 4. Object Management Group. OMG UML 2.0 is especially true when the lan- OCL RFP, document ad/00-09-03. Sept. 2000. 5. Object Management Group. OMG UML 2.0 guage design is occurring in a Diagram Interchange RFP, document ad/01- consortium with a record num- 02-09. Feb. 2001. ber of participants. Conse- quently, I expect UML 2.0 Cris Kobryn (Cris.Kobryn@telelogic. designers will find that maintain- com) is the chief technologist at Telelogic ing basic project and architec- and co-chair of both the UML Revision Task tural discipline is far more Force and the Analysis and Design Task Force at the OMG. challenging than fulfilling any of their technical requirements. In facing this challenge, I hope the UML designers learn from © 2002 ACM 0002-0782/02/0100 $5.00
110 January 2002/Vol. 45, No. 1 COMMUNICATIONS OF THE ACM