uml use case - cpe.ku.ac.th

UML Use Case

Requirements analysis and systemRequirements analysis and system specification

Requirements analysis and system ifi ispecification

• Why is it one of first activities in software life cycle?• Why is it one of first activities in software life cycle?– Need to understand what customer wants first!– Goal is to understand the customer’s problemGoa s to u de sta d t e custo e s p ob e– Though customer may not fully understand it!

• Requirements analysis says: “Make a list of the guidelines we will use to know when the job is done and the customer is satisfied.”

AKA requirements gathering or requirements engineering– AKA requirements gathering or requirements engineering• System specification says: “Here’s a description of whatthe program will do (not how) to satisfy thethe program will do (not how) to satisfy the requirements.” – Distinguish requirements gathering & system analysis?– A top‐level exploration into the problem and discovery of whether it can be done and how long it will take

Evolutionary requirementsEvolutionary requirements

• Requirements are capabilities and conditions to which the system and the project must conform

• A prime challenge of requirements analysis is to find,A prime challenge of requirements analysis is to find, communicate, and remember what is really needed, in the form that clearly speaks to the client and e o a c ea y spea s o e c e a ddevelopment team members.

Functional (what behaviors it does) and non‐functional (how it does them)and non‐functional (how it does them)

• Functional requirements describe system behaviors– Priority: rank order the features wanted in importance– Criticality: how essential is each requirement to the overall

system?system?– Risks: when might a requirement not be satisfied?

What can be done to reduce this risk?• Non functional requirements describe other desired• Non‐functional requirements describe other desired

attributes of overall system—– Product cost (how do measure cost?)– Performance (efficiency, response time? startup time?)– Portability (target platforms?), binary or byte‐code

compatibility?p y– Availability (how much down time is acceptable?)– Security (can it prevent intrusion?)

Safety (can it avoid damage to people or environment?)– Safety (can it avoid damage to people or environment?)– Maintainability (in OO context: extensibility, reusability)

"Editor with undo"Editor with undo • A very simple, initial requirements spec

– Why might a small and concise initial spec be a good idea?– Fosters initial buy‐in and agreement by everyone on team– Traditional real world specs are usually much longer– Traditional real‐world specs are usually much longer

• What’s the purpose of a purpose or vision statement?• Why is scope important?Why is scope important?• Why a glossary of terms and definitions?• Business case and user perspective:p p

– Business context and case: Who wants it and why?– User characteristics: profile of user community, expected

ti ith t & d iexpertise with system & domain– User objectives: “wish list” from user’s perspective– Interface requirements: GUI API communication interfacesInterface requirements: GUI, API, communication interfaces,

software interfaces

FURPS+ model(Grady 1992)

FURPS is a checklist for requirements:FURPS is a checklist for requirements:

• Functional (features, capabilities, security)

• Usability (human factors, help, documentation)

• Reliability (frequency of failure, recoverability, predictability)

• Performance (response time, throughput, accuracy,Performance (response time, throughput, accuracy, availability, resource usage)

• Supportability (adaptability maintainability• Supportability (adaptability, maintainability, internationalization, configurability)

What’s with the + in FURPS+?What s with the + in FURPS+?

A d d ’ fAnd don’t forget….• Implementation (resource limitation, language and

l h d )tools, hardware)• Interface (constraints posed by interfacing with

l )external systems)• Operations (system management in its operational

i )setting)• Packaging (for example, a physical box)• Legal (licensing)

Desiderata for a requirements specificationa requirements specification

• Should say what, not how. Why?• Correct: does what the client wants, according to specificationCorrect: does what the client wants, according to specification

– Like motherhood and apple pie—how to accomplish it?– Ask the client: keep a list of questions for the client– Prototyping: explore risky aspects of the system with client– Prototyping: explore risky aspects of the system with client

• Verifiable: can determine whether requirements have been met– But how do verify a requirement like “user‐friendly” or

“it should never crash”?it should never crash ?• Unambiguous: every requirement has only one interpretation• Consistent: no internal conflicts

If you call an input "Start and Stop" in one place don't call it– If you call an input Start and Stop in one place, don t call it "Start/Stop" in another

• Complete: has everything designers need to create the software• Understandable: stakeholders understand enough to buy into it• Understandable: stakeholders understand enough to buy into it

