UML version 2.0

Introduction
Although UML 2.0 is not completely new, I was not able to have a look at it until now. For people like me, and for other people who are interested, I tried to summarize the differences between UML 2.0 and UML 1.4. At the very bottom of this post, I added a link to a site where all the UML 2.0 diagrams are explained. I used the information described on the pages of this link and other information which is available on the internet, to complete this post.

Infrastructure/Superstructure
Various meta-models, like UML, uses a meta-language core. This core consists of a couple of (model) packages, which themselves consists of a set of more fine-grained (model) packages. Meta-models can use these (model) packages for their definition. Meta-models themselves can be customized, because they consist of (model) packages too. These packages are extendable without interfering with the meta-language core. This means that new languages or profiles can be created based upon the meta-language core.

So, the meta-language core can be used to define modeling constructs used to create new meta-models. A new meta-model is created by instantiating meta-classes in the InfrastructureLibrary. The InfrastructureLibrary is a (model) package which uses the meta-language core (model) package and other (user) defined (model) packages (for instance a profile (model) package). Profiles typically are used to tailor meta-models to certain platforms, like C++, EJB, etc. A profile is not useful standalone and must be based on a meta-model, like UML, which it extends.

The four-layer meta-model still applies for UML 2.0. At top level the MOF (Meta Object Facility) Meta meta-model resides. The MOF uses the same meta-language core as UML does. The InfrastructureLibrary however, is being used at both levels in a different manner. I will not explain the four-layer meta-model in more detail, in this post.

The Infrastructure specification of UML 2.0 is being re-used when creating other meta-models. The whole UML meta-model is instantiated from the definition of the meta meta-classes in the InfrastructureLibrary when creating other meta-models.

The UML Kernel package is the meta-class of every other package; all other packages depend on it and it forms the middle of UML. The Kernel package is comparable with the Constructs package of the InfrastructureLibrary. However, it adds more capabilities to the modeling constructs.

OCL
Object Constraint Language is being used in UML models to define constraints. OCL did not have a meta-model (UML 1.4), which makes it difficult to define integration with UML models. OCL 2.0, which is fully integrated with UML 2.0, does have a meta-model, which is based on the same Kernel as the one used by UML 2.0.

OCL 2.0 is a general object query language that can be used wherever expressions over UML models are required. Additional concepts to express messages sent by components, classes or other constructs that may have behavior have been added to OCL to allow the specification of behavioral constraints.

Component diagrams
The graphical notation of components changed. UML 2.0 components are modeled as simple rectangles. Within the rectangle the original 1.4 UML component notation is shown as a visual stereotype to indicate that the rectangle represents a component. However, this may be replaced by a textual stereotype with the name component. The lollipop is still used to indicate an interface although the UML 2.0 version introduced the socket symbol to indicate a required interface. With the socket symbol, an equivalent textual stereotype which describes the dependency is included.

This diagram is still powerful and the new notation does not change the use of the diagram, modeling both business and technical architectural issues.

Composite Structure diagrams
This diagram is new in UML 2.0. The diagram is used to explore run-time instances of objects and the roles that they take within a collaboration (modeled as a dashed circle). Rectangles model instances of any type of classifier (classes, interfaces, objects). Optionally properties, used by the collaboration, are shown in the rectangles. The instances (rectangles) are connected to the collaboration. The connections are explained by plain text.

Probably I will not use this diagram because a sequence diagrams will suffice in the cases that I need to model run-time instances and the interaction between objects.

Timing Diagrams
This new diagram explores the behavior of objects in a certain time period. Timing diagrams can be used to design embedded software.

I think I will not make use of this diagram. And I can’t think of an example in IT-projects I have been participating in, where this diagram would be of any help.

Interaction Overview Diagrams
This diagram is a variant on the existing activity diagram which I am font of in particular. The big difference between the activity diagram and this new diagram is that the nodes are frames instead of ‘normal’ activities. There are two types of frames, interaction frames which show a UML interaction diagram (sequence-, communication-, timing- and interaction overview diagram) and interaction occurrence frames indicating an activity. So different kinds of UML diagrams are modeled in an Interaction Overview diagram and connected with each other. Start, Stop and decision points are applicable in this diagram as they still are in the activity diagram. The UML interaction diagram frames are indicated with sd (sequence diagrams), cd (communication diagrams), td (timing diagrams) and iod (interaction overview diagrams), and in some cases, even the name of the diagram is given. Interaction occurrence frames are titled as ref.

This diagram is useful because it is possible to model an interaction between different models. An activity diagram is still powerful because it can be used by an information annalist to explain the process to the business, while the interaction overview diagram (as well as the activity diagram) is useful for people with more knowledge of UML then (no offense) business people.

State Machine Diagrams
To understand complex objects you might develop UML state machine diagrams to describe the various states of an object and the transitions between those states. A UML state machine diagram is a new naming for state diagram which is the name used in UML 1.4 for this type of modeling. I could not find a difference in the purpose of this type of diagram.

More information on UML diagrams as well as examples about the above diagrams can be found on Agile Modeling.