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 - Customer  list products, order products, accept payment Actor - Sales agent  list products, order products, accept payment, calculate commission Can have a general actor – Purchaser Actor Generalization

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

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

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

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]