What’s New for UML Version 2

Introducing UML 2
Version 2 of the Unified Modeling Language (UML2) provides many of the familiar
UML1 diagrams, upgrades several diagrams making them more expressive, and adds a
number of new diagrams to keep up with the changes in object-oriented development.
The diagrams are organized into two main categories. Structural diagrams show the static
structure of a set of modeling elements. Behavioral diagrams allow you to focus on the
functional aspects of objects from different perspectives. Figure 1 provides a
categorization of UML 2 diagrams.

Basically
Diagram Unchanged

Many Changes

Significant
Changes
Structural Behavioral
New

Use
Class Object Package Activity State Machine
Case

Composite Interaction
Structure
Protocol State Machine

Component Deployment Interaction

Overview Timing

Sequence Communication

Figure 1: UML Diagram Organization

Please note: Due to the newness of UML2, several example figures are copied from the
final UML2 Superstructure submission to the Object Management Group
(www.omg.org). When you see a figure with a double asterisk after the caption (**), then
the figure was copied from the 3rd revised submission to OMG RFP ad/00-09-02 for the
Unified Modeling Language: Superstructure Version 2. The page reference at the end of
each figure caption with double asterisks is the page number in the UML2 Superstructure
submission where the original figure may be found. The submission date is April 10,
2003. Copyright © 2001-2003 U2 Partners (www.u2-partners.org), including content
adapted from the OMG Unified Modeling Language Specification v. 1.4. Copyright ©
1997-2001 Object Management Group (www.omg.org).

Jim Schardt © 2008 Educational Experiences. Page 1 of 13

 The UML2 Superstructure submission was voted on and approved by the Analysis and
Design Task Force of the OMG in Paris on June 6th, 20003. As part of OMG’s
standardization process, a “Finalization Task Force” (FTF) was created to produce the
formal, edited document and make minor changes to fix small problems in the approved
UML2 specification. Therefore, the examples shown here may need minor changes as a
result of the FTF’s work. The OMG will publish the results of the FTF’s effort at
www.omg.org.

Limitations Addressed in UML2

UML2 addresses many of the limitations of UML1 to include:
• Support for component based development;
• Modeling of runtime architecture of the internal structure of composite classes;
• Provision for independent mini state machines known as submachines;
• Improved control and data flow in activity diagrams;
• More robust modeling of object interactions over time;
• Support for Model Driven Architecture (MDA) tools.
• Increased support for systems engineering not just software development.

UML2 Structure Diagrams

Class Diagram
The class diagram of UML2 has changed little from UML1. You will find all the familiar
modeling elements — classes, attributes, operations, associations, multiplicity, roles,
qualifiers, and association classes.

Composite Structure Diagram

Often the things you are interested in modeling have an internal structure. UML1
provided a little notation for showing the internal structure of composites (the filled in
diamond shape indicating a strong form of aggregation). UML2 carefully defines this
notion of composites in a composite structure diagram. Basically you use this diagram to
show the internals of a classes, components, and nodes using this diagram. Miniature
composite structure diagrams can appear on any other type of structure diagrams. For
instance, a component diagram could show the internals of a component by providing a
composite structure diagram in that specific component. You can also use these diagrams
to express patterns of collaborating objects and the roles they play in a pattern.
Composite structure diagrams are composed of parts (classes with a defined role in the
context of the enclosing composite), and connections (associations with limitations on
potential links in the context of the enclosing composite).

Jim Schardt © 2008 Educational Experiences. Page 2 of 13

 This diagram is most often used to show hidden internal details of a class, an object, or a
component. Figure 2 shows a composite Car class with two parts. The rear part is a type
of Wheel class and the e part is a type of Engine class. There are 2 rear parts and they
are connected via the axle connection to port p on the e part.

Figure 2: Internal Structure Diagram ** (pg. 144)

Component Diagram
When UML1 was first defined, component based design had not really gotten started.
UML2 had to address this issue and allow modelers and developers to explicitly show
components and how those components are wired together — thus the component
diagram. A component is defined as a replaceable unit with well defined interfaces that
separate operation specification from their method realization. Examples of components
include subsystems, enterprise java beans, OCXs, or a web service. Looking beyond
software, components could also be hardware really any replaceable unit with well
defined interfaces.
Components are shown as class boxes with interface symbols (lollipops and sockets). A
lollipop symbol represents an interface that is provided by the component and a socket
symbol represents and interface that is required by the component (must be provided by
some other component).
Figure 3 shows a store component with an OrderEntry provided interface and an
Account required interface. The diagram also shows the internal composite structure of
the Store with the Order, Customer, and Product unnamed parts. You can also see the
ball and socket connector where the Order component requires a Person interface and
the Customer component provides a Person interface. The small icon in the upper right
hand corner indicates that the class is stereotyped as a component. You can also just use
«component» as the stereotype instead of the little component icon.

