Applying UML and Patterns

25.3 THE EXTEND RELATIONSHIP respect to the included Handle Credit Payment subfunction use case. On the other hand, the use case that is an inclusion, extension, or specialization is called an addition use case. Handle Credit Payment is the addition use case in the include relationship to Process Sale. Addition use cases are usually abstract. Base use cases are usually concrete. The extend Relationship Suppose a use case's text should not be modified (at least not significantly) for some reason. Perhaps continually modifying the use case with myriad new extensions and conditional steps is a maintenance headache, or the use case has been baselined as a stable artifact, and can't be touched. How to append to the use case without modifying its original text? The extend relationship provides an answer. The idea is to create an extending or addition use case, and within it, describe where and under what condition it extends the behavior of some base use case. For example: UC1: Process Sale (the base use case) Extension Points: VIP Customer, step 1 . Payment, step 7. Main Success Scenario: 1 . Customer arrives at a POS checkout with goods and/or services to purchase. … 7. Customer pays and System handles payment. … UC15: Handle Gift Certificate Payment (the extending use case) … Trigger: Customer wants to pay with gift certificate. Extension Points: Payment in Process Sale. Level: Subfunction Main Success Scenario: 1 . Customer gives gift certificate to Cashier. 2. Cashier enters gift certificate ID. … This is an example of an extend relationship. Note the use of an extension point, and that the extending use case is triggered by some condition. Exten- sion points are labels in the base use case which the extending use case refer- ences as the point of extension, so that the step numbering of the base use case can change without affecting the extending use case—indirection yet again. Sometimes, the extension point is simply \"At any point in use case X.\" This is especially common in systems with many asynchronous events, such as a word processor (\"do a spell check now,\" \"do a thesaurus lookup now\"), or reactive con- trol systems. Note however, as described in the prior include relationship sec- 389

25.4 25 - RELATING USE CASES tion, that include can also be used to describe asynchronous event handling. The extend alternative is an option when the base use case is closed to modification. Note that a signature quality of the extend relationship is that the base use case (Process Sale) has no reference to the extending use case (Handle Gift Certificate Payment), and therefore, does not define or control the conditions under which the extensions trigger. Process Sale is complete and whole by itself, without knowing about the extending use case. Observe that this Handle Gift Certificate Payment addition use case could alter- natively have been referenced within Process Sale with an include relationship, as with Handle Credit Payment. That is often suitable. But this example was motivated by the constraint that the Process Sale use case was not to be modi- fied, which is the situation in which to use extend rather than include. Further, note that this gift certificate scenario could simply have been recorded by adding it as an extension in the Extensions section of Process Sale. This approach avoids both the include and extend relationships, and the creation of a separate subfunction use case. Indeed, just updating the Extensions section is usually the preferred solu- tion, rather than creating complex use case relationships. Some use case guidelines recommend using extending use cases and the extend relationship to model conditional or optional behavior inserted into the base use case. This is not inaccurate, but it misses the point that optional and conditional behavior can simply be recorded as text in the Extensions section of the base use case. The complication of using the extend relationship and more use cases is not motivated only by optional behavior. What most practically motivates using the extend technique is when it is unde- sirable for some reason to modify the base use case. The generalize Relationship Discussion of the generalize relationship is outside the scope of this introduc- tion. However, note that use case experts have been successfully doing use case work without this optional relationship, which adds another level of complexity to use cases, and there is not yet agreement by practitioners on the best-practice guidelines of how to get value from this idea. A common observation by use case consultants is that complications result and unproductive time is spent on the addition of many use case relationships. 390

USE CASE DIAGRAMS25.5 Use Case Diagrams Figure 25.1 illustrates the UML notation for the include relationship, which is the only one being used in the case study, following the advice of use-case experts to keep things simple and prefer the include relationship. NextGen POS Process Sale Cashier «include» «include» «actor» Accounting Customer Handle Check «include» Handle Credit Payment Payment System UML notation: Handle Cash the base use Payment «actor» case points to Credit the included use «include» «include» Authorization case «include» Service Process Rental Handle Returns Manage Users ... Figure 25.1 Use case include relationship in the Use-Case Model. The extend relationship notation is illustrated in Figure 25.2. Process Sale Extension Points: UML notation: Payment 1. The extending use case points to the base use case. VIP Customer 2. The condition and «extend» extension point can be Payment, if Customer shown on the line. presents a gift certificate Handle Gift Certificate Payment Figure 25.2 The extend relationship. 391

