Section 1.2. Why UML 2.0?

1.2. Why UML 2.0?

The first version of UML allowed people to communicate designs unambiguously, convey the essence of a design, and even capture and map functional requirements to their software solutions. However, the world changed more fundamentally with the recognition that systems modeling, rather than just software modeling, could also benefit from a unified language such as UML.

The driving factors of component-oriented software development, model-driven architectures, executable UML, and the need to share models between different tools placed demands on UML that it had not originally been designed to meet.

Also, UML 1.x and all of its previous revisions were designed as a unified language for humans. When it became important for models to be shared between machinesspecifically between Computer Aided Systems Engineering (CASE) toolsUML 1.x was again found wanting. UML 1.x's underlying notation rules and its meta-model were (ironically) not formally defined enough to enable machine-to-machine sharing of models.

MDA and Executable UML

Two reasonably new approaches to system development inspired many of the improvements made in UML 2.0. In a nutshell, Model Driven Architectures (MDAs) provide a framework that supports the development of Platform Independent Models (PIMs) models that capture the system in a generic manner that is divorced from concerns such as implementation language and platform.

PIMs can then be transformed into separate Platform Specific Models (PSMs) that contain concrete specifications for a particular system deployment (containing details such as implementation language and communications protocols, etc.). MDA requires a formally structured and interoperable meta-model to perform its transformations, and this level of meta-model is now provided by UML 2.0.

For many of the same reasons, executable UML provides a means by which a PSM could contain enough complete information so that the model can be effectively run. Some day, you could conceivably drag around a few symbols, and complete, runnable software would pop out! An executable UML engine requires that the UML model be defined well enough for it to be able to generate and execute the modeled system.

Unfortunately, even though UML 2.0 is supposed to provide the mechanisms to make MDA and executable UML a reality, tools support is not yet fully developed.

Although UML 1.5 described a system fairly well, the model describing the modelthe meta-modelhad become patched and overly complex. Like any system that has an overly complex design, and is fragile and difficult to extend, UML had become overly complex, fragile, and difficult to extend; it was time for a re-architecture.

The designers of UML 2.0 were very careful to ensure that UML 2.0 would not be too unfamiliar to people who were already using UML 1.x. Many of the original diagrams and associated notations have been retained and extended in UML 2.0 as shown in Table 1-1. However, new diagram types have been introduced to extend the language just enough so that it can support the latest best practices.

With Version 2.0, UML has evolved to support the new challenges that software and system modelers face today. What began many years ago as a unification of the different methods for software design has now grown into a unified modeling language that is ready and suitable to continue to be the standard language for the myriad of different tasks involved in software and systems design.

Table 1-1. To describe the larger landscape of systems design, UML 2.0 renamed and clarified its diagrams for the new challenges facing system modelers today

Diagram type	What can be modeled?	Originally introduced by UML 1.x or UML 2.0	To learn about this diagram type, go to...
Use Case	Interactions between your system and users or other external systems. Also helpful in mapping requirements to your systems.	UML 1.x	Chapter 2
Activity	Sequential and parallel activities within your system.	UML 1.x	Chapter 3
Class	Classes, types, interfaces, and the relationships between them.	UML 1.x	Chapters 4 and 5
Object	Object instances of the classes defined in class diagrams in configurations that are important to your system.	Informally UML 1.x	Chapter 6
Sequence	Interactions between objects where the order of the interactions is important.	UML 1.x	Chapter 7
Communication	The ways in which objects interact and the connections that are needed to support that interaction.	Renamed from UML 1.x's collaboration diagrams	Chapter 8
Timing	Interactions between objects where timing is an important concern.	UML 2.0	Chapter 9
Interaction Overview	Used to collect sequence, communication, and timing diagrams together to capture an important interaction that occurs within your system.	UML 2.0	Chapter 10
Composite Structure	The internals of a class or component, and can describe class relationships within a given context.	UML 2.0	Chapter 11
Component	Important components within your system and the interfaces they use to interact with each other.	UML 1.x, but takes on a new meaning in UML 2.0	Chapter 12
Package	The hierarchical organization of groups of classes and components.	UML 2.0	Chapter 13
State Machine	The state of an object throughout its lifetime and the events that can change that state.	UML 1.x	Chapter 14
Deployment	How your system is finally deployed in a given real-world situation.	UML 1.x	Chapter 15