Jim Schardt © 2008 Educational Experiences. Page 3 of 13

 Figure 3 Component Diagram Example ** (pg. 120)

Object Diagram
There is nothing really new in object diagrams. Just show objects on diagrams the same
way you always have.

Package Diagram
Not much has changed with the UML package notation in UML2. Packages now have
there own diagram and the notation used to import elements of another package have
changed a little. Figure 4 shows the ShoppingCart package publicly importing the
elements of the Types package via the «import» dependency. ShoppingCart privately
imports the Auxiliary package via the «access» dependency. Thus the WebShop
package only imports the elements from ShoppingCart and Types due to the private
nature of the «access» dependency.

Figure 4 Public and Private Package Imports** (pg. 16)

Jim Schardt © 2008 Educational Experiences. Page 4 of 13

 Deployment Diagram
Deployment diagrams are still shown with connected 3D blocks as nodes. But, the word
Artifact replaces the old UML1 meaning of component. Artifacts are now what we call
the physical manifestation of software including executables, dll's, java jars, documents
and other files.
The idea of showing execution nodes and communication paths remains unchanged. The
entire deployment notation you are used to using carries over to UML2. However, if you
want to show a software artifact you do not use components, you use class boxes with the
«artifact» stereotype and/or a dog-eared icon in the upper right hand corner. You can
create deployment diagrams at the class and instance level.
Figure 5 shows a node at the instance level with two artifacts. The ShoppinCart.jar
depends on the Order.jar.

Figure 5: Simple Deployment with Artifacts** (pg. 161)

UML Behavior Diagrams

Use Case Diagram

Use Case Diagrams have not really changed with UML2.

Activity Diagram
Activity Diagrams have changed to allow the modeler and the developer to express Petri
Nets. In UML2 most of the notation for activity diagrams is the same but activity
diagrams now have extra meaning. As Petri Nets these diagrams are more powerful at
expressing control flow, discrete object flow, and continuous object flow.
Figure 6 shows some of the basic notation for a complex Process Order activity. An
object, Requested Order, flows into this activity and kicks off a sub activity — Receive
Order. The small dot is the starting point for the Process Order activity and the bull’s-
eye is where the activity and all flows terminate. The diamond allows control to flow
based on a decision. The thick bar notation allows for forking the control flow in a
Jim Schardt © 2008 Educational Experiences. Page 5 of 13
 concurrent way. The diamond merges and the thick bar joins control flows as well. An
object flow is also shown by the activity Send Invoices generating objects of the Invoice
class and which in turn flows on to the Make Payment activity. You can specify pre and
post conditions for an activity as well.

Figure 6: Example Activity Diagram** (pg.258)

UML2 retains the idea of swimlanes. When you want to model business processes use
swimlanes. You can also use swimlanes to indicate who is responsible for a group of
behaviors described in an activity diagram. A swimlane is a way of partitioning activities
amoung classes. New to UML2 is the ability to have multiple dimensions. For example
you might have one dimension for business process job role and another dimension for
location of that job. See Figure 7 as an example.

Jim Schardt © 2008 Educational Experiences. Page 6 of 13

 Figure 7 Swimlane example** (pg. 277)

State Machine Diagram

The notation you already know for state diagrams carries over to the UML2 state
machine diagram. The ability of have “submachines” — mini state machines — that you
can reference from other state machines has been carefully defined in UML2.
You can place a frame around a state machine indicating its context. This is usually the
name of the class that has the state machine for its internal dynamic behavior
specification.
The diagram in Figure 8 shows a state machine for an ATM. Notice the states are
surrounded by a frame with the name of the state machine. ReadAmount :
ReadAmountSM indicates a submachine is being used. The circle with an X in it and the
word aborted indicates an exit point from the submachine when there is an aborted
event that occurs while in the ReadAmount submachine, otherwise there is an automatic
transition from rhe ReadAmount submachine to the VerifyTransaction state.

Figure 8: ATM State Machine** (pg. 466)

Protocol State Machine Diagram

