A Comparative Analysis of Use Case Relationships

Transcription

1 A Comparative Analysis of Use Case Relationships Margaret Hilsbos, Il-Yeol Song, and Yoo Myung Choi College of Information Science and Technology, Drexel University, Philadelphia, PA {mhilsbos, song, Abstract. Use case relationships are used to manage the complexity of use cases. The UML defines the three types of use case relationships: include, extend, and generalization. The appropriate use of the use case relationships, however, is one of the most contentious areas. We found that the suggestions of various authors overlap but conflict, leaving room for dissension. In this paper, we present a comparative analysis of the use case relationships discussed in eleven literatures, including the UML 2.0 specification. For a coherent approach for applying use case relationships, we present three rules derived from the review of the literatures and our own experience and illustrates the rules with examples. Our rules are based on the analysis of preconditions, postconditions of use cases, and characteristics of the behaviors being separated. 1 Introduction Use Cases are a fundamental starting point of object oriented analysis and design. The Unified Modeling Language (UML) through release 1.5 has not defined all aspects of use case modeling explicitly, and does not provide a method for determining the correct modeling techniques for a given situation. Several authors have discussed various approaches; some different authors approaches conflict with each other. The release of UML 2.0 clarifies some of the rules, but still leaves gaps. Ambiguity and misuse of use cases and use case relationships have been cautioned against by many authors [9, 10, 11, 14, 16, 21, 22]. In this paper, we analyze the application of use case relationships. Use case relationships are used to manage the complexity of use cases. The UML defines the three types of use case relationships: include, extend, and generalization [20]. The appropriate use of the use case relationships, however, is one of the most contentious areas in a use case modeling. Metz et al. [17] review various meanings of alternative courses discussed by several authors and summarize three different meanings of them alternative history, use case exceptions, and alternative part. To our knowledge, however, there has been no comparative study on use case relationships by different views of various experts and literature. In this paper, we present a comparative analysis of the use case relationships discussed in eleven literatures, including the UML 2.0 specification. We present the agreed usages and different view points of the use case relationships. Several points of contention are identified and a logical resolution is argued for each. Finally, we propose three rules for applying use case relationships and illustrate them with examples. J. Akoka et al. (Eds.): ER Workshops 2005, LNCS 3770, pp , Springer-Verlag Berlin Heidelberg 2005

2 54 M. Hilsbos, I.-Y. Song, and Y.M. Choi The rest of this paper is organized as follows: Section 2 provides an extensive literature review in term of usages of use case relationships. Section 3 presents three recommended rules of using the use case relationship for a coherent approach. Section 4 concludes our paper. 2 Comparative Review There are three types of relationships used in use case models: include, extend, and generalization. The include and extend relationships are represented as a stereotype dependency and are enclosed in guillemets as: extend, include. Use case relationships enter the modeling process after an initial set of use cases have been determined and at least high-level descriptions have been written. The following general purposes have been suggested for applying relationships to the use case model: 1. factor out reused behavior to remove redundancy [1, 175; 3, 169; 2; 8, 161; 13, 111; 15, 388] 2. factor out requirements that can be implemented at a later time [3, 165; 5, 260; 6, 237; 8, 169] 3. separate functionality to reduce the scope of an initial use case to a more manageable size [1, 206; 6, 110; 15, 388; 19] 2.1 Include The following rules are generally agreed upon by the authors surveyed: The base use case calls the included use case, like a subroutine. After execution of the included use case, control returns to the base use case at the point just after the inclusion was called. An included use case must contain only one insertion segment. The entire included use case is executed when it is called. An included use case may be called by multiple other base use cases; that is the original intention of include. Using include for Behavior Common to More Than One Use Case. The UML 2 specification states that the include relationship is intended to be used when there are common parts of the behavior of two or more use cases [18, 518]. Most of the surveyed authors noted common behavior as a major reason for using include [1; 3; 4; 5; 8; 12; 13; 15; 20; 24]. Chonoles and Schardt suggest particularly looking for an opportunity to factor out common behavior when several use cases interact with the same external system as a secondary actor. It is very probable in this situation that the interaction with the external system should be common; factoring it out as an included use case helps prevent inconsistency [8, 163]. Using include for Optional or Alternative Paths. The UML 2.0 specification states Note that the included use case is not optional, and is always required for the including use case to execute correctly [18, 518]. But several authors propose that

3 A Comparative Analysis of Use Case Relationships 55 include may be used for conditional behavior. Armour and Miller note that no conditional guard is associated with the included use case at its inclusion point but this does not preclude the including use case from containing conditional logic that might result in the included behaviors not executing during a particular instance of execution [3, 169]. Bittner and Spence do not discuss the point, but their example for «include» is conditional: If the customer is a new customer, include use case Add Customer Information [5, 257]. Cockburn implies support for using include for conditional behavior, by restricting the use of extend to cases where the base use case is locked, or there are very many asynchronous extensions. He argues that include is much easier for most people to understand and use than extend or generalization, and should therefore be preferred [6, 116, 207]. Larman references Cockburn s statement and uses examples of include which are conditional [15]. Using include to Handle Asynchronous Actions. Larman suggests using «include» to handle asynchronous events, instead of using «extend» as others suggest [15, 387]. An asynchronous action is one that can be called at any, or almost any, point in the base use case. Using include to Decompose Overly Complex Use Cases. The UML 2.0 specification notes The Include relationship allows hierarchical composition of use cases as well as reuse of use cases [18, 518]. Larman also suggests using include to decompose an overwhelmingly long use case into subunits to improve comprehension [15, 387]. Kulak and Guiney show examples of include used to decompose business processes, but their examples are not functional decomposition of use cases [13, 172, 256]. Other authors also use include to decompose a complex use case [24, 215; 20, 80]. The logic of an Include use case, however, should be complex enough to deserve a separate use case documentation [23]. 2.2 Extend Regarding the extend relationship, the following rules are generally agreed by the authors surveyed: The base use case must be able to stand alone it can execute completely and successfully without executing the extending use case. An extending use case cannot stand alone it is never directly initiated by an actor, and depends on the base use case (i.e., it is always abstract). An extending use case may contain multiple insertion segments; an extension point must be defined for each segment. For each insertion segment, control must exit from and return to the base use case at the same point, the extension point. An extending use case may be re-used; it may extend more than one base use case. In this case, the base use cases establish the pre-conditions for the extending use case. If two use cases share an extension, then at the extension point for each base use case, the system conditions must satisfy the same precondition. In the following subsections, we review reasons for using extend proposed by various authors.

4 56 M. Hilsbos, I.-Y. Song, and Y.M. Choi Using extend for a Complex Alternative Course of Action. Adolph and Bramble suggest using extend when an alternative course of action interrupts a number of steps in a scenario. They use the example Book Flight for Frequent Flier as an extension of the use case Book Flight [1, ]. See Figure 1 for the depiction of this example in the use case diagram. Fig. 1. An example of a complex alternative course of action The extending use case Book Flight for Frequent Flier is said to have multiple insertion segments because the base use case is interrupted several times within one alternative scenario. The use of one extending use case to handle multiple insertion segments which occur at different points in the base use case is supported by several other authors [3; 4; 20]. UML 2.0 supports using extend when there are multiple insertion segments (behavior fragments) in the extending use case [18, 515]. Using extend for Optional Behavior or Exceptional Behavior. Using extend for optional behavior or exceptional behavior is supported by most of the reviewed authors [1, 195; 3, 153; 4, 87; 5, 259; 7; 12, 130; 13, 44; 24, 53]. Armour and Miller caution that the extension must always return control to the base use case at the extension point; therefore it is not appropriate to use extend for exception or error handling that does not return control to the base use case, or does not return control at the step immediately following the extension point. Using extend for Asynchronous Options. Constantine and Lockwood [7] and Cockburn [6, 237] discuss the use of extend to indicate the availability of asynchronous options. Cockburn uses the example of spell-check in a word processor. Constantine and Lockwood unfortunately give the example of resetting a test, which seems inappropriate for an extend because it seems to violate the rule that control must return to the base use case at the step immediately following the point of interruption by the extension. Using extend to Add Behavior After the Base Use Case Is Locked. A few authors emphasize the value of extend for adding behavior to a base use case when its documentation is locked [4; 5; 6; 8; 15]. The argument for this is that the base use case doesn t need to know about the extension so therefore the extension can be added without updating the base use case documentation. Chonoles and Schardt note that in practice, this can result in confusing documentation, particularly if several releases have resulted in multiple nested extensions to the same base use case [8, 170]. Using extend to Separate Behavior to be Deferred in Development. Armour and Miller suggest using extend to separate behaviors that can be developed later

5 A Comparative Analysis of Use Case Relationships 57 from a base use case. They suggest this separation enables setting a lower priority for the extending use case than the base use case [3, 165]. Cockburn implies a similar approach [6, 237]. Extension Points. Some authors suggest that it can be desirable to depict extension points on the use case diagram [1, 188; 3, 163; 5, 265; 24, 55]. It can be anticipated that adding extension point information could clutter the diagram, as Cockburn suggests [6, 238]. Extension point information displayed in the use case diagram is removed from the context of the use case steps, so it is unclear what added value there is in showing it on the diagram. 2.3 Generalization Use case generalization is fairly straightforward and there is general agreement among authors as to its usage. The reviewed authors suggest using use case generalization in the following situations: variations on a similar goal [3, 175; 4, 82] when different technologies are used to achieve a goal [5, 267; 8, 166; 24, 58; 19; 20, 675] when different actors achieve similar goals, or the same goal by different means [6, 241; 8, 166] However, we note that use case generalizations can be restated using either extend or include relationships. Some authors recommend that generalization not be used as they can create confusion. [6, 12, 13, 15,]. Cockburn also discusses the hazards of using use case generalization. [6, 240] 3 Synthesis: A Coherent Approach to Use Case Relationships The above review could be characterized as a list of differences. The lack of agreement among experts on so many points regarding use case relationships seems to ensure that there dwill be costly disagreements in the field. To avoid such disagreements, it would be helpful to have a coherent and dependable model for assigning use case relationships. The characteristics desired of such a model are that: The rules are unambiguous. The rules are easy to understand. The rules are simple to use. These rules are difficult to achieve from a reading of the reviewed authors. Generally the applications proposed by the reviewed authors are understandable, and sometimes simple to apply. The problem is that when taken together, the suggestions of various authors overlap but conflict, leaving room for dissension. From our review we suggest to limit application of the reviewed authors suggestions by the following guiding principles: 1. Minimize interleaving [19] 2. Conform to the UML specification to the extent possible. Standards are created for the purpose of establishing a common language. Creating individual

6 58 M. Hilsbos, I.-Y. Song, and Y.M. Choi dialects reduces portability and increases the learning curve for new team members. 3. The use case diagram is not a process flow. Do not use relationships for behavior that can stand alone with the proper specification of preconditions and postconditions (Example: Log In is not included, it establishes the precondition for other use cases) 4. Do not create a too small fragment of operations as an inclusion use case [23]. To further improve on this situation, we propose the three sets of rules for applying use case relationships. The first looks at using pre- and post-conditions to segregate terminal and initial behavior, respectively. The second determines the correct relationship based on general features of the behaviors being separated. The third evaluates relationships based on the assignment of postconditions. The rule sets operate from different perspectives and may be applied in tandem. 3.1 Rule Set 1: Avoid Relationship Overuse by Understanding Pre- and Postconditions An included use case should probably not be called at the very beginning or very end of a use case flow. Encapsulatable behavior at the beginning of a use case should be separated as a stand-alone use case. The postcondition of this use case becomes a precondition for the original use case. An example of this is the Log In use case for many applications. If Log In is treated as an included use case, the number of «include» arrows on the diagram could overwhelm and obscure other content. Likewise, if behavior at the end of a use case seems to be a candidate for «include», consider whether the behavior can be treated as a stand-alone use case, with its precondition being the adjusted postconditions of the original use case (the postconditions of the original are adjusted to eliminate any set by the new use case). For example, one might be inclined to include Process Payment with use cases Process Sale and Process Rental. Instead, Process Payment should, in most cases, be factored into a standalone use case. It is at the end of the sale or rental process, and usually contains sufficient complexity to warrant a separate use case. In the case that there are other processes after payment before the customer can leave the store, or exit the web transaction as the case may be, those processes similarly stand alone. Examples might be: Disable Security Tag ; Send Confirmation . The precondition for Process Payment and the postcondition for Record Order become, an order is prepared for payment. Note the matching of the postcondition of one use case to the precondition of another. 3.2 Rule Set 2: Characteristics of the Behaviors Use include when the behavior fragment is required for at least one alternative described by the base use case, to fulfill the postconditions of the base use case AND is referred to more than once (multiple use cases, multiple times within the same use case, and/or is stand-alone as well as referred to from a use case).

7 A Comparative Analysis of Use Case Relationships 59 Example: In some applications, there is a need to process coupons or discounts. Some of these (such as a manufacturer s coupon) are validated and rung as part of the order, before arriving at the total for payment. Then (for some applications) there are special discounts that apply only when, for example, a certain payment method is used. Particularly in the payment-specific case, it is difficult to factor out the processing of the discount as a standalone use case, because the discount must be returned and a new total calculated before Process Payment can complete. So in this circumstance, the use of include may make the most sense. It should be noted that, absent the requirement for applying promotions during payment processing, Process Promotion could possibly be factored out as standalone, by adjusting the postcondition of Record Order to match the precondition of Process Promotion : order is complete and ready to apply discounts. The use case is shown in Figure 2. Use extend when the behavior fragment is never required for successful completion of the base use case, and has its own postconditions AND needs to be separated from the base use case to improve clarity AND cannot be modeled as a stand-alone use case without overly fragmenting the base use case Example: In a sales application where a customer may order several different items (e.g., an online bookstore), an item may not be in stock. If the order is to be processed anyway, the backordered item entails some additional processing before completing the order. This situation may be best modeled using an extending use case, as shown in Figure 2. Fig. 2. Example of Rule Set 2 Use generalization when the behavior fragment represents an alternative, similar use case. [differences may include initiating Actor and/or postconditions] AND

8 60 M. Hilsbos, I.-Y. Song, and Y.M. Choi the common behavior of the similar use cases cannot be simply factored out as an include OR the project team prefers to see the commonality of the use cases indicated (i.e. the relative similarity of the use cases determines whether you just include common behavior, or show the use cases as specializations of the same general process). For example, in the Process Payment use case (Figure 2), there are several types of payment methods. It would not be simple or straightforward to use include for the common behavior, and it seems quite natural to use generalization in this case the phrase different means of achieving the same goal is a tip that generalization probably applies. 3.3 Rule Set 3: The Postcondition Perspective The following rules may be used to establish the appropriate segregation of behavior into use cases. Postconditions of alternatives deciding whether to use relationships or unrelated use cases. If an alternative scenario of a use case results in different postconditions, a separate use case is required, which may be unrelated, or related through extension or generalization (not inclusion). If an alternative is just another path to get to the same set of postconditions, a separate use case is not required and probably should not be used. Effects of relationships on postconditions:-deciding which relationships to use A includes B. The postconditions of B are necessary to fulfill the postconditions of A, for at least one alternative. For at least one scenario of A, the postconditions of A are only fulfilled if B is executed properly. B has its own postconditions, but they may be overridden by actions performed in A after the inclusion. The postconditions of A include those of B. B extends A. The postconditions of A are fulfilled whether or not B is executed. B has its own postconditions. Therefore, B and A have different postconditions. B and C specialize A. B and C must each fulfill all postconditions specified in A. B and C each may specify additional postconditions, and must specify postconditions if none are specified by A. The set of postconditions which must be fulfilled is Ap + Bp when B is executed, Ap + Cp when C is executed. Here, Ap, Bp, and Cp represent the postconditions of A, B, and C, respectively. 4 Conclusion We have reviewed and summarized use case literatures regarding the application of use case relationships. We have noted areas of agreement and difference. We then discussed arguments made for resolution of differences. As a coherent approach for correctly applying to use case relationships, we have also proposed three rules derived from the review of the literatures and our own experience. Our rules are based on the

9 A Comparative Analysis of Use Case Relationships 61 analysis of preconditions, postconditions of use cases, and general features of the behaviors being separated. From this analysis we conclude that practitioners should be aware of the nuances of appropriate application of each use case relationship, apply the relationships sparingly, and, when in doubt, develop several alternative models for complex problems. There may be more than one correct model to a given problem; the best solution is any solution that works and can be agreed to by the project team and stakeholders. References 1. Adolph, S. and Bramble, P. (2003). Patterns for Effective Use Cases. Addison-Wesley. 2. Ambler, S. W. (2002). Reuse in Use-Case Models: <<extend>>, <<include>>, and Inheritance (Chapter 6 of the book The Object Primer 2/e.) Retrieved 9/2/2003 from 3. Armour, F. and Miller, G. (2001). Advanced Use Case Modeling: Software Systems. Addison-Wesley. 4. Arlow, J. and Neustadt, I. (2002). UML and the Unified Process: Practical Object- Oriented Analysis and Design. Addison-Wesley. 5. Bittner, K. and Spence, I. (2003). Use Case Modeling. Addison-Wesley. 6. Cockburn, A. (2001). Writing Effective Use Cases. Addison-Wesley. 7. Constantine, L., and Lockwood, L. (2001). Structure and Style in Use Cases for User Interface Design, in van Harmelen, M., ed. Object Modeling and User Interface Design. Addison-Wesley. 8. Chonoles, M. J.; Schardt, J.A. (2003). UML 2 for Dummies. Wiley. 9. Firesmtih, D. (2005). Open Process Framework. index.html?components/workproducts/modelset/usecasemodel/usecasemodelingguideli nes.html~contents. 10. Genova, G., Llorens, J. and Metz, P. (2005). Open Issues in Industrial Use Case Modeling, UML 2004 Satellite Activities, LNCS 3297, Genova, G., Llorens, J. and Quintana, V. (2002). Digging into Use Case Relationships, Proc. of UML 2002, Gomaa, H. (2000). Designing Concurrent, Distributed, and Real-Time Applications with UML. Addison-Wesley. 13. Kulak, D. and Guiney, E. (2000). Use Cases: Requirements in Context. Addison-Wesley. 14. Korson, T. (1998). The Misuse of Use Cases, Object Magazine, 8(3), SIGS Publications, 1998, Larman, C. (2002) Applyng UML and Patterns: An Introduction to Object-Oriented Analysis and Design and the Unified Process. Prentice Hall PTR. 16. Lilly, S. Use Case Pitfalls: Top 10 Problems from Real Projects, in the Proceedings of TOOLS, USA Metz, P., O Brien, J., and Weber, W. (2003). "Specifying Use Case Interaction: Types of Alternative Courses", Journal of Object Technology, Vol. 2, No.2, 2003, Object Management Group. (August 2003). UML 2.0 Superstructure Final Adopted specification. Retrieved 9/12/2003, Rawsthorne, D. CapturedAbstraction A Pattern for Applying UML Generalization, in Adolph, S. et al. (2003). Patterns for Effective Use Cases, Addison-Wesley. 20. Rumbaugh, J., Jacobson, I., and Booch, G. (2005). The Unified Modeling Language Reference Manual. Addison Wesley.

10 62 M. Hilsbos, I.-Y. Song, and Y.M. Choi 21. Simons, A J H. and Graham, I. "30 Things that go wrong in object modelling with UML 1.3", chapter 17 in: Behavioral Specifications of Businesses and Systems eds. H Kilov, B Rumpe, I Simmonds (Kluwer Academic Publishers, 1999), Simons, A. J H. "Use cases considered harmful", Proc. 29th Conf. Tech. Obj.-Oriented Prog. Lang. and Sys., (IEEE TOOLS-29 Europe), Song, I.-Y. (2004). Object-Oriented Analysis & Design Using UML: A Practical Approach. Pearson Custom Publishing. 24. Schneider, G. and Winters, J. P. (2001). Applying Use Cases. 2 nd ed. Addison-Wesley.