Use Casesrowemi/classes/SE343/se343_543... · Web viewUse Cases Read Chapters 7 and 8 of Using UML...

Notes: 004 – Use CasesCS/SE3430 / CS5430 - Object-Oriented Analysis and Design

1 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 requirements2. Planning iterative development3. Validating systems 4. Verifying systems

Developed by Ivar Jacobson

1.1 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

1.1.1 Use Case DiagramTwo components , Actors and Use Cases. See Figure 7.2 on page 94Actors:

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:

o Don’t specify individuals, but the roles they play in the domain Example: don’t use Bubba, but use Bubba’s role as a Bank Customer.

o 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 don’t need to get into the details of other systems.

©2011 Mike Rowe 09/29/2011 2:43 PM


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. o This provides guidance for keeping the level of granularity high enough.o Example1: Entering one’s PIN in an ATM machine does not provide something

meaningful to the actor, an ATM Bank Customer who is withdrawing money.o 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.

o This provides guidance for keeping the level of granularity low enough.o 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. o 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

o What's an external system? keyboard? Internet? Another Computer? o 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

©2011 Mike Rowe 09/29/2011 2:43 PM


include those which get value from the contact o 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:

o Assess how much each actor needs a particular use case. o Identify any known risks associated with each use case.o Provide a first rough estimate of cost to implement each use case.o 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?

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

1.2 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 user’s point of view. Written in concise steps from a user’s / actor’s 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 card3. 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

©2011 Mike Rowe 09/29/2011 2:43 PM


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 ono Input from the Client: (can cancel at anytime, want a receipt, which account, etc.)o Internal state of the System: (out of paper for receipt, too little cash in ATM, etc.)o Time-outs and errors: (System may cancel transaction on a timeout for Client action,

network response, repeated wrong PIN, bad ATM card, etc.)o Each instance, represents unique path, and is called a Use Case Scenario. The set of all

scenarios is a use case (class). o Sunny Day Scenario – term used to refer to the primary, everything goes smooth, path

through a use case. o 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?

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

o 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! o 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.

o Focus on finding things of value that a system provides to its actors How detailed should the steps be?

o 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 1000’s of use cases.

©2011 Mike Rowe 09/29/2011 2:43 PM


Biggest system I worked on probably approached around 5,000 use cases. There were about 50 subsystems each with about 100 use cases.

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

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

1.3 Use Case Scenarios/Flows Rules of Thumb

Effective Use of Language in Use Cases, By Kendall Scotthttp://www.requirementsnetwork.com/sites/requirementsnetwork.com/files/Effective%20Use%20of%20Language%20in%20Use%20Cases.pdf

©2011 Mike Rowe 09/29/2011 2:43 PM

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

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


Use active voice, and speak from the actor’s perspectiveo “ The customer selects the item”

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

Use present tenseo “The customer selects the item.”

NOT “The customer shall select the item” // future tense or “The customer selected the item” // past tense

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

Express your text in the form of “call and response.” o The text should reflect the fact that the actor performs some action(s) and the system

responds accordinglyo “The System prompts for a PIN.” (CALL) and o “The Client enters a PIN.” (RESPONSE)

Keep the use case short

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

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

Establish the initial contexto 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.”

Don’t 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.

o A use case can’t just end floating in space—something 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.”

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

©2011 Mike Rowe 09/29/2011 2:43 PM


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

o 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. o “If a (sober) person off the street can’t read this and understand it right off the bat in 30

seconds, there’s something wrong with it.” o “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.

o Rowe’s version, “Should be simple enough for your grandmother to understand”

End goal of Use Caseso This is a device to capture requirements in ways that the people building the system will

understand and be able to run with. It’s a means to an end, not the end in itself o 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.

1.4 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. o 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 user’s perspective. Requirements engineers may not consider better ways of providing the same or better functionality. o 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.

©2011 Mike Rowe 09/29/2011 2:43 PM


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

©2011 Mike Rowe 09/29/2011 2:43 PM


2 Systematic Development of Use Cases

Start with a casual format and successively refine them into a more formal (dressed up) style. The project’s 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.)

2.1 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 ListACTOR Task-Level Goal Priority Trigger Within

Scope**Bank_Clerk Produce ATM cards User selected NOATM_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

©2011 Mike Rowe 09/29/2011 2:43 PM


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

o For planning iterative phases, we can also concentrate on high priority goals first.o 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. . .

2.2 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 BriefActor Goal BriefATM_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

©2011 Mike Rowe 09/29/2011 2:43 PM


money).

2.3 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 ATM’s home bank computers, the home bank computers are linked to other bank’s 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.

2.4 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 <<includes>> and <<extends>> subflows.

©2011 Mike Rowe 09/29/2011 2:43 PM


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

©2011 Mike Rowe 09/29/2011 2:43 PM


Label : UC_WdMonOCTITLE : 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 machineSCOPE: {{Subsystem Name if this were a bigger system}}LEVEL: main/detail, extends/includesSTAKEHOLDERS and INTERESTS: ATM customer (CUSTOMER): desires money, desires security of access to his/her accountBANK: 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 cardTRIGGER: User starts transaction by inserting an ATM cardMAIN 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 amount12. 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 Customer’s 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)

©2011 Mike Rowe 09/29/2011 2:43 PM


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 amountc. Timeout interval for canceling session.d. Maximum number of withdrawal transactions per 24 hour period.e. . . .

TRACING TO SYSTEM-LEVEL REQUIRES: R-Security-023R-Security-064. . .RELATED USE CASES: UC_DepositKNOWLEDGE SOURCE: where did the information come from like: Bobob the bank VP in charge of nickels.REQUIREMENTS ENGINEER: BerthaREVISION HISTORY:

