Use Case Relationships and Diagrams: Mechanics by Example

Hal Smith
Penn State New Kensington 3550 Seventh Street Rd Upper Burrell PA 15068 (724) 325 6759

hhs10@psu.edu
1 Introduction

The UML Use Case is given limited treatment in many books that are not specifically written as a methodology for writing and managing use cases. Finding a book which provides as much insight into use cases as it does to the various other UML artifacts is difficult. Many such books provide a brief discussion of the notions of actor, scenario, and use case as well as discuss diagrammatically the relationships between use cases of include, extend, and generalization. However, they fall short of providing complete examples of tying the written-word use cases to a complicated diagram and dismiss or defer the discussion to texts which deal specifically with use cases. This discussion is an attempt to provide some of the missing details. It is a nutshell version which will exhibit possible mechanics for tying written-use cases to the various use case diagram notations. 2 Actors, Scenarios and Use Cases

As with any discussion about use cases, we start by identifying the three key terms: actor, scenario, and use case. The point of using use cases is to define the functionality of some entity. We will refer to this entity as a system and not try to define exactly what a system is. For our purposes, we can think of a system as something with which an interaction will take place. An actor interacts with a system to achieve a goal. For certain systems, actors will represent humans but this is not always the case. Actors may also be other systems (software or hardware). Actors should be represented by the role they play with respect to a system rather than representing a specific person or system.
Example. Suppose the system being discussed is an ATM machine, we may have actors such as Account Holder and Technician. Here it is most likely the case that an Account Holder and a Custodian are people. There is no reason to assume that the Account Holder and Custodian are not the person. It may very well be that Jane Technician is the Technician of a given ATM. After servicing the ATM machine, Jane may then need to

-1-

make a withdrawal. Hence, Jane plays the role of both a Technician as well as an Account Holder.

Actors provide a stimulation to the system. They cause something to happen. In turn, the system responds. The way in which a system responds may depend on several factors such as data provided with the stimulus, the current state of the system, and the current state of any systems with which the system being discussed must interact (for example, an ATM machines response to a deposit request may depend on the availability of a central banking system where accounts are stored). When an actor stimulates a system, the system has at any given moment a single response as at any point in time the system has exactly one state. The response is captured as a series of steps. A possible response to a given stimulus is called a scenario. Thus, when an actor interacts with a system, the system responds in a specific way. It should be pointed out that may be many scenarios associated to a given stimulus but only one scenario will be executed for a given stimulus. The following are examples of possible scenarios that can occur for an ATM Machine when an Account Holder attempts to withdraw funds.
Scenario Withdrawal at an ATM Machine. The Account Holder places card in card slot. The system prompts Account Holder for PIN. The Account Holder enters in PIN. The system verifies the card and PIN are valid and prompts user to select a transaction. The Account Holder selects Withdrawal. The system retrieves the account information and prompts Account Holder for amount to withdraw. The Account Holder enters the amount. The system verifies that there is enough money in the account to support the withdrawal, verifies there is enough cash in the machine to support the withdrawal, reduces the account by the amount requested and dispenses money to the Account Holder. The card is returned to the Account Holder. Scenario Card is rejected. The Account Holder places card in card slot. The system prompts Account Holder for PIN. The Account Holder enters in PIN. The system determines the card or PIN is not valid. The system displays an error message to the Account Holder and the card is returned. Scenario Insufficient Funds in Account for Withdrawal. The Account Holder places card in card slot. The system prompts Account Holder for PIN. The Account Holder enters in PIN. The system verifies the card and PIN are valid and prompts user to select a transaction. The Account Holder selects Withdrawal. The system retrieves the account information and prompts Account Holder for amount to withdraw. The Account Holder enters the amount. The system determines there is not sufficient funds to the support the withdrawal. The system displays an error message and the card is returned.

A use case is a collection of related scenarios. The criteria for what scenarios can be grouped together into a use case is not defined. It is up to the individuals creating and managing the use cases to determine this. There are heuristics that exist that provide suggestions but these heuristics can vary widely. We should observe that it is possible to represent each scenario as its own use case and it is a perfectly valid representation of the systems functionality. Keep in mind that the

-2-

sole purpose of any UML artifact is to facilitate communication of the design of a system. Identifying each scenario as a use case achieves this primary objective. If each scenario can be considered a use case, it is reasonable to ask, What good is the distinction? Use cases provide a means of managing scenarios. Since use cases represent a collection of scenarios, several scenarios which represent alternative outcomes of the same stimuli can be grouped into a common collection. If we reexamine the scenarios for the ATM Machine, all stemming from an Account Holder attempting to perform a withdrawal, we see there is considerable overlap between them. First, they all begin with the same initial steps. If these common steps are altered, it would require changing the steps in all three scenarios. For example, in the future the account card may be replaced by a fingerprint or retina scan. This problem would be compounded if we think of all scenarios for an ATM machine (i.e., consider various transaction types: withdrawal, deposit, balance check, transfer). Use cases, and the relationships between use cases we will explore later, help manage this change. As we move forward, it will help to provide more structure to the way we capture scenarios and use cases. Rather than describing the scenario in a paragraph form (sometimes referred to as a casual form), we will describe each scenario as a series of steps and enumerate the steps numerically. For example,
Scenario Withdrawal at an ATM Machine. 1. The Account Holder places card in card slot. 2. The system prompts Account Holder for PIN. 3. The Account Holder enters in PIN. 4. The system verifies the card and PIN are valid and prompts user to select a transaction. 5. The Account Holder selects Withdrawal. 6. The system retrieves the account information and prompts Account Holder for amount to withdraw. 7. The Account Holder enters the amount. 8. The system verifies that there is enough money in the account to support the withdrawal. 9. The system verifies there is enough cash in the machine to support the withdrawal. 10. The system reduces the account by the amount requested and dispenses money to the Account Holder. 11. The card is returned to the Account Holder.

