Tuesday, 24 July 2012 01:00

Excavating The Extension Use Case - Part 2

Written by

Introduction

Part 1 of this article revealed the extension use case as a much more specialized construct than commonly suggested. Part 2 increases that notion and deals with some of the consequences of this narrower view of extension use cases.

1Further observations

If the principle of encapsulation is to be upheld, as Rumbaugh suggested in [1], it cannot apply solely to the base use case’s steps but must apply equally to the data manipulated by those steps. The UML provides a convention for declaring an extension point for a base use case in terms of its steps, but I know of no UML convention for declaring which data a base use case makes available at an extension point. Consequently, I must conclude that a base use case’s data is unknown to, and therefore inaccessible by, an extension use case. However, apart from a use case’s private (local) data, there may be public (global) data, which is accessible by all use cases, including extension use cases (e.g., User Id).

Additionally, it seems to me that a condition associated with an extension point must also “belong to” the base use case and not to the extend relationship between the extension use case and the base use case as in the example shown in Figure 16.3 of [2]. In terms of this example, how can the “customer selected HELP” condition arise unless the base use case accommodates it to arise? After all, the base use case describes how, in pursuit of a certain goal, the initiating actor can interact with the system to which the base use case belongs. Actually, I see no need for an “extension condition” when you name an extension point after the condition that has arisen in the base use case at the extension point.

 

Actually, an extension point should never be named after an action that is assumed to be performed at the extension point (i.e., by an extension use case), because as part 1 of this article explained, the base use case doesn’t know whether it’s being extended at a given extension point, let alone by which extension use case!

Extension use cases without and with actor involvement

In Jacobson’s example cited in part 1 of this article, the base use case’s initiating actor is unaware of the extension use case, because the extension use case doesn’t require the actor’s involvement. However, there are also extension use cases that do involve the actor. This is fine, as long as the goal of the extension use case is perpendicular to that of the base use case, and the extension use case doesn’t require any of the base use case’s private data. This is illustrated in the following diagram.

2

After the “Log In” base use case reaches the “User has been authenticated” extension point, the “Advertise Product” extension use case is given control. The extension use case determines whether, during one of its previous executions, the user chose or declined to be informed about the product. If not, the user chooses one of the following options, which causes the extension use case to take the corresponding action.

2.5

The extension use case then ends and control returns to the base use case.

This behavior can be modeled as an extension use case because its goal in no way contributes to the base use case’s goal, it requires none of the base use case’s private (local) data (e.g., User Password, Security Questions and Answers) and the data it does require has been defined as public (global) data (i.e., User Id).

This extension use case controls an interaction between the system and the base use case’s initiating actor in pursuit of the “Advertise Product” goal of the off-stage stakeholder that is perpendicular to the “Log In” goal of the on-stage stakeholder.

Extension use cases vis-à-vis event-driven architecture (EDA)

Part 1 of this article noted that an extension use case intersects with a base use case at a single condition or event in the base use case. While this is an event-based relationship, an extend relationship is not suited to represent an event-driven relationship as understood in event-driven architecture because it fails to meet at least the following EDA principles described in [3].

Reports current events: A publisher use case is modeled to produce an event object that represents an event as it happens or a condition as it is detected. Mediated by an event manager, the event object triggers one or more subscriber use cases that are modeled to consume the event object.

  • A base use case doesn’t produce an event object, so it’s not a publisher.

  • An extension use case is neither triggered by nor consumes an event object, so it’s not a subscriber.

Late or no binding: An event publisher and event subscriber are not aware of each other’s identities when they are developed or deployed.

  • While a base use case is unaware of an extension use case, an extension use case is aware of the base use case and its extension point from the moment the extension use case is modeled because it owns the relationship with the base use case.

Moreover, the relationship between a publisher and a subscriber use case is asynchronous (the latter doesn’t execute as part of the former), whereas the relationship between an extension use case and a base use case is synchronous (the former executes as part of the latter).

My first article [4] outlines an approach for modeling publisher and subscriber use cases that requires neither extension use cases nor inclusion use cases.

Summary of this article's considerations

The table below summarizes the considerations identified thus far.  The concluding article [6] adds one more consideration, based on the article [5] that precedes it.

3

(*) If/when there is a convention for declaring certain of a base use case’s private data as publicly accessible at an extension point, model the behavior as an extension use case.

(**) This implies that the behavior’s goal contributes in some way to the base use case’s goal in the eyes of the use case’s initiating actor.

Note

The term “base use case” only applies in the context of a use case relationship (e.g., in the context of an extend relationship, it refers to the extended use case). For ease of reference, I have used the term here also to refer to a ‘candidate’ base use case, even when, after further consideration, it doesn’t end up being an extended use case.

Don't forget to leave your comments below.


References

[1] 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).

[2] Object Management Group (OMG), OMG Unified Modeling LanguageTM (OMG UML), Superstructure, Version 2.4.1, Section 16.3.3, Description.

[3] W. Roy Schulte et al., Smart Devices and Sense-and-Respond Systems Are Event-Driven, 12 October 2009, Gartner, Inc.

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

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

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

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 2020

macgregor logo white web