Adv Use cases Actor generalization general and special

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

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

• 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)

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

• • 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

• The client use 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

• Issue. Fine 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

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

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

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-cases Each 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. .

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?

• 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? "

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]