The Protocol State Machine diagram is new to UML 2. It is based on the state machine
diagram but focuses on allowable sequences of behavior invocation on a class to express
a protocol instead of what happens inside a state. If you want to show the right invocation
order of operations on a class and expose the pre and post conditions for those operations
then the Protocol State Machine Diagram is for you.
Figure 1Figure 9 illustrates a simple protocol state machine for a Door. Notice the frame
surrounding the diagram with the {protocol} property. The big difference in notation
Jim Schardt © 2008 Educational Experiences. Page 7 of 13
 between a state machine and a protocol state machine is in the transition line between
states. The transition is named as [precondition] event / [post condition]. These
transitions have no actions. Generally, the events are the names of operations on a single
class. When the Door is in the opened state, the Close operation may be invoked. The
precondition that the doorWay has the property of isEmpty must be true. The Close
transition has no post condition.

Figure 9: Protocol State Machine** (pg. 424)

Sequence Diagram
Sequence Diagrams are significantly enhanced. The basic notation for objects and trace
lines looks the same. But, you now place a "frame" around the diagram. You can
reference or show mini sequence diagrams in a larger sequence diagram. And, you can
easily show alternative flows, optional flows, interaction, and a host of other flows in one
diagram.
Place a sequence diagram inside a frame with the “sd” keyword. Instead of having object
instances you have connectable parts of classes. They are much the same as object
instances for the purpose of interactions. You can show more complex sequences by
placing frames inside the main sequence diagram frame. Some of the “sequence
fragments you can use are:
• ref: a reference frame to another sequence diagram
• alt: show alternative sequences based on some constraint (see Figure 10)
• loop: show iteration over a set of event sequences
• par: show event sequences that can happen in parallel
• critical: show a region of event sequences that must happen.
Jim Schardt © 2008 Educational Experiences. Page 8 of 13
 We are just getting started.

Figure 10: Sequence Diagram** (pg. 372)

Interaction Overview Diagram

The Interaction Overview Diagram is also brand new. This diagram is sort of like an
activity diagram but it focuses on events instead of actions. Use this diagram to show an
overview of interactions for a complex Use Case or a system.
Often use cases involve several objects interacting in a main flow, successful alternative
flows, as well as error flows. The complexity of allowable interactions increases with the
use of use case «includes» and «extends». With UML1 you had to create many different
sequence diagrams, but it was easy to loose track of how these different diagrams related
to each other. The interaction overview diagram shows how major sequences are related
over time and control flow.

Jim Schardt © 2008 Educational Experiences. Page 9 of 13

 Figure 11: Interaction Overview Example** (pg. 407)

Jim Schardt © 2008 Educational Experiences. Page 10 of 13

 Communication Diagram
The Communication Diagram is the new name for the old Collaboration Diagram of
UML1. Right now communication diagrams are not as expressive as the older
collaboration diagram. Multi-objects, role names and constraints seem to be missing. Stay
tuned, the ACC is working to influence the UML2 Finalization Task Force to make the
Communication Diagram as expressive as the old Collaboration Diagram. The notation
looks pretty much the same however with some subtle changes. For instance, the lines
between the parts are messages not links or associations, therefore you cannot show
association notation on the line as you could with UML1 collaboration diagrams.

Figure 12: Communication Diagram** (pg. 404)

Timing Diagram
UML2 has a new diagram to help those that need to focus on timing — the Timing
Diagram. In this diagram you show the lifelines (objects/parts) on the side of the diagram.
Each object goes through some states and a timing line is used to show when and how
long the object can be in that state. You can also show messages being passed between
different objects in the diagram.

Jim Schardt © 2008 Educational Experiences. Page 11 of 13

 Figure 13: Timing Diagram** (pg. 411)

Miscellaneous Diagrams

Information Flow Diagram

One of the needs of Systems Engineers is addressed in a new Information Flow
diagram. This diagram shows the flow of information among entities. Figure 14 shows
the flow of wage information from a Company to an Employee entity. Information like
wage is shown at a high level of abstraction without showing its structure. Other
diagrams can be used to show how information gets represented.

Figure 14: Information Flow** (pg. 487)

Jim Schardt © 2008 Educational Experiences. Page 12 of 13

 Collaborations
The word collaboration is now associated with patterns of interaction between
collaborating objects in UML2. A collaboration is a composite structure diagram showing
the classes, their roles and constrains that define a pattern for reuse.
Figure 15 shows a collaboration, BrokeredSale, that consists of using two occurrences
of the Sale collaboration. The Sale collaboration involves two roles — buyer and seller.
Classes are shown taking on the different roles of the Sale collaboration.

Figure 15: Brokered Sale Pattern** (pg. 135)

Jim Schardt © 2008 Educational Experiences. Page 13 of 13