5

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:

Example

JChris
  • 161
  • 4
  • Why is "admin" pointing to "user," not "authenticate?" – Robert Harvey Dec 22 '16 at 16:27
  • I'm using `generalization`, as you can see by the arrowhead style from `Admin` to `User`. Example: http://www.modernanalyst.com/Careers/InterviewQuestions/tabid/128/ID/360/What-is-actor-generalization.aspx – JChris Dec 22 '16 at 16:28

2 Answers2

7

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.

Thomas Owens
  • 79,623
  • 18
  • 192
  • 283
  • 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 Dec 22 '16 at 18:23
  • 2
    @JChris If you're learning UML, I would recommend reading about Martin Fowler's [UML Modes](http://www.martinfowler.com/bliki/UmlMode.html) and Scott Ambler's [Agile Modeling](http://www.agilemodeling.com/). – Thomas Owens Dec 22 '16 at 18:34
  • @Thomas: By your statement, "What you have created is invalid," and by your reference to §18.2.1.4, are you suggesting that Actors cannot have generalizations between them? – Jim L. Dec 31 '16 at 03: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 Dec 31 '16 at 03: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. Dec 31 '16 at 03:29
  • @JimL. Can you point to the relevant sections in the specification that say that? I've been looking for something that says if a Generalization is or is not an Association and haven't found it yet. Although even if generalization of Actors is allowed, the model presented in the question is still not right, since the use case shown actually represents two sets of behaviors while a use case is supposed to show a single set of behaviors. – Thomas Owens Dec 31 '16 at 03:39
  • Forget text searches. Follow the metamodel diagrams, from Actor up to Classifier. You will find a meta association with ends called "general" and "specific". – Jim L. Dec 31 '16 at 03:42
  • @JimL. That's on my to-do list in the very near future. I'll edit this answer if and when I find specific information in the spec. If you can point out the specific section or page numbers to save me the work, that would be great. Or write your own answer to the question that references/quotes the right parts of the spec. – Thomas Owens Dec 31 '16 at 03:46
  • You really should have done that already. Now five people have learned it incorrectly. Another answer cannot undo that. – Jim L. Dec 31 '16 at 03:48
1

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
Chk Tsang
  • 21
  • 6
  • 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. – Shegit Brahm Sep 03 '19 at 13:19