Auburn University http://www.eng.auburn.edu/~xqin COMP 2710 Software Construction Use Case Analysis – Examples and Exercises Dr. Xiao Qin Auburn University http://www.eng.auburn.edu/~xqin xqin@auburn.edu

Review: Generalization vs. Extend A use case generalization shows that one use case is simply a special kind of another. References: Visual Case - UML Tutorial – Use Case Diagram.pdf Generalization: (not very popular) When a use case describes a variation on another use case, use a generalization link.  In the example below, the use case limit exceeded describes a situation in which the usual scenario of online purchase is not performed.  Use cases that generalize another use case should only specify an alternative, even exceptional, scenario to the use case being generalized.  The overall goal of the use cases should be the same. (Same Goal) Extend: In some instances you want to describe a variation on behaviour in a more controlled form.  In such instances you can define extension points in the extended use case.  In the example below, search by name is said to extend search at the name extension point.  The extends link is more controlled than the generalization link in that functionality can only be added at the extension points. (different Goal) An extend relationship indicates that one use case is a variation of another. Adding actions. 2

Extend vs. Include Extend is used when a use case conditionally adds steps to another first class use case. e.g., An ATM machine: “Assess Fee” extends “Withdraw Cash” and describe the conditional "extension point" that is instantiated when the ATM user is not a member. Basic "Withdraw Cash“ stands on its own, without the extension. Include is used to extract use case fragments that are duplicated in multiple use cases. The included use case cannot stand alone and the original use case is not complete without the included one. Extend is used when a use case conditionally adds steps to another first class use case. For example, imagine "Withdraw Cash" is a use case of an ATM machine. "Assess Fee" would extend Withdraw Cash and describe the conditional "extension point" that is instantiated when the ATM user doesn't bank at the ATM's owning institution. Notice that the basic "Withdraw Cash" use case stands on its own, without the extension. Include is used to extract use case fragments that are duplicated in multiple use cases. The included use case cannot stand alone and the original use case is not complete without the included one. This should be used sparingly an only in cases where the duplication is significant and exists by design (rather than by coincidence). For example, the flow of events that occurs at the beginning of every ATM use case (when the user puts in their ATM card, enters their PIN, and is shown the main menu) would be a good candidate for an include. This may be contentious but the "includes are always and extends are sometimes" is a very common misconception which has almost taken over now as the de-facto meaning. Here's a more correct approach (in my view, and checked against Jacobson, Fowler, Larmen and 10 other references). Relationships are dependencies The key to Include and extend use case relationships is to realise that, common with the rest of UML, the dotted arrow between use cases is a dependency relationship. I'll use the terms 'base', 'included' and 'extending' to refer to the use case roles. include A base use case is dependent on the included use case(s); without it/them the base use case is incomplete as the included use case(s) represent sub-sequences of the interaction that may happen always OR sometimes. ( This is contrary to popular misconception about this, what your use case suggests always happens in the main scenario and sometimes happens in alternate flows simply depends on what you choose as your main scenario; use cases can easily be restructured to represent a different flow as the main scenario and this should not matter). In the best practice of one way dependency the base use case knows about (and refer to) the included use case, but the included use case shouldn't 'know' about the base use case. This is why included use cases can be: a) base uses case in their own right and b) shared by a number of base use cases. extend The extending use case is dependent on the base use case; it literally extends the behaviour described by the base use case. The base use case should be a fully functional use case in its own right ('include's included of course) without the extending use case's additional functionality. Extending use cases can be used in several situations: a) The base use case represents the "must have" functionality of a project while the extending use case represents optional (should/could/want) behaviour. This is where the term optional is relevant - optional whether to build/deliver rather than optional whether it sometimes runs as part of the base use case sequence. b) In phase 1 you can deliver the base use case which meets the requirements at that point, and phase 2 will add additional functionality described by the extending use case. This can contain sequences that are always or sometimes performed after phase 2 is delivered (again contrary to popular misconception). c) It can be used to extract out sub sequences of the base use case, especially when they represent 'exceptional' complex behaviour with its own alternative flows. One important aspect to consider is that the extending use case can 'insert' behaviour in several places in the base use case's flow, not just in a single place as an included use case does. For this reason it is highly unlikely that an extending use case will be suitable to extend more than one base use case. As to dependency, the extending use case is dependant on the base use case and is again a one way dependency, i.e. the base use case doesn't need any reference to the extending use case in the sequence. That doesn't mean you can't demonstrate the extension points or add a x-ref to the extending use case elsewhere in the template; but the base use case must be able towork without the extending use case. 3

Extend vs. Include Wheels Car DVD players 4

Use Case Diagrams UML use case relationship -symbols Relationships: Use cases may be related to other use cases. Excerices 5

Use Case Diagram - Exercise Actors: customer, waiter, chef, cashier Use Cases: order food, cook food, serve food, eat food, order wine, serve wine, drink wine, pay for food, pay for wine Use case relationships? 6

Use Case Diagram – An Example References: Visual Case - UML Tutorial – Use Case Diagram.pdf Generalization: When a use case describes a variation on another use case, use a generalization link.  In the example below, the use case limit exceeded describes a situation in which the usual scenario of online purchase is not performed.  Use cases that generalize another use case should only specify an alternative, even exceptional, scenario to the use case being generalized.  The overall goal of the use cases should be the same. Extend: In some instances you want to describe a variation on behaviour in a more controlled form.  In such instances you can define extension points in the extended use case.  In the example below, search by name is said to extend search at thename extension point.  The extends link is more controlled than the generalization link in that functionality can only be added at the extension points. Goto 9 7

UML use case relationship symbols - Generalization A use case that is a variation on normal behavior of another use case describes a generalization relationship. These generalization use case relationships can be used to describe actions when an alternative behavior must be carried out for some reason. 8

UML use case relationship include or use – Exercise Review Transcript Data use case is used by the Register for Course use case to be sure the student has met the course's prerequisites. Review Transcript Data use case is also used by Graduate Student use case to be sure that all program requirements have been met for graduation. reviewer ------- (review transcript data) <-- include -- (register for course) ^ | include (graduate student) 9

UML use case relationship symbols – extend or extends A use case may extend a use case by adding new actions to it. <<includes>>, <<include>>, <<use>>, <<uses>> 10

UML use case relationship extend or extends – Exercise Use case Register for Distance Course may extend use case Register for Course. Additional actions must be performed when a student registers for a distance course. reviewer ------- (register for course) <-- extend -- (register for distance course) 11

Use Case Template See also: A Use Case Template.pdf Reference: http://www.bredemeyer.com/pdf_files/use_case.pdf 12

Use Case – An Example See also: A Use Case Template.pdf The example below shows a use case that describes the interactions involved in repairing a cellular network. The business goal of the (primary) actor the Operator is to repair the network. The other active participants are the cellular network itself and a field maintenance engineer. The source information for the use case comes from two sources viz. Operating Manual [1993] and [Jones 1998]. In order for the use case to succeed it is assumed that any changes that are sent to the cellular network will not fail. That is the network cells will change as directed. 13

Extending a Use Case See also: A Use Case Template.pdf Reference: http://www.bredemeyer.com/pdf_files/use_case.pdf 14

Extending a Use Case – An example See also: A Use Case Template.pdf 15

Use Case - Exercise 16

Summary Use Cases describe the behavioral aspects of the system. Use cases are not design tools. Use Cases are a convenient way to document the functions that the system must support. Use Cases are used to identify the components (classes) of the system. Use case relationships? Why use cases are not design tools? - Just functional descriptions not software structure. 17