Does UML Use Case allow "use case polymorphism"?

Question

I have two Actors: User and Admin that will interact with my system. Admin uses generalization to inherent use cases from User. I have a use case named authenticate that should have two different behaviors. The post-condition for this use case is: User authenticated.

1. If User is calling it, it should only ask for username
2. If Admin is calling it, it should ask for username and password

The Use Case Diagram would look like that:

Answer 1

This answer has been updated for UML 2.5.1 specification.

---

First, it appears that the notation is valid.

Actors (18.2.1) can only have Associations to UseCases, Components, and Classes and these Associations must be binary.

The relationship between Admin and User is Generalization (defined in 9.9.7). It is a specialization of the DirectedRelationship (defined in 7.8.5) which is a specialization of Relationship (defined in 7.8.15). The specializations of Relationship are DirectedRelationship and Association (defined in 11.8.1). This means that a Generalization is not an Association.

The Actor puts restrictions on what a valid Association is. However, the definition of Actor does not restrict other relationships, so we need to look through the hierarchy of definitions to determine if a Generalization is valid.

Actor is a specialization of a BehavioredClassifier (10.5.1). None of the defined Association Ends covers this case, so we need to keep looking. A BehavioredClassifier is a specialization of a Classifier (10.5.1.3). One of the Association Ends of a Classifier is Generalization. Because a Classifier allows for Generalization between Classifiers and an Actor is a Classifier without further restriction on the Generalization, the relationship appears to be valid.

I'd like to note that there is no example diagram that shows a Generalization relationship between two Actors. Also, there is no discussion in the text (that I could find) about this relationship. The only way to learn about it is to follow the formal definitions of Actor, Association, and Generalization all the way through their hierarchy.

---

The next thing to look at is if this diagram would make sense to a reader.

Formally, Use Cases are described in Section 18 of the UML spec - a Use Case is a set of behaviors that a system offers, and this set of behaviors can also include variations (and variations include, but are not limited to exceptional behavior and error handling). Informally, a use case is "a list of actions or event steps typically defining the interactions between a role and a system to achieve a goal".

As a reader, if I saw the diagram without any explanatory text, I would make the assumption that the behavior defined by the Authenticate use case was the same for both Admin and User. After all, both have a relationship to the same set of behaviors called Authenticate. I would not expect a single symbol on a diagram to denote two different sets of event steps.

In UML, Use Cases can be related to each other, such as by the Extends and Includes relationships along with Generalization. These can be used to modify the behavior of a Use Case.

---

I believe that you can express everything that you want to express in a UML Use Case diagram. However, I'm not convinced that the example, as presented in the question, is the best way of communicating the information to interested parties.

My preference would be to generally avoid use case diagrams. Instead, I would a favor one of a number of textual or tabular methods for capturing use cases, relating them to each other, and extracting common steps or information shared across use cases to a single location. This is similar to advice provided by Martin Fowler in UML Distilled.

If you strong feel that a use case diagram is needed, I would look at how I represent the Authenticate use case to make it more clear that there are actually two different flows. I believe that there are a few different options here that all conform to the specification.

Answer 2

I would prefer to factorize the commonalities between two use cases using generalization relationship between use cases.

The use cases Phone Order and Internet Order are specializations of the abstract use case Place Order (in italics).

In other words, generalization is used when you find two or more use cases that have commonalities in behavior, structure, and purpose. When this happens, you can describe the shared parts in a new, often abstract, use case, that is then specialized by child use cases.

You are further structuring use cases with ( and ) once know gain more understanding of the project.

Note that: (learn more about use cases)

1. A parent use case may be specialized into one or more child use cases that represent more specific forms of the parent.
2. Neither parent nor child is necessarily abstract
3. Although the parent in most cases is abstract.
4. A child inherits all structure, behavior, and relationships of the parent. Children of the same parent are all specializations of the parent.
5. Generalization is applicable to both use cases and actors