UML 2001: A Standardization Odyssey As the UML reaches the ripe age of four, both its proponents and its critics are scanning the recent changes in the UML 1.3 revision. CRIS KOBRYN In a relatively short period of time the Unified Modeling Language has emerged as the software industry’s dominant modeling language. UML is not only a de facto modeling language standard; it is fast becoming a de jure standard. Nearly two years ago the Object Management Group (OMG) adopted UML as its standard modeling language. As an approved Publicly Available Specification (PAS) submitter to the International Organization for Standardization (ISO), the OMG is proposing the UML specification for international timescales of standards usually conflict with the standardization. It is anticipated that the “fast competitive need to use the latest technology as track” PAS process will complete sometime next early as possible. From a technical perspective, the year, at which time UML will be formally recog- need to achieve consensus encourages “design by nized as an international standard for information committee” processes. In this sort of environment, technology. sound technical tradeoffs are often overridden by The major benefits of international standardiza- inferior political compromises. Too frequently the tion for a specification include wide recognition and resulting specifications become bloated with patches acceptance, which typically enlarge the market for in a manner similar to the way laws become fattened products based on it. However, these benefits often with riders in “pork belly” legislation. demand a high price. Standardization processes are This article explores how the UML is faring in typically formal and protracted, seeking to accom- the international standardization process. It assumes modate a diverse range of technical and business the reader is generally familiar with the use of UML, requirements. From a business perspective, the and instead focuses on the language’s recent and COMMUNICATIONS OF THE ACM October 1999/Vol. 42, No. 10 29 future evolution. The processes and architectures Figure 1. The origin and descent of UML. for UML change manage- ment are examined, followed 2001? «document» by discussion of how these (planned major revision) UML 2.0 processes and architectures were used in the recent «refine» minor revision of the lan- guage (UML 1.3), and how 2000? «document» they may be applied in the (planned minor revision) UML 1.4 next major revision (UML 2.0), which is tentatively «refine» scheduled to be completed in «document» 2001. Factors contributing to 1999 the success of the UML will UML 1.3 be assessed here, followed by speculation on its future. «refine» Pre-Standardization 1998 «document» History UML 1.2 The UML started out as a collaboration among three «refine» outstanding methodologists September 1997 «document» who are collectively referred (final submission UML 1.1 to as “the Amigos”: Grady to OMG) Booch, Ivar Jacobson, and James Rumbaugh. At first «refine» Editorial revision with no significant Booch and Rumbaugh technical changes. January 1997 sought to unify their meth- «document» (initial submission UML 1.0 ods with the Unified to OMG) Method v. 0.8 in 1995; a year later Jacobson joined «refine» refinement dependency them to collaborate on the 1996 «document» slightly less ambitious task UML 0.9 of unifying their modeling languages with UML 0.9 [1, 2]. The UML static struc- «refine» ture diagram in Figure 1 «document» shows these early specifica- 1995 Unified Method document stereotype tions and their descendents 0.8 in historical perspective. The UML reaped the benefits and assumed the responsibilities of its privi- modeling experts assumed the responsibility to make leged birth. Users quickly recognized the advantages of the language a formal standard as well. The “UML a common modeling language that could be used to Partners,” representing a diverse mix of vendors and visualize, specify, construct and document the artifacts system integrators, began working with the Amigos of a software system. They enthusiastically applied in 1996 to propose UML as the standard modeling early drafts of the language to diverse domains ranging language for the OMG. The Partners organized from finance and health to telecommunications and themselves into a software development team that aerospace. Driven by strong user demand, the model- followed a disciplined process. Since the process was ing tool vendors soon included UML support in their based on an iterative and incremental development products. life cycle, the team produced frequent “builds” and At the same time that UML was becoming a de draft releases of the specification, just as one would facto industry standard, an international team of do when developing a commercial product. 30 October 1999/Vol. 42, No. 10 COMMUNICATIONS OF THE ACM Figure 2. Activity diagram showing OMG processes. • Incomplete semantics and notation for activity graphs. Activity graph semantics, which were added relatively later in the swimlane process, were not fully integrated with Submission TeamTask Force Revision Task Force the state machine semantics on which start activity activity control flow they depended. In addition, some nota- Begin tion conveniences required by business fork of control modelers were missing. Develop technology Issue RFP specification • Standard elements bloat. The language RFP specification included many standard ele- [issued] conditional thread join of control ments (stereotypes, tagged values, and constraints) that were hastily added to Submit specification draft object flow address the requirements of various com- Specification peting methods groups. Many of these [optional] [initial input value proposal] Collaborate w standard elements had sparse semantics competitive submitters and were inconsistently named and Evaluate initial submissions organized. join and fork of control Finalize • Architectural misalignment. The submitters specification Specification fell short of their goal of implementing a [final proposal] 4-layer metamodel architecture using a Evaluate final 1 submissions strict metamodeling approach. Instead they settled for the pragmatic, but less rig- Vote to recommend orous, loose (non-strict) metamodeling guard approach. This adversely affected the inte- Specification [if YES] [if NO] [adopted] branch gration of UML with other OMG model- ing standards, such as the Meta Object Revise Implement specification Facility (MOF) [5]. specification Specification [revised] Enhance specification Recommend Rather than delay the standardization of revision UML, the submitters resolved to address some of these problems in the next revision of else [if Enhanced] end activity the language. Processes for Evolution To better understand the process for UML evolution, it will be helpful to examine the The Partners focused on improving the language’s generic mechanisms that the OMG provides for stan- architecture and formalism, and ensuring that it was fully dards revisions: Request for Proposals (RFPs) and general purpose (i.e., that it met the demands of other Revision Task Forces (RTFs) [6]. The manner in mainstream methods in addition to those of the Ami- which the RFP process complements the RTF and gos). They also defined a facility for interchanging UML submission processes is shown in a UML activity dia- models between tools and an optional language for con- gram in Figure 2. In this diagram the submission, straints. The Partners tendered their initial UML pro- RFP and RTF processes are partitioned into vertical posal to the OMG (UML 1.0) in January 1997 [7]. After “swimlanes” labeled for the stakeholders who drive nine months of intensive improvements to the specifica- each process (Submission Team, Task Force, and Revi- tion they submitted their final proposal (UML 1.1) in sion Task Force, respectively). Activities are shown by September 1997, which the OMG officially adopted as shapes with straight tops and bottoms, and with convex its object modeling standard in November 1997 [8]. arcs on the side; object flows that are inputs to or out- It is important to note that the UML suffered some puts by an activity are shown by rectangles. undesirable side effects from its relatively fast ride The RFP process is the OMG’s primary mechanism through the OMG submission process. Although the for adopting new specifications and enhancing existing infrastructure and most of the superstructure of the lan- 1 guage were sound, several significant problems were In strict metamodeling, every element of a Mn level model is an instance of exactly one element of a Mn+1 level model. In loose metamodeling a Mn level model is an instance known at the time of the final submission: of a Mn+1 level model. COMMUNICATIONS OF THE ACM October 1999/Vol. 42, No. 10 31 specifications. As the left and middle swimlanes show, that couldn’t be resolved quickly were delegated to spe- a Task Force issues an RFP that one or more Submis- cialized workgroups (for example, the Structural Work- sion Teams respond to with draft specifications referred group for issues related to static structural modeling) to as initial proposals. The Task Force then evaluates for further action. the initial proposals and provides feedback to the sub- Between Technical Committee meetings the work- mitters, who are encouraged to collaborate with com- groups functioned as virtual teams that recommended petitors before completing their final proposals. After corrections and clarifications to the issues assigned