Skip to main content

Comparing and Contrasting Use Case Model Elements, Part 1


This 3-part article compares and contrasts pairs of use case model elements. This emphasizes that each featured element has a unique purpose. It also serves as a quick guide for determining when to use these elements. Lastly, it is a summary of my earlier Business Analyst Times use case modeling articles.

The article’s sections provide a logical progression through various pairs of use case model elements. Each section is meant to stand more or less on its own, with the intention that you can read most sections without having to read preceding ones. One side effect of this is that certain points occur in multiple sections.


A use case with an initiating actor represents an interaction of a user with a system. Yet, identifying that system doesn’t seem to be standard use case modeling practice.

  • The following summarizes key points made in [1].
  • The general term ‘system’ is represented in the UML as outlined in [2.2].

vangalen Img01 Nov5In a way, ‘use case modeling’ is an unfortunate term, because in the end use case modeling is not about modeling just use cases, but about modeling the systems to which those use cases apply. As long as we remember that, the term is secondary.


It seems to me that the nature of a UML-based use case model cannot be grasped completely without an understanding of concrete and abstract use cases. Likewise, that distinction cannot be understood fully without considering a use case model’s ‘modeling time’ and ‘execution time’ views, because it’s only in the latter view that the distinction becomes crystal clear (i).vangalen Img02 Nov5

In summary, each use case is either concrete or abstract, so unless we choose to ignore this aspect altogether, it’s important to know how to determine this for every use case we model. This article, and my previous ones, should help with that.


In this section, the general term ‘relationship’ includes and excludes the following.

vangalen Img03 Nov5See [3] for include relationship, [4] and part 3 of this article for extend relationship, [2] for generalization relationship, and [3.1] for association.

vangalen Img04 Nov5In summary, association and relationship are each other’s inverse.


The general term ‘included use case’ covers:

  • An abstract ‘inclusion use case‘ that is included at least twice (see [3.1]);
  • A concrete use case that is included at least once (see [3.2]).

The ‘extension use case’ concept is explored in [4] and in this article’s part 3.

vangalen Img05 Nov5In summary, the include and extend relationships are each other’s inverse.


In this section:

  • An ‘inclusion use case‘ refers to an abstract use case ‘fragment’ that’s included at least twice (see [3.1]).
  • A ‘generalization use case’ represents the common aspects of two or more ‘specialization use cases’ (see [2]).

vangalen Img06 Nov5In summary, the inclusion and generalization use cases are each other’s inverse.


The patterns in this section show that the goal of a user interacting with a system isn’t necessarily equal to the goal of the use case the user initiates towards that end. Moreover, a use case that is directly or indirectly related to the initiated use case may represent a goal of someone other than the user (i.e., an off-stage stakeholder).

Note that this section is about meeting a user goal by ‘going deep’ for a given concrete use case, not by ‘going across’ several of a system’s concrete use cases.

Pattern 1: User’s Goal = Use Case Goal

This is the simplest pattern, where a single initiated use case meets the user’s goal.

vangalen Img07 Nov5The use case may meet sub goals of one or more off-stage stakeholders, but that is not obvious from the use case diagram; only the use case’s specification will tell. 

Pattern 2: User’s Goal = Use Case Goal (With Included Use Case Sub Goal)

In this pattern, the initiated use case represents the user’s goal, but an included use case represents an off-stage stakeholder’s goal, which is a sub goal of the initiated use case’s goal.

vangalen Img08 Nov5An included use case can be abstract (as in the diagram) or concrete (as in [3.2]).

Some key observations about this pattern are summarized below.

vangalen Img09 Nov5In summary, an included use case always represents a sub goal of the including use case’s goal (the former is nested within the latter).


Part 2 continues with two more user goal vs. use case goal patterns and compares and contrasts a few more pairs of use case model elements.

Don’t forget to leave your comments below.


(i) The conceptual ‘execution time’ view is the natural complement to the real ‘modeling time’ view represented by use case diagrams and use case specifications.

  • The ‘modeling time’ view can also be seen as the ‘classifier’ view, in that its core elements of system, actor, association and use case are all classifiers, each of which “is a classification of instances” that “describes a set of instances that have features in common”, according to [5].
  • The ‘execution time’ view can also be thought of as the ‘instance’ view, because for a given system (an instance of a classifier) its usual focus is on a single user (an instance of an initiating actor) and a single use case execution (an instance of an initiated use case), which are connected via a link (an instance of the association between the actor and the use case).

Considering only the ‘modeling time’ view amounts to just seeing half the picture.


[1] Willem Van Galen, The System: Don’t Model A Use Case Without It!, 11 September 2012

[2.1] Willem Van Galen, Generalization and Use Case Models, Part 1, 12 August 2013

[2.2] Willem Van Galen, Generalization and Use Case Models, Part 2, 2 September 2013 

[3.1] Willem Van Galen, Putting The Inclusion Use Case In Focus, 21 August 2012 

[3.2] Willem Van Galen, The Include Relationship’s Other Use, 18 June 2013 

[4.1] Willem Van Galen, Excavating the extension use case, Part 1, 10 July 2012 

[4.2] Willem Van Galen, Excavating the extension use case, Part 2, 24 July 2012 

[4.3] Willem Van Galen, Excavating the extension use case, Part 3, 12 March 2013 

[5] Object Management Group (OMG), OMG Unified Modeling LanguageTM (OMG UML), Superstructure, Version 2.4.1.