Object-oriented Analysis and Design Chap 30 Relating Use Cases Software Engineering 1
Object-oriented Analysis and Design The include Relationship 1 q q q 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 UC 1: Process Sale m Main Success Scenario: w 1. Customer arrives at a POS checkout with goods and/or services to purchase w. … w 7. Customer pays and System handles payment. … m Extensions: w 7 b. Paying by credit: Include Handle Credit Payment. w 7 c. Paying by check: Include Handle Check Payment. … UC 7: Process Rental m Extensions: w 6 b. Paying by credit: Include Handle Credit Payment. Software Engineering 2
Object-oriented Analysis and Design The include Relationship 2 q UC 12: Handle Credit Payment m Level: Subfunction m Main Success Scenario: w 1. Customer enters their credit account information. w 2. System sends payment authorization request to an external Payment Authorization Service System, and requests payment approval. w 3. System receives payment approval and signals approval to Cashier. m Extensions: w 2 a. System detects failure to collaborate with external system: - System signals error to Cashier. - Cashier asks Customer for alternate payment. Software Engineering 3
Object-oriented Analysis and Design The include Relationship 3 q q q 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. UC 1: Process Foo. Bars m Main Success Scenario: m… m Extensions: w a*. At any time, Customer selects to edit personal information: Edit Personal Information. w b*. At any time, Customer selects printing help: Present Printing Help. w 2 -11. Customer cancels: Cancel Transaction Confirmation q q 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. Software Engineering 4
Object-oriented Analysis and Design The include Relationship 4 Next. Gen POS Process Sale Cashier «include» «actor» Accounting System «include» Customer Handle Check Payment «include» UML notation : the base use case points to the included use case Handle Cash Payment «include» Handle Credit Payment «actor» Credit Authorization Service «include» Process Rental Handle Returns Manage Users. . . Software Engineering 5
Object-oriented Analysis and Design Concrete/Abstract Use Cases q 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. q 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. Software Engineering 6
Object-oriented Analysis and Design Base/Addition Use Cases q 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. q Addition use case m be an inclusion, extension, or specialization. Handle Credit Payment is the addition use case in the include relationship to Process q Sale. Addition use cases are usually abstract. Base use cases are usually concrete. Software Engineering 7
Object-oriented Analysis and Design The extend Relationship 1 q q 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. UC 1: Process Sale (the base use case) m Extension Points: VIP Customer, step 1. Payment, step 7. m Main Success Scenario: w 1. Customer arrives at a POS checkout with goods purchase w. … w 7. Customer pays and System handles payment. … q and/or services to UC 15: 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: w 1. Customer gives gift certificate to Cashier. w 2. Cashier enters gift certificate ID. Software Engineering 8
Object-oriented Analysis and Design The extend Relationship 2 q 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. q Practically motivates using the extend technique q when it is undesirable for some reason to modify the base use case. q Software Engineering 9
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 Software Engineering 10
Object-oriented Analysis and Design The generalize Relationship q Can do use case work without this optional relationship m adds another level of complexity to use cases. Software Engineering 11
Скачать презентацию Object-oriented Analysis and Design Chap 30 Relating Use
70ba70238f61da3dcb6399743c210940.ppt