Monday, 02 September 2013 07:39

Generalization and Use Case Models, Part 2

Written by

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 <<function>> 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 <<service>> 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 <<process>> 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.

 

Read 28241 times
Willem Van Galen

Willem Van Galen is a retired Senior Systems Analyst previously employed at a large financial services company in London, ON, Canada.  From 2008-2016, one of his responsibilities was designing, delivering and reinforcing use case modeling training, practices and standards.  In 2011, he enhanced these to reflect service-oriented architecture and event-driven architecture.

© BA Times.com 2019

macgregor logo white web