Chapter 26 MODELING GENERALIZATION Crude classifications and false generalizations are the curse of the organized life. — A generalization by H.G. Wells Objectives • Create generalization-specialization hierarchies. • Identify when showing a subclass is worthwhile. • Apply the \"100%\" and \"Is-a\" tests to validate subclasses. Introduction Generalization and specialization are fundamental concepts in domain model- ing that support an economy of expression; further, conceptual class hierarchies are often the basis of inspiration for software class hierarchies that exploit inheritance and reduce duplication of code.26.1 New Concepts for the Domain Model As in iteration 1, the UP Domain Model may be incrementally developed by con- sidering the concepts in the requirements for this iteration. Techniques such as the Concept Category List and noun phrase identification will help. An effective approach to developing a robust and rich domain model is to study the work of other authors on this subject, such as {Fowler96]. The myriad subtle modeling issues they explore are beyond the scope of this book. 393

26 - MODELING GENERALIZATION Concepts Category List Table 26.1 shows some noteworthy concepts being considered in this iteration. Table 26.1 Category Concepts List Category Examples physical or tangible objects specifications, designs or descriptions CreditCard, Check of things places CashPayment, CreditPayrnent, transactions CheckPayment transaction line items CreditAuthorizationService, roles of people CheckAuthorizationService containers of other things CreditAuthorizationService, things in a container CheckAuthorizationService other computer or electro-mechanical systems external to our system AccountsReceivable abstract noun concepts organizations events rules and policies catalogs records of finance, work, contracts, legal matters financial instruments and services manuals, books394

NEW CONCEPTS FOR THE DOMAIN MODELNoun Phrase Identification from the Use Cases To reiterate, noun phrase identification cannot be mechanically applied to iden- tify relevant concepts to include in the domain model. Judgement must be applied and suitable abstractions developed, since natural language is ambigu- ous and relevant concepts are not always explicit or clear in existing text. How- ever, it is a practical technique in domain modeling since it is straightforward. This iteration handles the scenarios of the Process Sale use case for credit and check payments. The following shows some noun phrase identification from these extensions: Use Case UC1: Process Sale Extensions: 7b. Paying by credit: 1 . Customer enters their credit account information. 2. System sends payment authorization request to an external Payment Autho- rization Service System, and requests payment approval. 2a. System detects failure to collaborate with external system: 1. System signals error to Cashier. 2. Cashier asks Customer for alternate payment. 3. System receives payment approval and signals approval to Cashier. 3a. System receives payment denial: 1. System signals denial to Cashier. 2. Cashier asks Customer for alternate payment. 4. System records the credit payment, which includes the payment approval. 5. System presents credit payment signature input mechanism. 6. Cashier asks Customer for a credit payment signature. Customer enters signature. 7c. Paying by check: 1. The Customer writes a check, and gives it and their driver's license to the Cashier. 2. Cashier writes the driver's license number on the check, enters it, and requests check payment authorization. 3. Generates a check payment request and sends it to an external Check Autho- rization Service. 4. Receives a check payment approval and signals approval to Cashier. 5. System records the check payment, which includes the payment approval.Authorization Service Transactions The noun phrase identification reveals concepts such as CreditPaymentRequest and CreditApprovalReply. These may in fact be viewed as types of transactions with external services, and in general, it is useful to identify such transactions because activities and processes tend to revolve around them. 395

