Skip to main content

The System: Don’t Model a Use Case Without It!


After getting involved in use case modeling many years ago, I was surprised to learn that some people had no qualms about modeling a use case without defining the “system” whose behavior the use case represented, even though there is a UML notation for it.  Today, the Internet contains many use case diagrams that lack any sense of “the system” (thankfully, it also contains many that do depict and name it). 

This article presents four questions that point to key reasons for defining a use case’s system, and three subtle aspects of representing systems in use case models.

Note: Section 16.1 of [1] uses “subject” to refer to “the system under consideration to which the use cases apply.”  This article uses “system” instead.  See also (*) of the second question below.

1.  Without a system, …

… what are actors interacting with?

According to section 16.3.1 of [1], a use case’s actor (class) represents an entity (instance) that “interacts with the [system]” and that is “external to the [system]”.  The use case, which is internal to the system, specifies how the interaction can take place and what its results can be, but is not something actor instances interact with.

It’s impossible to define a proper use case model if we don’t honor this fundamental notion from the start by defining “the system under consideration to which the use cases apply” (section 16.1 of [1]) in use case diagrams and use case specifications.


Tip: When you draw a use case diagram, always start by drawing and naming the system whose behavior is represented by the use cases to be added to that diagram.

… what is the boundary of a use case model?

In a way, the term “use case modeling” is unfortunate, because in the end it is not about modeling individual use cases but about modeling a particular system, such that each system has its own use case model.

Obviously, we can’t define a system’s use case model if we don’t have a clear sense of what that system is to begin with.

Tip: Just like in class modeling it’s impossible to define an operation without first defining the class that owns the operation, in use case modeling (or “system modeling”) we ought to consider it impossible to define a use case without first defining the system to which the use case applies (*), because, essentially, a use case represents an “operation” of a system (**).

(*)  It would go too far right now to explore the UML’s distinction between a use case’s “subject” (to which the use case applies) and a use case’s “owner” (that owns the use case).  For the purpose of this article, the “subject” and the “owner” are one and the same and represented as the “system”.

(**)  According to section 16.3.6 in [1], a use case “need not be attached to any specific subject [(system)].”  That strikes me as peculiar, because in explaining the use case concept, the description in the same section refers to a use case’s subject (system) no less than twelve times!  The gist of this article is that, for all practical intents and purposes, each use case ought to apply to a certain system.

… what constrains the use of include relationships?

As demonstrated in [2], an include relationship can only be used within a system.

Therefore, we can’t be sure we’re using include relationships properly if we have no clear idea of a system’s boundary.  See [2] for an additional constraint.

… how can we define a logical application systems architecture?

Influenced most recently by service-orientation, an organization’s application systems domain can be divided into architectural layers.  The top layer supports business processes and is itself supported by several underlying component layers.

A fundamental rule is “call down only”, so that a system in a higher layer can initiate an interaction with a system in any lower layer, but not the other way around.

Use case models can represent the logical (technology-neutral) view of this domain.

The following table summarizes 4 of the 5 layers from [3], in order to show how each “system” in these layers can be represented by its own use case model.


Without defining a use case’s system, we have no clear idea about the use case’s place in the systems architecture and we’d be modeling the use case in a vacuum.In this article, it’s not about the precise layers (different organizations favor different layers) but about having a layered systems architecture to begin with.

However, a use case’s system doesn’t magically appear when we start use case modeling during a project.  As this section aims to illustrate, that system must be defined and justified in an organization’s systems architecture before we know we need a use case model for it at all, let alone what its use cases ought to be.

2.  Representing systems in use case models

The previous section moved from the need to identify the system for a single use case to the need to identify such systems for an entire organization.  This section deals with some of the subtler aspects of representing (the connection between) systems in use case models.

Connections between systems: a notational wrinkle

Point 3 of [2] hints at a wrinkle in the UML representation of the connection between two systems.  This wrinkle can be summarized visually as follows (*).


The bottom view is perfectly in tune with the specification of Some Application Function Use Case, which at some point contains the step, “Initiate Some Service Use Case of Some Component.” (**)  Without that step, there would be no justification of why Some Component is a supporting actor of Some Application Function Use Case, and no clarification of where and how Some Component supports that use case.

(*)  The <> stereotype (short for “application function”) is for interactive use cases with a human initiating actor, while the <> stereotype is for use cases with an electronic initiating actor.  See also the first reply attached to [2].

(**)  The step is not written as, “Include …”, because the two use cases are connected via an association, not an include relationship (see [2] for details).

The next aspect is about getting one step closer to representing that a connection between two systems is in the end a connection between two of their use cases.

Generic initiating actor for service use cases

In the Some Component’s use case diagram above, the service use case’s initiating actor is shown specifically as Some Application, but this is only done to make the point represented by the bottom picture.  Like object operations, service use cases don’t assume context, because they are reusable by current and future consumers, in unpredictable contexts.  As a service use case sees it, its initiating actor is generic.

To reflect this in a use case model, I use “Electronic Function” as the initiating actor of every service use case.  This actor represents any set of electronic instructions, such as interactive application functions, batch applications, and services.  These are typical service consumers.  This evolves the use case diagram to the following.


An alternative is to name the generic actor after the role these electronic functions play vis-à-vis a service use case, like “Service Consumer”.  Still, I prefer “Electronic Function”, because it’s a more direct and obvious representation than “Service Consumer” (the former reflects the actor’s nature, whereas the latter doesn’t), and “Service Consumer” is redundant and therefore doesn’t add anything (the fact that it’s the initiating actor of a service use case already shows it’s a service consumer).

In use case models, a specific Electronic Function is represented as a use case.

Systems can be arranged into hierarchies

One best kept use case modeling secret (*) seems to be that systems can be arranged into hierarchies, where:

  • A lower-level system inherits use cases from its higher-level system(s).
  • A use case of a lower-level system can redefine (augment, constrain, or override) a use case inherited from a higher-level system.
  • Higher-level systems can be abstract, while lowest-level systems are concrete.

This is because in [1], a use case’s system is a Classifier, Classifiers can be arranged into hierarchies of generalized and specialized Classifiers, a specialized Classifier inherits Named Elements from its generalized Classifier(s), and a Use Case is a specialized Named Element.  (Since actors and use cases are also Classifiers, they can each be arranged in hierarchies as well, but this is outside the article’s scope.)

There may not be many opportunities to use this approach (I used it once so far), but it’s good to have this option in our use case modeling toolbox.

(*)  Another one may be revealed in a future article.

In conclusion

It is my hope that this article contributes to understanding the crucial role of systems in use case models (and the crucial role of use case models in the logical representation of systems) and to producing clear and intuitive use case models.

Don’t forget to leave your comments below.




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

[2] Willem Van Galen, Putting the inclusion use case in focus, 21 August 2012,

[3] Everware-CBDI, Service Architecture Layers, slide 9 of this presentation:

This article ignores the fifth layer, since it’s not needed to make the related point.

Essentially, there are two conventions for using the term “service”.

  1. 1.A “service” refers to a container and its operations are its “capabilities”.
  2. 2.The container is called a “component” and its operations are its “services”.

The above presentation uses the first.  In contrast, I use the second, as it strikes me as more intuitive (“service” refers to the service provided, not the service provider).