Combining the scenarios into a single use case is a matter of style. Remember: the goal is to communicate the various alternatives that can occur as a result of an Account Holder attempting to withdraw funds. Use cases start with a main or primary scenario. Often, this scenario represents the success scenario. In the case of withdrawing funds, the success scenario results in the Account Holder receiving the requested cash. Alternatives are listed below the main scenario and indicate how they diverge from the main scenario. The basic idea is that an alternative scenario has some number of steps in common with the main scenario and some number of steps which differ from the main scenario (ergo, alternative).

-3-

Exactly how to capture the alternative relative to the main scenario is again a matter of style. A common approach is to replace steps n to m in the main scenario with some alternate set of steps. The alternative enumerates its steps beginning with the first step replaces. If we combine the Withdrawal at an ATM Machine and Card Rejected scenarios into a single use case, it would look something like
Use Case Withdrawal Main Scenario 1. The Account Holder places card in card slot. 2. The system prompts Account Holder for PIN. 3. The Account Holder enters in PIN. 4. The system verifies the card and PIN are valid and prompts user to select a transaction. 5. The Account Holder selects Withdrawal. 6. The system retrieves the account information and prompts Account Holder for amount to withdraw. 7. The Account Holder enters the amount. 8. The system verifies that there is enough money in the account to support the withdrawal. 9. The system verifies there is enough cash in the machine to support the withdrawal. 10. The system reduces the account by the amount requested and dispenses money to the Account Holder. 11. The card is returned to the Account Holder. Alternative: Card Rejected 4. The system determines that the card or PIN is invalid. 5. The system displays an error message to the user. 6. The card is returned to the user.

The above use case describes two scenarios. The main scenario is identical to the Withdrawal at an ATM Machine scenario. The alternative, Card Rejected, indicates there is an alternate scenario that can occur. Since the alternative begins with step 4, we think of the scenario represented by this alternative as being steps 1 through 3 of the main scenario and then steps 4 through 6 in the alternative scenario. We can group more scenarios into this use case. For instance, we can include the Insufficient Funds in Account scenario as follows
Use Case Withdrawal Main Scenario 1. The Account Holder places card in card slot. 2. The system prompts Account Holder for PIN. 3. The Account Holder enters in PIN. 4. The system verifies the card and PIN are valid and prompts user to select a transaction. 5. The Account Holder selects Withdrawal. 6. The system retrieves the account information and prompts Account Holder for amount to withdraw. 7. The Account Holder enters the amount.

-4-

The system verifies that there is enough money in the account to support the withdrawal. 9. The system verifies there is enough cash in the machine to support the withdrawal. 10. The system reduces the account by the amount requested and dispenses money to the Account Holder. 11. The card is returned to the Account Holder. Alternative: Card Rejected 4. The system determines that the card or PIN is invalid. 5. The system displays an error message to the Account Holder. 6. The card is returned to the user. Alternative: Insufficient Funds in Account 8. The system determines there is insufficient funds in the account to support the withdrawal. 9. The system displays an error message to the Account Holder. 10. The card is returned to the Account Holder.

8.

It may be that alternate scenarios address only a sequence of steps in the middle of the main scenario. That is, the first n and last m steps of the main scenario are the same as an alternate scenario but the middle k steps differ. Using the ATM example, suppose there is an option for a Quick $60 withdrawal at the ATM, withdraw $60 from the account. If an Account Holder selects the Quick $60 transaction, there is no need to prompt the Account Holder for an amount to withdraw. The scenario might read
Scenario Quick $60. The Account Holder places card in card slot. The system prompts Account Holder for PIN. The Account Holder enters in PIN. The system verifies the card and PIN are valid and prompts user to select a transaction. The Account Holder selects Quick $60. The system retrieves the account information. The system verifies that there is enough money in the account to support the withdrawal, verifies there is enough cash in the machine to support the withdrawal, reduces the account by the amount requested and dispenses money to the Account Holder. The card is returned to the Account Holder.

To incorporate this into the use case, we would write

Use Case Withdrawal Main Scenario 1. The Account Holder places card in card slot. 2. The system prompts Account Holder for PIN. 3. The Account Holder enters in PIN. 4. The system verifies the card and PIN are valid and prompts user to select a transaction. 5. The Account Holder selects Withdrawal. 6. The system retrieves the account information and prompts Account Holder for amount to withdraw. 7. The Account Holder enters the amount. 8. The system verifies that there is enough money in the account to support the withdrawal. 9. The system verifies there is enough cash in the machine to support the withdrawal.