– Tension between understandability and other desiderata?• Modifiable: requirements change!

Ch h ld b t d d d i th !– Changes should be noted and agreed upon, in the spec!

Use casesUse cases• First developed by Ivar Jacobson p y

– Now part of the UML (though not necessarily object‐oriented)– Emphasizes user’s point of view– Explains everything in the user’s language

• A "use case" is a set of cases or scenarios for using a system tied together by a common user goala system, tied together by a common user goal– Essentially descriptive answers to questions that start with

“What does the system do if …” – E.g., “What does the auto‐teller do if a customer has just deposited a

check within 24 hours and there’s not enough in the account without the check to provide the desired withdrawal?”the check to provide the desired withdrawal?

– Use case describes what the auto‐teller does in that situation• Use case model = the set of all use cases• Why are use cases good for brainstorming requirements?

Brief Use Case formatBrief Use Case format

Brief format narrates a story or scenario of use in prose form, e.g.:

Rent Videos. A Customer arrives with videos to rent. The Clerk enters their ID, and each video ID. The System outputs information on each. The Clerk requests the

l Th S i hi h i i hrental report. The System outputs it, which is given to the Customer with their videos.

Fully dressed Use Case (from Fowler & Scott, UML Distilled)

Use Case: Buy a Product (Describe user’s goal in user’s language)Use Case: Buy a Product (Describe user s goal in user s language)Actors: Customer, System (Why is it a good idea to define actors?)1. Customer browsers through catalog and selects items to buy2 Customer goes to check out2. Customer goes to check out3. Customer fills in shipping information (address; next‐day or 3‐day delivery)4. System presents full pricing information, including shipping

f ll d d f5. Customer fills in credit card information6. System authorizes purchase7. System confirms sale immediately8. System sends confirming email to customer (Did we get the main scenario right?)Alternative: Authorization Failure (At what step might this happen?)( p g pp )6a. At step 6, system fails to authorize credit purchase

Allow customer to re‐enter credit card information and re‐tryAlternative: Regular customer (At what step might this happen?)Alternative: Regular customer (At what step might this happen?)3a. System displays current shipping information, pricing information,

and last four digits of credit card information3b Customer may accept or override these defaults3b. Customer may accept or override these defaults

Return to primary scenario at step 6

Scenario use case and goalScenario, use case and goal

• A scenario is a specific sequence of actions and interactions in a use case.– One path through the use case

– E.g., The scenario of buying a product

• A use case is a collection of success and failure scenarios describing an actor using a system to support a goal.g y pp g

Heuristics for writing use case textHeuristics for writing use case text

• Avoid implementation specific language in use cases such as• Avoid implementation specific language in use cases, such as IF‐THEN‐ELSE or GUI elements or specific people or depts– Which is better: “The clerk pushes the OK button.”

or: “The clerk signifies the transaction is done.”?or: The clerk signifies the transaction is done. ? – The latter defers a UI consideration until design.

• Write use cases with the user’s vocabulary, the way a users would describe performing the taskdescribe performing the task

• Use cases never initiate actions; actors do. – Actors can be people, computer systems or any external entity

that initiate an action. • Use case interaction produces something of value to an actor• Create use cases & requirements incrementally and iteratively

– Start with an outline or high‐level descriptionStart with an outline or high level description– Work from a vision and scope statement– Then broaden and deepen, then narrow and prune

More use case pointersMore use case pointers

Add di i d di i i h• Add pre‐conditions and post‐conditions in each use case:– What is the state of affairs before and after use case occurs?– Why?– Why?

• Some analysts distinguish between business and system use cases:– System use cases focus on interaction between actors

within a software systemBusiness use cases focuses on how a business interacts– Business use cases focuses on how a business interacts with actual customers or events

– Fowler prefers to focus on business use cases first, then come up with system use cases to satisfy them

– Note iterative approach in developing use cases, too

Text and DiagramsText and Diagrams

• Use case text provides the detailed description of a particular use case

• Use case diagram provides an overview of interactions between actors and use cases

Use case diagramg

• Bird’s eye view of use cases for a system• Stick figures represent actors (human or computer in roles)

