Section 7.3. Advanced Use Case Modeling


7.3. Advanced Use Case Modeling

As it does for other classifiers, UML provides mechanisms for reusing and adding on to use cases and actors. You can expand an actor's capabilities or replace entire use cases using generalization. You can factor out common elements of use cases using included use cases, or add on to base use cases using use case extension.

7.3.1. Actor and Use Case Generalization

Though not officially mentioned in the specification, actors and use cases can be generalized like many other classifiers. Actor generalization is typically used to pull out common requirements from several different actors to simplify modeling. For example, Figure 7-10 shows several administrators and the use cases they need to invoke. You may have a Database Administrator, a Backup Administrator, and a Deployment Administrator, all with slightly different needs. However, the majority of the needs of the individual actors may overlap. You can factor out a generic System Administrator actor to capture the common functionality, and then specialize to identify the unique needs of each actor.

You represent actor generalization like any other classifier; draw a solid line, with a closed arrow pointing from the specialized actor to the base actor. Figure 7-11 shows the same information as Figure 7-10 but in a much easier-to-read diagram.

Use cases may be generalized as well. Typically use case generalization is used to express some high-level functional need of a system without going into specifics. Specializations of a general use case introduce specific functionality. For example, a generic use case can be Verify Passenger Identity, and specializations of that use case can be Check Passenger Fingerprint and Verify Passenger's RFID Tag. It is important to notice that even with use case generalization, you should still discuss functionality, not implementation. You should not have specializations of a use case for different ways to implement the same functionality, only to represent different functionality.

You represent use case generalization just like you do actor generalization: using a solid line, with a closed arrow pointing from the specialized use case to the base use case. If the general use case represents abstract functionality (meaning it's a functional concept but doesn't actually explain how a user would do something), you show the name of the use case in italics. Figure 7-12 shows the verification use cases and their relationships.

7.3.2. Use Case Inclusion

You can factor out common functionality from several use cases by creating a shared, included use case. Unlike in use case extension (discussed next), the use case that includes another use case is typically not complete on its own. The included functionality isn't considered optional; it is factored out simply to allow for reuse in other use cases.

You show use case inclusion using a dashed line, with an open arrow (dependency) pointing from the base use case to the included use case. Label the line with the keyword include. Figure 7-13 shows an example of use case inclusion.

Figure 7-11. Actor generalization, in which the System Administrator is the generic base actor and the lower three are specializations


Figure 7-12. Use case generalization


Include or Includes?

Often there is disagreement between UML modelers as to whether the proper keywords are include and extend or includes and extends. One would think the UML specification would put this to rest. However, as of the UML 2.0 specification, the use case section states that the keywords are include and extend, and then proceeds to show examples using includes and extends! We think it's safe to say, that either is acceptable.


Figure 7-13. Use case inclusion


7.3.3. Use Case Extension

UML provides the ability to plug in additional functionality to a base use case if specified conditions are met. For example, if you are modeling a banking application, you can have a use case named Open Account that specifies how the user can create a new account with the bank. You can offer a joint account that allowed a user to add other people to his account. The joint account functionality can be captured with a different, use case named Add Joint Member. In this case the specified condition for the extension is more than one member on the bank application.

UML clearly specifies that a base use case should be a complete use case on its own. The extension use cases are typically smaller in scope and represent additional functionality, so they may not be useful outside the context of the base use case.

Any use case you want to extend must have clearly defined extension points. An extension point is a specification of some point in the use case where an extension use case can plug in and add functionality. UML doesn't have a particular syntax for extension points; they are typically freeform text, or step numbers if the use case functionality is represented as a numbered list.

You list extension points in a use case oval, or in a separate compartment when using the classifier notation. Figure 7-14 shows a use case with extension points.

Figure 7-14. Oval and classifier notation for a use case with extension points


You represent a use case extension by showing a dashed line, with an open arrow (dependency) pointing from the extension use case to the base use case. Label the line with the keyword extend. Figure 7-15 shows an example of use case extension.

Figure 7-15. Use case extension


To provide more detail you can specify where the new functionality plugs into the base use case by specifying an extension point and a note attached to the dependency line. Optionally you can specify under what condition the extension executes, such as applicants > 1. Figure 7-16 shows use case extension with a note specifying the extension point and the condition to execute the extra functionality.

Figure 7-16. Use case extension showing conditions in a note


When the system encounters an extension point in a use case, any conditions associated with extension use cases are evaluated. If a condition is met, the corresponding extension functionality is executed. Once all appropriate extension use cases have been executed, the base use case continues with the next step in the original flow.




UML 2.0 in a Nutshell
UML 2.0 in a Nutshell (In a Nutshell (OReilly))
ISBN: 0596007957
EAN: 2147483647
Year: 2005
Pages: 132

flylib.com © 2008-2017.
If you may any questions please contact us: flylib@qtcs.net