-5-

10. The system reduces the account by the amount requested and dispenses money to the Account Holder. 11. The card is returned to the Account Holder. Alternative: Card Rejected 4. The system determines that the card or PIN is invalid. 5. The system displays an error message to the Account Holder. 6. The card is returned to the user. Alternative: Insufficient Funds in Account 8. The system determines there is insufficient funds in the account to support the withdrawal. 9. The system displays an error message to the Account Holder. 10. The card is returned to the Account Holder. Alternate: Quick $60 5. The Account Holder selects Quick $60. 6. The system retrieves the account information. Return to step 8 in the main scenario.

2.1

Use Case Diagrams

Use case diagrams are one of many diagrams available in UML. They provide a graphical representation of actors and use cases (which actors are involved in which use case) and how different use cases relate to each other. At their most basic level, use case diagrams depict actors (a stick figure with a name label), the system under discussion (a rectangle with a name label) and use cases (an ellipse with a name label). Figure 1 is a possible use case diagram for an ATM machine. The system is identified (ATM), there are two actors (Account Holder and Technician), and four use cases (Withdrawal, Deposit, Transfer, and Run Diagnostics). It is worth noting that not every actor can initiate a given use case. However, a use case must have at least one actor that can be the initiator (otherwise, we should question the necessity of the use case!). As with any UML diagram, use case diagrams are not inherently complete, though it is possible. They communicate part of the system design. Certain use cases may require interactions via multiple actors. Consider a Launch System for a nuclear missile which has a two key system (that is, in order to get the missile into a ready state, both keys must be inserted and turned at the same time). A use case for Initialize has then two actors (Figure 2).

-6-

Figure 1 Possible use case diagram for ATM

Figure 2 Use case with two actors

There are many varying opinions as to how to best draw a use case diagram. Some use the use case diagram as in Figure 1 and Figure 2; that is, In general, use case diagrams only depict actors which are required to stimulate the use case. Thus, if the system needs data from a remote entity, such as the ATM requiring communication with a Central -7-

Bank System, the Central Bank System is not shown on the use case diagram. Further, interactions between actors is generally not depicted as that interaction is outside the scope of the system under discussion. What information to illustrate is a matter of style. Be careful about trying to communicate too much information in any one diagram. Also, remember that the purpose of use case diagrams is to communicate the relationship between use cases as well as identify various actors and their interactions with the system. It is the use case itself which communicates the details, not the diagram. Thus, it is unrealistic to assume that the use case diagram will provide significant insight into the system functionality. That is the job of the use cases. 2.2 Exercises

1. Write the explicit steps of each possible scenario in the following use case for a BLAH:
Use Case -

2. Create a single use case out of the following scenarios for BLAH:
Scenario: Scenario: Scenario:

3. Create a use diagram for a soda can vending machine. Try to include at least 5 use cases and at two actors: someone who uses the machine to obtain a soda and someone who services the machine.

The include relationship

Scenarios which initiate as a result of an interaction to accomplish the same goal can be grouped together into a use case. The scenarios are represented as a main scenario in the use case or an alternate scenario. The basic idea is that the alternatives reuse some number of steps from the main scenario but provide an alternate sequence for a collection of steps. It may also happen that two use cases share a sequence of identical steps. It may not make sense to merge the use cases together but we still would like to take advantage of the fact that there is commonality. This can be achieved by using an include relationship between use cases.

-8-

First, consider the Deposit use case for an ATM.

Use Case Deposit Main Scenario 1. The Account Holder places card in card slot. 2. The system prompts Account Holder for PIN. 3. The Account Holder enters in PIN. 4. The system verifies the card and PIN are valid and prompts user to select a transaction. 5. The Account Holder selects Deposit. 6. The system retrieves the account information and prompts Account Holder for amount to deposit. 7. The Account Holder enters the amount. 8. The system starts the deposit slot mechanism. 9. The Account Holder places the deposit item into the deposit slot mechanism. 10. The system detects the deposit item and stops the deposit slot mechanism. 11. The system adds the deposit amount to the account. 12. The card is returned to the Account Holder. Alternative: Card Rejected 4. The system determines that the card or PIN is invalid. 5. The system displays an error message to the Account Holder. 6. The card is returned to the user. Alternative: Deposit Slot Mechanism Fails to Start 8. The system fails to start the deposit slot mechanism. 9. The system displays an error message to the Account Holder. 10. The card is returned to the Account Holder. Alternative: Deposit Slot Mechanism Times Out 9. The Account Holder does not place the deposit item in the deposit slot mechanism within 5 seconds. 10. The system did not detect a deposit item and stops the deposit slot mechanism 11. The system displays an error message to the Account Holder. 12. The card is returned to the user.

