1. Software Engineering 1 Object-oriented Analysis and Design Chap 30 Relating Use Cases

2. Software Engineering 2 Object-oriented Analysis and Design The include Relationship 1  Some partial behavior across several use cases. m paying by credit occurs in several use cases, including Process Sale, Process Rental, Contribute to Lay-away Plan. m to separate it into its own subfunction use case, and indicate its inclusion. m This is simply refactoring and linking text to avoid duplication  UC1: Process Sale m Main Success Scenario:  1.Customer arrives at a POS checkout with goods and/or services to purchase .…  7.Customer pays and System handles payment.… m Extensions:  7b. Paying by credit: Include Handle Credit Payment.  7c. Paying by check: Include Handle Check Payment.…  UC7: Process Rental m Extensions:  6b. Paying by credit: Include Handle Credit Payment.

3. Software Engineering 3 Object-oriented Analysis and Design The include Relationship 2  UC12: Handle Credit Payment m Level: Subfunction m Main Success Scenario:  1.Customer enters their credit account information.  2.System sends payment authorization request to an external Payment Authorization Service System, and requests payment approval.  3.System receives payment approval and signals approval to Cashier. m Extensions:  2a. System detects failure to collaborate with external system:  System signals error to Cashier.  Cashier asks Customer for alternate payment.

4. Software Engineering 4 Object-oriented Analysis and Design The include Relationship 3  Using include with Asynchronous Event Handling m when a user is able to, at any time, select or branch to a particular window, function, or Web page, or within a range of steps.  a*, b*,... style labels in the Extensions section.  UC1: Process FooBars m Main Success Scenario: m … m Extensions:  a*. At any time, Customer selects to edit personal information: Edit Personal Information.  b*. At any time, Customer selects printing help: Present Printing Help.  2-11. Customer cancels: Cancel Transaction Confirmation  Subfunction use cases and use the include relationship when: m They are duplicated in other use cases. m A use case is very complex and long, and separating it into subunits aids comprehension.  As a first rule, always use the include relationship between use cases.

5. Software Engineering 5 Object-oriented Analysis and Design The include Relationship 4 NextGen POS Cashier Customer Handle Cash Payment Process Rental Process Sale Handle Check Payment Handle Returns «include» «actor» Accounting System «actor» Credit Authorization Service Manage Users... UML notation: the base use case points to the included use case Handle Credit Payment

6. Software Engineering 6 Object-oriented Analysis and Design Concrete/Abstract Use Cases  Concrete use case m Be initiated by an actor and performs the entire behavior desired by the actor. m Process Sale is a concrete use case.  Abstract use case m Be never instantiated by itself; it is a subfunction use case that is part of another use case. m Handle Credit Payment is abstract; it doesn't stand on its own, but is always part of another story, such as Process Sale.

7. Software Engineering 7 Object-oriented Analysis and Design Base/Addition Use Cases  Base use case m includes another use case, or is extended or specialized by another use case. Process Sale is a base use case with respect to the included Handle Credit Payment.  Addition use case m be an inclusion, extension, or specialization. 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.

8. Software Engineering 8 Object-oriented Analysis and Design The extend Relationship 1  The extend relationship m Suppose a use case's text should not be modified or has been baselined as a stable artifact, and can't be touched. m 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.  UC1: Process Sale (the base use case) m Extension Points: VIP Customer, step 1. Payment, step 7. m 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) m Trigger: Customer wants to pay with gift certificate. m Extension Points: Payment in Process Sale. m Level: Subfunction m Main Success Scenario:  1.Customer gives gift certificate to Cashier.  2.Cashier enters gift certificate ID.

9. Software Engineering 9 Object-oriented Analysis and Design The extend Relationship 2  The use of an extension point, and that the extending use case is triggered by some condition. m Extension points are labels in the base use case which the extending use case references as the point of extension. m the extension point may simply "At any point in use case X." with many asynchronous events, such as a word processor ("do a spell check now," "do a thesaurus lookup now"), or reactive control systems.  updating the Extensions section is usually the preferred solution, rather than creating complex use case relationships.  Practically motivates using the extend technique  when it is undesirable for some reason to modify the base use case.

10. Software Engineering 10 Object-oriented Analysis and Design The extend Relationship 3 Process Sale Extension Points: Payment VIP Customer «extend» Payment,if Customer presents a gift certificate UML notation: 1.The extending use case points to the base use case. 2.The condition and extension point can be shown on the line. Handle Gift Certificate Payment

11. Software Engineering 11 Object-oriented Analysis and Design The generalize Relationship  Can do use case work without this optional relationship m adds another level of complexity to use cases.