Tuesday, 19 November 2013 07:11

Comparing and Contrasting Use Case Model Elements, Part 2

Written by

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 <<deviation>> 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 <<augmentation>> 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.

Read 9110 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