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:



2 Answers 2


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 ( 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.

  • Thanks for the insightful answer. To be honest, I'm just learning about UML and some of its diagrams, so I "must" deal with Use Case to learn more about it. This isn't something for production or work.
    – JChris
    Commented Dec 22, 2016 at 18:23
  • 2
    @JChris If you're learning UML, I would recommend reading about Martin Fowler's UML Modes and Scott Ambler's Agile Modeling.
    – Thomas Owens
    Commented Dec 22, 2016 at 18:34
  • @Thomas: By your statement, "What you have created is invalid," and by your reference to §, are you suggesting that Actors cannot have generalizations between them?
    – Jim L.
    Commented Dec 31, 2016 at 3:21
  • @JimL. I need to dig deeper into v2.5 of the spec to confirm, but that's my initial reading. I've seen generalization between actors done, but it's not presented as an example in the formal specification and it seems like it's not allowed. It could be confusing wording in that section of the specification, so I'll likely need to read a lot of other sections in more detail and jump around between definitions. It's on my list to do in the near future, though.
    – Thomas Owens
    Commented Dec 31, 2016 at 3:25
  • An Actor is ultimately a kind of Classifier that can have Generalizations with other Classifiers. A Generalization is not a more specific kind of Association.
    – Jim L.
    Commented Dec 31, 2016 at 3:29

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

enter image description here

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
  • The 2.5.1 UML - as far as I can read it - also only knows include, extend and extension points between use cases. So I would rather expect your diagram with an "extend" rather "specialize". The general idea of splitting use cases due to actor's difference, I agree. Commented Sep 3, 2019 at 13:19

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.