37669127 UML Use Case Diagrams

8/8/2019 37669127 UML Use Case Diagrams

1/43

Requirements CaptureRequirements Capture

using UML Use Casesusing UML Use Cases

Requirements CaptureRequirements Capture

using UML Use Casesusing UML Use Cases


2/43

Use Case Diagrams 2

Object Oriented Analysis and Design

ContentsR equirements CollectionThe UML MechanismUse Cases

ActorsUse Case DiagramsScenarios

R elationships between Use Cases


3/43

Use Case Diagrams 3


R equirements CollectionR equirements are the underlying principle of any software development project.

Denotes the user-requirements; defines the

goals to be achieved.Must be precisely and completely understoodby the team providing the solution.

User requirements (and team members) keepchanging; requirements must therefore bewell-documented.


4/43

Use Case Diagrams 4


R equirements Collection (contd.)

A thorough and unambiguous understandingof the requirements is vital to ensure thateveryone knows what they are doing and why.

Must be reviewed, reviewed again andreviewed yet again before the design andimplementation begins.

Involves the participation of domain-experts toensure that the requirements have beencorrectly understood.

captures the WHAT of the problem-domain.


5/43

Use Case Diagrams 5


The UML MechanismUse Case Diagrams

Captures the problem-domain in terms of functionality to be provided (Use Cases), and

the roles (Actors) for whom these functionsare performed.

An abstraction of the problem-domain and avehicle to facilitate a clear, well-articulated andunambiguous understanding of the problem-domain.


6/43

Use Case Diagrams 6


Use CaseIs an abstraction of a set of sequences thatyield some functionality.R epresents some user-visible function.

Is always initiated by an actor.

Describes the interaction between the actorsand the system for a system function.

Achieves a discrete goal for the actor.

Notation:


7/43

Use Case Diagrams 7


Finding Use CasesW hat functions does the system perform?

W hat functions do the actors require?W hat input/output does the system need?


8/43

Use Case Diagrams 8


Use Case - ExampleThe Bookworm is a circulating library that lends booksand journals for a specified period of time. Books arelent to members only. If available, the book is issuedimmediately to the requesting member. If the book is

not currently available, the member can reserve thesame. If the member fails to return the book after thespecified period and/or loses or damages the book, heis required to make the loss/damage. Alternatively, atthe end of the period, the borrower may renew theissue.Membership is accorded for a period of one year, at theend of which the member has the option to renew hismembership.


9/43

Use Case Diagrams 9


Use Case - Example (contd.)

ReserveBook IssueBook ReturnBook

CollectDues

Use C a ses :

RenewIssue RnwMship

ViewCatalog


10/43

Use Case Diagrams 10


Purpose of Use CasesTo capture functional requirements of asystem.To communicate with end users and domain

experts.To design test cases for validating systemfunctionality.To provide traceability from requirementsinto actual classes and operations.To drive the development process.To plan iterations and releases


11/43



ActorsEntities external to the system who interact withthe system.

Communicate with the system by sending

and/or receiving messages.R epresents a role, not individuals; can be aperson or a device or another system.

An actor may participate in many use cases; ause case may have several actors participatingin it.

Notation:


12/43



Finding ActorsW ho uses the main functionality of the system?

W ho needs support from the system?W ho will need to maintain, administrate, and keepthe system working?

W hich hardware devices the system needs tohandle?

W hich other systems does the system need tointeract with?


13/43



Actors - ExampleThe Bookworm is a circulating library that lends booksfor a specified period of time. Books are lent tomembers only. If available, the book is issued forthwithto the requesting member. If the book is not currently

available, the member can reserve the same. If themember fails to return the book after the specifiedperiod and/or loses or damages the book, he is requiredto make good the loss/damage.

Ac tor s :

Librarian Member


14/43



Use Case Diagram A graphical representation of the Use Cases of asystem, its actors, and the interaction betweenthem.

It depicts the system boundary.Diagram Model elements

Actors

Use casesR elationships

between Actors and Use Casesbetween Use Cases themselves


15/43



Use Case Diagram: Example

Librarian Member

IssueBook

CollectDues

R eturnBook

R eserveBook

R enewIssue

R nwMship

ViewCatalog

R egMembership


16/43



Use Case DescriptionIs a text description of the use case functionalityin the user language and terminology

