Adv. Use cases

1. Adv. Use cases • Actor generalization – general and special actors • Use case generalization – general and special use cases • Include and extend relationships among use cases • Keep these simple – and use only to enhance clarity

2. Actor Generalization • Actor - Customer  list products, order products, accept payment • Actor - Sales agent  list products, order products, accept payment, calculate commission • Can have a general actor – Purchaser

3. Abstract Actor - Purchase  list products, order products, accept payment • Concrete actor - Customer and Sales agent are derived from Purchaser • Concrete actor - Sales agent  calculate commission • (unique to sales agent)

4. Use-case generalization • One use can be a specialization of another use case • Use only to add clarity to your diagram • Child inherits all properties – but cannot override relationship and attribute • An abstract use case may have incomplete or empty event flow • The child use case is precise

5. Find product is a general use case • Find books is a specific case • Find cds is another specific case • We can have other use cases as and when identified • Many use cases may involve a common sequence of event flow • We can then write a separate use case for this common sequence • And then include it whenever it is needed

6. The client use case calls the supplier use case as appropriate • Find employee details is a supplier use case • Change employee details, view employee details, delete employee details, etc. are client use cases • Some supplier use cases can be used to extend client use case • Extension are new add-on behavior and are not necessary for completeness of use case

7. IssueFine for overdue book can be a supplier use case • Can be used in a return books use case as an extension • Multiple versions of extension may be useful and pluggable • Clarity is the key to all analysis and design diagrams • Maintain glossary of terms as you develop them

8. Use-case Engineering • Develop top-level readable use-case descriptions. This should include actors involved and success criteria. • Identify alternate situations and descriptions of events thereof. • Capture the actor's intention, not the user interface details. • Have an actor pass information, validate a condition, or update state. • Write between-steps commentary to indicate step sequencing (or lack of). • Specify data names and descriptions as required

9. Focus • User/Actor intent and objective • Is-a relationship may indicate general-special actors or general-special use-cases • Common steps/events in a different use-cases may be identified as include use-cases • Useful – optional steps – may be identified as extension use-cases

10. Writing Use-cases • Name the system scope. • Brainstorm and list the primary actors. Find every human and non-human primary actor, over the life of the system. • Brainstorm and exhaustively list user goals for the system. • Select one use-case at-a-time to expand. Write narrative to learn the material. • Write the main success scenario (MSS). Use 3 to 9 steps to meet all interests and guarantees. • Brainstorm and exhaustively list the extension conditions.Include all that the sytsem can detect and must handle. • Write the extension-handling steps – as use-casesEach will end back in the MSS, at a separate success exit, or in failure. • Extract complex flows to sub use cases; merge trivial sub use cases.Extracting a sub use case is easy, but it adds cost to the project. .

11. Process • Use Case Title • Is it an active-verb goal phrase that names the goal of the primary actor? • Can the system deliver that goal? • Primary Actor • Does he/she/it have behavior? • Does he/she/it have a goal against the System under Discussion - that is this a service promise of the System? • Preconditions • Are they mandatory, and can they be set in place by the System • Is it true that they are never checked in the use case? • Main Success scenario • Does it have 3-9 steps? • Does it run from trigger to delivery of the success guarantee? • Does it permit the right variations in sequencing?

12. Each Step in Any • Is it phrased as a goal that succeeds? • Does the process move distinctly forward after its successful completion? • Is it clear which actor is operating the goal--who is "kicking the ball"? • Is the intent of the actor clear? • Is the goal level of the step lower than the goal level of the overall use case? Is it, preferably, just a bit below the use case goal level? • Are you sure the step does not describe the user interface design of the system? • Is it clear what information is being passed in the step? • Does it "validate" as opposed to "check" a condition? • Extension Condition • Can and must the system both detect and handle it? • Is it what the system actually needs? • Overall Use Case Content • To the sponsors and users: "Is this what you want?“ • To the sponsors and users: "Will you be able to tell, upon delivery, whether you got this?“ • To the developers: "Can you implement this?"

13. Guide • Avoid pronouns when there may be more than one actor • Avoid adverbs or adjectives • Avoid negatives • Describe in present tense format • Every event should have a meaningful response • Has to be coherent set of steps • Subject verb object [propositional phrase]