OOA/DBilal Hayat ButtA:4 Sept 2014B:2 Sept 2014C:4 Sept 2014

Goals & Scope of Use Case

• What is a proper, valid use case ?– Granularity level

• For Course registration application which one of the following is a proper use case– Verify password– log in– Add a course

EBP Guideline

Use Cases & Goals• Actors has goals (record sale, add course, issue book) and they use computer application to achieve that.

• EBP is therefore a user level goal

• While figuring out use cases try to raise the level of a goal to a user level goal.

Raising the Goal level – Course registration

system…• You: what u want to do with the system• Academics: log in (a sub function)• You: why would you want to login ?(raising the level of goal)• Academics: to add course, find student’s GPA(That’s what user want to do)• You: why would you want to do that ?• Academics: To run the students registration process smoothly

(More of an enterprise level goal and not a user level goal)

Reasonable EBP Violations…

• If there are too many use cases. Sometimes the CRUD (create, retrieve , update & delete) cases are combined to form one use case (Manage User, Maintain Engine). Although they represent four different user goals

• Some times a sub function is repeated in several base use cases.– Log in , Pay by credit

• Though the user goal or business process is somewhat higher

(login to add course, recording a sale and payment is by credit) yet the common sub function is often separated and shown as a separate use case (will be discussed in usecase relationships)

Use Cases Types & Formats

• Black Box– Treats the system as a black box– No information about the internal working of the system

– Focus on what and not how• E.g.

– The system records lending of the book (best)– The system saves the data of the book lender into a file or database (bad)

– the system issues the SQL insert statement. (worst)

Use case types and formats

• Black-box use cases describe system responsibilities, i.e. define what the system must do.

• Uses cases may be written in three formality types– Brief: one-paragraph summary, usually of the main success scenario.

– Casual: Informal paragraph format. Multiple paragraphs describing success as well as alternate course of action

– Fully dressed: elaborate. All steps and variations are written in detail. Two column or a single column format with everything explained

UC Brief Format: Process Sale

A customer arrives at a checkout with items to purchase. The cashier uses the POS system to record each purchased item. The system presents a running Total and line-item details. The customer enters payment information, which the system validates and records. The system updates inventory. The customer receives a Receipt from the system and then leaves with the items.

Usually, writing the stories is more important than

diagramming a use case model in UML

UC Casual Format: Handle ReturnsMain Success Scenario: A customer arrives at a checkout with

items to return. The cashier uses the POS system to record each returned item…

Alternate Scenarios:If they paid by credit, and the reimbursement transaction to their credit account is rejected, inform the customer and pay them with cash.

If the item identifier is not found in the system, notify the cashier and suggest manual entry of the identifier code

If the system detects failure to communicate with the external accounting system… (etc.)

UC Fully-dressed:Process Sale

Use case UC1: Process SalePrimary Actor: CashierStakeholders and Interests:

-Cashier: Wants accurate and fast entry, no payment errors, …-Salesperson: Wants sales commissions updated.…

Preconditions: Cashier is identified and authenticated.Success Guarantee (Postconditions):

-Sale is saved. Tax correctly calculated.…

Main success scenario (or basic flow): [see next slide]Extensions (or alternative flows): [see next slide]Special requirements: Touch screen UI, …Technology and Data Variations List:

-Identifier entered by bar code scanner,…Open issues: What are the tax law variations? …

Main success scenario (or basic flow): The Customer arrives at a POS checkout with items to purchase.The cashier records the identifier for each item. If there is more thanone of the same item, the Cashier can enter the quantity as well.The system determines the item price and adds the item information tothe running sales transaction. The description and the price of the currentitem are presented.On completion of item entry, the Cashier indicates to the POS system that item entry is complete.The System calculates and presents the sale total.The Cashier tells the customer the total.The Customer gives a cash payment (“cash tendered”) possibly greaterthan the sale total.

Extensions (or alternative flows):If invalid identifier entered. Indicate error.If customer didn’t have enough cash, cancel sales transaction.

Fully dressed example:Process Sale (cont.)

Fully Dressed Details…• Stakeholders and Interests

– Important: defines what the use case covers (“all and only that which satisfies the stakeholders’ interests”)

• Preconditions– What must always be true before beginning a scenario in the use case

– (e.g., “user is already logged in”)

Details…[2]• Success Guarantees (Postconditions)– What must be true on successful completion of the use case; should meet needs of all stakeholders

• Basic Flow– Records steps: interactions between actors; a validation (by system); a state change (by system)

Details…[3]• Extensions (Alternative Flows)

– Scenario branches (success/failure)– Longer/more complex than basic flow– Branches indicated by letter following basic flow step number, e.g. “3a”

– Two parts: condition, handling• Special Requirements

– Non-functional considerations (e.g., performance expectations)

Details…[4]• Technology & Data Variations

– Non-functional constraints expressed by the stakeholders

– (e.g., “must support a card reader”)

Essential vs. Concrete style

• Essential: Focus is on intend.– Avoid making UI decisions

• Concrete: UI decisions are embedded in the use case text.– e.g. “Admin enters ID and password in the dialog box (see picture X)”