No specific UML format

Describes WH AT and not HOWTypically includes:

O bjectives of the use caseH

ow the use case is initiatedThe flow of events Alternate flow in the use caseH ow the use case finishes with a value to the actor


17/43



Flow of EventsUse Case is an abstraction of behaviour (set of sequences).

The behaviour of the Use Case can be described

by a flow of events - which spells out in slightdetail what exactly the Use Case does.

Typically, flow of events specifies:the main flow of events (what happens and inwhat order when all is well).

alternate flow(s) of events (what happens and inwhat order when something goes wrong).


18/43



Use Case Description - Example

Use C a se : ViewCatalog Ac tor s : Librarian, Member

Purpo se : Browse the Catalog of books and journalsOv e rvi ew : Allows the librarian or a member to browse

through the catalog of books. The catalogcontains details such as ..

M ain flow of events :The use case begins when either actor starts browsing for a book. Theycan specify a specific book by Title, Author or Publisher. All bookssatisfying the specified criteria are displayed to the user (Librarian or Member).


19/43




UsesExtends

Extends relationship : extendsuse case A extends use case B when usecase A is similar to use case B, but hassome additional functionality.extended use cases are typically used todescribe variations in the normal flow of events described by a general use case


20/43




Uses relationship : usesuse case A uses use case B when usecase B is a chunk of behavior that is

required across several use cases.common behavior in several use casescan be factored out into a single use casethat is used by the other use cases


21/43



extends and uses : Example

Librarian

Member

IssueBook

R eturnBook

R eserveBookR enewIssue

R nwMship

UpdtBooks-in-hand

uses

usesCollectDues

Permit Transaction

uses usesBkR eserved

ChgsDue

extends

extends


22/43



Use Cases and Scenarios A Use Case actually describes a set of sequences [of actions].Each sequence represents one possible flow

of actions in using the system.Each sequence is called a Scenario.

A Scenario is basically one instance of a usecase.

a Scenario is to a Use Case, what an Object isto a Class.


23/43



Steps in Use Case ModelingEstablish the system boundary. Identify the actors thatuse the system.

For each actor, consider what functions the systemprovides for each Actor.

R epresent each function as a Use case. Name the UseCase with the name of the function.

Connect the Actor to all Use Cases initiated by the Actor.

If the Use Case requires participation by other Actors,connect these actors also to the Use Case.


24/43



Steps in Use Case ModelingFactor optional or exceptional behavior in a Use Case,into a separate Use Case and connect this new UseCase with the main Use Case by extends relationship.

Analyze all Use Cases and identify common functionsacross groups of Use Cases. Factor each such commonfunction into a separate Use Case and connect thiscommon Use Case with the other Use Cases that use it,by uses relationship.


25/43



Alternative Steps1. Identify who is going to be using the system

directly. These are the actors.2. Pick one of those actors.

3. Define what that actor wants to do with thesystem. Each thing that the actor does withthe system becomes a use-case.

4. For each use-case, decide on the most usualcourse of events when that actor is using thesystem.


26/43



6.Describe that basic course in the descriptionfor the use case. Describe it in terms of whatthe Actor does and the system does inresponse. Use implementation-independentterms.

7. W hen the basic course is described, consider alternates courses of events and add those asextending use-cases.

8.Extract common courses as "used" use-cases.

R epeat steps 2 - 7 for all other actors.


27/43



Use Case R ealizationThe use case diagram is an external view of thesystem

A use case is realized in a collaboration

A collaboration shows an internalimplementation- dependent solution of a usecase in terms of:

classes/objectstheir relationshipstheir interaction


28/43



Use Case R ealization

U se Case A:ClassA :ClassB

:ClassC :ClassD

1: msg1

2: msg2

3: msg3

A Collaboration

Class A

Oper1()...

Class B

Oper2()...

Class C

Oper3()...

Use Case A description1. Step 1

2. Step 23. ...


29/43



R ealization: Example

Left O uter Join

:UserInterface

:Parser

: CodeGenerator

:O ptimiser

1: parse(query)

2:optimize(postfix query)

3: GenCode(query tree)

: R untimeProcessor

4: Execute(code)

: Database


30/43



Use-Cases: P oints to P onder If I have a Use-Case that is associated with more thanone actor such that each actor has a different interest inthe same Use-Case, how do I model it?

