In the first edition of UML Distilled, I talked about perspectives and how they altered the way people draw and interpret models—in particular, class diagrams. UML now takes this into account by saying that all classes on a class diagram can be specialized as either types or implementation classes.

An implementation class corresponds to a class in the software environment in which you are developing. A type is rather more nebulous; it represents a less implementation-bound abstraction. This could be a CORBA type, a specification perspective of a class, or a conceptual perspective. If necessary, you can add stereotypes to differentiate further.

You can state that for a particular diagram, all classes follow a particular stereotype. This is what you would do when drawing a diagram from a particular perspective. The implementation perspective would use implementation classes, whereas the specification and conceptual perspective would use types.

You use the realization relationship to indicate that an implementation class implements one or more types.

There is a distinction between type and interface. An interface is intended to directly correspond to a Java or COM-style interface. Interfaces thus have only operations and no attributes.

You may use only single, static classification with implementation classes, but you can use multiple and dynamic classification with types. (I assume that this is because the major OO languages follow single, static classification. If one fine day you use a language that supports multiple or dynamic classification, that restriction really should not apply.)

In previous printings of UML Distilled, I said that the {complete} constraint on a generalization indicated that all instances of the supertype must also be an instance of a subtype within that partition. UML 1.1 defines instead that {complete} indicates that all subtypes within that partition have been specified, which is not quite the same thing. I have found some inconsistency on the interpretation of this constraint, so you should be wary of it. If you do want to indicate that all instances of the supertype should be an instance of one of the subtypes, I suggest using another constraint to avoid confusion. Currently, I am using {mandatory}.

In UML 1.0, using composition implied that the link was immutable, or frozen, at least for single-valued components. That constraint is no longer part of the definition.

UML defines the constraint {frozen} to define immutability on association roles. As it’s currently defined, it doesn’t seem to apply it to attributes or classes. In my practice, I now use the term frozen instead of immutability, and I’m happy to apply the constraint to association roles, classes, and attributes.

In UML 1.0, a return on a sequence diagram was distinguished by using a stick arrowhead instead of a solid arrowhead (see previous printings). This was something of a pain, as the distinction was too subtle and easy to miss. UML 1.1 uses a dashed arrow for a return, which pleases me, as it makes returns much more obvious. (As I used dashed returns in Analysis Patterns [Fowler, AP], it also makes me look influential.) You can name what is returned for later use by using the form enoughStock := check().

In UML 1.0, the term role indicated primarily a direction on an association (see previous printings). UML 1.1 refers to this usage as an association role. There is also a collaboration role, which is a role that an instance of a class plays in a collaboration. UML 1.1 gives a lot more emphasis to collaborations, and it looks as though this use of “role” may become the primary one.

The changes to use cases involve new relationships between use cases. UML 1.1 has two use case relationships: «uses» and «extends», both of which are stereotypes of generalization. UML 1.3 offers three relationships.

There is some confusion about the relationship between the old relationships and the new ones. Most people used «uses» the way the 1.3 «includes» is used, so for most people, we can say that «includes» replaces «uses». And most people used 1.1 «extends» in both the controlled manner of the 1.3 «extends» and as a general overriding in the style of the 1.3 generalization. So, you can think that 1.1 «extends» has been split into the 1.3 «extend» and generalization.

Now, although this explanation covers most UML usage that I’ve seen, it isn’t the strictly correct way of using those old relationships. However, most people didn’t follow the strict usage, and I don’t really want to get into all that here.

When the UML reached version 1.2, there were quite a few open questions about the semantics of activity diagrams. So, the 1.3 effort involved quite a lot of tightening up on these semantics.

For conditional behavior, you can now use the diamond-shaped decision activity for a merge of behavior as well as a branch. Although neither branches nor merges are necessary to describe conditional behavior, it is increasingly common style to show them so that you can bracket conditional behavior.

The synchronization bar is now referred to as a fork—when splitting control—or as a join—when synchronizing control together. However, you can no longer add arbitrary conditions to joins. Also, you must follow matching rules to ensure that forks and joins match up. Essentially, this means that each fork must have a corresponding join that joins the threads started by that fork. You can nest fork and joins, though, and you can eliminate forks and joins on the diagram when threads go directly from one fork to another fork, or one join to another join.

Joins are fired only when all incoming threads complete. However, you can have a condition on a thread coming out of a fork. If that condition is false, that thread is considered complete for joining purposes.

The multiple-trigger feature is no longer present. In its place, you can have dynamic concurrency in an activity, shown with a * inside an activity box. Such an activity may be invoked several times in parallel; all its invocations must complete before any outgoing transition can be taken. This is loosely equivalent to, although less flexible than, a multiple trigger and matching synchronization condition.

These rules reduce some of flexibility of activity diagrams but do ensure that activity diagrams are truly special cases of state machines. The relationship between activity diagrams and state machines was a matter of some debate in the RTF. Future versions of the UML (after 1.4) may well make activity diagrams a completely different form of diagram.

Attributes and unidirectional associations are now primarily simply different notations for the same underlying concept of property. Discontinuous multiplicities, such as [2, 4], have been dropped. The frozen property has been dropped. I’ve added a list of common dependency keywords, several of which are new to UML 2. The «parameter», and «local» keywords have been dropped.

The big change here is the interaction frame notation for sequence diagrams to handle iterative, conditional, and various other controls of behavior. This now allows you to express algorithms pretty completely in sequence diagrams, although I’m not convinced that these are any clearer than code. The old iteration markers and guards on messages have been dropped from sequence diagrams. The heads of the lifelines are no longer instances; I use the term participant to refer to them. The collaboration diagrams of UML 1 were renamed to communication diagrams for UML 2.

Stereotypes are now more tightly defined. As a result, I now refer to words in guillemets as keywords, only some of which are stereotypes. Instances on object diagrams are now instance specifications. Classes can now require interfaces as well as provide them. Multiple classification uses generalization sets to group generalizations into groups. Components are no longer drawn with their special symbol. Active objects have double vertical lines instead of thick lines.

UML 1 separated short-lived actions from long-lived activities. UML 2 calls both activities and uses the term do-activity for the long-lived activities.

UML 1 treated activity diagrams as a special case of state diagram. UML 2 broke that link and as a result removed the rules of matching forks and joins that UML 2 activity diagrams had to keep to. As a result, they are best understood by token flow rather than by state transition. A whole bunch of new notation thus appeared, including time and accept signals, parameters, join specifications, pins, flow transformations, subdiagram rakes, expansion regions, and flow finals.

A simple but awkward change is that UML 1 treated multiple incoming flows to an activity as an implicit merge, while UML 2 treats them as an implicit join. For this reason, I advise using an explicit merge or join when doing activity diagrams.

Swim lanes can now be multidimensional and are generally called partitions.