Elli (b h i f ti lit b )• Ellipses are use cases (behavior or functionality seen by users)• What can user do with the system?

– E.g., Trader interacts with Trader Contract via a Trade CommoditiesE.g., Trader interacts with Trader Contract via a Trade Commodities transaction

• <<include>> relationship inserts a chunk of behavior (another use case)(another use case)

• <<extend>> adds to a more general use case

Advantages of use casesAdvantages of use cases

Wh t d thi k?• What do you think?• Systematic and intuitive way to capture functional requirements?• Facilitates communication between user and system analyst:Facilitates communication between user and system analyst:

– Text descriptions explain functional behavior in user’s language– Diagrams can show relationship between use case behaviors

h h ld b h i h di ?– When should we bother with diagrams?• Use cases can drive the whole development process:

– Analysis understand what user wants with use casesAnalysis understand what user wants with use cases– Design and implementation realizes them– How can use case help with early design of UI prototype?– How can use cases set up test plans?– How can use cases help with writing a user manual?

Use cases assignmentUse cases assignment

• Develop a set of use cases and a use case diagram for a simple ATMg p(simple means you can just consider two kinds of accounts savings and checking and twoof accounts, savings and checking, and two transactions, deposits and withdrawals)

b• Due anytime Sunday, September 7

on Blackboardon Blackboard

Automatic Teller Machine (ATM)Automatic Teller Machine (ATM) Case Studyy

Use case ModelingUse case Modeling

20

Views of modeling and diagrams

21

Automatic Teller Machine (ATM) Case Study

• Identify the actors,

• Identify the use cases,Identify the use cases,

• Construct a use case diagram,

• Write a textual description of the use cases,

• Complete the descriptions with dynamicComplete the descriptions with dynamic diagrams,

• Organize and structure the use cases.

22

Problem statement

Thi t d i lifi d t f thThis case study concerns a simplified system of the automatic teller machine (ATM). The ATM offers the following services:the following services:

1. Distribution of money to every holder of a smartcard via a card reader and a cash dispensersmartcard via a card reader and a cash dispenser.

2. Consultation of account balance, cash and cheque deposit facilities for bank customers whocheque deposit facilities for bank customers who hold a smartcard from their bank.

3. All transactions are made secure.4. It is sometimes necessary to refill the dispenser, etc.

23

Step 1 – Identifying the actors of the ATMStep 1 – Identifying the actors of the ATM

An actor is a construct employed in use cases that define a role that a user or any other ysystem plays when interacting with the system under consideration It is a type of entity thatunder consideration. It is a type of entity that interacts, but which is itself external to the subject Actors may represent human userssubject. Actors may represent human users, external hardware, or other subjects.

24

Step 1 – Identifying the actors of the ATMStep 1 – Identifying the actors of the ATM

F “P bl ”• From “Problem statement”• Rule: The actor is the who or what that benefits from

i th tusing the system.– Every “holder of a smartcard”. He or she will be able to use the ATM to withdraw money using his or her smartcardthe ATM to withdraw money using his or her smartcard

– The card reader and cash dispenser constitute part of the ATM. Can they be considered as actors?

– Identifies additional services that are only offered to bank customers who hold a smartcard from this bank. This is therefore a different profile from the previous one whichtherefore a different profile from the previous one, which we will realize by a second actor called Bank customer.

25

Step 1 Identifying the actors of the ATMStep 1 – Identifying the actors of the ATM

All transactions are made secure But who makes them secure? There– All transactions are made secure. But who makes them secure? There are therefore other external entities, which play the role of authorization system and with which the ATM communicates directly. An interview with the domain expert is necessary to allow us to p yidentify two different actors:

• The Visa authorization system (VISA AS) for withdrawal y ( )transactions carried out using a Visa smartcard (we restrict the ATM to Visa smartcards for reasons of simplification)

• The information system of the bank (Bank IS) to authorize all transactions carried out by a customer using his or her bank smartcard, but also to access the account balance.

– ATM also requires maintenance work, such as refilling the dispenser with bank notes, retrieving cards that have been swallowed, etc. These maintenance tasks are carried out by a new actor which – to simplifymaintenance tasks are carried out by a new actor, which – to simplify matters – we will call Maintenance operator.

26

