Author: Willem Van Galen

Comparing and Contrasting Use Case Model Elements Part 3

INTRODUCTION

This final part of the article compares and contrasts three more pairs of use case model elements, and suggests that use cases are not instantiated in their capacity as included, extending and generalization use cases.

EXTENSION USE CASE VS. OPTION FLOW

The ‘extension use case’ concept is explored in [1] and in section ‘Instantiating Included and Extending Use Cases?’ below.

The ‘option flow’ idea is introduced in [2] and further referenced in [1.3].

vgdec3 img01

In summary:

  • It seems to me that the use of the extension use case to represent conditional behavior whose outcome is reflected in the postconditions of the extended use case, is actually an antipattern (i).
  • As Jacobson writes in [3], “The base use case must be complete by itself and not require the extension. Otherwise, you must use alternative paths to describe additional behavior.”
  • When such conditional behavior is non-essential to the extended use case (i.e., the use case can achieve its goal without the behavior), option flows are those “alternative paths”.

EXTENSION USE CASE VS. SUBSCRIBER USE CASE

The ‘extension use case’ concept is explored in [1] and in section ‘Instantiating Included and Extending Use Cases?’ below.
The ‘subscriber use case’ and ‘publisher use case’ notions are introduced in [4].

vgdec3 img02Article [1.2] provides a rationale for why base & extension use cases don’t reflect Event-Driven Architecture, while publisher & subscriber use cases do.

INSTANTIATING INCLUDED AND EXTENDING USE CASES?

Where I encountered the idea

In [3], Jacobson seems to suggest that during the execution of a concrete base use case an included or extending use case can be instantiated, as follows.

  • When a user initiates the concrete base use case, it gets instantiated;
  • At an inclusion point in the base use case, the included use case gets instantiated as well;
  • At an extension point in the base use case, the extending use case gets instantiated as well.

This impression is based on:

  • The statement, “Concrete use cases can extend a base use case or be included in a base use case.” (ii)
  • The definition of concrete extension and inclusion use cases as use cases that “interact with and provide value to actors” and that have “significant behavior”.

At first blush, I’m not won over by this definition, as it seems arbitrary:

  • Abstract extension and inclusion use cases can also “interact with and provide value to [users]”; they just can’t be initiated (instantiated) by them.
  • Obviously, “significant” is a subjective term.

More important, the UML doesn’t seem to support the notions of a concrete extension use case and a concrete inclusion use case (where ‘inclusion use case’ refers to a use case fragment as defined in [5.1], not to an included use case that’s concrete in its own right as discussed in [5.2]).

The following sections explore this in more detail.

Extension use cases in the UML

Key excerpts of chapter 16.3.3 in [6] are:

  • An extended use case has an “extension location”, which is an “ordered list of extension points […] specifying where the respective behavioral fragments of the extending use case are to be inserted.”
  • An extension use case “consists of one or more behavior fragment descriptions that are to be inserted into the appropriate spots of the extended use case.”

The paragraph after that states:

  • “The individual fragments are executed as the corresponding extension points of the extending use case are reached. Once a given fragment is completed, execution continues with the behavior of the extended use case following the extension point. Note that even though there are multiple use cases involved, there is just a single behavior execution.”

No concrete extension use cases, then

The preceding leaves me with the following impression.

  • An extension use case isn’t meant to be concrete, because its specification is nothing more than a bunch of “behavior fragment descriptions”, whose only purpose is “to be inserted into the appropriate spots of the extended use case [specification]” (it’s not meant to represent the full life cycle behavior of an independent extension use case instance).
  • In other words, an extension use case’s specification only makes sense in the context of the behavior of the extended use case, and only to the extent that the extended use case’s extension points reveal clues about that behavior (the rest of the behavior is encapsulated in the extended use case).
  • Moreover, the quote’s concluding note reinforces the notion that at execution time there is only one use case instance (“just a single behavior execution”), which, of course, is an instance of the concrete use case the user initiated and whose specification is, in this case, combined with the specification of the extension use case, as described in detail in [6] (the extension use case isn’t instantiated).

See (iii) for additional comments on [3] and event-driven use case coupling.

Directed relationships in the UML

More generally, in [6] the include, extend and generalization relationships are different types of directed relationship. They are relationships between use cases, but as the above shows, they are fundamentally (at modeling time and execution time) about connections between the specifications of the related use cases; they are not about links between instances of the related use cases (at execution time), because that’s what associations are for (at modeling time).

Functional dependencies

These relationships represent functional dependencies between the specifications of the related use cases, as summarized below (initiating actors omitted for brevity).

vgdec3 img03The diagram shows the included, extending and generalization use cases as abstract. However, it’s not their abstract nature, but their capacity as included, extending and generalization use cases, that determines they won’t be instantiated.