Notice that the first four steps in the main scenario of the Deposit use case are identical to the those in the main scenario of the Withdrawal use case. Further, the first alternative in both use cases (Card Rejected) are identical. The include relationship between use cases enables us to break out the common behavior from the two use cases and create another use case that can be referenced. The behaviors associated to Validate form a special type of use case called an abstract use case. The reason such a use case is called abstract is that the use case does not stand as a formal use case on its own. It is really a behavior (or set of behaviors) the system exhibits while achieving other goals. In our example, we do consider the act of validating a card and PIN a goal of any actor involved with the system. Use cases are not restricted to only include abstract use cases, they can also include other (non-abstract) use cases.

-9-

If one use case wishes to include another, it references the use case by name. Thus, we may define the following use case
Use Case Validate Main Scenario 1. The Card Holder places card in card slot. 2. The system prompts Card Holder for PIN. 3. The Card Holder enters in PIN. 4. The system verifies the card and PIN are valid and prompts Card Holder to select a transaction. Alternative: Card Rejected 4. The system determines that the card or PIN is invalid. 5. The system displays an error message to the Card Holder. 6. The card is returned to the Card Holder.

Then, the Deposit use case would be as follows

Use Case Deposit Main Scenario 1. Include Validate, Account Holder plays the role of Card Holder. 2. The Account Holder selects Deposit. 3. The system retrieves the account information and prompts Account Holder for amount to deposit. 4. The Account Holder enters the amount. 5. The system starts the deposit slot mechanism. 6. The Account Holder places the deposit item into the deposit slot mechanism. 7. The system detects the deposit item and stops the deposit slot mechanism. 8. The system adds the deposit amount to the account. 9. The card is returned to the Account Holder. Alternative: Deposit Slot Mechanism Fails to Start 5. The system fails to start the deposit slot mechanism. 6. The system displays an error message to the Account Holder. 7. The card is returned to the Account Holder. Alternative: Deposit Slot Mechanism Times Out 6. The Account Holder does not place the deposit item in the deposit slot mechanism within 5 seconds. 7. The system did not detect a deposit item and stops the deposit slot mechanism 8. The system displays an error message to the Account Holder. 9. The card is returned to the user.

Notice that the first step in the main scenario of the Deposit use case is to include the Validate use case. Also notice that the Card Rejected alternate scenario is no longer formally a part of the Deposit Use case. It is part of the Validate use case. By including the Validate use case, the Deposit use case imports the steps in the main scenario of Validate as well as any alternate scenarios Validate specifies (in this case, it is just Card Rejected). - 10 -

This new specification of the Deposit use case is equivalent to the one we specified previously. We can do the same with for the Withdrawal use case (and leave it as an exercise for the reader). We should also point out that we opted to replace the Account Holder actor with a Card Holder actor in the Validate use case. The reason for this is that the Validate use case is not aware of the reason it is being used. It only requires that some entity with a card inserts the card into the slot. Whether or not the Card Holder in fact is also an Account Holder, is irrelevant. There are two immediate benefits to the include relationship: maintenance of the use cases and extensibility of the system. At a minimum, maintenance of the use cases becomes easier. If we later decide to alter any Validation scenario, we need only do it in one place. Suppose we later decide that the ATM machine will not use PINs but will instead requires a finger print scan in conjunction with an account card. Prior to using the include relationship, we would have had to go update two difference use cases. Using the include relationship means we only have to update the Validate use case. Further, if we decide that there needs to be additional alternate scenarios as part of the Validate use case, we can do that efficiently as well for the same reasons. Second, suppose we wish to add more functionality to the system; for example, transfers. We can take advantage of the include relationship there as well. To add new functionality requires limited knowledge of the details of validation. It can be included almost blindly. 3.1 Include relationships and use case diagrams

Now that we understand how the include relationship works, we need to understand how to represent it in a diagram. To begin, we need to understand the dependency relationship in UML. Any element that has a relationship to another element in UML can be said to depend on that element. Dependency is the most generic relationship available in UML. It just indicates that there is a relationship and the relationship needs to be further investigated to understand its nature. Ultimately, the dependency relationship can be thought of as simply as follows: If A depends on B, then a change in B may cause a change in A. The include relationship is a specific type of dependency. This is evident from the previous discussion. Since the Deposit use case is included the Validate use case, adding an alternate scenario to the Validate use case implies that that alternate scenario is part of the Deposit use case. For example, if we added an alternate scenario called Card Reader Failed which addresses the case when there is a mechanical failure in card reader mechanism, this would now be a

- 11 -

possible outcome of an Account Holder trying to initiate a deposit transaction with an ATM. Diagrammatically, a dependency relationship is represented by a dashed-line arrow with a stick arrowhead (as in Figure 3). The dependency is then further annotated with the label <<include>>. This label is a stereotype. Stereotypes, which are words encapsulated in guillemets or double angled brackets1, are used in UML to provide specific meaning to a diagrammatic element. It can be thought of as a special type of element. Thus applying the <<include>> stereotype to a dependency means that that dependency has a specific interpretation. In this case it means that the two use cases which it joins (in Figure 3 it is Withdrawal to Validate as well as Deposit to Validate). We will see further stereotypes in this discussion as well as when discussing other types of UML diagrams. Certain stereotypes, such as <<include>> and <<extend>> are part of the UML specification. UML also permits user-defined stereotypes as well.

