1

Notes: 004 Use Cases

CS/SE3430 / CS5430 - Object-Oriented Analysis and Design

Use Cases

Read Chapters 7 and 8 of Using UML

Issue: How do we systematically capture requirements?

Just asking stakeholders will produce random coverage of a domain.

Use Cases Centric approach provides a mechanism for systematically capturing large related segments of domain requirements from the users perspective in the form of scenarios. Most stakeholders know how they interact or will interact with a system, or what needs a system must satisfy.

By capturing large related chunks of specification, we are less likely to miss significant parts than we would be by dealing with individual requirements.

If we have the large chunks it is easy to fill in the missing gaps.

Use Cases modeling helps in more than four ways

1. Capturing requirements

2. Planning iterative development

3. Validating systems

4. Verifying systems

Developed by Ivar Jacobson

Use Case Model/Diagram and Scenarios

The use case centric approach is composes of diagrams and scenarios.

Use Case Scenarios are short stories written in a specific format that define how the system is used. Sometimes these are called use case flows.

Diagrams provide an abstraction of how uses cases interact with each other and the users of the system

Use Case Diagram

Two components , Actors and Use Cases. See Figure 7.2 on page 94

Actors:

Represented by stick people in the model

Someone or something that the system interacts with. Can be a person, another system, but generally NOT a group.

Has a role in or with the use case

Identifying human actors:

Dont specify individuals, but the roles they play in the domain

Example: dont use Bubba, but use Bubbas role as a Bank Customer.

Roles each unique actor role is represented by an Actor even if the different roles are played by the same individual.

Non-human actors: allows abstraction of other systems that interact with our system. This simplifies the model, in that we dont need to get into the details of other systems.

Use Case

Represented by an oval in the model.

A use case represents a sequence of actions or steps a system performs that yields an observable result of value to a particular actor.

An action is a procedure that is invoked when an actor provides a signal to the system or when the system is triggered (example a time out occurs). An action is atomic it is performed entirely or not at all.

Use verb phases to name Use Cases (WithdrawMoney, CheckoutBook, OrderPizza, EatLunch, TakeOutTheGarbage, etc.) Do not use nouns (Withdrawal, Book Checkout, Pizza Order, Lunch, )

Scope of a Use Case can be controlled by the following guidelines:

An observable result of value an actor should not need to perform several use cases to achieve something useful.

This provides guidance for keeping the level of granularity high enough.

Example1: Entering ones PIN in an ATM machine does not provide something meaningful to the actor, an ATM Bank Customer who is withdrawing money.

Example2: Taking a picture with a camera ( aiming, focusing, clicking the button) is at a good level in that it produces something of value for the Actor, whereas just clicking the button of the camera (alone) is not sufficient.

A particular actor forces the value of a use case to be relevant to a specific user or small class of users.

This provides guidance for keeping the level of granularity low enough.

Example: A Use Case should not include all transactions of an ATM machine (WithdrawMoney, PayBills, PayLoan, BuyStocks, ) as most Actor instances will never use all of these use cases.

Use Case Diagram:

A use case diagram relates the actors and use cases for a system or subsystem.

Actors are connected to Use Cases by non-directed lines.

Earlier versions of Use Cases used directed lines in order to show participation receive benefit, provide signals, etc.

One way of developing Use Cases:

1. The list of Use Case titles that your team has developed are the starting point for further development.

2. Next, you identify the actors (roles) for each of the use cases. Identify all actors that need to use (interact with) a use case or receive benefit from it.

Alternatively, you can identify all of the actors and then identify the use cases with which they interact. Note the book suggests this method.