Graphical representations of an actorGraphical representations of an actor

The standard graphical representation of the actor in UML is the icon called stick man with the name of the actor below the drawing It is also possible to show an actor as a classdrawing. It is also possible to show an actor as a class rectangle with the <<actor>> keyword. A third representation (halfway between the first two) is also possible, as indicated ( y ) p ,below.

27

Step 2 – Identifying use casesStep 2 – Identifying use cases

• A use case represents the specification of a sequence of actions, including variants, that a q f gsystem can perform, interacting with actors of the systemthe system.

• A use case models a service offered by the h /system. It expresses the actor/system

interactions and yields an observable result of value to an actor.

28

Step 2 – Identifying use casesStep 2 – Identifying use cases• Cardholder• Cardholder:

– Withdraw money.• Bank customer:

Withd ( thi t t f t!)– Withdraw money (something not to forget!).– Consult the balance of one or more accounts.– Deposit cash.

Deposit cheques– Deposit cheques.• Maintenance operator:

– Refill dispenser.Retrieve cards that have been swallowed– Retrieve cards that have been swallowed.

– Retrieve cheques that have been deposited.• Visa authorization system (AS):

None– None.• Bank information system (IS):

– None.

29

Step 2 – Identifying use casesStep 2 – Identifying use cases

Primary or secondary actor• Contrary to what we might believe, all actors do not necessarily use

h ! W ll h f h h dthe system! We call the one for whom the use case produces an observable result the primary actor. In contrast, secondary actors constitute the other participants of the use case. Secondary actors p p f yare requested for additional information; they can only consult or inform the system when the use case is being executed.

• This is exactly the case of the two “non‐human” actors in our example: the Visa AS and the Bank IS are only requested by the ATMexample: the Visa AS and the Bank IS are only requested by the ATM within the context of realizing certain use cases. However, they themselves do not have their own way of using the ATM.

30

Step 3 – Creating use case diagramsStep 3 – Creating use case diagramspreliminary use case diagram

31

Step 3 – Creating use case diagramsStep 3 – Creating use case diagramsSophisticated version use case diagram

32

Step 3 – Creating use case diagramsStep 3 – Creating use case diagrams

• But a problem arises for the shared use case, Withdraw money. Indeed, if thecase, Withdraw money. Indeed, if the primary actor is a Visa card holder, the Vi AS t b ll d ( hi h illVisa AS must be called on (which will then be responsible for contacting the IS p gof the holder’s bank); whereas the ATM will contact the Bank IS directly if itwill contact the Bank IS directly if it concerns a bank customer.

Step 3 – Creating use case diagramsStep 3 – Creating use case diagramsOne solution consists in ddadding an association with each of the two

h hinon‐human actors. This simplistic modeling d k i ldoes not make it clear to the reader of the di h hdiagram that the actors are selectively

i i i bparticipating two by two and not all

htogether.34

Step 3 – Creating use case diagramsStep 3 – Creating use case diagramsAnother solution would be to distinguish two use

f h i hd l f Wi hdcases for the withdrawal of money: Withdraw money using a Visa card and Withdraw money

b k d husing a bank card. This more precise, yet more cumbersome, modeling is easier for the reader of the diagram to grasp.

35

Step 4 – Textual description of use casesStep 4 – Textual description of use cases

In order to explain the dynamics of a use case in detail the most obvioususe case in detail, the most obvious way of going about it involves textually y g g ycompiling a list of all the interactions b t th t d th tbetween the actors and the system.

36

Step 4 – Textual description of use casesStep 4 – Textual description of use cases

S i dScenarios and use cases• We call each unit of description of action sequences a

sequence A scenario represents a particular succession ofsequence. A scenario represents a particular succession of sequences, which is run from beginning to end of the use case. A scenario may be used to illustrate an interaction or the execution of a use case instance.

Representation of the scenarios of a use case37

Step 4 – Textual description of use casesStep 4 – Textual description of use casesA structure of textual description

d f ( d )• Identification summary (mandatory)– includes title, summary, creation and modification dates, version, person

in charge, actors...in charge, actors...

• Flow of events (mandatory)– describes the main success scenario,10 the alternative and error ,

sequences,11 as well as the preconditions and the post conditions.

( )• UI requirements (optional)– possibly adds graphical user interface constraints (required look and

feel) Screen copies indeed a disposable model are greatly appreciatedfeel). Screen copies, indeed a disposable model, are greatly appreciated.