Figure 3 - Possible use case diagram for an ATM that uses the include relationship

Figure 3 represents a possible use case diagram for an ATM machine and represents the same information as Figure 1 (the original use case diagram) in terms of system functionality but sets the stage for easier maintenance and extensibility of the collection of use cases for the system.
Technically speaking, guillemets are their own characters, and , and are distinct for the double angled brackets. It is acceptable to represent guillemets with double angled brackets as we have. In this document we have used double angled brackets as a matter of convenience.
1

- 12 -

We have only illustrated an include relationship in a case where the abstract use case, Validate, is included in several use cases which are carried out by an Account Holder. This does not have to be the case. Any use cases can be included by any other use case. To illustrate this using our current example, suppose it is decided for the ATM being designed that the Technician performs diagnostics testing by means of interacting through special screens at the same display that the Account Holder uses. To accomplish this, a special card and PIN will be provided to a Technician that, when used at the ATM, provides different diagnostics options rather than the traditional Account Holder transaction options. Thus, a validation sequence would be part of the Run Diagnostics use case. We can then take advantage of the Validate abstract use case in much the same way that the Withdraw, Deposit and Check Balance use cases did. We then may have a use case diagram as in Figure 4.

Figure 4 - Possible use case for an ATM Machine

3.2

Exercises

1. Using the include relationship, rewrite the use case for Withdrawal (from section 2). 2. The include relationship between use cases spreads the steps apart and introduces several enumerations in each scenario. Write out the explicit sequence of steps for each possible scenario described by the Deposit use case.

- 13 -

3. This exercise builds on the use case diagram created in Exercise 3 from section 2.2. Identify candidate use cases which might share common steps. Rework the use case diagram to exhibit the include relationship. 4. Give an example of a real (or potentially real) system that has (at least) two use case that relate via an include relationship where the included use case is not abstract. That is, the system should have the property that there exists two use cases, A and B, such that A includes B and A is not abstract, having at least one actor that initiates it. 4 The extend relationship

We discussed how the include relationship enables efficiency and extensibility to the management of use cases. The include relationship is just one such mechanism. The include relationship represents a verbatim inclusion. That is, when use case A includes use case B, A does not provide alternate scenarios for the main scenario in use case B. There are circumstances where we may desire that we enable other use cases the ability to provide specific types of alternatives. For instance, it may be that we need to break apart existing use cases as they are getting too large to manage. It also may be that once a use case is written, we do not want to modify it but need to provide alternatives. This would be analogous to managing source code: it is often preferable to write new code to address new functionality than it is to modify existing code. One mechanism to do this is the extend relationship. The other mechanism to do this is the generalization relationship. We will discuss generalization in section 5. The extend relationship is a controlled relationship. Extend relationships require the existence of extension points. An extension point in a use case identifies a step in the main scenario of the use case at which a deviation can exist. If use case A extends use case B, it can only do so at the specified extension points. As contrast, alternate scenarios specified within a given use case can deviate from the main scenario at any point. Suppose that after further investigation we determine that there are many reasons why the deposit slot mechanism of the ATM system may fail, not necessarily limited to those discussed as part of the Deposit use case. Since we cannot predict all the failures, we want to leave a hook into the Deposit use case that enables us to later add scenarios without having to modify existing use cases. To indicate this in a use case, we need to tag the appropriate line to indicate it is an extension point. How the line is tagged is a matter of style and differs from methodology to methodology. For this example, we will use the following structure to indicate an extension point: XP#. The number enables multiple extension points in a use case. Other methodologies may require more elaborate structures. Thus, the Deposit use case becomes
Use Case Deposit

- 14 -

Main Scenario 1. Include Validate, Account Holder plays the role of Card Holder. 2. The Account Holder selects Deposit. 3. The system retrieves the account information and prompts Account Holder for amount to deposit. 4. The Account Holder enters the amount. 5. XP 1: The system starts the deposit slot mechanism. 6. The Account Holder places the deposit item into the deposit slot mechanism. 7. The system detects the deposit item and stops the deposit slot mechanism. 8. The system adds the deposit amount to the account. 9. The card is returned to the Account Holder. Alternative: Deposit Slot Mechanism Times Out 6. The Account Holder does not place the deposit item in the deposit slot mechanism within 5 seconds. 7. The system did not detect a deposit item and stops the deposit slot mechanism 8. The system displays an error message to the Account Holder. 9. The card is returned to the user.

The Deposit use case no longer provides alternatives to address the failure of the deposit slot mechanism. We now view failures of the deposit slot mechanism as extensions of the Deposit use case. Suppose we initially still only have identified the previous two failures of the deposit slot mechanism: the deposit slot motor fails to start and the deposit slot door does not open. We can capture this in two ways: provide both scenarios in one use case or provide them in separate use cases. If we provide them in one use case, we may capture the scenarios in the following manner