The remaining question, “can an included, extending or generalization use case be a concrete use case outside its capacity as a related use case?”, is explored below and in [5.2] and [7].

vgdec3 img04No instantiation of included, extending and generalization use cases, then

Based on this reading:

  • I don’t see how it’s possible or necessary to instantiate a use case in its capacity as an included, extending or generalization use case.
  • An included use case and a generalization use case can be concrete in their own right, but I cannot think of any situation in which an extending use case can be concrete in its own right; it seems that an extending use case is always abstract.

FUNCTIONAL DEPENDENCY VS. SEQUENTIAL DEPENDENCY

Before concluding the article, this section compares and contrasts ‘functional’ and ‘sequential’ dependencies between use cases. These are detailed in [8] and [5.2].

Note that the following applies to dependencies between use cases within a given system, not between use cases of different systems (iv).

vgdec3 img05In summary, being able to recognize and model sequential dependencies between use cases is likely to reduce the use of relationships between use cases as compared to viewing and modeling every dependency as a functional one (e.g., including the ‘Sign In’ use case in every concrete use case that requires a user to be signed in).

IN CONCLUSION

It is my hope that this article helps to underline the unique purpose of each of the referenced use case model elements, is instructive in deciding when to use them, and promotes greater consistency across use case models (that is, system models…).

NOTES

(i) An example of this antipattern is:

  • The Place Order use case is extended by the Apply Discounts use case.
  • The Place Order use case’s postconditions state that one or more discounts may have been applied (e.g., “For each approved discount, the order’s pre-tax total amount has been reduced by the discount amount”).

This is an antipattern because Place Order is oblivious of Apply Discounts and therefore neither knows about discounts nor can refer to them in its postconditions.

  • If Apply Discounts were to be maintained as an extending use case, any mention of discounts would have to be removed from Place Order’s postconditions, because applying discounts could not possibly be a sub goal of Place Order’s goal; however, the fact that Apply Discounts would have to update Place Order’s ‘pre-tax total amount’ disqualifies it from being an extending use case (see section ‘On patterns 3 and 4’ in part 2 of this article).
  • So, discounts must be mentioned in Place Order’s postconditions and Apply Discounts must be represented as an option flow, making applying discounts an optional sub goal of Place Order’s goal.

(ii) Article [5.2] deals with including a use case that’s already a concrete use case in its own right, but the questions this section pursues are:

  • In its capacity as an included use case, can a concrete use case be instantiated?
  • Can an extending use case be a concrete use case in its own right?
  • Can an extending use case be instantiated at all?

(iii) Figure 2 in [3] is about a quasi event-driven connection between the concrete use cases Conduct Transaction and Inspect Transaction Failures.

  • The extending use case Register Failures ‘publishes’ an ‘event’ (of type ‘transaction failed’) that occurred in the extended use case Conduct Transaction.
  • The ‘special’ dependency (without a definite stereotype) between the concrete use case Inspect Transaction Failures and use case fragment Register Failures represents that Inspect Transaction Failures is a ‘subscriber’ to the ‘events’ that are ‘published’ by Register Failures.

That being so, I’d model this connection using the Event-Driven Architecture approach outlined in [4] instead, for the following reasons.

  • Figure 2 of [3] deals with exception events; the approach in [4] is first of all about normal events, but can handle exception events just as well (why have two approaches for the same pattern?).
  • Figure 2 of [3] shows a ‘dependency trail’ from Inspect Transaction Failures, via Register Failures, all the way back to Conduct Transaction (tight coupling); using the approach in [4], there is no dependency between a subscriber use case and any ‘upstream’ use cases, because a subscriber use case is only interested in events, independent of the use case(s) that published them (loose coupling).

In Figure 2 of [3], the publication of events is handled by an extension use case; in the approach in [4], the publication is part of the use case that encounters them. Reasons for favoring the latter pattern include the following.

  • Publishing an event typically means including event data in the published event object; such data is, of course, readily accessible by the use case that encounters the event, but is not necessarily accessible, or easily accessible, by a separate extension use case of that use case.
  • Depending on how widely the approach gets used, the number of ‘publisher’ extension use cases could get large and use case diagrams could look cluttered.

In the end, it’s a matter of preference, because both approaches work.

(iv) A use case of a given system is functionally dependent on a use case of another system when the other system is a supporting actor of the given system’s use case; this dependency is shown as an association that crosses the system boundaries and ought to be detailed in the given use case’s specification (e.g., “The system initiates of ”).

Don’t forget to leave your comments below.

REFERENCES

[1.1] Willem Van Galen, Excavating the extension use case, Part 1, 10 July 2012, http://www.batimes.com/articles/excavating-the-extension-use-case.html

