DOC PREVIEW
UT Dallas CS 6359 - Chapters_7_30

This preview shows page 1-2-3-25-26-27 out of 27 pages.

Save
View full document
View full document
Premium Document
Do you want full access? Go Premium and unlock all 27 pages.
Access to all documents
Download any document
Ad free experience
View full document
Premium Document
Do you want full access? Go Premium and unlock all 27 pages.
Access to all documents
Download any document
Ad free experience
View full document
Premium Document
Do you want full access? Go Premium and unlock all 27 pages.
Access to all documents
Download any document
Ad free experience
View full document
Premium Document
Do you want full access? Go Premium and unlock all 27 pages.
Access to all documents
Download any document
Ad free experience
View full document
Premium Document
Do you want full access? Go Premium and unlock all 27 pages.
Access to all documents
Download any document
Ad free experience
View full document
Premium Document
Do you want full access? Go Premium and unlock all 27 pages.
Access to all documents
Download any document
Ad free experience
Premium Document
Do you want full access? Go Premium and unlock all 27 pages.
Access to all documents
Download any document
Ad free experience

Unformatted text preview:

Slide 1What will we learn?Relating Use CasesRelating Use CasesTerminology: Types of Use CasesTerminology: Types of Use CasesThe include RelationshipThe include RelationshipThe include RelationshipThe extend RelationshipThe extend RelationshipSlide 12UML Diagrams – Extend RelationshipSlide 14Other RequirementsSupplementary SpecificationVisionVisionGlossaryDomain RulesEvolving RequirementsA Typical Situation …A Typical Situation …Tips to Capturing Requirements*Tips to Capturing Requirements*Takeaways from Chapters 30 and 7Next …Object-Oriented Analysis and DesignCHAPTERS 30, 7: RELATING USE CASES, OTHER REQUIREMENTS1What will we learn?How to relate use cases to each otherOther requirements, and how to capture them in artifacts2Relating Use CasesOften we need to relate one use case to another, such as the withdrawing money from the ATM and establishing a session on the ATM use casesNote that this does not change the behavior of the system – it’s simply a way to better organize a set of use cases that hopefully makes the system more understandableAlso reduces redundant text, which makes it easier to manage documentation3Relating Use CasesThese relationships are tools that can help organize use cases – they should not be the focus of the use case development effortSpend your time writing text, not debating diagrams and relationshipsKeep in mind, the organization of use cases by relationships may evolve over the iterations (in the Elaboration Phase, for example). It is not worth the effort to try to get all the relationships defined up front – this is Waterfall thinking4Terminology: Types of Use CasesA concrete use case is initiated by an actor and performs the entire behavior desired by the actor to meet a goal. These are the elementary use cases that we have seen earlierAn abstract use case is a use case that is never instantiated on its own; it is always a part of another use case, like a “subfunction” use case. For example, in our POS case study, we may have a Process Sale use case, and a part of that use case may be Handle Credit Payment. The first use case is concrete, the second is abstract, because it is always used as part of another use case. 5Terminology: Types of Use CasesAbstract use cases often evolve later in the iteration process, when it is noticed that certain process steps are repeated in multiple use cases. Fundamental process in developing reusable code: If you see commonly occurring themes (code), abstract out and create sub-classesThe use case that includes another use case (or is extended or specialized by another use case) is called the base use case. The use case that is the inclusion, extension, or specialization is called the addition use case. 6The include RelationshipMost common and importantThis will involve an abstract use case that contains some behavior that is common to several other concrete use casesIf we consider the previous example, we may have something like this in the Process Sale use case:Main Success Scenario1. Customer arrives at POS system with goods/services to purchase…7. Customer pays and System handles paymentExtensions:7a. Paying by credit: Include Handle Credit Payment7b. Paying by check: Include Handle Check Payment7The include RelationshipThe Handle Credit Payment use case would then have its own use case description, complete with Main Success Scenario and ExtensionsUse of the “Include” keyword is optional; it can be left offWhen using included use cases, hyperlinks (either in document or on line) is very usefulThis can also be used to break up a very complex use case into higher level steps which are then detailed in the included use casesThis can also be used to capture branching behavior or asynchronous behavior in the use caseThese are actions that the user may take at any time in main success scenario, and thus are not associated with any particular step8The include RelationshipTo include an asynchronous branch point in a use case, we usually use the following notation:Extensions*a. At any time, the Customer selects to cancel the request: Cancel Request*b. At any time, the Customer selects to return to main menu: Return to Main Menu3 – 10: Customer requests help: Show Help ScreenNote the last extension indicated that this included use case can be instantiated at any time between steps 3 and 10 (inclusive)9The extend RelationshipThis relationship is used to add to a use case that has been more or less frozen for some reasonSometimes expanding or extending a use case is troublesome, and needs to be avoidedUse “Extension Points” to extend the base use case, and then write the subfunction use case separately Process Sale (Base Use Case)…Extension Points: Payment in Step 7…7. Customer pays and System handles payment10The extend RelationshipPay With Gift Certificate (Extended Use Case)…Trigger: Customer wants to use a gift certificateExtension Points: Payment in Process SaleLevel: SubfunctionMain Success Scenario:1. Customer gives gift certificate to the Cashier2. …Note the extended use case refers to the Extension Point, not a numbered step in the base use case - more robust. 1112This diagram shows how to indicate an “include” relationship in a UML diagramNextGen POSCashierCustomerHandle CashPaymentProcess RentalProcess SaleHandle CheckPaymentHandle Returns«include» «include»«include»«include» «include»«include»«actor»AccountingSystem«actor»CreditAuthorizationServiceManage Users...UML notation: the base use case points to the included use caseHandle CreditPaymentUML Diagrams – Extend Relationship13Process SaleExtension Points:PaymentVIP Customer«extend»Payment, if Customer presents a gift certificateUML 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 Payment14This diagram shows how to indicate an “extend” relationship in a UML diagramProcess SaleExtension Points:PaymentVIP Customer«extend»Payment, if Customer presents a gift certificateUML 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 PaymentOther RequirementsIn the UP, there are some other important requirements artifacts other than the Use-Case ModelThese may not be as important to OOA/OOD, but they are needed for the project to succeedOther important artifacts that capture requirements:Supplementary


View Full Document

UT Dallas CS 6359 - Chapters_7_30

Documents in this Course
Lecture2

Lecture2

63 pages

Lecture3

Lecture3

49 pages

Lecture4

Lecture4

48 pages

Lecture5

Lecture5

47 pages

Lecture6

Lecture6

45 pages

Lecture7

Lecture7

63 pages

Lecture8

Lecture8

77 pages

Lecture9

Lecture9

48 pages

Lecture10

Lecture10

84 pages

Lecture11

Lecture11

45 pages

Lecture12

Lecture12

134 pages

Lecture13

Lecture13

62 pages

Lecture14

Lecture14

76 pages

Project

Project

2 pages

Chapter_1

Chapter_1

25 pages

Load more
Download Chapters_7_30
Our administrator received your request to download this document. We will send you the file to your email shortly.
Loading Unlocking...
Login

Join to view Chapters_7_30 and access 3M+ class-specific study document.

or
We will never post anything without your permission.
Don't have an account?
Sign Up

Join to view Chapters_7_30 2 2 and access 3M+ class-specific study document.

or

By creating an account you agree to our Privacy Policy and Terms Of Use

Already a member?