Use Case Deposit Slot Mechanism Failure Extends: Deposit Main Scenario Replace XP1 with 1. The system starts the deposit slot mechanism motor. 2. The system fails to open the deposit slot mechanism door. 3. The system stops the deposit slot mechanism motor. 4. The system displays an error message to the Account Holder. 5. The card is returned to the user. Alternative: Deposit Slot Mechanism Fails to Start 1. The system fails to start the deposit slot mechanism motor. Rejoin the main scenario at step 4.

If we provide them in two use cases, the scenarios may be captured as follows

- 15 -

Use Case Deposit Slot Mechanism Door Failure Extends: Deposit Main Scenario Replace XP1 with 1. The system starts the deposit slot mechanism motor. 2. The system fails to open the deposit slot mechanism door. 3. The system stops the deposit slot mechanism motor. 4. The system displays an error message to the Account Holder. 5. The card is returned to the user.

Use Case Deposit Slot Mechanism Motor Failure Extends: Deposit Main Scenario Replace XP1 with 1. The system fails to start the deposit slot mechanism motor. 2. The system displays an error message to the Account Holder. 3. The card is returned to the user.

4.1

Use case diagrams and the extend relationship

The extend relationship is diagrammed in much the same way as the include relationship. If use case A extends use case B, then use case A has a form of dependency on use case B. We again use stereotypes. The extend relationship is a dependency relationship stereotyped as an extend relationship using the label, <<extend>>. To diagram the use case as we last refined them, we would have the diagram depicted by Figure 5.

- 16 -

Figure 5 Possible use case diagram for ATM that uses the extend relationship

Though we have chosen not to show it in the diagram, the <<extend>> notation can also indicate the extension point. Thus, Figure 5, we could have replaced <<extend>> with <<extend>> (XP1) or <<extend>> (deposit slot mechanism does not start). Whether to include the extension point is a matter of style. The driving influence should be the readability of the diagram. 4.2 Exercises

1. (a) Using the extend relationship, separate the Withdraw use case such that each alternative is an extension. (b) Draw the new use case diagram for the ATM which now includes the extensions of the Withdraw use case. 2. It is also possible to extend extensions. That is, if use case B extends use case A, we can create use case C such that use case C is an extension of use case B. Hence, we would have an extension chain: use case C extends use case B extends use case A. (a) Rewrite the Deposit Slot Mechanism Motor Failure use case and the Deposit Slot Mechanism Door Failure use case such that we have a chain of extensions starting with Deposit use case. (b) Draw the resulting use case diagram for the ATM.

- 17 -

3. The extend relationship between use cases spreads the steps apart and introduces several enumerations in each scenario. Write out the explicit sequence of steps for the Deposit Slot Mechanism Motor Failure use case.

The generalization relationship

The generalization relationship is, in some sense, a relaxed version of the extend relationship. The generalization relationship does not require the use of extension points. Before we discuss the generalization further, it needs to be stated that the generalization relationship is thought of in a way opposite the way that either the include or extend relationship. When we state, use case B includes use case A, there is implied information. That is, use case B is aware of use case A but use case A has no awareness of use case B. The same is true for the extend relationship: if use case B extends use case A, B is aware of A but A is not aware of B. When we state, use case B is a generalization of use case A, the opposite is true: use case A is aware of use case B but use case B is not aware of use case A. The different relationships are depicted in Figure 6. The generalization relationship is one that is used in other UML diagrams between various entities. There is a unique notation to indicate that a generalization exists between two elements: a solid-lined arrow with an open arrowhead (as opposed to the stick arrowheads used in the dependency notation).

Figure 6 Diagrammatic comparison of the following relationships (a) Use case B includes use case A (b) Use case B extends use case A (c) Use case B generalizes use case A

In light of this difference, the generalization relationship is also sometimes referred to as a specialization relationship. This provides the same orientation as the other relationships and implies the same information. Thus, stating, use case B is a generalization of use - 18 -

case A, is the same as stating, use case A is a specialization of use case B. Now, however, we can generate the same mental picture as we do for include and extend. Figure 7 provides a diagrammatic representation. As initially stated, generalization is a similar to extension. The difference is that generalization does not require the explicit mention of extension points. Thus, a generalization of a use case is permitted to provide alternate behavior as necessary. It is possible to specify a systems functionality only using extensions and inclusions. It is natural to then question the necessity of having both generalization and extension. This matter is addressed in section 5.4. We first discuss the mechanics of using a specialization.

Figure 7 Diagrammatic comparison of the following relationships (a) Use case B includes use case A (b) Use case B extends use case A (c) Use case B specializes use case A

5.1

Use case diagrams and the generalization relationship

It is more meaningful to continue this discussion by referring to the relationship as a specialization rather than a generalization as we want to provide a discussion analogous to those for include and extend. The mechanics of the specialization are almost identical to that of extension. To illustrate the use of specialization, we provide a variation on managing the use cases associated to the failure of the deposit slot mechanism. Since we have already shown the mechanics of connecting use cases together as well as how use cases (in text form) relate to use case diagrams, we will first discuss specializations and use case diagrams then discuss the mechanics of the textual use cases.

- 19 -