• Non‐functional constraints (optional)– may possibly add the following information: frequency, availability, y p y g q y, y,

accuracy, integrity, confidentiality, performance, concurrency, etc.38

Describe the mandatory part of the withdraw money using a visa card use case.

Identification summaryIdentification summaryTitle: Withdraw money using a Visa card

Summary: this use case allows a Visa card holder, who is not a customer of the bank, to withdrawwho is not a customer of the bank, to withdraw money if his or her daily limit allows it.

Actors: Visa CardHolder (primary) Visa ASActors: Visa CardHolder (primary), Visa AS (secondary).

Creation date: 02/03/02 Date of update: 08/19/03

Version: 2.2 Person in charge: Pascal Roquesg q

39


Flow of events

Preconditions:Preconditions:

• The ATM cash box is well stocked.

• There is no card in the reader.

Main success scenario:Main success scenario:1. The Visa CardHolder inserts his or her smartcard in the ATM’s card reader.

2. The ATM verifies that the card that has been inserted is indeed a smartcard.

3. The ATM asks the Visa CardHolder to enter his or her pin number.

4. The Visa CardHolder enters his or her pin number.

5. The ATM compares the pin number with the one that is encoded on the chip of the smartcard.

6. The ATM requests an authorisation from the VISA authorisation system.

7. The VISA authorisation system confirms its agreement and indicates the daily withdrawal limit.

8. The ATM asks the Visa CardHolder to enter the desired withdrawal amount.

9. The Visa CardHolder enters the desired withdrawal amount.

10 The ATM checks the desired amount against the daily withdrawal limit10. The ATM checks the desired amount against the daily withdrawal limit.

11. The ATM asks the Visa CardHolder if he or she would like a receipt.

12. The Visa CardHolder requests a receipt.

13. The ATM returns the card to the Visa CardHolder.

14. The Visa CardHolder takes his or her card.

15. The ATM issues the banknotes and a receipt.

16. The Visa CardHolder takes the banknotes and the receipt.40


Another possible presentation13 consists in separating the actions of the actors and

those of the system into two columns as follows:those of the system into two columns as follows:

41


“Alternative” sequences:A1: temporarily incorrect pin number

The A1 sequence starts at point 5 of the main success scenario.6. The ATM informs the CardHolder that the pin is incorrect for the first or second time.6. The ATM informs the CardHolder that the pin is incorrect for the first or second time.

7. The ATM records the failure on the smartcard.

The scenario goes back to point 3.

A2: the amount requested is greater than the daily withdrawal limitA2: the amount requested is greater than the daily withdrawal limit

The A2 sequence starts at point 10 of the main success scenario.11. The ATM informs the CardHolder that the amount requested is greater than the daily withdrawal

limit.limit.

The scenario goes back to point 8

A3: the Visa CardHolder does not want a receipt

The A3 sequence starts at point 11 of the main success scenarioThe A3 sequence starts at point 11 of the main success scenario.12. The Visa CardHolder declines the offer of a receipt.

13. The ATM returns the smartcard to the Visa CardHolder.

14. The Visa CardHolder takes his or her smartcard.

15. The ATM issues the banknotes.

16. The Visa CardHolder takes the banknotes.42


Error sequences:

E1: invalid card

The E1 sequence starts at point 2 of the main success scenario.3. The ATM informs the Visa CardHolder that the smartcard is not valid

(unreadable, expired, etc.) and confiscates it; the use case fails.

E2: conclusively incorrect pin numberE2: conclusively incorrect pin number

The E2 sequence starts at point 5 of the main success scenario.6. The ATM informs the Visa CardHolder that the pin is incorrect for the third p

time.

7. The ATM confiscates the smartcard.

8 The VISA authorisation system is notified; the use case fails8. The VISA authorisation system is notified; the use case fails.

E3: unauthorised withdrawal

The E3 sequence starts at point 6 of the main success scenarioThe E3 sequence starts at point 6 of the main success scenario.7. The VISA authorisation system forbids any withdrawal.

