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 , 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 , 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  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 , 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  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 <<function>> stereotype (short for “application function”) is for interactive use cases with a human initiating actor, while the <<service>> stereotype is for use cases with an electronic initiating actor. See also the first reply attached to .
(**) The step is not written as, “Include …”, because the two use cases are connected via an association, not an include relationship (see  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 , 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.
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.
 Object Management Group (OMG), OMG Unified Modeling LanguageTM (OMG UML), Superstructure, Version 2.4.1, http://www.omg.org/spec/UML/2.4.1/.
 Willem Van Galen, Putting the inclusion use case in focus, 21 August 2012, http://www.batimes.com/articles/putting-the-inclusion-use-case-in-focus.html.
 Everware-CBDI, Service Architecture Layers, slide 9 of this presentation: http://www.codegeneration.net/cg2007/sessions/slides/EverwareCBDIMetaModelPresentation.ppt.
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.A “service” refers to a container and its operations are its “capabilities”.
- 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).