o Created: Who and wheno Reviewed: Who and when engineer’s name/ customer’s nameo Revised: Who and when engineer’s nameo Revisions Reviewed: Who and when engineer’s name o Signed Off: Who and when customer’s name

. . .

©2011 Mike Rowe 09/29/2011 2:43 PM


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

2.6.1 Detailed Entity TableWhile 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.

©2011 Mike Rowe 09/29/2011 2:43 PM

http://www.requirementsnetwork.com/user_registration?destination=trackerlite

http://www.requirementsnetwork.com/user_registration?destination=trackerlite


Detailed Entity TableEntity / Type DescriptionCustomer A person with an account at the bank

Attributes Definition Sensitive Type LengthfirstName The first name of the Customer No Text 25lastName The last name of the Customer No Text 25SSN Social Security Number Yes Text 9driversLicenseNumber A drivers license number Yes Text 12driversLicenseState State that issued drivers license No Text 2creditLimit Upper borrowing limit for this

CustomerYes Money 11.2

dateOfBirth Date of birth of the Customer Yes Text YYYYMMDDPIN Personal Identification Number Yes numeric nnnnmotherMaiden Mother’s Maiden name Yes text 24

Relationships Business RulemarriedTo A Customer may be married to zero or one SpouseparrentOf A Customer may be the parent of zero, one or more ChildaccountsOf A Customer may have one or more AccountsaccountIssuranceMax 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 DescriptionSpouse A person to whom a Customer is married.

Attributes Definition Sensitive Type LengthfirstName The first name of the Spouse No Text 25lastName The last name of the Spouse No Text 25SSN Social Security Number Yes Text 9driversLicenseNumber A drivers license number Yes Text 12driversLicenseState State that issued drivers license No Text 2dateOfBirth Date of birth of the Customer Yes Text YYYYMMDDPIN Personal Identification Number Yes numeric nnnndateOfBirth Date of birth of the Customer Yes Text YYYYMMDDmotherMaiden Mother’s Maiden name Yes text 24

Relationships Business RulemarriedTo A Spouse may be married to zero or one CustomerparrentOf A Spouse may be the parent of zero, one or more Child

Entity / Type Description

©2011 Mike Rowe 09/29/2011 2:43 PM


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

Attributes Definition Sensitive Type LengthfirstName The first name of the Child Yes Text 25lastName The last name of the Child Yes Text 25schoolName Name of the school the Child attends

or “n/a” if noneYes Text 25

We can use this table to spot o missing relationships, o inconsistencies – we want all use cases to use the same labels for data entities and all of the

data entities attributes, associations, … ,o plan for a secure system – if we see some data are sensitive we know at all points that this

data must have special handling,o possible reuse opportunities (inheritance), and o help in reviewing knowledge with the customers.

Be wary of going too fast from analysis to design!

2.6.2 CRUD TableA 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 DisplayScoreBuyDefense

ExecuteEngagement ExecuteEngadement

GoldCoin CalculatePlanetOutput DisplayScoreBuyWeapons

BuyDefenseBuyWeaponsBuyTechnology

BuyDefenseBuyWeaponsBuyTechnology. . .

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.

©2011 Mike Rowe 09/29/2011 2:43 PM


2.6.3 Summary of Collecting Data RequirementsThe 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.

2.7 Relationships among use cases

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

1. Have the high-level Use Case diagram2. Have the Use Case Work Flows (somewhat complete, more than just titles needed)

2.7.1 <<Uses>> or <<Includes>>o Factor out common behavior from two or more main use caseso Shown as a dashed line with an arrow pointing at the behavior that is factored out (refactoring

use cases) of the other use cases.o The flow of an <<includes>> is ALWAYS executed. This will be a significant difference between

<<includes>> and the other factoring use cases.

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

©2011 Mike Rowe 09/29/2011 2:43 PM

Extend Loan

Check out Book

Check for Reservations

<<includes>>

<<includes>>


o 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 ATM1. 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 amount12. 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 Customer’s 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 – don’t factor.

©2011 Mike Rowe 09/29/2011 2:43 PM


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

2.7.3 Disadvantages (according to Stevens) Tends to push design/architecture down a functional v. OO approach. – I don’t think it does

any more than a straight requirements driven start. o 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 don’t 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.

2.7.4 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).

2.8 Separating variant behavior <<extend>>

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

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

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 <<extend>> for “Refuse loan”.

©2011 Mike Rowe 09/29/2011 2:43 PM


An <<extend>> 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 <<extend>> (See Refuse loan extends based check of

number of books checked out).

Back to the ATM system, <<extend>> scenarios:o Refuse withdrawal (too much money withdrawn in a day)o Refuse withdrawal (user doesn’t have enough money in account)o Refuse withdrawal (ATM doesn’t have enough money to provide the service)o Refuse service because wrong PIN entered.o . . .

2.9 Generalization

o Use cases and Actors can be generalized or specialized. o Example from library system

o Actors Journal Barrower is a specialization of a Book Barrower.o Use Cases Checkout Journal is a specialization of Book Checkout

©2011 Mike Rowe 09/29/2011 2:43 PM

UC_CheckoutBook

<<extend>> UC_RefusesLoanExtension points: UC_RefuseLoan

Book Borrower

Checkout Book

Checkout Journal


2.10 Level of a Use Case Diagram and the System Box

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

2.10.1 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.)

©2011 Mike Rowe 09/29/2011 2:43 PM

Journal Borrower

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


2.11 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 Rowe 09/29/2011 2:43 PM

Use Casesrowemi/classes/SE343/se343_543... · Web viewUse Cases Read Chapters 7 and 8 of Using UML...

Documents

Transcript of Use Casesrowemi/classes/SE343/se343_543... · Web viewUse Cases Read Chapters 7 and 8 of Using UML...