8. The ATM ejects the smartcard; the use case fails.43


E4: the card is not taken back by the holdery

The E4 sequence starts at point 13 of the main success scenario.14. After 15 seconds, the ATM confiscates the smartcard.16.

15. The VISA authorisation system is notified; the use case fails.

E5: the banknotes are not taken by the holder

The E5 sequence starts at point 15 of the main success scenario.16. After 30 seconds, the ATM takes back the banknotes.

17 The VISA authorisation system is informed; the use case fails17. The VISA authorisation system is informed; the use case fails

Postconditions:• The cashbox of the ATM contains fewer notes than it did at the start of the use case

(the number of notes missing depends on the withdrawal amount).

44


UI i tUI requirementsThe input/output mechanisms available to the Visa

CardHolder must be:CardHolder must be:• A smartcard reader.• A numerical keyboard (to enter his or her pin number), with

“ ” “ ” d “ l” k“enter”, “correct” and “cancel” keys.• A screen to display any messages from the ATM.• Keys around the screen so that the card holder can select a• Keys around the screen so that the card holder can select a

withdrawal amountfrom the amounts that are offered.• A note dispenser.p• A receipt dispenser.

45


UI i tUI requirementsThe input/output mechanisms available to the Visa

CardHolder must be:CardHolder must be:• A smartcard reader.• A numerical keyboard (to enter his or her pin number), with

“ ” “ ” d “ l” k“enter”, “correct” and “cancel” keys.• A screen to display any messages from the ATM.• Keys around the screen so that the card holder can select a• Keys around the screen so that the card holder can select a

withdrawal amountfrom the amounts that are offered.• A note dispenser.p• A receipt dispenser.

46


Non functional constraintsNon‐functional constraints

47

Step 5 Graphical description of use casesStep 5 – Graphical description of use cases

Th t t l d i ti i ti l f th d t ti• The textual description is essential for the documentation of use cases, as it alone enables ease of communication with users, as well as agreeing on domain terminology that is used.

• However, the text also has its disadvantages as it difficult to show how the sequences follow one another or at whatshow how the sequences follow one another, or at what moment the secondary actors are requested. Besides, keeping a record of changes often turns out to be rather tiresome It is therefore recommended to complete thetiresome. It is therefore recommended to complete the textual description with one or more dynamic UML diagrams.– Activity Diagram– Sequence Diagram (System Sequence Diagram)

48


F d th ti it di• For use cases, we recommend the activity diagram, as users find it far easier to understand since it resembles a traditional diagram. However, the state diagram may g , g ybe useful for use cases that are very interactive.

• For certain scenarios, the sequence diagram works ll W d th t t it b h iwell. We recommend that you present it by showing

the primary actor on the left, then an object representing the system in a black box, and finally, any p g y , y, ysecondary actors that may be requested during the scenario on the right of the system. We will use the title system sequence diagram as proposed by Larmantitle system sequence diagram as proposed by Larman(Applying UML and Patterns (2nd Edition), Prentice‐Hall, 2001.).

49


50

System sequence diagram describes the main success scenario of theWithdraw money using a Visa card usescenario of the Withdraw money using a Visa card use

case

51

Activity diagram describes the dynamics of the withdraw money using a visa card use case

lik h i di h l• Unlike the previous sequence diagram that only describes the main success scenario, the activity di t ll th ti iti th tdiagram can represent all the activities that are carried out by the system, with all the conditional branches and all the possible loopsbranches and all the possible loops.

• The activity diagram is essentially a flowchart, h i fl f l f i i i ishowing flow of control from activity to activity. The transitions are triggered at the end of ti iti ti t b i d t iactivities or actions; steps can be carried out in

parallel or in sequence.

52

Activity diagram describes the dynamics of the withdraw money using a visa card use case

53

Step 6 Organizing the use casesStep 6 – Organizing the use cases

With UML, it is actually possible to detail and organize use cases in two different and gcomplementary ways:

• by adding include, extend and generalization relationships between use cases;

• by grouping them into packages to define• by grouping them into packages to define functional blocks of highest level.

54

Include relationship between use casesInclude relationship between use cases

Fi l ’ kl h i l d l i hiFirst, let’s tackle the include relationship: • a relationship from a base use case to an inclusion use