Recall that we can use extensions as a means of breaking apart use cases when they become over complicated or when we need to provide an efficient mechanism to handle additional or modified behavior. The investigation into the deposit slot mechanism revealed that there a variety of problems that can occur. As we saw in Figure 5, as we add more extensions of the Deposit use case, the diagram becomes cluttered. We would like to be able to represent the fact that there are extensions that capture the potential failures in the deposit slot mechanism without having to clutter the use case diagram. To do this, we first create a generic use case, Deposit Slot Mechanism Failure, that extends the Deposit use case. Second, we will use the specialization relationship between Deposit Slot Mechanism Failure and the specific failure use cases: Deposit Slot Mechanism Motor Failure and Deposit Slot Mechanism Door Failure. Thus, we represent the relationship between our use cases in two diagrams: Figure 8 and Figure 9.

Figure 8 Possible use case diagram for ATM using the generic Deposit Slot Mechanism Failure use case

- 20 -

Figure 9 Generalization relationship is used to illustrate that a motor failure and a door failure are a kind of failure

The specialization relationship is often associated with the phrase is a. We can apply it here: a Deposit Slot Mechanism Motor Failure is a Deposit Slot Mechanism Failure. As there are no restrictions to how a specialization can provide for alternate scenarios with respect to the use case it specializes, we have much greater flexibility. Though we have complete freedom with the way in which we provide for alternate scenarios with respect to the Deposit Slot Mechanism Failure, since Deposit Slot Mechanism Failure is an extension of Deposit, any specializations of Deposit Slot Mechanism Failure are still governed by the rules of extension with respect to Deposit. 5.3 Handling generalization relationships in use case details

All that remains is to provide the use case details for the current set of use cases, specifically those in Figures 8 and 9. We need only create Deposit Slot Mechanism Failure and then modify Deposit Slot Mechanism Motor Failure and Deposit Slot Mechanism Door Failure. To begin, the Deposit Slot Mechanism Failure structure will be as before for an extension of the Deposit use case that addresses an alternative for step 6 of Deposit, i.e., extension point XP1.
Use Case Deposit Slot Mechanism Failure Extends: Deposit Main Scenario Replace XP1 with 1. The system detects a problem with some element of the deposit slot mechanism. 2. The system displays an error message to the Account Holder. 3. The system returns the card to the Account Holder.

The Deposit Slot Mechanism Failure is intentionally generic. We needed a mechanism to act as a place holder for the variety of problems associated to the start up of the - 21 -

mechanism. Capturing all possible scenarios in one use case was too complicated. This generic use case enables us to talk about the concept of a start up failure without having to describe in detail, too early, exactly what constitutes a failure. We can now, and then later, describe different use cases which capture a variety of failure scenarios. Currently we only have two: Deposit Slot Mechanism Motor Failure and Deposit Slot Mechanism Door Failure. Since we have chosen to represent these as specializations, we are not restricted with respect to how we deviate from the Deposit Slot Mechanism Failure use case (but as there are only three small steps from which to deviate, there is not much we can do). Thus, we may write the remaining use cases as follows
Use Case Deposit Slot Mechanism Door Failure Specializes: Deposit Slot Mechanism Failure Main Scenario Replace steps 1 - 3 with 1. The system starts the deposit slot mechanism motor. 2. The system fails to open the deposit slot mechanism door. 3. The system stops the deposit slot mechanism motor. 4. The system displays an error message to the Account Holder. 5. The card is returned to the user.

Use Case Deposit Slot Mechanism Motor Failure Specializes: Deposit Slot Mechanism Failure Main Scenario Replace steps 1 3 with 1. The system fails to start the deposit slot mechanism motor. 2. The system displays an error message to the Account Holder. 3. The card is returned to the user.

5.4

Generalization vs. Extension: Whats the difference?

We mentioned previously that a system can be specified using only include and extend relationships. Hopefully, there has been some light shed on why generalizations are necessary in use case management but we take a few moments to provide a more focused discussion. The extend relationship provides a mechanism to support the ability to specify use cases that deviate in specific places from another use case. This provides a certain degree of control in the sense that we know that if one use case extends another there is only a set number of places from which the use case can vary.

- 22 -

This poses a problem: the extend relationships assume that we can predict exactly where the extension points need to be. For a simple system that is one-of-a-kind, this may be a realistic. However, for systems which evolve from one generation to another or systems that are part of a collection of related systems (i.e., a product line), this may not be practical. This is where the specialization relationship is useful. It enables unrestrained deviation from the originally specified behavior. The natural question to ask is, Why not rewrite the use cases to either address the new functionality or to include the necessary extension points? If we are in the process of defining the use cases for a new system, the answer is, We probably would. For a new system, there has been no design, code or tests that exist. As the system matures, the general rule of thumb is that adding new code is generally easier and safer than modifying existing code. The same is true with use cases. Since relationships introduce dependencies, modifying an existing use case may have impacts on other use cases. This is sometimes referred to as the ripple effect. Now considering that use cases give rise to design, code and system tests, changing a use case can have a dramatic impact. This is not to say that use cases should be viewed as unchangeable. We only need to keep in mind that changing a use case requires investigating the impact the change has on the system as a whole. It can also be said that avoiding changes to use cases (or any other aspect of the system for that matter) because the impact is unknown is be an indicator that that aspect of the system needs to be explored, understood and somehow documented. The decision to change or not to change a use case is a matter of balancing the concern of all stakeholders. 5.5 Exercises

