| Lesson 5 | Recognizing patterns of reconciliation |
| Objective | Summarize the three-way comparison between the diagrams. |
Object Model - Value
Reconciling the different diagrams can be the most effective way to build and enhance your models. Iterative review, refinement, and enhancement keep the process moving and remove any concern about missing information.
Each pass through the diagrams builds on information from the previous passes. The diagrams are revised and improved with each successive pass.
By the early 1990s, a few leaders had emerged from the field of methods and notations. Object-Oriented Software Engineering (OOSE), developed by Ivar Jacobson, is based around the use-case concept that proved itself by achieving high levels of reuse by facilitating communication between projects and users, a key success factor for IT projects. James Rumbaugh developed the Object-Modeling Technique (OMT) with an emphasis on the analysis of business and data intensive systems for defining a target problem, a second key success factor for IT projects. The Booch method, developed by Grady Booch, had particular strengths in design and implementation, defining and mapping a solution to the target problem, a third key to successful IT projects. These significant contributions are like the legs on a three-legged stool:
the combination of the three methods and their notations supported the entire range of requirements needed to create a single, comprehensive software-modeling standard.
It is important to point out that many other methods provided some of the same three key factors. The difference is that they did not aggressively seek to combine their efforts to address the bigger picture, a standards-based approach to modeling software. In October
1994, Grady Booch and Jim Rumbaugh, working at Rational Software Corp., started merging their two methods. The independent evolution of their two products was bringing the methods closer together anyway; Booch was adopting more of an analysis focus and Rumbaugh was
assuming more of a design focus. Now the deliberate reconciliation began in earnest. The effort resulted in a greatly simplified notation and a deliberate effort to address the need for a true language architecture rather than simply a notation. An architectural approach would bring the
needed semantic integrity and consistency for a durable standard.
A year later, in the fall of 1995, Booch and Rumbaugh had completed the first draft of the merged method referred to as Unified Modeling Language version 0.8. About the time that the draft was completed, Ivar Jacobson and his company, called Objectory, joined Rational
Software Corp., and the "three amigos"-Booch, Rumbaugh, and Jacobson-began integrating OOSE into the UML standard. The use-case concept brought to UML the essential user-centric elements that completed the range of features to make UML the comprehensive standard that it
needed to be to gain wide acceptance.
Booch, Rumbaugh, and Jacobson established four goals for the Unified Modeling Language:
- Enable the modeling of systems (not just software) using object-oriented concepts
- Establish an explicit coupling to conceptual as well as executable artifacts
- Address the issues of scale inherent in complex, mission-critical systems
- Create a modeling language usable by both humans and machines
The result of the collaborative effort of the three amigos was the release of UML versions 0.9 and 0.9.1 in the fall of 1996. However, despite the fact that they sought feedback from the development community, they recognized the need for broader involvement if the UML was truly
to be a standard.
Enter the Object Management Group (OMG), the standards body that brought us CORBA, Interface Definition Language (IDL), and the CORBA Internet Inter-ORB Protocol (IIOP). By this time UML was being recognized as vital to the goals of many companies. It was in their
best interest to see that the standard get the support it needed to be completed. In response to this overwhelming need, the OMG published a Request for Proposal (RFP), and then the Rational Software Corporation created the UML Partners consortium, which was committed to
finishing what the three amigos had started. Contributing members of the consortium included a mix of vendors and system integrators: Digital Equipment Corporation, HP, i-Logix, IntelliCorp, IBM, ICON Computing, MCI Systemhouse, Microsoft, Oracle, Rational Software, TI, and
Unisys. The result of their efforts was published in January 1997 as UML 1.0.
In reading this brief history you have probably noticed that this all happened pretty fast. The drive to deliver the final version so quickly had its consequences. While the architecture infrastructure and even the superstructure were relatively well defined, some problems remained. For
example, the Activity diagram did not have the ties to the state machine semantics required to
support all of the features and notations needed for real business modeling. Also, many of the
Standard Elements were added hastily and had not been fully defined. Most important, the
meta-modeling approach fell short of the desired implementation, making it difficult to align UML
with the Meta-Object Facility (MOF), a foundation technology in the OMG's MDA strategy.
Fortunately, the standard is still evolving.
The OMG set up a Revision Task Force (RTF) to oversee the ongoing evolution of the UML
standard. The RTF is responsible for addressing all questions, changes, and enhancements to
UML and for publishing subsequent releases. To date, the RTF has taken up more than 500
formal usage and implementation issues submitted to the OMG for consideration.
The standard has since progressed through version 1.3 (1.2 was a purely editorial revision) and
on to version 1.4. The most recently adopted specification (September 2002) is version 1.4.1
with Action Semantics, which, as the name implies, added action semantics to the 1.4
specification. Action Semantics is a critical element in the creation of executable UML models.
Patterns of Reconciliation
To summarize, there are several different patterns of reconciliation:
| Use cases and scenarios |
| Use cases and the class diagram |
| The class diagram and interaction diagrams |
| Scenarios and interaction diagrams |
| The data dictionary and use cases |
| The data dictionary and the class diagram |
| Object diagrams and the class diagram |
Remember that nothing is ever set in stone. Everything should be tested and questioned. Use the diagrams as tools to encourage participation, to challenge the way people see the problem, and to solicit new ideas.