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 ) 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 , 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.
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.
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.
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.
Association between two service use cases specifying the same system
According to section 16.3.6 of , “Two use cases specifying the same [system] cannot be associated since each of them individually describes a complete usage of the [system].” In other words, you cannot draw an association between two use cases that apply to the same system, where the first initiates the second.
Based on practical experience, I have come to view this rule as too narrow when it comes to service use cases. As mentioned, the generic initiating actor of a service use case represents all its possible consumers, including other service use cases!
The only condition I see for stretching the rule for service use cases is that the second service use case must already exist as a public service use case in its own right, lest we are tempted to create private service use cases whose sole purpose is to reflect the functional decomposition of a public service use case (see also ).
Just as in class modeling it’s possible for one public operation of a given class to invoke another public operation of the same class, it ought to be possible for one public service use case of a given system to initiate another public service use case of the same system. Relaxing the rule increases service use case reuse.
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.
Powered by Facebook Comments