[1.2] Willem Van Galen, Excavating the extension use case, Part 2, 24 July 2012, http://www.batimes.com/articles/excavating-the-extension-use-case-part-2.html

[1.3] Willem Van Galen, Excavating the extension use case, Part 3, 12 March 2013, http://www.batimes.com/articles/excavating-the-extension-use-case-part-3-nuance.html

[2] Willem Van Galen, Use Case Goals, Scenarios and Flows, 13 November 2012, http://www.batimes.com/articles/use-case-goals-scenarios-and-flows.html

[3] Ivar Jacobson, Use Cases: Yesterday, Today, and Tomorrow, 20 November 2003, found at http://www.ibm.com/developerworks/rational/library/775.html (page no longer exists; see: http://www.spinsp.org.br/grupo/Future_%20of_Cases.pdf).

[4] Willem Van Galen, Modeling Loosely Coupled Use Cases, 30 April 2012, http://www.batimes.com/articles/modeling-loosely-coupled-use-cases.html

[5.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

[5.2] Willem Van Galen, The Include Relationship’s Other Use, 18 June 2013, http://www.batimes.com/articles/the-include-relationships-other-use.html

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

[7] Willem Van Galen, Generalization and Use Case Models, Part 2, 2 September 2013, http://www.batimes.com/articles/generalization-and-use-case-models-part-2.html

[8] Willem Van Galen, Use Case Preconditions: A Best-Kept Secret?, 15 October 2012, http://www.batimes.com/articles/use-case-preconditions-a-best-kept-secret.html

Comparing and Contrasting Use Case Model Elements, Part 2

INTRODUCTION

This second part of the article concludes the user goal vs. use case goal patterns and compares and contrasts an additional pair of use case model elements introduced along the way.

USER GOAL VS. USE CASE GOAL (CONT’D)

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 3: User’s Goal = Use Case Goal (With Deviation Extension Use Case Side Goal)

In this pattern, the initiated use case pursues the user’s goal, but is interrupted for a moment by an extension use case that pursues an off-stage stakeholder’s side goal.

  • Typically, and in this example, this pattern is about different stakeholders, but perhaps there are situations where both goals have the same stakeholder.

I use the term ‘deviation extension’ to indicate that the goal of the extension use case deviates from (is at odds with) the goal of the extended use case, albeit without the extended use case knowing so.

  • The ‘deviation’ extension use case’s goal can also said to be ‘perpendicular’ to the extended use case’s goal, in the sense that it ‘cuts across’ that goal (see [1]).
  • In the next diagram, this is emphasized by drawing the two use cases at a right angle of each other and by using the <> stereotype.

Regarding the following diagram, which is based on Ivar Jacobson’s example in [2]:

  • The Call Handling use case allows a user to make a phone call. The use case starts when the user lifts the receiver off the hook (the example is from 1979).
  • The conditional Traffic Recording use case counts the phone call being made, but only when traffic must be recorded.

In other words, a call can be counted, but this behavior is non-essential to completing the Call Handling use case.

vangalen nov19 IMG01Key observations about this pattern are provided after pattern 4.

Pattern 4: User’s Goal = Use Case Goal + Augmentation Extension Use Case Side Goal

This is the pattern where the initiated use case pursues part of a larger user goal and, unbeknownst to itself, is augmented by an extension use case that represents another part of that larger user goal.

  • This pattern is typically about situations where both goals have the same stakeholder.

I use the term ‘augmentation extension’ to indicate that the goal of the extension use case augments (is incremental to) the goal of the extended use case, albeit without the extended use case knowing so.

  • The ‘augmentation’ extension use case’s goal can also said to be ‘linear’ to the extended use case’s goal, in the sense that it ‘falls in line’ with that goal.
  • In the next diagram, this is reinforced by drawing the two use cases horizontally in line with each other and by using the <> stereotype.

Regarding the following diagram (i):

  • The Bonus Employee use case allows a user to specify a one-time bonus for an employee. The use case enables the user to provide the employee’s id, to correct it when necessary, to provide the bonus amount and description, and to complete or cancel the transaction.
  • The conditional Verify Employee Id use case provides the user with the employee name for the employee id provided.

In other words, the user can choose to verify the employee id, but this behavior is non-essential to completing the Bonus Employee use case.

vangalen nov19 IMG02On patterns 3 and 4

The following observations about patterns 3 and 4 apply in the end to the extension use case construct in general.

vangalen nov19 IMG03In summary, an extension use case always represents a side goal to the extended use case’s goal (the former is not nested within the latter).

In Conclusion

These four patterns (see article’s part 1 for the first two) result from ‘separating concerns’, which in this case requires recognizing the difference between:

  • User goal vs. use case goal;
  • User goal vs. off-stage stakeholder goal;
  • Sub goal vs. side goal;
  • Deviation extension vs. augmentation extension.

DEVIATION EXTENSION USE CASE VS. AUGMENTATION EXTENSION USE CASE

In keeping with the article’s theme, this section compares and contrasts the notions of ‘deviation’ and ‘augmentation’ extension use cases introduced above.

vangalen nov19 IMG04

TO BE CONTINUED

Part 3 compares and contrasts a few more pairs of use case model elements and explores whether use cases can be instantiated in their capacity as included, extending and generalization use cases.

Don’t forget to leave your comments below.

NOTE
(i) The comments added to [1.2] introduced the example of a word processing application with an extended use case Edit Document and an extending use case Check Spelling. Even though this could serve in principle as an example of an ‘augmentation’ extension, it is purposely avoided here, for the following reasons.

  • I doubt it’s a good idea to use a use case model to represent a word processing application, because while use cases are great for modeling sequential processes, they seem to be less than ideal for modeling event-driven processes like those of a word processing application (not to be confused with the loose/event-driven coupling of sequential processes detailed in [4]).
  • Marking extension points in a predefined sequential process is straightforward, but doing so in an event-driven process is pretty well impossible, because there is no predetermined sequence of steps a user must take.

REFERENCES

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

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

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

[2] Ivar Jacobson, Use Cases and Aspects – Working Seamlessly Together, Journal Of Object Technology, Vol. 2, No. 4, July-August 2003.

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

[4] Willem Van Galen, Modeling Loosely Coupled Use Cases, 30 April 2012.

Comparing and Contrasting Use Case Model Elements, Part 1

INTRODUCTION

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.

SYSTEM VS. NO SYSTEM

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.

CONCRETE USE CASE VS. ABSTRACT USE CASE

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.

ASSOCIATION VS. RELATIONSHIP

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.

INCLUDED USE CASE VS. EXTENSION USE CASE

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.

INCLUSION USE CASE VS. GENERALIZATION USE CASE

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.

USER GOAL VS. USE CASE GOAL

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).

