Changes from UML 1.2 (and 1.1) to 1.3 (and 1.4)

Use Cases

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.

The include construct is a stereotype of dependency. This indicates that the path of one use case is included in another. Typically, this occurs when a few use cases share common steps. The included use case can factor out the common behavior. An example from an ATM might be that Withdraw Money and Make Transfer both use Validate Customer. This replaces the common use of uses.
Use case generalization indicates that one use case is a variation on another. Thus, we might have one use case for Withdraw Money (the base use case) and a separate use case to handle the case when the withdrawal is refused due to lack of funds. The refusal could be handled as a use case that specializes the withdrawal use case. (You could also handle it as just another scenario within the Withdraw Money use case.) A specializing use case like this may change any aspect of the base use case.
The extend construct is a stereotype of dependency. This provides a more controlled form of extension than the generalization relationship. Here the base use case declares a number of extension points. The extending use case can alter behavior only at those extension points. So, if you are buying a product on line, you might have a use case for buying a product with extension points for capturing the shipping information and capturing payment information. That use case could then be extended for a regular customer for which this information would be obtained in a different way.

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 usage of the UML 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.

Activity Diagrams

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 form 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 of 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 they 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.