Excavating The Extension Use Case

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.

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.

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.

Misapplications

Now that I view the extension use case this way, several of its widely advocated uses strike me as misapplications or anti-patterns. These include using an extension use case to represent the following.

1. Optional behavior that contributes to the goal of the base use case?s initiating actor. This category includes Cockburn?s examples mentioned in part 1 of this article. For example, ?Check spelling? is a mini goal toward the ?Edit document? goal in the eyes of the initiating actor.

2. Behavior that accesses data in the base use case. For example, not only does ?Check spelling? read the document being edited in the base use case, it may also update that document by making spelling corrections to it.

3. Behavior that belongs to a base use case whose specification is locked, or base use case behavior that will be added in a later release. Here, using an extension use case is driven by circumstances surrounding the delivery of a system, not by the nature of that system. That doesn?t seem to be the point of representing a system?s functional requirements as use cases.

Rather than model such behavior as an extension use case, add it to the base use case, where it can access the use case?s private data, if necessary. By the way, if you don?t like ?alternative flow? to label purely optional/non-essential behavior, which isn?t an alternative to any other behavior, consider using ?neutral flow? instead.

This way, all the behavior related to the initiating actor?s goal is brought together in one use case rather than spread across several use cases. Your readers will appreciate that.

One outcome of these findings and consequences is that opportunities to use the extension use case construct are relatively few, as befits its specialized nature.

To extend or not to extend

Finally, the following decision table shows how I currently decide whether or not to use an extension use case to model behavior that doesn?t correspond to a complete actor-initiated use case.

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

In conclusion

This ?archeological dig? made me understand the extension use case more clearly than before and replaced vague subjectivity on when it might be used with clear objectivity on when it ought to be used. I hope this article does the same for you.

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.

?

Article source: http://feedproxy.google.com/~r/BusinessAnalystTimes-BusinessAnalysisHome/~3/Zp0WVm1gky0/excavating-the-extension-use-case-part-2.html

Tags: Business Analysis, Business Analysis - Net, Business Analyst Times, development, Management, methodology

This entry was posted on October 19, 2012 at 7:00 pm and is filed under Articles, Business Analysis, Development, Management, Methodology, On the Net. You can follow any responses to this entry through the RSS 2.0 feed.

Source: http://projectcommunityonline.com/excavating-the-extension-use-case.html?utm_source=rss&utm_medium=rss&utm_campaign=excavating-the-extension-use-case

geithner gabrielle giffords juliette lewis chelsea handler mitch daniels shirataki noodles john kerry