if i h th b h i f th bcase, specifying how the behavior for the base use case contains the behavior of the inclusion use case. The behavior is included at the location which is defined inbehavior is included at the location which is defined in the base use case. The base use case depends on performing the behavior of the inclusion use case, but p gnot on its structure.

• We use this relationship to avoid describing the same sequence several times by factorizing the shared behavior in its own use case.

55

Include relationship between use casesInclude relationship between use casesIf we examine the textual description of the Withdraw money using a Visa

d i d il i h fi f h icard use case in detail, we notice that steps one to five of the main success scenario will also perfectly apply to all use cases of the bank customer.

Furthermore, this main success sequence is completed by the A1 (temporarily incorrect pin number), E1 (invalid card) and E2 (conclusively incorrect pin number) alternative or error sequencesnumber) alternative or error sequences.

We can therefore rightfully identify a new use case included in the previous ones that we will call Authenticate, and which contains the sequences

d b Thi ill ll ll h d d lquoted above. This will allow us to remove all these redundant textual descriptions from the other use cases by concentrating better on their functional specificities.

In UML, this mandatory include relationship between use cases is shown by a dashed arrow with an open arrowhead from the base use case to the included use case. The arrow is labeled with the keyword <<include>>, asincluded use case. The arrow is labeled with the keyword <<include>>, as indicated on the following diagram.

56

Extend relationship from an extension usecase to a base use case

L t’ ti l i ith th t d l ti hiLet’s continue our analysis with the extend: a relationship from an extension use case to a base use case, specifying how the behavior defined for the extension p y guse case augments (subject to conditions specified in the extension) the behavior defined for the base use case The behavior is inserted at the location definedcase. The behavior is inserted at the location defined by the extension point in the base use case. The base use case does not depend on performing the behavior of the extension use case. Note that the extension use case is optional unlike the included use case which is mandatory We use this relationship to separate anmandatory. We use this relationship to separate an optional or rare behavior from the mandatory behavior.

58

Extend relationship from an extension usecase to a base use case

When re‐examining the withdraw money issue, it did not take us long to notice that the bank customer applies almost the same main success sequence as the Visa CardHolder However as amain success sequence as the Visa CardHolder. However, as a customer, he or she also has access to the other use cases: why not allow him or her to consult his or her balance just before he jor she selects the desired withdrawal amount? The customer could then change the desired amount according to what is left h hin his or her account.

59

Generalization relationshipGeneralization relationship

Let’s consider the following two use cases: Deposit cash and Deposit cheques.

They both involve the same actors: the Bank customer as the primary actor and the Bank IS as the secondary actor. But in particular, they say the same thing: the possibility offered to a bank customer to deposit money using the ATM. Whether this transaction entails inserting the notes in a note reader, or simply depositing an envelope containing one or more cheques is not important. The result will be similar, that is to say, a credit line will be entered on the customer’s account.

60

Complete use case diagram of the ATMdiagram of the ATM

To improve our model, we will therefore organize the use cases and reassembleuse cases and reassemble them into coherent groups. To do this, we use the ,general‐purpose mechanism for grouping elements in

h h ll dUML, which is called package.

61

Structuring of the ATM use casesStructuring of the ATM use cases• There are several possible strategies: proceed with grouping byThere are several possible strategies: proceed with grouping by

actor, by functional domain, etc. In our example, grouping use cases by primary actor is natural, as this also allows the secondary actors to be distributed.

• The inclusion use case, Authenticate, is placed in a separate package as a shared support service, in order to distinguish it from the real functional cases which include it. The dependency arrows between packages synthesize thedependency arrows between packages synthesize the relationship between the contained use cases. The following diagram presents the proposed structuring of the use cases by d ag a p ese ts t e p oposed st uctu g o t e use cases bymaking the primary actor appear in front of each package to remind us which actor is connected to which package.18 Note that the use of double‐headed filled arrows to connect packages 62

Structuring of the ATM use casesStructuring of the ATM use cases

63

Use case diagram of the Visa withdrawal package

64

Use case diagram of the Customer transactions package

65

Use case diagram of the Maintenance packageUse case diagram of the Maintenance package

66

uml use case - cpe.ku.ac.th

Documents