Jan R. McFadyen1 Use Case development As analysis proceeds, you recognize commonality amongst the Use Cases that you will abstract out into common Use Cases, and complexity due to error handling and alternative flows that may be placed in extensions to the basic Use Cases There are no binding rules here, except for the one that tells you to create concise, clear, understandable, easy-to-read, and correct specifications!

Jan R. McFadyen2 Extends Originates because of thoughts like: What could go wrong here? How might this work out differently? Includes Occur when you have a chunk of behaviour that is similar across more than one use case and you don’t want to keep copying the description of that behaviour Use Case relationships: extends, includes, generalization

Jan R. McFadyen3 Use Case - Include Used to factor out behaviour to create reusable parts simplifies descriptions, but diagram becoming more complex for user comprehension a refinement where some design decision is being made BookBorrower Extend loan Borrow copy > Check for reservation >

Jan R. McFadyen4 Use Case - Include Perhaps each user must be validated BookBorrower Extend loan Borrow copy > Validate user >

Jan R. McFadyen5 Use Case - Include Cashier Process Sale Handle Cheque Payment > Handle Cash Payment > Handle Credit Payment Process Rental >

Jan R. McFadyen6 Use Case - Extend Used for “unusual” cases a refinement where some design decision is being made The target Use Case extends the source Use Case at a given extension point the association goes from the exceptional to the more general BookBorrower borrow copy refuse loan > Main Case Subsidiary Case