TO BE CONTINUED

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.

NOTE

(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.

REFERENCES

[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.

 
 
 
 
 
 
 
 

Generalization and Use Case Models, Part 2

Introduction

The article’s first part set the stage with an object-oriented example of generalization (and specialization) of classes and then discussed generalization of use case actors.  This second part continues with generalization of use cases and concludes with generalization of systems to which use cases apply.

GENERALIZING USE CASES

Why use cases can be generalized

In [1], UseCase is a subclass of BehavioredClassifier, which is a subclass of Classifier.  Because generalization is a feature of Classifier, UseCase inherits this feature from that class.  In other words, use cases can be arranged in a use case hierarchy.

An example

Imagine producing a use case model for a travel website and finding out that the concrete use cases Book a Car, Book a Flight and Book a Hotel are all based on one core booking process and only differ in certain details.  How can you define the core booking process once and address the unique details for each concrete use case?  

By using use case generalization, of course!  See next diagram (i) (ii).

MVGAug6th-1

Use case generalization (and specialization) results in a use case hierarchy.

What a use case hierarchy means

Because we’re generalizing three already existing concrete use cases, the resulting generalization use case is ‘completely partitioned’ (entirely subdivided into sub use cases) and therefore abstract (no use case instances can be created in it).

As with any generalization, type correspondence between the sub and super use cases is a must.  The statements ‘Book a Car is a type of Book a Trip Component’, ‘Book a Flight is a type of Book a Trip Component’ and ‘Book a Hotel is a type of Book a Trip Component’ are all true, so the use case hierarchy is appropriate.

When a concrete use case has a generalization relationship with a generalization use case, it means that at run time the generalization use case’s specification and the concrete use case’s specification are combined into a single use case specification that governs the behavior of each use case instance in the concrete use case.

  • The behavior of a concrete Book a Car use case instance is governed by the combined use case specifications of the Book a Trip Component and Book a Car use cases.
  • There will never be a Book a Trip Component use case instance.

The use case specifications

The generalization use case’s specification:

  • Defines the initiating actor, provided this is common to all of the specialization use cases.
  • Defines the supporting actor(s) common to all of the specialization use cases. 
  • Defines the steps that are common to all of the specialization use cases.
  • May define default steps that apply to some but not all of the specialization use cases (*).
  • May define empty placeholders for steps that are to be defined by one or more of the specialization use cases (**).

A specialization use case’s specification:

  • Defines the initiating actor, provided this is not defined by the generalization use case specification.
  • Defines any supporting actor(s) needed by the specialization use case and not defined by the generalization use case specification.
  • May override default steps of the generalization use case’s specification, by defining its own version of those steps (*).
  • May fill in empty placeholders of the generalization use case’s specification, by defining its own steps for those placeholders (**).
  • May delete steps of the generalization use case’s specification.
  • May add its own steps, which aren’t in any way anticipated in the generalization use case’s specification (***).

(*)  Similar to the object-oriented example’s ‘method override’ pattern in [2].
(**)  Similar to the object-oriented example’s ‘method deferral’ pattern in [2].
(***)  Similar to the object-oriented example’s ‘operation addition’ pattern in [2].

In the end, both specifications must be written so that when they’re combined, the result represents the complete specification for the specialization use case.

The two specifications are always “textually combined”, similar to the way some included use case specifications are “textually included” in a base use case specification, as outlined in [3] and [4].

Object-oriented use case implementation

Specifying use case steps this way foreshadows an object-oriented implementation of the use cases involved, where the steps of the use cases map to operations on underlying classes. 

  • Just like the steps are defined for generalization and specialization use cases, the operations can be defined on generalization and specialization classes, as illustrated in the object-oriented example in [2].

GENERALIZING SYSTEMS

What is a system, again?

According to 16.3.2 (iii) in [1], a UseCase has:

  1. An ‘owning classifier’.  This is the ‘namespace’ of which the UseCase is an ‘owned member’.  It is the unique location in a model where the UseCase is defined (iv).
  2. Zero or more ‘subjects’.  These are the Classifiers to which the UseCase applies (for a given ‘subject’, the UseCase “specifies some behavior […] that the subject can perform”).

Section 16.3.2 in [1] states that “the owning classifier typically represents the subject to which the owned use cases apply”, but adds that “this is not necessarily the case.”

  • Since a Classifier (and therefore, a UseCase) can be a PackageableElement, and a PackageableElement is owned directly by a Package, a UseCase’s ‘owning classifier’ can be a Package.
  • Obviously, a UseCase doesn’t represent behavior that a Package can perform, because a Package is merely “used to group [model] elements, and provides a namespace for the grouped [model] elements.”

So, if and when a UseCase’s ‘owning classifier’ is a Package, the UseCase’s ‘subject’ defines the system (or its ‘subjects’ define the systems) to which the UseCase applies.  But why can there be multiple subjects?

  • Although [1] doesn’t seem to state it outright, I suspect this is meant to support UseCase reuse.

In any event, a UseCase “specifies some behavior […] that [a system] can perform”, where ‘system’ is either the UseCase’s ‘owning classifier’ or one of the UseCase’s ‘subjects’ (if the ‘owning classifier’ is a Package).  The article’s remainder uses the generalized term ‘system’, which covers both alternatives.

Section basis

The contents of this section are based on the following assertions.

  • A use case is to a ‘system‘ what an operation is to a class.
  • A ‘classifier behavior’ is to a use case what a ‘method’ is to an operation.

UML metamodel summary

These statements are based on the next diagram, which summarizes the classes and associations from [1] that are essential to these points.  The diagram shows how the pattern of a Classifier (‘system’) and its UseCases mirrors the pattern of a Class and its Operations, and how the pattern of a UseCase and its ‘classifier behavior’ mirrors the pattern of an Operation and its ‘method’.

MVGAug6th-2

Classifier diagram

Because of the above, and using the default Classifier notation (7.3.8), we can show Classifiers (‘systems’) and their UseCases in a “classifier diagram” like the one below, similar to how we can show Classes and their Operations in a class diagram like the one in [2].

Imagine a consumer electronics retailer with two branded distribution channels, and a website for each channel.  In the next diagram, the abstract channel website system represents what the concrete channel website systems have in common (v).

MVGAug6th-3

Justification

I don’t recall reading about a system hierarchy elsewhere, but it strikes me as valid, for the following reasons.

  1. A UseCase’s ‘system’ is a Classifier, and as such is concrete or abstract (7.3.8).
  2. Since they are Classifiers, ‘systems’ can be arranged into a hierarchy, using generalization relationships (7.3.8).
  3. Since a UseCase is to a ‘system’ what an Operation is to a Class, a UseCase can be shown in the “use cases compartment” of a ‘system’, similar to how an Operation is shown in the operations compartment of a Class (7.3.8).
  4. Because a UseCase is also a type of RedefinableElement “defined in the context of a classifier” (7.3.47), it can be “redefined more specifically or differently in the context of another classifier that specializes (directly or indirectly) the context classifier.”  In other words, a UseCase of a super ‘system’ can be redefined by a sub ‘system’, similar to how an Operation (also a type of RedefinableElement) of a super Class can be redefined by a sub Class.

Type correspondence

As is the case for a class hierarchy, ensuring type correspondence is a must for a system hierarchy.

  • In this case, the statements ‘the Red Channel Website is a type of Channel Website’ and ‘the Blue Channel Website is a type of Channel Website’ are true, so the system hierarchy is appropriate.

Class diagram and method specification

Based on the earlier class diagram, the diagram below illustrates the scope of:

  • A class diagram.
  • What I know as a “method specification”.

MVGAug6th-4

Use case diagram and use case specification

Along similar lines, the following diagram illustrates the scope of:

  • A use case diagram.
  • What I habitually refer to as a “use case specification”.

MVGAug6th-5

Note:

  • Since the earlier diagram doesn’t include actors, neither does this one; however, actors are part of both scopes, as applicable.
  • While [1] specifies that both an Operation and a Behavior specify preconditions and postconditions, it makes no such statement about a UseCase, which is why these conditions are in square brackets in the above diagram. 
  • However, given this comparison of a UseCase to an Operation, it stands to reason to expect a UseCase to specify preconditions and postconditions as well. 
  • In fact, this is a must for a UseCase whose system doesn’t provide a Behavior for it, but defers this to its sub systems (like the object-oriented example’s ‘method deferral’ pattern in [2]). 
  • See also the discussion on contravariance (of superclass and subclass preconditions) and covariance (of superclass and subclass postconditions) in chapter 11 of [5].

Use case parameters

Using the use case stereotypes I mentioned in earlier articles, use cases and parameters relate as follows.

  • A <> use case (short for ‘application function’; initiated by a person) typically has no parameters, because data is exchanged between user and system as a use case execution unfolds.
  • A <> use case (initiated by an electronic entity) typically has input and output parameters, because that’s the nature of a service.  This kind of use case is most like an operation of a class.
  • A <> use case (short for ‘scheduled process’; initiated by a schedule or time) typically has no parameters, because it knows by design where to get its input and where to put its output.

Use case reuse

A system hierarchy enables use case reuse within the hierarchy, where there is type correspondence between the systems.  Assigning a use case to multiple ‘subjects’ accommodates use case reuse without a system hierarchy, so there isn’t necessarily type correspondence between the systems.

Use case polymorphism

Both reuse approaches contribute to polymorphism, where different systems can respond to the same kind of message requesting the execution of a certain use case. 

Scope of polymorphism

The scope of polymorphism for a given use case is the set of systems to which the use case applies (directly or indirectly) and can be one of the following.

  • When using a system hierarchy, the top-level system that defines a certain use case and the lower-level systems that inherit it, form what [5] calls a ‘cone’ of polymorphism, because the scope of polymorphism is (a branch of) the inverted tree structure of a system hierarchy, which is shaped like a cone.
  • When assigning a use case to multiple ‘subjects’, those systems end up forming what [5] calls a ‘ragged’ scope of polymorphism, because the scope doesn’t necessarily correspond to (a branch of) the inverted tree structure of a system hierarchy, and therefore doesn’t necessarily form a cone shape.

Implementation considerations

The table below summarizes for the hierarchy types discussed in this article to what degree they’re directly supported in the physical (technology-specific) domain.

Since these constraints do not apply to the logical (technology-neutral) domain to which use case models belong, we can use actor, use case and system generalization in use case models without reservation.

MVGAug6th-6

In conclusion

Actor, use case and system generalization (and specialization) are special tools we can add to our use case modeling toolbox.  We may not use them all that often (they are listed in most-to-least-likely-to-use order), but it’s good to know they’re there, just in case we encounter those special circumstances where they’re just what we need to get the job done right.

Don’t forget to leave your comments below.

 


 

Notes

(i)  To convey the fundamentals as clearly as possible, the example is purposely kept simple and excludes additional trip components (e.g., a cruise), trip component bundles (e.g., flight + hotel), and the use of external systems (supporting actors).

(ii)  Associating the initiating actor with an abstract use case is notational shorthand for associating the initiating actor with each of the concrete use cases instead.  As such, it upholds the rule that a concrete use case is a use case that has an initiating actor.  See also the inherited association in the object-oriented example in [2].

(iii)  Throughout the article, 2- or 3-part numbers refer to sections in [1] (e.g., 13.3.2) and UML role names are enclosed in single quotes (e.g., ‘classifier behavior’).

(iv)  The ownership association between Classifier and UseCase is a specialization of the ownership association between Namespace (‘namespace’) and NamedElement (‘owned member’).  While ‘owned member’ is specialized to ‘owned use case’, no specialization for ‘namespace’ is given.  This article uses ‘owning classifier’ as that specialization, which [1] uses throughout the text but not in the formal model.

(v)  A “classifier diagram” introduces a clash of terms, because in such a diagram:

  • An abstract use case is a UseCase for which the system doesn’t provide a Behavior, not a UseCase that cannot be instantiated.
  • A concrete use case is a UseCase for which the system does provide a Behavior, not a UseCase that can be instantiated.

To avoid this clash, alternative terms in a “classifier diagram” could be:

  • An ‘abstract as operation’ UseCase.
  • A ‘concrete as operation’ UseCase.

References

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

[2] Willem Van Galen, Generalization and Use Case Models, Part 1, 12 August 2013, http://www.batimes.com/articles/generalization-and-use-case-models-part-1.html

[3] 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

[4] Willem Van Galen, The Include Relationship’s Other Use, 18 June 2013, http://www.batimes.com/articles/the-include-relationships-other-use.html

[5] Meilir Page-Jones, Fundamentals of Object-Oriented Design in UML, 4th Printing, September 2000, Addison-Wesley.

 

Generalization and Use Case Models, Part 1

INTRODUCTION

Starting with an object-oriented example to set the stage, this article explores generalization (and specialization) in use case modeling. Part one outlines key concepts and addresses generalization of use case actors. Part two covers generalization of two additional use case model elements.

SETTING THE STAGE

The best way to promote a common understanding of generalization is through a simple object-oriented example, especially since use case models are founded on object-oriented principles (i). Most of the concepts encountered in the example trace back to [1] and [2], which strike me as highly informative books.

An object-oriented example

Imagine an object-oriented inventory system for an organization’s tables and chairs. In the real world, each table and each chair is a physical object. In the electronic world of the inventory system, each physical table is represented as an electronic object of type Table and each physical chair is represented as an electronic object of type Chair, so that:

  • Each object’s type indicates what the object is in and of itself (independent of any context), for its entire existence (the type doesn’t change during the object’s lifetime).
  • An object’s type corresponds to the concrete class in which it is created (ii), so that an object of type Table is created in the concrete class Table and an object of type Chair is created in the concrete class Chair.

The Table and Chair classes are defined beforehand and specify the kinds of characteristics (e.g., particular attributes and associations) for which an object created in the class has individual characteristics (e.g., specific attribute values and links). For example, a Chair object has a True or False value for the Chair class’s hasArmRests attribute.

In defining these concrete classes, we may notice that they have certain kinds of characteristics in common (e.g., they both have the ‘color’ attribute). This is a clue that we can generalize these classes to a superclass, like Furniture Piece, to represent what tables and chairs have in common.

  • Since each object that belongs to the Furniture Piece class is either a Table or a Chair, the Furniture Piece class is said to be abstract, to indicate that it cannot be instantiated (there will be no objects of type Furniture Piece).
  • Another way to express this is that the Furniture Piece class is ‘completely partitioned’ (it is completely subdivided into subclasses).

Furniture Piece represents a ‘generalization’ of (the objects in) its subclasses, as depicted in the following diagram.

VanGalenAug12 01

Class hierarchies

Generalizing classes creates a class hierarchy. In this example, it starts with a flat structure of two concrete classes that reflect what their objects are in and of themselves, which is then expanded into a hierarchy by adding an abstract superclass that represents what objects in the two subclasses have in common.

The class hierarchy in the diagram above is represented below as a class diagram, expanded with some attributes (iii), an association, and some operations (see later).

VanGalenAug12 02

Inheritance

A key feature of a class hierarchy is inheritance, in which kinds of characteristics defined for a superclass are inherited by its subclasses.

Inheritance is a class construct, not an instance one.

  • This means that, for example, the Table and Chair classes inherit the color attribute from the Furniture Piece class, such that each Table and Chair object must be assigned a value for the color attribute at the time of the object’s creation.
  • It does not mean that each Table and Chair object inherits its particular color (a color attribute value) from a corresponding Furniture Piece object, because there are only Table and Chair objects, no Furniture Piece objects.

Likewise, the Table and Chair classes inherit the association with the Location class from the Furniture Piece class, such that each Table and Chair object may have a link to an ‘assigned location’.

Specialization

A class hierarchy can also result from specialization. This means introducing a subclass, and representing how it differs from its superclass by defining kinds of characteristics that apply to the subclass but not to the superclass (iv).

  • To a superclass, a subclass is a ‘specialization’ of the superclass.
  • To two or more subclasses, a shared superclass is their ‘generalization’ (v).

In the earlier class diagram, Table and Chair are specializations of Furniture Piece, where Table has the maxNumberOfPeople attribute (but Furniture Piece doesn’t) and Chair has the hasArmRests attribute and the getSeatingPosition operation (but Furniture Piece doesn’t).

The following three sections describe additional examples of specialization.

Deferring methods to subclasses

Apart from inheriting attributes and an association, Table and Chair also inherit the getCapacity operation (vi). An operation on a class represents that an object in the class is capable of a named behavior, in this case, getting its capacity.

  • Capacity represents the number of people the corresponding physical object can accommodate.
  • A Table’s capacity is indicated by the maximum number of people that can sit around it, while a chair’s capacity is always equal to one.

The Furniture Piece’s operation is shown in italics to indicate that it’s abstract. This means that Furniture Piece doesn’t provide a method for this operation but leaves it up to its subclasses to do so (vii). In contrast, Table and Chair show the operation in straight font to convey that it’s concrete. This means that each subclass provides its own method for the operation.

  • Thus, when a Table object is asked to perform the operation, the Table class’s method is to return the Table object’s value for the maxNumberOfPeople attribute, and when a Chair object is asked to perform the operation, the Chair class’s method for this operation is to return 1.

So, providing a method for the superclass’s operation is deferred to the subclasses.

Overriding a method

An alternative pattern for modeling the getCapacity methods is as follows.

  • Furniture Piece’s getCapacity operation is concrete and its method is to return 1 (i.e., this is the default method).
  • Chair inherits the method from Furniture Piece, but Table defines its own method, which is to return a Table object’s value for the maxNumberOfPeople attribute.

Thus, Table’s own method overrides Furniture Piece’s default method.

Adding an operation and its method

Chair has an operation over and above the one it inherits.

  • The getSeatingPosition operation returns “in” or “on” for a given Chair object.
  • The corresponding method gets the Chair’s hasArmRests attribute value, and returns “in” or “on” based on whether this value is True or False, respectively.

The added operation helps to define Chair as a specialization of Furniture Piece.

Type and class

In philosophy, there is a difference between a type (which represents a certain concept, like chair) and a class (which is a collection of objects, such as tables and/or chairs).

In class diagrams, these two aspects are combined, such that a class represents both a concept (through the kinds of characteristics that characterize it) and a collection (of objects that have individual characteristics for those kinds of characteristics).

Even so, there is still a linguistic distinction, because an object ‘is of’ a certain type but ‘belongs to’ (is a member of) a class. At minimum, an object that is of a certain type belongs to the concrete class in which it is created; if that class has any superclasses, the object belongs to those as well, albeit indirectly.

Type correspondence

A key measure of the correctness of a class hierarchy is type correspondence. This means that the statement ‘ is a type of ’ must be true for each combination of subclass and superclass (representing the subtype and the supertype, respectively, keeping in mind that a class represents both a type and a collection).

  • For example, ‘a Table is a type of Furniture Piece’ and ‘a Chair is a type of Furniture Piece’.

Let’s now turn to generalization (and specialization) in use case modeling. 

GENERALIZING ACTORS

Why actors can be generalized

In [3], Actor is a subclass of BehavioredClassifier, which is a subclass of Classifier. Because generalization is a feature of Classifier, Actor inherits this feature from that class. In other words, actors can be arranged in an actor hierarchy.

An example

A concrete use case has one and only one initiating actor (viii), but what if some of a system’s use cases can be initiated by users of different kinds, such as Contact Centre Specialists and Customer Statement Specialists? Actor generalization solves that problem, as illustrated in the following diagram.

VanGalenAug12 03

Actor generalization (and specialization) creates an actor hierarchy.

What an actor means

The earlier object-oriented example deals with electronic objects internal to a system, each of which comes into existence by being created in a concrete class. In contrast, the notion that actor instances are created in concrete actors doesn’t apply, because:

  • An actor represents actual entities that can use a system (e.g., actual people, actual systems, actual functions), which already exist in their own right.
  • An actor represents a role some entity may play, not what the entity is in and of itself.

When an actor is concrete, it means that entities are assigned to it, not that they are created in it.

Two patterns

In fact, we need to be aware of two modeling patterns, for which I use the following terms and definitions.

  • Classification: arranging entities in classes based on what the entities are in and of themselves, such that an entity belongs to one and only one concrete class that reflects the entity’s type, and belongs to that class for its entire existence (ix).
  • Categorization: assigning entities of one or more types to categories, based on point-in-time rules, judgment or preference, such that an entity may belong to multiple categories at once, and may belong to a category for part(s) of its existence.

Thus, the earlier class hierarchy reflects classification, while the above actor hierarchy represents categorization. The next diagram shows the latter (x).

VanGalenAug12 04

Like the Furniture Piece class in the object-oriented example, the Customer Service Specialist actor is abstract, because it is completely partitioned (i.e., completely subdivided into subactors).

Unlike the Furniture Piece class, the Customer Service Specialist actor is not ‘disjoint’, but ‘overlapping’ (as [3] calls it), because a given person can in principle belong to multiple subactors at once (a clue we’re dealing with categorization, not classification).

Type correspondence

As for a class hierarchy, ensuring type correspondence is a must for an actor hierarchy, albeit that here the types are strictly the actor names themselves, rather than the types (conceptual or otherwise) of actual users (e.g., Person).

  • In this case, ‘a Contact Centre Specialist is a type of C