– Concrete style not suitable during early requirements analysis work.

Use Cases vs. Feature Lists

• Feature Lists: “the system shall…”– More traditional approach– Less preferable for user-oriented s/w– Only mention function, not flow– If flows are written elsewhere, then redundant= hard to maintain in parallel

• High-level feature lists are okay– Include in Vision document– “executive summary of use cases”

Extend / Include UC• Extending use case typically defines optional behavior that is not necessarily meaningful by itself. The extend relationship is owned by the extending use case. The same extending use case can extend more than one use case, and extending use case may itself be extended.

• Including use cases are usually not complete by themselves and require the included use cases.  Include relationship between use cases is shown by a dashed arrow with an open arrowhead from the including (base) use case to the included (common part) use case. The arrow is labeled with the keyword «include».

Use Case – Example (self service machine – extends relationship)

Restoc

k

Close Machine

Open Machine

<<includes>>

<<includes>>

Restock According to Sales

<<extends>>

Use Case – Example (self service machine – generalize relationship): Actor-to-Actor relationship

Supplier Agent

Restocker Collector

generalized actor

specialized actor

Use Case – Example (self service machine – generalize relationship): Actor-to-Actor relationship – example 2

Cook

Mom Cook Father Cook

generalized actor

specialized actor

Library System Use CaseA library contains books and journals. The task is to develop a computer system for borrowing books. In order to borrow a book the borrower must be a member of the library. There is a limit on the number of books that can be borrowed by each member of the library. The library may have several copies of a given book. It is possible to reserve a book. Some books are for short term loans only. Other books may be borrowed for 3 weeks. Users can extend the loans. DRAW USE CASE DIAGRAM

Suppose we want to develop software for an alarm

clock.• The clock shows the time of day. Using buttons, the user can set the hours and minutes elds individually, and choose fibetween 12 and 24-hour display. It is possible to set one or two alarms. When an alarm res, it will sound some noise. fiThe user can turn it off, or choose to ’snooze’. If the user does not respond at all, the alarm will turn off itself after 2 minutes. ’Snoozing’ means to turn off the sound, but the alarm will re again after some minutes of delay. fiThis ’snoozing time’ is pre-adjustable.

• DRAW USE CASE DIAGRAM

Use Case Model serve as an

Input/bases for• the cost and effort estimation. (UCP)• the delivery contract in a particular release. (RUP is Use Case Driven)

• the functional testing process and UAT, helping to assure that the system actually does what it was intended to do

• a reference point to trace back the requirements, hence make it difficult for requirements to fall through the cracks

• the user documentation, conveniently organized in a step-by step format.

Benefits of Use Cases• Use cases are the primary vehicle for requirements capture in RUP

• Use cases are described using the language of the customer (language of the domain which is defined in the glossary) therefore act as an easily-understood communication mechanism

• Use cases provide a concise summary of what the system should do at an abstract (low modification cost) level.

Benefits of Use Cases• They are relatively easy to write and easier to read.

• They force developers to think through the working of a system from the perspective of a user.

• They engage the users in the requirements process:– helping them understand the system that is being proposed.

– giving them a way to communicate and document their needs.

• They give context for the requirements of the system:– One can understand why a requirement is what it is– as well as how the system meets its objectives.

Benefits of Use Cases• They provide an ordering mechanism for requirements:– one can tell what has to happen before the next thing happens, and so on.

• In most circumstances, development team is also involved in writing use cases. That means not only that they actually understand requirements better but also that the developers know they are responsible for determining them.

• It is a critical tool in the analysis process, helping us understand what the system needs to do and how it might go about doing it.

Difficulties with Use Cases

• As functional decompositions, it is often difficult to make the transition from functional description to object description to class design

• Reuse at the class level can be hindered by each developer “taking a Use Case and running with it”. Since UCs do not talk about classes, developers often wind up in a vacuum during object analysis, and can often wind up doing things their own way, making reuse difficult

• Use Cases make stating non-functional requirements difficult (where do you say that X must execute at Y/sec?)

• Testing functionality is straightforward, but unit testing the particular implementations and non-functional requirements is not obvious

KEY POINTS• use cases are not diagrams, they are text. Focusing on secondary value UML use case diagrams rather than the important use case text is a common mistake for use case novices.

• Write usecases at the user goal level.– Use Cases describe WHAT the system will do, but never describe HOW it will be done.

– Use Cases are Analysis Products, not Design Products.• In RUP

– Identify most of the use cases in inception– For 10/20 % high risk or high priority use cases write fully dressed versions

– For the remaining majority write brief versions– Define the majority chunk of remaining use cases during elaboration.

Assignment 2• Submit use case model of CASE STUDY 2 - ATM• Due Date: on slate• Use case modeling of functional requirements.– Describe each step (5 step receipe) in your assignment.

– Use cases (one to two paragraphs, as in example).– Use case diagram that shows complete system desc.– BONUS: Refine your Domain Model from Asgn 1.

• Each use case pass the following test– Boss / EBP Test– Size test