UT Dallas CS 6359 - S5_Chapters30-7 (27 pages)

Previewing pages 1, 2, 3, 25, 26, 27 of 27 page document View the full content.
View Full Document

S5_Chapters30-7



Previewing pages 1, 2, 3, 25, 26, 27 of actual document.

View the full content.
View Full Document
View Full Document

S5_Chapters30-7

216 views


Pages:
27
School:
University of Texas at Dallas
Course:
Cs 6359 - Object-Oriented Analysis and Design
Object-Oriented Analysis and Design Documents
Unformatted text preview:

Object Oriented Analysis and Design CHAPTERS 30 7 RELATING USE CASES OTHER REQUIREMENTS SLIDES BY DR SEMPER 1 What will we learn How to relate use cases to each other Other requirements and how to capture them in artifacts 2 Relating Use Cases Often 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 cases Note 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 understandable Also reduces redundant text which makes it easier to manage documentation 3 Relating Use Cases These relationships are tools that can help organize use cases they should not be the focus of the use case development effort Spend your time writing text not debating diagrams and relationships Keep 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 thinking 4 Terminology Types of Use Cases A 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 earlier An 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 5 Terminology Types of Use Cases Abstract 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 subclasses The 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 6 The include Relationship Most common and important This will involve an abstract use case that contains some behavior that is common to several other concrete use cases If we consider the previous example we may have something like this in the Process Sale use case Main Success Scenario 1 Customer arrives at POS system with goods services to purchase 7 Customer pays and System handles payment Extensions 7a Paying by credit Include Handle Credit Payment 7b Paying by check Include Handle Check Payment 7 The include Relationship The Handle Credit Payment use case would then have its own use case description complete with Main Success Scenario and Extensions Use of the Include keyword is optional it can be left off When using included use cases hyperlinks either in document or on line is very useful This can also be used to break up a very complex use case into higher level steps which are then detailed in the included use cases This can also be used to capture branching behavior or asynchronous behavior in the use case These are actions that the user may take at any time in main success scenario and thus are not associated with any particular step 8 The include Relationship To 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 Menu 3 10 Customer requests help Show Help Screen Note the last extension indicated that this included use case can be instantiated at any time between steps 3 and 10 inclusive 9 The extend Relationship This relationship is used to add to a use case that has been more or less frozen for some reason Sometimes expanding or extending a use case is troublesome and needs to be avoided Use 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 payment 10 The extend Relationship Pay With Gift Certificate Extended Use Case Trigger Customer wants to use a gift certificate Extension Points Payment in Process Sale Level Subfunction Main Success Scenario 1 Customer gives gift certificate to the Cashier 2 Note the extended use case refers to the Extension Point not a numbered step in the base use case more robust 11 NextGen POS Process Sale Cashier include 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 include actor Credit Authorization Service Process Rental Handle Returns Manage Users This diagram shows how to indicate an include relationship in a UML diagram 12 UML Diagrams Extend Relationship Process Sale Extension Points Payment VIP Customer extend Payment if Customer presents a gift certificate Handle Gift Certificate Payment 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 13 Process Sale Extension Points Payment VIP Customer extend Payment if Customer presents a gift certificate Handle Gift Certificate Payment 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 This diagram shows how to indicate an extend relationship in a UML diagram 14 Other Requirements In the UP there are some other important requirements artifacts other than the Use Case Model These may not be as important to OOA OOD but they are needed for the project to succeed Other important artifacts that capture requirements Supplementary Specification Most non functional requirements like reporting packaging documentation etc Glossary Terms and Definitions Vision High level system description Business Rules Rules that may transcend the current project i e tax laws etc 15 Supplementary Specification Look for requirements information and constraints not easily captured in the use cases or Glossary Use FURPS In particular look for Usability Reliability Performance and Supportability requirements These are known as the Quality Requirements This will be important when we get to architecting the system architectural analysis and design are largely


View Full Document

Access the best Study Guides, Lecture Notes and Practice Exams

Loading Unlocking...
Login

Join to view S5_Chapters30-7 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 S5_Chapters30-7 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?