Identifying the users for a use case should be easy (if it's not, watch out we may have a bad use case!)

Identifying non-human actors is trickier

What's an external system? keyboard? Internet? Another Computer?

Alternative sets to include:

include all external systems that this system must get data from or supply data to

include those which initiate a contact

include those which get value from the contact

Why exclude most some non-human actors?

end up analyzing portions that are well outside scope

example: for an ATM the posting payments to customer accounts at a bank. We should not go this deep, just use the main bank and not go deeper.

For future planning:

Assess how much each actor needs a particular use case.

Identify any known risks associated with each use case.

Provide a first rough estimate of cost to implement each use case.

This will help prioritize the Use Cases. This will help in sorting out what is or is not needed in Phase I or Iteration I of the Project. Do the most needed first. Which use cases would the user most want to see early?

May want to start early on the more risky use cases to allow time to work things out.

May help to identify which real people are associated with each actor. This can help with elaborating use case flows. Go to the individuals to get their perspective on a use case.

System boundaries a big system can be subdivided into subsystems. Rectangular boxes, UML Packages, are used to separate the subsystems of use cases.

Once this is done, one can start elaborating the use cases (see Use Case Flow of events below).

Look at library system in the book, page 94.

List the Use Case Titles: ReserveBook, BorrowCopyOfBook, ReturnCopyOfBook, ExtendLoan, BorrowJournal, ReturnJournal, UpdateCatalog, BrowseForBook, ReturnBooksToShelf, PurchaseNewBooks, InventoryBooks, PutBookOnReserve, BarrowReserveBook, ReturnReserveBook, CheckOutCD, ReturnCD,

Identify Actors for each use Case:

Use Case (Flow of Events or Scenarios)

Capture the details of WHAT a use case should do. Use cases can replace low-level requirements or augment low-level requirements by showing how they function altogether.

A scenario defines a process from the users point of view.

Written in concise steps from a users / actors perspective.

Domain terms must be consistently defined in the project glossary.

Example: Withdraw Money from an ATM (Note: I have capitalized Actor Names)

1. The use case begins when the Client inserts an ATM card.

2. The System reads the information on the ATM card

3. The System validates the information read from the ATM card.

4. The System prompts for PIN.

5. The Client enters PIN.

6. The System validates PIN.

7. The System asks which operation the Client wishes to perform.

8. The Client selects Cash withdrawal

9. The System prompts for the amount to withdraw.

10. The Client enters amount

11. The System displaces account types (checking, saving, credit) and requests the Client select one for withdrawal

12. The Client selects the account type

13. The System communicates with the ATM network to validate account ID, PIN, and availability of the amount requested.

14. The System asks the Client whether he/she wants a receipt.

15. The System asks the Client to withdraw the card. (This is a security measure to ensure that Clients do not leave their cards in the machine.)

16. The Client withdraws the card.

17. The System dispenses the requested amount of cash.

18. The System prints a receipt.

19. The Client pulls out the receipt.

There are various paths through this use case based on

Input from the Client: (can cancel at anytime, want a receipt, which account, etc.)

Internal state of the System: (out of paper for receipt, too little cash in ATM, etc.)

Time-outs and errors: (System may cancel transaction on a timeout for Client action, network response, repeated wrong PIN, bad ATM card, etc.)

Each instance, represents unique path, and is called a Use Case Scenario. The set of all scenarios is a use case (class).

Sunny Day Scenario term used to refer to the primary, everything goes smooth, path through a use case.

Rainy Day Scenario any path that deviates from the sunny day.

EX: paper jam in the ATM machine. Machine is out of money. Non-valid PIN entered, etc. What do we do under these exception cases?

Scope of a use case

What is too little and what is too much for a single use case.

We could combine all ATM transactions into a single use case (Withdraw, Deposit, Transfer, Pay Loan, etc.).

This would provide multiple observable results for an actor, therefore not a good idea.

Also, subclasses of actors may never use all of these transactions. Has anyone used the Pay Loan use case?

This is too large!

We could break the Withdraw use case into multiple use cases, Read Pin, Validate Pin, but each of these alone do not provide an observable of result of any real value to any actor.

This is too small.

Focus on finding things of value that a system provides to its actors

How detailed should the steps be?

Until there is agreement among stakeholders (users, testers, designers, developers, etc.) with respect to what a use case means.

Organization of Use Cases Some huge systems may have 1000s of use cases.

Biggest system I worked on probably approached around 5,000 use cases.

There were about 50 subsystems each with about 100 use cases.

Use Case Package in larger systems one needs to group similar use cases together to help people access and analyze them. Systems, Subsystems, Subsubsystems, seem to provide natural container boundaries.

Usually a good size range in package will have from 5-20 Use Cases.

Packages can contain other Packages.

Subflows A main use case may be subdivided into several (alternative) subflows. This is generally done when the same set of steps is common to multiple main use cases. The concept is similar to a reusable function/procedure in a programming language.

UML 1.3 had two constructs for subflows, Uses and Extends .

Uses common steps that are ALWAYS executed in one or more use cases. Simply done for reuse of common concepts (code, doc, tests, ). EX: StartATM_Session, ReadCard, and EnterAndValidatePIN are common to all ATM functions (Withdraw, Deposit, Transfer, PayLoan, etc.). We could make a Uses use case of UserAuthentication.

Extends common steps that are CONDITIONALLY executed in one or more use cases. Done primarily to simplify the flow of scenarios. EX: what processing shall be done when user enters a bad PIN 3 times. OR. Adding the non-standard telephone services (CallWaiting, CallForwarding) to a standard 2-party call.

UML 1.4 has three constructs for subflows; Inclusion, Extension, Generalization/Specialization

Inclusion is the same as Uses, common steps that are ALWAYS executed in one or more use cases. The flow of a use case is incomplete if the Inclusion is not present.

Extends non-standard processing the EXTENDS of UML 1.3. The point at which an extends attaches to another Use Case is called the Extension Point

Generalize/Specialize modifications of a use case to suit a more specialized function. The steps are generally the same as a class of use cases, but there may be more attributes involved. Also, generalize/specialize can be applied to Actors.

Non-functional Requirements requirements that relate to concurrency, performance, reliability are generally not covered by use cases. This is why we may need System Level requirements to cover this aspect.

Validation Walking a use case. Stakeholders act out the use case flows to determine whether they are valid.

Use Case Scenarios/Flows Rules of Thumb

Effective Use of Language in Use Cases, By Kendall Scott

http://www.requirementsnetwork.com/sites/requirementsnetwork.com/files/Effective%20Use%20of%20Language%20in%20Use%20Cases.pdf

Use active voice, and speak from the actors perspective

The customer selects the item

NOT The item is selected by the customer // this is passive voice

Use present tense

The customer selects the item.

NOT The customer shall select the item // future tense

or The customer selected the item // past tense

Often times we use the future tense for requirements see future tense above.

Express your text in the form of call and response.

The text should reflect the fact that the actor performs some action(s) and the system responds accordingly

The System prompts for a PIN. (CALL) and

The Client enters a PIN. (RESPONSE)

Keep the use case short

The use case should address one functional requirement, or perhaps a small set of requirements, and do it in a way that is obvious to anyone who reads it.

Note that we may be using Use Cases rather than writing requirements and that we are using one functional requirement as a unit of measure rather than a concrete entity.

Each use case should be a small, mobile unit that lends itself to possible reuse in other contexts.

Establish the initial context

You have to specify where the actor is, and what he or she is looking at, at the beginning of the use case. There are two ways to do this.

1. The first way involves specifying the context as part of the first sentence/step: The Accountant enters his or her user ID and password on the System Login page,

2. The second way involves defining a precondition: The Accountant is looking at the System Login page or The system is displaying the System Login page.

Dont do both and be consistent from use case to use case.

Make sure that each use case produces at least one obvious result of value to one or more actors, even if that result is negative.

A use case cant just end floating in spacesomething measurable has to happen. Of course, this is generally some positive result: The actor is logged in to the system, The system creates an Order, The system generates a report.

Some like to specify this as a postcondition dont do it in both the last step of a use case and in a postcondition (this would be redundant).

Write your alternate courses rainy day scenarios the same way you write your basic course, except of course that alternates have the word if.

Signal the presence of an alternate course involves using words such as validates, verifies, ensures, or checks.

The system verifies that the credit card number the Customer entered matches one of the numbers it has recorded for that Customer, this begs the question Well what happens if the verification fails?

If the system does not match the entered credit card number to any of its stored values, then it displays an error message and prompts the Customer to enter a different number.

Simplify, simplify, simplify.

If a (sober) person off the street cant read this and understand it right off the bat in 30 seconds, theres something wrong with it.

Right off the bat means that your reader should not be slowed down by unfamiliar acronyms, unclear jargon, sloppy verbiage, or, especially, Using Big Words Where Little Words Will Do Just Fine Syndrome.

Rowes version, Should be simple enough for your grandmother to understand

End goal of Use Cases

This is a device to capture requirements in ways that the people building the system will understand and be able to run with. Its a means to an end, not the end in itself

Use cases are the input artifact for many other process tasks: Design, Coding, Test Generation, Documentation, Maintenance, Consider what information is necessary to complete these future project tasks.

Possible Problem with Use Cases (according to Stevens)

Use Case centric approach will end up with a non-object oriented system. The author states that developers may rush to develop the use cases, which are procedural in nature, without bothering to develop objects. This leads to code that is difficult to maintain.

My opinion, this is more of a process problem and this situation is just as likely to occur with straight requirements.

There is a danger of mistaking design for requirements. Use case flows are generally written as very concrete procedures from a users perspective. Requirements engineers may not consider better ways of providing the same or better functionality.

My opinion, this is no different from capturing straight requirements. Use Cases flows can often help stakeholders see better procedures. Use cases have been used for non-software systems to optimize people organizations, factories, etc. Until a process is modeled, it is hard to optimize it.

Author approach of specifying actors and then their needs may result in missing critical requirements.

My comment, sometimes it is also useful to start with use case titles (features) and then identify actors.

The approach one takes may depend on how well you know a domain. If you know a domain, it may be better to start with Use Case titles.

Systematic Development of Use Cases

Start with a casual format and successively refine them into a more formal (dressed up) style. The projects needs determine what is formal enough. (The following material is from Cockburn, A., Writing Effective Use Cases, Addison-Wesley, 2004 this is a great book with lots of practical ideas on Use Case centric development.)

Task-Level Goal List Step One

1. Identify actors,

2. Identify goals of each of the actors in the form of short verb phrases,

ATM_Customer Withdraws money

ATM_Customer Checks money market account balance

ATM_Machine Runs built in test (BIT)

ATM_Machine Authorizes the ATM_Customer

. . .

3. Optionally one may add another column indicating what triggers an event/goal. For instance Run build-in-test may be triggered by an ATM_Customer starting any kind of transaction, and also periodically trigged by a timer (once an hour maybe).

4. Once a sizable number of goals have been defined, it is beneficial to prioritize them. Users and Requirements engineers arrive at priority. The priority may relate to a development release or iteration.

5. Optionally, may also want to add a column that indicates whether a goal is within the scope of a project. Or for large systems we may define to which subsystem the use case is belongs.

Task-Level Goal List

ACTOR

Task-Level Goal

Priority

Trigger

Within Scope**

Bank_Clerk

Produce ATM cards

User selected

NO

ATM_Customer

WithdrawMoney (ourBankCustomer)

2

User selected

YES

ATM_other BanksCustomer

WithdrawMoney (anotherBanksCustomer)

3

User selected

YES

ATM_Customer

CheckMoneyMarketAccount balance

3

User selected

YES

ATM_Machine

RunBuiltInTest (BIT)

1

Timer, transactions,

Maintenance subsystem

ATM_Machine

AuthorizeATM_Customer

1

Transactions

Security subsystem

ATM_Customer

Open new bank accounts

User selected

NO

. . .

** For large Systems, use the subsystem name for the Within Scope col.

The Task-Level Goal list can be very useful in:

Defining the scope of your current project,

Planning multiple iterations.

For planning iterative phases, we can also concentrate on high priority goals first.

Sometime it makes sense to do some lower priority items first because they will make other items easier to implement/test/

All stakeholders can quickly see the candidate goals for the system and negotiate priorities. . .

Use Case Briefs (not formal attire) Step Two

A use case brief is the next step. It consists of a couple (2 to 6) sentences, which describe the use case behavior. It includes only the most import activities and failures. In addition to getting agreement on what is important for a use case, a brief can also help initial estimates of effort. They can also be useful in selecting COTS components at this early stage.

Use Case Brief

Actor

Goal

Brief

ATM_Customer (ourBankCustomer)

WithdrawMoney (ourBankCustomer)

An authorized ATM_Customer specifies the amount of money they wish to withdraw from one of their accounts. They receive the money, deduct this amount from their balance, and print a receipt. If they do not have enough money in their account, under some circumstances they may be able to receive a loan.

ATM_Customer (anotherBankCustomer)

WithdrawMoney (anotherBankCustomer)

The ATM machine makes electronic contact with another bank to authorize that the ATM_Customer can withdraw a specified amount of money from one of their accounts. They receive the money, deduct this amount from their balance, and print a receipt. If they do not have enough money in their account, under NO circumstances will they receive a loan.

ATM_Machine

RunBuiltInTest (BIT)

The ATM machine runs the BIT to determine the functionality of all the ATM subsystems. The ATM machine runs the BIT on both a configurable time schedule and at the beginning of each customer transaction. The results of the BIT determine which transactions are allowed. Some subsystems need not be functional for some of the transaction types (for instance the printer is not needed for withdrawing money).

Design Scope Step Three

Defines the context for our system. It sometimes is called a context diagram. An ATM consists of all of the software and hardware in the box. The box is linked to a communications network, the network is linked to the ATMs home bank computers, the home bank computers are linked to other banks computers and so on.

This helps explicitly define the scope of the system for all stakeholders.

It is also useful in identifying and defining which subsystem of a large subsystem a use case belongs.

It also helps define which interfaces need to be defined

For larger system, we represent each subsystem as a block and specify which use cases belong to each subsystem.

Produce a detailed Use Case Diagram Step Four

From the Use Case Briefs and the Use Case Context Diagram produce a detailed Use Case Diagram showing all of the Actors and Use Cases within the scope of the system. Use Packages to organize these use cases into logical Subsystems, subsubsystems,

This diagram will continue to be modified as the next step is performed, as in step five you will find opportunity to and subflows.

Use Case Flows or Scenarios Step Five

There are many formats used to specify the detail flows of use cases. Generally, the format is based on the level of formality needed for the particular project. The Style and Form are generally refined based on project and company needs.

Here is an example of a formal Use Case once again, not All Fields are necessary for all projects.

Label : UC_WdMonOC

TITLE : Use Case: WithdrawMoney(our customer) : Withdraw money from ATM (our bank customer)

PRIMARY ACTOR: ATM customer (CUSTOMER)

SECONDARY ACTOR(s): ATM machine (ATM)

GOAL IN CONTEXT: ATM customer receives funds from an ATM machine

SCOPE: {{Subsystem Name if this were a bigger system}}

LEVEL: main/detail, extends/includes

STAKEHOLDERS and INTERESTS:

ATM customer (CUSTOMER): desires money, desires security of access to his/her account

BANK: desires authentication that customer is a bank customer and has funds to cover withdrawal; desires that ATM machine remains secure.

PRECONDITION: Our bank customer must have ATM card

TRIGGER: User starts transaction by inserting an ATM card

MAIN SUCCESS SCENARIO:

1. Customer inserts ATM card.

2. ATM runs BIT.

3. ATM reads information on the card.

4. ATM validates information on the card.

5. ATM displays prompts for PIN.

6. Customer enters PIN.

7. ATM validates PIN by checking a MD5 hash.

8. ATM displays prompt asking Which operation do you want to perform?

9. Customer selects Cash withdrawal

10. ATM displays prompt for amount to withdraw.

11. Customer enters amount

12. ATM displays prompt requesting from which account to withdraw.

13. Customer selects the account type (checking, saving, credit).

14. ATM communicates with the ATM network to authorize user by validating account ID, PIN, and availability of the amount requested.

15. The ATM displays prompt asking the Customer whether he/she wants a receipt.

16. ATM asks the client to withdraw the card.

17. Customer withdraws the card. (This is a security measure to ensure that Customers do not leave their cards in the machine.)

18. ATM sends a message over the ATM Comm link to the main bank computer commanding that the amount to be dispensed is deducted from the Customers account.

19. ATM dispenses the requested amount of cash.

20. ATM prints receipt.

21. The use case ends.

EXTENSIONS: (Note: often extensions are complex. You will want to define the entry level condition here and reference the label for the Extension Use Case following the entry condition.)

2a. If BIT fails ATM displays out of order message to user and sends message to main bank computer requesting service. (see UC_RequestService)

4a. If ATM cannot validate information on card the ATM displays message that indicates bad card and halts scenario. (see UC_RejectCard)

7a. If ATM cannot validate PIN the ATM keeps the card, displays a message that indicates PIN failure, and then halts scenario. (see UC_RejectPin)

11a. If the ATM does not have sufficient funds to cover withdrawal, a message indicating this and the maximum amount that can be funded is displayed to the CUSTOMER and then the Scenario is restarted at step 9.

14a. If the Customer does not have sufficient funds, but has more than $20, the ATM displays the maximum amount the user can withdraw and the Scenario is restarted at step 9.

14b. If the Customer has less in their account than the minimal amount that the machine can fund, then the ATM displays a message indicating this and the Scenario is halted after the card is ejected.

15a. This step is performed only if there is paper left to print the receipt.

20a. Receipt is printed only if Customer requests one.

Inclusions:

2a. RunBIT the BIT will be run for each transaction and includes: UC_CheckPower, UC_CheckPrinter, UC_CheckTamper, UC_CheckMoney, UC_CheckCommLink,

4a. AuthenticateUserCard checks the information on the card against bank records to make sure the user has an account from which they may perform a transaction.

. . .

ISSUES and TBDs:

a. Maximum withdrawal amount

b. Minimum withdrawal amount

c. Timeout interval for canceling session.

d. Maximum number of withdrawal transactions per 24 hour period.

e. . . .

TRACING TO SYSTEM-LEVEL REQUIRES:

R-Security-023

R-Security-064

. . .

RELATED USE CASES:

UC_Deposit

KNOWLEDGE SOURCE: where did the information come from like: Bobob the bank VP in charge of nickels.

REQUIREMENTS ENGINEER: Bertha

REVISION HISTORY:

Created: Who and when

Reviewed: Who and when engineers name/ customers name

Revised: Who and when engineers name

Revisions Reviewed: Who and when engineers name

Signed Off: Who and when customers name

. . .

Collecting Data Requirements

It is often useful to collect data requirements as we develop our use cases. Historically data dictionaries contained information about the type, range, relationships and usage of data in a system. We may want to consider modifying this approach. Keith Matthews (2006) published a set of ideas in the Requirements Network Group http://www.requirementsnetwork.com/user_registration?destination=trackerlite that with a little modification (by me) seems to provide good utility. This new approach contains two different sets of tables.

Detailed Entity Table

While we are capturing use case flow, it is generally also a good time to capture details about data entities. This will help all stakeholders come to a common understanding of the data entities and the relationships among the entities. Below are data that might be useful to capture at this time.

Category

Information Categories

Entity

Name, Definition, Notes, Volumetrics, Attributes, Relationships

(Associations), Specific Business Rules, .......

Attributes

Name, Definition, Notes, Cardinality, Data Type, Length, Precision,

Volumetrics, Value Domain, Minimum, Maximum, Calculation,

Specific Business Rules, Default Value, Order, Security Considerations, .......

Associations

Name, Entities it relates, Cardinalities, Navigability, .......

If a lot of the above information would be useful for a project, a database of spreadsheet would be the suitable mechanism for maintaining it. Below is a simple example using a table to maintain a few of the information categories.

Detailed Entity Table

Entity / Type

Description

Customer

A person with an account at the bank

Attributes

Definition

Sensitive

Type

Length

firstName

The first name of the Customer

No

Text

25

lastName

The last name of the Customer

No

Text

25

SSN

Social Security Number

Yes

Text

9

driversLicenseNumber

A drivers license number

Yes

Text

12

driversLicenseState

State that issued drivers license

No

Text

2

creditLimit

Upper borrowing limit for this Customer

Yes

Money

11.2

dateOfBirth

Date of birth of the Customer

Yes

Text

YYYYMMDD

PIN

Personal Identification Number

Yes

numeric

nnnn

motherMaiden

Mothers Maiden name

Yes

text

24

Relationships

Business Rule

marriedTo

A Customer may be married to zero or one Spouse

parrentOf

A Customer may be the parent of zero, one or more Child

accountsOf

A Customer may have one or more Accounts

accountIssuranceMax

A Customer is insured for up to a maximum total across all Accounts of $1,000,000 by the F.D.I.C.

Entity / Type

Description

Spouse

A person to whom a Customer is married.

Attributes

Definition

Sensitive

Type

Length

firstName

The first name of the Spouse

No

Text

25

lastName

The last name of the Spouse

No

Text

25

SSN

Social Security Number

Yes

Text

9

driversLicenseNumber

A drivers license number

Yes

Text

12

driversLicenseState

State that issued drivers license

No

Text

2

dateOfBirth

Date of birth of the Customer

Yes

Text

YYYYMMDD

PIN

Personal Identification Number

Yes

numeric

nnnn

dateOfBirth

Date of birth of the Customer

Yes

Text

YYYYMMDD

motherMaiden

Mothers Maiden name

Yes

text

24

Relationships

Business Rule

marriedTo

A Spouse may be married to zero or one Customer

parrentOf

A Spouse may be the parent of zero, one or more Child

Entity / Type

Description

Child

A person who is legally classified as a dependent of a Customer or Spouse

Attributes

Definition

Sensitive

Type

Length

firstName

The first name of the Child

Yes

Text

25

lastName

The last name of the Child

Yes

Text

25

schoolName

Name of the school the Child attends or n/a if none

Yes

Text

25

We can use this table to spot

missing relationships,

inconsistencies we want all use cases to use the same labels for data entities and all of the data entities attributes, associations, ,

plan for a secure system if we see some data are sensitive we know at all points that this data must have special handling,

possible reuse opportunities (inheritance), and

help in reviewing knowledge with the customers.

Be wary of going too fast from analysis to design!

CRUD Table

A CRUD (CreateReadUpdateDelete) Table defines at a high level where (by use case) a data entity is used and how it is used (Created, Read, Updated, Deleted). It does not get into the detail about the makeup of each entity. There is one CRUD table per system. If we see that a data entity is missing any CRUD stage, then it is likely that there is a gap in our use cases.

CRUD Table for a Star Wars-type computer game

Data Entity

Use Cases

--Created--

Use Cases

--Read--

Use Cases

--Updated--

Use Cases

--Deleted--

Defense

BuyDefense

DisplayScore

BuyDefense

ExecuteEngagement

ExecuteEngadement

GoldCoin

CalculatePlanetOutput

DisplayScore

BuyWeapons

BuyDefense

BuyWeapons

BuyTechnology

BuyDefense

BuyWeapons

BuyTechnology

. . .

Weapon

BuyWeapons

DisplayScore

. . .

. . .

Population

. . .

. . .

. . .

. . .

In this table we list the use cases that make use of each of the data entities and how the use cases use the entities. This table helps us keep track of the data lifecycle (creation through destruction) in a system.

Summary of Collecting Data Requirements

The Detailed Entity Table maintains consistency in the data entities as we discover how they are being used and are associated.

The CRUD table helps us keep track of the use of each of the entities. This is important when we need to react to changes. If one use case changes, it may require modifications to entities. In turn, the changes to an entity may cascade into the other use cases that use that entity.

Relationships among use cases

This is old school Use Case Centric stuff from Jacobson circa 1998.

Preconditions:

1. Have the high-level Use Case diagram

2. Have the Use Case Work Flows (somewhat complete, more than just titles needed)

or

Factor out common behavior from two or more main use cases

Shown as a dashed line with an arrow pointing at the behavior that is factored out (refactoring use cases) of the other use cases.

The flow of an is ALWAYS executed. This will be a significant difference between and the other factoring use cases.

EX: Check out book and Extend loan may both use Check for reservation

(Extend Loan)

(>)

(Check for Reservations)

(Check out Book)

The Check for reservations is also included in other use cases. The steps for included use cases are factored out of the main use cases and a notation is placed in the main use case flow to indicate the factoring. Then the Librarian Actor checks to see if the book is already reserved. (See UC_CheckForReservations).

Lets identify possible inclusions in the ATM machine.

Withdraw Money from an ATM

1. Customer inserts ATM card.

2. ATM runs BIT.

3. ATM reads information on the ATM card.

4. ATM validates information on the ATM card.

5. ATM displays prompts for PIN.

6. Customer enters PIN.

7. ATM validates PIN.

8. ATM displays prompt asking Which operation do you want to perform?

9. Customer selects Cash withdrawal

10. ATM displays prompt for amount to withdraw.

11. Customer enters amount

12. ATM displays prompt requesting from which account to withdraw.

13. Customer selects the account type (checking, saving, credit).

14. ATM communicates with the ATM network to authorize user by validating account ID, PIN, and availability of the amount requested.

15. The ATM displays prompt asking the Customer whether he/she wants a receipt.

16. ATM asks the client to withdraw the ATM card.

17. Customer withdraws the card. (This is a security measure to ensure that Customers do not leave their cards in the machine.)

18. ATM sends a message over the ATM Comm link to the main bank computer commanding that the amount to be dispensed is deducted from the Customers account.

19. ATM dispenses the requested amount of cash.

20. ATM prints receipt.

21. The use case ends.

Possible Inclusions

ATM performs a BIT

Authorize Customer

Check printer, prompt for receipt, print receipt

Update account balances

Already written Components:

Inclusions may be COTS or in house developed business objects. For example: we probably have something for Authorize Customer.

When to stop factoring:

If the work in factoring is more work than implementing dont factor.

Advantages of Inclusions:

Can save further analysis and design work from this point on.

Only need to develop the functionality once.

Can share testing. Speeds validation walkthroughs. Only need to test it once as code.

Can share documentation, this can be significant if functionality is visible to users.

Indicates an early decision to reuse a component in particular parts. Need to pay particular attention to this component so that the component will be suitable for both instances.

Can make the main uses cases simpler by abstracting detailed parts out.

Can help refine project plan earlier. The more and earlier reuse is identified, the less resources are needed in the project. Estimating the efforts required for reused components is far easier that new work!

The above are more difficult to do using a requirements only approach instead of use case centric approach.

Disadvantages (according to Stevens)

Tends to push design/architecture down a functional v. OO approach. I dont think it does any more than a straight requirements driven start.

The author suggests developing the high-level object model in parallel. I think that this will result in some speculative work and will increase throw away work, this increases the total work load.

Modeling incorporating inclusions is harder for non-UML skilled people to follow. At least there is a user perspective model to use v. no model at all (like a strict requirements only approach).

The more complex the use case model the harder it is to maintain. I dont see how this is any different with requirements based approach. If you change a requirement you must review the changed requirement against other requirements to determine if there are conflicts, new gaps, etc. introduced into requirements.

Summary of Inclusion

Can simply or provide an abstract view of the main use cases

Show common functionality among use cases

To document that we have a reuse opportunity

To document the selection of a preexisting component (COTS).

Separating variant behavior

If the two or more scenarios of a use case have significantly different behaviors /flows based on circumstances we need extension(s)

use cases flows are NOT executed every time. Recall that this is a significant difference between and .

In the book they have a scenario in which a book barrower is refused a book check out because (s)he has too many books checked out. We can have an for Refuse loan.

An is connected to the extended use case by a dashed line and an arrow pointing back to the extended use case.

The extended use case lists the point at which the extension occurs.

The extended use case flow refers to the (See Refuse loan extends based check of number of books checked out).

(UC_CheckoutBook)

(>)

(UC_RefusesLoan) (Extension points: UC_RefuseLoan)

Back to the ATM system, scenarios:

Refuse withdrawal (too much money withdrawn in a day)

Refuse withdrawal (user doesnt have enough money in account)

Refuse withdrawal (ATM doesnt have enough money to provide the service)

Refuse service because wrong PIN entered.

. . .

Generalization

Use cases and Actors can be generalized or specialized.

Example from library system

Actors Journal Barrower is a specialization of a Book Barrower.

Use Cases Checkout Journal is a specialization of Book Checkout

(Checkout Book)

(Book Borrower)

(Checkout Journal)

(Journal Borrower)

Level of a Use Case Diagram and the System Box

From: http://www.andrew.cmu.edu/course/90-754/umlucdfaq.html

How do you know what to put in the "System" box?

The system box only appears on the top-level diagram (remember that a typical UML Use Case description will be composed of many diagrams and sub-diagrams), and should contain use case ovals, one for each top-level service that your system provides to its actors. Any kind of internal behavior that your system may have that is only used by other parts of the system should not appear in the system-level box. One useful way to think of these top-level services is as follows: if a use case represents a top-level service, then it should make sense for the actors who interact with it to request only that service of your system in a single session (in whatever sense a "session" is intelligible in your system.)

What Level should a Use Case be, Example: In the diagram below we would like to represent the use cases for a camera. Suppose we choose "Open Shutter", "Flash", and "Close Shutter" as the top-level use cases. Certainly these are all behaviors that a camera has, but no photographer would ever pick up their camera, open the shutter, and then put it down, satisfied with their photographic session for the day. We must see or produce some observable benefit opening a shutter by itself does nothing for the primary actor! The crucial thing to realize is that these behaviors are not done in isolation, but are rather a part of a more high-level use case, "Take Picture" does result in some useful goal being achieved by an Actor. (Note that it does make sense for a photographer to "Take Picture" just once during a session with their camera.)

Interactions between Use Cases

Once relationships between use cases have been identified it is important to understand what information will need to flow across this interface.

2011 Mike RowePage 1009/19/2011 12:00 PM

ATM

Comm

Link

ATM Machine

use cases

Central Bank

Computer

Other Banks

other

applications

Our Bank

Our Banks ATM Customer

Another Bank's

Customer

Our Bank's Customer