M odel it as just one Use-Case in the top-level Use-Case Diagram. Also examine the functionality encapsulated inthe Use-Case to find out whether some common behavior can be factored out.

Is it necessary to explicitly associate an actor in aspecialization with the Use-Cases that the super-type is

associated with?N o; the generalization hierarchy implies that the

specialized actor is also associated with those Use-Cases


31/43



Use-Cases: P oints to P onder Does every actor become a class?

There is no such relationship. If some data/state of theactor needs to be stored by the system, then the actor findsexpression as a class.

Is there any mapping between a Use-Case and a classor set of classes?

There is no direct mapping that can be established. However, associated with each Use-Case is a Sequence Diagram and a Collaboration Diagram. These model theclasses and the interaction between them.


32/43



Use Case - ExampleIndian R ailways provides for advance reservation on alllong-distance travel. The passenger seeking reservationof berth or seats should purchase the tickets fromR ailway R eservation O ffices or Authorized Travel

Agency only. To make an advance booking, thepassenger is expected to fill in a prescribed applicationform and submit it to the reservation counter with theappropriate amount. Advanced R eservations are madeup to 60 days in advance for all trains, for all classesexclusive of the day of departure of trains. An individualcan book only up to six passengers on one requisitionform provided all passengers are for the samedestination and for the same train.


33/43



Use Case - Example (contd.)Indian R ailways wishes to develop a ticketing andreservation system. This must support advance bookingof tickets, cancellation of tickets and change of class of aticket. All these are handled by a R eservation Clerk.

The system will also have a web-interface where userscan register themselves and purchase tickets online.They can pay either by using their online bankingaccount or by credit card or by VPP. R eservations made

over the internet can only be cancelled across thecounter.

The system will also have a querying facility that allowsusers to check train time-tables, fares and availability of

tickets.


34/43



Use Case - Example (contd.)

MakeR eservation

CancelR eservation Modify Class

Print Ticket

Use C a ses :

Q ueryTimetable Check Fare

R egister as Member


35/43



Actors - ExampleIndian R ailways wishes to develop a ticketing andreservation system. This must support advance bookingof tickets, cancellation of tickets and change of class of a ticket.

The system will also have a web-interface where userscan register themselves and purchase tickets online.

Ac tor s :

R eservationClerk

Passenger


36/43



Use Case Diagram: Example

R eservationClerk

Passenger

MakeR eservation

Modify Class

Print Ticket

Q ueryTimetable

Check Fare

CancelR eservation

R egister as Member


37/43



extend and include : Example

R eservationClerk

Passenger

Make R eservation

Cancel R eservation

UpdateSeat Availability

include

include

Generate PaymentFailure Notice

extendFactor out common behaviour in a Use Case that other Use

Cases include.

Describe variations fromNormal Flow in a

extending Use Case


38/43



Case on Library


39/43



Case on Video StoreTheimage cannotbe displayed.Your computer may nothaveenough memory toopen theimage,or the imagemay havebeen corrupted. Restartyour computer,and then open thefileagain.If thered x stillappears,you may havetodeletethe imageand then insertit again.


40/43



Case on Contact ManagementTheimage cannotbe displayed.Your computer may nothaveenough memory toopen theimage,or the imagemay havebeen corrupted. Restartyour computer,and then open thefileagain.If thered x stillappears,you may havetodeletethe imageand then insertit again.


41/43



SummaryR equirements elicitation is the stepping stoneto the project.

R equirements must clearly and completely

understood by the entire project team.Must be reviewed for semantic correctnessand completeness.

R equirements elicitation must focus on theWH AT of the system and must be documentedin the users vocabulary.


42/43



SummaryUse Case Diagrams is the UML mechanism for requirements capture.

Use Case Diagrams are a graphical

presentation of the actors in the domain andthe use cases initiated by them.

Use cases are abstractions of discretebehaviour exhibited by the system; perform aspecific goal for an actor.

An actor is an abstraction of a role played byanyone or anything interacting with the system.


43/43



Summary A use case is essentially a set of sequence of actions. A specific sequence of this set of sequences is called a scenario.

A scenario is documented as Flow of Events; each use case has a main flow of events and alternate flow of events.

Common behaviour across use cases can befactored out and is then either used or extended by other use cases.

Documents

37669127 UML Use Case Diagrams