26 - MODELINGGENERALIZATION These transactions do not have to represent computer records or bits travelling over a line. They represent the abstraction of the transaction independent of its means of execution. For example, a credit payment request may be executed by people talking on the phone, by two computers sending records or messages to each other, and so on.26.2 Generalization The concepts CashPayment, CreditPayment, and Check Payment are all very sim- ilar. In this situation, it is possible (and useful1) to organize them (as in F'igure 26.1) into a generalization-specialization class hierarchy (or simply class hierarchy) in which the superclass Payment represents a more general con- cept, and the subclasses more specialized ones. Payment superclass - more general concept Credit these are conceptual Payment classes, not software classes Cash Check subclass - more Payment Payment specialized concept Figure 26.1 Generalization-specialization hierarchy. Note that the discussion of classes in this chapter refers to conceptual classes, not software classes. Generalization is the activity of identifying commonality among concepts and defining superclass (general concept) and subclass (specialized concept) rela- tionships. It is a way to construct taxonomic classifications among concepts which are then illustrated in class hierarchies. Identifying a superclass and subclasses is of value in a domain model because their presence allows us to understand concepts in more general, refined and abstract terms. It leads to economy of expression, improved comprehension and a reduction in repeated information. And although we are focusing now on the UP Domain Model and not the software Design Model, the later design and implementation of super- and subclass as software classes that use inheritance yields better software. 1. Later in the chapter, we will investigate reasons to define class hierarchies. 396

DEFININGCONCEPTUALSUPERCLASSESANDSUBCLASSES Thus:Identify domain superclasses and subclasses relevant to the current investi-gation, and illustrate them in the Domain Model.UML notation—To review the generalization notation introduced in a priorchapter, in the UML the generalization relationship between elements is indi-cated with a large hollow triangle pointing to the more general element from themore specialized one (see Figure 26.2). Either a separate target or shared targetarrow style may be used. Payment Payment Cash Credit Check Cash Credit CheckPayment Payment Payment Payment Payment PaymentFigure 26.2 Class hierarchy with separate and shared arrow notations.26.3 Defining Conceptual Superclasses and Subclasses Since it is valuable to identify conceptual super- and subclasses, it is useful to clearly and precisely understand generalization, superclasses, and subclasses in terms of class definition and class sets.2 This following sections explore these. Generalization and Conceptual Class Definition What is the relationship of a conceptual superclass to a subclass? A conceptual superclass definition is more general or encompassing than a subclass definition.For example, consider the superclass Payment and its subclasses (CashPayment,and so on). Assume the definition of Payment is that it represents the transac-tion of transferring money (not necessarily cash) for a purchase from one party2. That is, a class's intension and extension. This discussion was inspired by |MO95|. 397

26 - MODELINGGENERALIZATION to another, and that all payments have an amount of money transferred. The model corresponding to this is shown in Figure 26.3. Payment amount : Money Cash Credit Check Payment Payment Payment Figure 26.3 Payment class hierarchy. A CreditPayment is a transfer of money via a credit institution which needs to be authorized. My definition of Payment encompasses and is more general than my definition of CreditPayment. Generalization and Class Sets Conceptual subclasses and superclasses are related in terms of set membership. All the members of a conceptual subclass set are members of their superclass set. For example, in terms of set membership, all instances of the set CreditPayment are also members of the set Payment. In a Venn diagram, this is shown as in Figure 26.4. Payment CashPayment CreditPayment CheckPayment Figure 26.4 Venn diagram of set relationships.398

DEFINING CONCEPTUAL SUPERCLASSES AND SUBCLASSESConceptual Subclass Definition ConformanceWhen a class hierarchy is created, statements about superclasses that apply tosubclasses are made. For example, Figure 26.5 states that all Payments have anamount and are associated with a Sale. Payment Pays-for Sale amount : Money 11 Cash Credit CheckPayment Payment PaymentFigure 26.5 Subclass conformance.All Payment subclasses must conform to having an amount and paying for aSale. In general, this rule of conformance to a superclass definition is the 100%Rule: 100% Rule100% of the conceptual superclass's definition should be applicable to the sub-class. The subclass must conform to 100% of the superclass's:• attributes• associationsConceptual Subclass Set Conformance A conceptual subclass should be a member of the set of the superclass. Thus, CreditPayment should be a member of the set of Payments. Informally, this expresses the notion that the conceptual subclass is a kind of superclass. CreditPayment is a kind of Payment. More tersely, is-a-kind-of is called is-a. 399

26 - MODELING GENERALIZATION This kind of conformance is the Is-a Rule: Is-a Rule All the members of a subclass set must be members of their superclass set. In natural language, this can usually be informally tested by forming the statement: Subclass is a Superclass For instance, the statement CreditPayment is a Payment makes sense, and con- veys the notion of set membership conformance. What Is a Correct Conceptual Subclass? From the above discussion, apply the following tests3 to define a correct subclass when constructing a domain model: A potential subclass should conform to the: • 100% Rule (definition conformance) • Is-a Rule (set membership conformance)26.4 When to Define a Conceptual Subclass Rules to ensure that a subclass is correct have been examined (the Is-a and 100% rules). However, when should we even bother to define a subclass? First, a definition: A conceptual class partition is a division of a conceptual class into disjoint subclasses (or types in Odell's terminology) [MO95]. The question may be restated as: \"When is it useful to show a conceptual class partition?\" For example, in the POS domain, Customer may be correctly partitioned (or sub- classed) into MaleCustomer and FemaleCustomer. But, is it relevant or useful to show this in our model (see Figure 26.6)? 3. These rule names have been chosen for their mnemonic support rather than precision. 400

WHEN TO DEFINE A CONCEPTUAL SUBCLASS Customer Correct subclasses. But useful? Male FemaleCustomer CustomerFigure 26.6 Legal conceptual class partition, but is it useful in our domain?This partition is not useful for our domain; the next section explains why.Motivations to Partition a Conceptual Class into Subclasses The following are strong motivations to partition a class into subclass:Create a conceptual subclass of a superclass when:1. The subclass has additional attributes of interest.2. The subclass has additional associations of interest.3. The subclass concept is operated on, handled, reacted to, or manipulated differently than the superclass or other subclasses, in ways that are of interest.4. The subclass concept represents an animate thing (for example, animal, robot) that behaves differently than the superclass or other subclasses, in ways that are of interest.Based on the above criteria, it is not compelling to partition Customer into thesubclasses MaleCustomer and FemaleCustomer because they have no additionalattributes or associations, are not operated on (treated) differently, and do notbehave differently in ways that are of interest4.Table 26.2 shows some examples of class partitions from the domain of pay-ments and other areas, using these criteria.4. Men and women do exhibit different shopping habits. However, these are notrelevant to our current use case requirements—the criterion that bounds ourinvestigation. 401