I'll take a stab at this. I'm not claiming to be the final authority on
this. But my conclusions are based on close reading of the UML 1.1, 1.3,
1.4 and 2.0 specifications over a period of time as well as reading the
literature in the last eight years and being involved in building a UML
1.4 tool for commercial use some years back.
The short story is that a lifeline in UML 2.0 represents a role. In UML
2.0 notation "A Lifeline is shown using a symbol that consists of a
rectangle forming its "head" followed by a vertical line (which may be
dashed) that represents the lifetime of the participant." So the
rectangle at the head of the line is part of the lifeline. In an
executing instance of a system, roles are of course played by instances.
However, in the context of specifying a UML 2.0 interaction, one is
actually specifying the interaction of roles and not instances.
Underlined names denote an instance while names without an underline
denote, among other things, a role. So, if one is specifying an
interaction among roles then you use the notation without underlined
Some details to short story:
In UML 2.0, a Sequence Diagram denotes and Interaction. From the spec:
"Interactions are units of behavior of an enclosing Classifier.
Interactions focus on the passing
of information with Messages between the ConnectableElements of the
In general the enclosing Classifier is the Classifier that owns the
Interaction in question. A Lifeline represents a ConnectableElement that
is within the Classifier that owns the Interaction that encloses the
Lifeline. (see UML 2.0 spec, Figure 14.4 - Lifelines and Section 14.3.19
- Lifelines). And just what is a ConnectableElement? It is a role within
a StructuredClassifier! (see Figure 9.2 - Structured Classifier and
Section 9.3.5 - ConnectableElement). So Lifelines represent roles, not
instances. Don't let the 0..1 multiplicity on the "represents"
association of Lifeline confuse you. All this does is allow you to have
an anonymous role. You can also have a Lifeline play the role of "self"
(see the Notation subsection of Section 14.3.19 - Lifeline).
So, how did we get here? This is the long story and here is my ex post
facto reconstruction. I don't expect everyone to follow me on this trip.
It took me years to get here.
The "U" in UML in this case was the unification of sequence diagrams and
collaboration diagrams (now UML 2.0's communication diagrams). Sequence
diagrams have their origins in Message Sequence Charts (MSC was part of
a CCITT standard). MSC was taken up by others, e.g. Object Message
Sequence Charts in "Pattern-Oriented Software Architecture by Buschmann
et. al. These diagrams were used to specify a scenario of interacting
entities, a.k.a objects. So the intent was to specify interaction
between what we now call instances. And it was a scenario in the sense
that a particular diagram covers only one particular interaction under a
fixed set of circumstances, and is in no way generic. Collaboration
diagrams came from another part of the OO community and are more
structurally oriented (I don't have the appropriate reference at hand,
and there is probably more than one). Some people used them to model
interactions between instances and some used them to model interactions
between roles, a seemingly minor distinction with great consequences.
Ideally, sequence and collaboration diagrams are just two sides of the
same coin, so the unification should be easy. That is, both diagrams are
just visualizations of the same underlying model. At least that appears
to be the intent in UML 1.1 (too bad I threw away my paper copy of the
UML 0.9 spec a while ago!). The UML 1.1 sequence diagram is the
"traditional" one we are most familiar with. However, UML 1.1 muddled up
the difference between instances (which it still called objects) and
roles. In some places it distinguishes between them and in others it
uses them interchangeably. In UML 1.1, names in both sequence and
collaboration diagrams are underlined. There was only one kind of
collaboration diagram, the one with underlined names. This clearly
didn't satisfy the role camp. The road to unification was rocky. In
addition, UML 1.1 lacked a "real semantics" and in fleshing out this
"real semantics" we arrived along the way at UML 1.3.
In UML 1.3 there are two kinds of collaboration diagrams, instance-level
diagrams and specification-level diagrams. These correspond to modeling
collaborations as interactions between instances or as interactions
between roles. From Section 3.64.2 of the UML 1.3 spec:
"A collaboration diagram shows a graph of either Objects linked to
each other, or
ClassifierRoles and AssociationRoles; it may also include the
communication stated by
an Interaction. A collaboration diagram can be given in two
different forms: at instance
level or at specification level; it may either show Instances,
Links, and Stimuli, or show
ClassifierRoles, AssociationRoles, and Messages."
One level deals with Instances while the other deals with Roles. Here is
the tip. If you see underlined names it an instance-level diagram. If
not it is a specification-level diagram.
UML 1.3 made a distinction between Collaboration and Interaction. From
"A Collaboration defines a specific way to use the Model Elements in
a Model. It
describes how different kinds of Classifiers and their Associations
are to be used in
accomplishing a particular task. The Collaboration defines a
restriction of, or a
projection of, a collection of Classifiers (i.e., what properties
Instances of the
participating Classifiers must have when performing a particular
"An Interaction defined in the context of a Collaboration specifies
the details of the
"communications that should take place in accomplishing a particular
In essence, an Interaction requires a Collaboration for its context.
Sequence diagrams in UML 1.3 were for Interactions. They contain
objects. However, the collaboration providing the context for the
interaction could remain anonymous, and usually was. In fact, UML tools
of the time didn't require a collaboration as a context for an
Collaboration diagrams could be used for either a Collaboration or an
Interaction layered on top of a Collaboration. From Section 3.64.1:
"A collaboration diagram presents a Collaboration, which contains a
set of roles to be
played by Objects, as well as their required relationships given in
a particular context.
The diagram may also present an Interaction, which defines a set of
specifying the interaction between the Objects playing the roles
within a Collaboration
to achieve the desired result."
In essence, a Collaboration specifies structure. Interaction specifies
how the parts of the structure communicate. A collaboration diagram can
show just structure or both structure and interaction. In either case
you get the choice of having a diagram with or without underlined names.
Are we getting confused yet? Here is the tip. If you see underlined
names you are dealing with an interaction, even if it looks like a
collaboration diagram. If the names are not underlined it is just a
collaboration. Because sequence diagrams only show interactions (in the
context of a collaboration, whatever that means) we only see underlined
names. Clearly, the desired unification hadn't quite taken place by UML
UML 1.4 really did unify these different concepts. It did so by making
things even more complex by introducing several concepts: Collaboration,
CollaborationInstanceSet, Interaction and InteractionInstanceSet. The
details are too complicated to go into here. Basically, UML 1.4 provides
the machinery to have sequence and collaboration diagrams at both the
instance-level or specification-level, where specification-level means
in terms of roles.
The UML 1.4 semantics of sequence diagrams is as follows: (Section
"A sequence diagram presents an Interaction, which is a set of
ClassifierRoles within a Collaboration, or an
InteractionInstanceSet, which is a set of
Stimuli between Instances within a CollaborationInstanceSet to
effect a desired
operation or result."
The semantics of collaborations diagrams is as follows: (Section 3.65.1)
"A collaboration diagram presents either a Collaboration, which
contains a set of roles
to be played by Instances, as well as their required relationships
given in a particular
context, or it presents a CollaborationInstanceSet with a collection
of Instances and
their relationships. The diagram may also present an Interaction
(InteractionInstanceSet), which defines a set of Messages (Stimuli)
interaction between the Instances playing the roles within a
Collaboration to achieve
the desired result."
In other words, either diagram type can now show either roles or
instances (but not both at the same time). And even more confusing, a
collaboration diagram could denote one of four things: a Collaboration,
a CollaborationInstanceSet, a Collaboration with an Interaction, or a
CollaborationInstanceSet with an InteractionInstanceSet. A sequence
diagram can denote either of the last two of these, although the
structural details of the Collaboration/CollaborationInstanceSet are not
part of the diagram. Here is the tip. If you see underlined names, you
are dealing with an instance-level thing. If not, then a
specification-level thing, i.e. roles. Now you get your choice with both
sequence and collaboration diagrams. Needless to say, no UML tool vendor
rushed out to expand their tool to provide this new possibility.
Sequence diagrams remained instance-level things in the eye of UML tool
vendors and modelers.
As you can see, the unification was not going well and things were
getting out of hand! In comes UML 2.0 to simplify things. Note, however,
the slow but steady acceptance of roles as a viable concept to be
modeled in the context of an interaction. UML 1.1 talked about roles but
didn't distinguish them in diagrams. Things were a bit muddled. In UML
1.3, collaboration diagrams distinguished between roles and instances,
but sequence diagrams still used only instances. By UML 1.4 both
collaboration and sequence diagrams could use either roles or instances,
although tool vendors did not provide tools to do so.
Basically, UML 2.0 threw out UML 1.4's CollaborationInstanceSet and
InteractionInstanceSet and expanded the concept of role. A Collaboration
is a structural concept (this was hinted at in UML 1.3 and 1.4, but now
it is unmistakably clear). Indeed, Collaboration is a subclass of
StructuredClassifier and BehavioredClassifier. As a StructuredClassifier
it has ConnectableElements, each of which plays a role within the
context of the collaboration. Connectable elements are Properties,
Ports, and Parameters. As a BehavioredClassifier a Collaboration can own
Interactions. Of course, any other BehavioredClassifier can also own an
Interaction, e.g., a Component could own an interaction. The Lifelines
of an Interaction represent the roles of the owning Classifier.
Lifelines show up in sequence diagrams as the named rectangle at the
head of a line. They show up in communication diagrams as just the named
rectangle. Because Lifelines represent roles, not instances, the names
are not underlined. Of course, it is clear that at any given time there
is only one instance playing a given role within a collaboration. For
example, if a role has multiplicity greater than one, you can specify a
selector to select the single instance. One advantage of using only
roles is that we don't have to provide any instances in order to specify
an interaction, even anonymous ones. We have only one concept and we
don't need the added complexity of a concept that can be used at both
instance level and specification level. Modeling with roles in UML 2.0
allows more flexibility because we are not restricted to instances of
classifiers. The roles played by Ports and operation Parameters can be
represented by Lifelines, a distinct advantage.
In summary, unification brought the original concept of role from
collaborations into sequence diagrams. Simplification threw classifier
instances out of interactions and, therefore, out of sequence and
collaboration diagrams. Now there are only roles in interactions and,
consequently, in sequence and communication diagrams. Thus, names are
not underlined. The set of things that can play roles in an interaction
has been expanded to include ports and parameters.
There is also an interesting development in the complexity of sequence
diagrams. The original Message Sequence Charts (MSC) and Object Message
Sequence Charts were intended to show a scenario in the sense that a
particular diagram covers only one particular interaction under a fixed
set of circumstances, and is in no way generic. These were the prototype
for UML's sequence diagrams. But UML was more ambitious from the start.
This is from the UML 1.1 specification for sequence diagrams:
"Sequence diagrams come in several slightly different formats
intended for different purposes.
A sequence diagram can exist in a generic form (describes all the
possible sequences) and in an
instance form (describes one actual sequence consistent with the
generic form). In cases without
Loops or branches, the two forms are isomorphic."
UML then went on to add diagrammatic constructs to show things such as
branches, loops and concurrency in order to describe all possible
sequences. The idea was to give a complete specification, perhaps even
one from which you could generate code. I worked on a tool for UML 1.4
that tried to do this. It was extremely difficult if not an impossible
UML 2.0 finally realized the goal of specifying a "generic form" for
sequence diagrams that is complete enough to generate code from. It is
really visual programming. And it is tool-able. It can also be complex.
About 90% of the UML 2.0 specification for interactions is there for
this purpose. You can argue about its usefulness. At OT 2004 (now the
SPA conference series) I saw Martin Fowler give an overview of UML 2.0.
He put up a slide with a sequence diagram that more or less filled the
slide. He then put up a slide containing the corresponding 3 lines of
code in Java and asked us which one we preferred. The message was clear.
You can still do "old-style" scenarios in UML 2.0, but you will need an
"underlying" collaboration (i.e., a structure that provides the roles
and any structural relationships). A good tool could made this
collaboration anonymous/hidden so you wouldn't have to deal with it when
illustrating cases having anonymous roles, e.g. ":Customer". But you
won't see underlined names, which means we are at the specification
The above is my reconstruction of the history of UML in this area. I
have not been able to discuss it with any of the people who were
directly responsible for the various versions of UML. It would be nice
to get their perspective.
p.s. Addressing Tony's question about Jacobson-style icons at the head
of lifelines. It's local style. A role (i.e., ConnectableElement) may
have a type (and usually will). An anonymous lifeline like ":Customer"
(i.e., one whose represents property is null) must have a type. In
either case the type can be any classifier. If the kind of classifier is
an Actor then you could use an actor icon. It's up to the tool. RSA 6.0
uses a rectangle containing an actor icon to the left of the name.
Earl Waldin tel: +41 31 828 9222
Paranor AG fax: +41 31 828 9299
Juraweg 14 email: email@example.com
> -----Original Message-----
> From: firstname.lastname@example.org
> [mailto:email@example.com] On Behalf Of Tony Simons
> Sent: Wednesday, 22 November, 2006 11:31
> To: firstname.lastname@example.org
> Subject: UML 2.0 Sequence Diagrams
> Dear PUML,
> Can anyone tell me why, in the OMG UML2.0 spec, the object lifelines
> in the sequence diagram notation have abandoned the convention for
> underlining the names of objects?
> Elsewhere in UML, object names are underlined, and still are in 2.0.
> Also, Praxis and others have alternative Jacobson-style icons for
> objects at the head of lifelines. Is this UML canon, or just a local
> Dr Anthony J H Simons email@example.com
> Senior Lecturer in Computer Science
> Department of Computer Science tel: (+44) 114 22 21838
> University of Sheffield dept: (+44) 114 22 21800
> Regent Court, 211 Portobello Street fax: (+44) 114 22 21810
> SHEFFIELD, S1 4DP univ: (+44) 114 22 22000
> United Kingdom
> To remove yourself from this list please mail
> with a message containing the word "unsubscribe".
Received on Thu 23 Nov 2006 - 13:54:40 GMT