1. As with the include and extend relationships between use cases, the steps for a given scenario get spread apart. It is important to know how to put them back together. Write out the steps for the scenario Deposit Slot Mechanism Door Failure. 2. Revisit the Withdraw use case and modify it in some meaningful manner by identifying new scenarios (by name, there is no need in this exercise to flush out the scenarios completely) to enable the use of the generalization and extend relationships. Draw the new use case diagram. 6 More on use case style

This main purpose of this discussion was to acquaint the reader with the tools available (use case relationships and diagrams) to help manage use cases. Though we did discuss examples and illustrate how one might textually capture the use

- 23 -

cases and their relationships, we did not discuss any particular methodology. How to effectively use the tools as well as identify the use cases for a given system is a subject of a number of methodology books, some of which are listed in the references. In a nut shell, how to apply use cases is a matter or style. As we discussed, the extension and generalization relationships are effectively the same. Some people prefer the rigidity and control that extensions offer where others prefer the flexibility that the generalizations provide. The best way to learn is by experience, trial and error. There are few wrong ways to employ use cases some approaches work better than others. We want to take a moment to identify some common additions used in the textual description. Each of the following elements is often given its own space in a use case to explicitly draw attention to the information they communicate. Specifying Actors Involved. Some styles recommend explicitly identifying the actors which are involved in the use case. It may further be suggested that an actor be identified as primary. The primary actor is the one involved in the use case that gets to most value out of the existence of the use case. Since use cases are goaloriented, the use case exists because some actor needs to achieve a goal with respect to the system. The primary actor may often be the initiating actor but this is not a necessity. Specifying pre-conditions and post-conditions. Use cases always have a set of assumptions built in to them. The assumptions are about the state of world immediately prior to initiating the use case. Such assumptions are called preconditions. Some general assumptions are vacuously true and go undocumented (i.e., The machine is on.) but that may not always be the case (The ATM is ready to accept a card it may be that the ATM is in a maintenance mode). Thus, it may be useful to specify certain preconditions. Post-conditions represent the state of the world, with respect to the system, immediately following the completion of the use case. Cockburn (in Writing Effective Use Cases, see references) uses guarantees in place of post-conditions. Cockburn is a good reference for learning more about pre-conditions, post-conditions (guarantees) and triggers. Specifying triggers. Triggers represent the primary event (and are sometimes called primary events) that caused the use case to initiate. The trigger is often the first step in the main scenario of use case. In this case, the trigger is initiated by the primary actor. For the ATM machine, the primary actor of the Withdrawal use case is the Account Holder and the trigger for Withdrawal use case to start is the insertion of the card. Triggers do not have to be a step in the use case but still be an essential part. This can happen when there are multiple actors involved in the use case but the primary actor is not the initiator.

- 24 -

Consider a Fire Monitoring System (FMS). The FMS being designed needs to have a locate capability. After a fire is detected, a guard (human) is notified. Upon receiving the notification, the guard has a variety of options, one of which is to locate the area of the building in which the fire is occurring on a building schematic. We may define a use case called Locate Fire to which there are two actors associated: Fire Sensor and Guard. The trigger for the use case is Fire Sensor informs FMS that a fire has been detected. The first step in the use case is Guard selects Locate. The Guard has no reason to initiate this use case unless the Guard is informed that a fire is occurring.

Summary

One approach to capturing system functionality is use cases. A use case is way of describing a collection of scenarios (specific sequences of events) that can occur as a result of an actor (a user of the system) interacting with the system to achieve a specific goal. There are several relationships that can exist between use cases: the include relationship, the extend relationship and the generalization relationship (also referred to as the specialization relationship). Use case diagrams provide a graphical representation of the relationships between use cases and between actors and use cases. The relationships between use cases provide mechanisms to better manage use cases. Use case diagrams serve two purposes: to help explore and manage the use cases as well as enable more efficient communication. It is important to remember that use case diagrams are almost meaningless in and of themselves. They enable little insight into the system without examining their formal descriptions. Well named use cases can provide some ideas of what the system may do but they barely scratch the surface. At best, use case diagrams provide a map of the use case space for a given system. Further Reading The following is a list of texts which provide further information on use cases. Not every book in the list is specifically about use cases but they all offer some discussion which might be useful. Most provide many further references. Adolph, Steve, Paul Bramble, Alistair Cockburn, and Andy Pols: Patterns for Effective Use Cases, Addison-Wesley, 2002.

- 25 -

Bittner, Kurt and Ian Spence: Use Case Modeling, Addison-Wesley, 2002. Cockburn, Alistair : Writing Effective Use Cases, Addison-Wesley, 2000 Fowler, Martin: UML Distilled: A Brief Guide to the Standard Object Modeling Language, 2e, Addison-Wesley, 2000. Larman, Craig: Applying UML and Patterns: An Introduction to Object-Oriented Analysis and Design and the Unified Process, 2e, Prentice Hall PTR, 2001

- 26 -