Basic UML – UML Diagrams – Extend use cases, Actor inheritance

In the last tutorial we introduced the idea of an included use case.  An included use case is a dialog sequence that occurs and will be invoked from one or more use cases.  An include use cases is always executed from the parent use case and represents mandatory behavior.

Extend Use Cases

The extend use case is also a dialog sequence; however, it is not invoked all the time.  The extend use case represents optional behavior, however, that is not a sufficient condition to create an extend use case.  In general, an extend use case must also have behavior that is not already handled by some other use case.  At this point our use case diagram looks as follows:

One common optional behavior for this use case would be Print out a gift receipt.  Not all purchases need to get a gift receipt and so this qualifies as optional behavior.   In addition, it is clear that a gift receipt will contain different information from the base receipt, i.e. no amounts will be shown, possibly a coupon will be printed.

We put the extend use case Print out a gift receipt and indicate that it is an extension to the Sell goods to customer use case.

Actor Inheritance

Let’s add a few more use cases for our Sales Representative:

• Return merchandise
• Find item in other stores

The updated diagram would be:

In addition, let's add the Manager actor to our system.  The manager in a retail system is able to do things like:

• Apply register discount
• Adjust inventory levels

The updated diagram would be:

The problem is that this diagram states that the Manager and the Sales Representative have mutually exclusive permissions to execute the use cases.  However this picture is incomplete, because in most retail stores, the Manager can also do everything that the Sales Representative can do.  A complete diagram would be as follows: 

This diagram is getting pretty crowded, and we have not even added all the retail use cases.  Fortunately, UML gives us a mechanism to easily indicate when one actor can do everything that another actor can do – Actor inheritance:

By designating the Manager as inheriting, or more precisely generalizing, the Sales Representative, we are declaring that the Manager can do everything that the Sales Representative can do.

This will go a long way towards cleaning up your use case diagrams.  Note, using actor inheritance does not express any new concepts on your diagram, it only simplifies the diagram.  To really simplify the diagram you would really create 2 diagrams in your UML tool:

Diagram 1:

Diagram 2:

Summary

• Use Include use cases to split out common use case dialog sections that repeat across use cases or are complicated enough to hit the purpose of your main use case
• Use Extend use cases to capture optional or exceptional behaviour to some use case
• Use actor Inheritance to simplify your diagrams by indicating when one actor can do everything that another actor can do.