FPGDST

OOSP (Object Oriented Software Engineering with Project)

Requirements Capture using UML Use Cases

C-DAC, 2009-10

FPGDST

OOSP (Object Oriented Software Engineering with Project)

Contents
Requirements Collection The UML Mechanism Actors Use cases Use Case Diagrams Use Case Documentation Template Steps in Use Case Modeling Use Case Realization Summary
C-DAC, 2009-10 2

FPGDST

OOSP (Object Oriented Software Engineering with Project)

Requirements Collection

Requirements forms the basis of any software development activity. Denotes the user-requirements; defines the goals to be achieved.

Must be precisely and completely understood by the team providing the solution.
User requirements (and team members) keep changing; requirements must therefore be welldocumented.
C-DAC, 2009-10 3

FPGDST

OOSP (Object Oriented Software Engineering with Project)

Requirements Collection (contd.)

Requirements must be complete, consistent and unambiguous. Must be reviewed, reviewed again and reviewed yet again before the design and implementation begins. Involves the participation of domain-experts to ensure that the requirements have been correctly understood. captures the WHAT of the problem-domain.
C-DAC, 2009-10 4

FPGDST

OOSP (Object Oriented Software Engineering with Project)

The UML Mechanism

Use Case Diagrams

Captures the problem-domain in terms of functionality to be provided (Use Cases), and the roles (Actors) for whom these functions are performed. An abstraction of the problem-domain and a vehicle to facilitate a clear, well-articulated and unambiguous understanding of the problemdomain.
C-DAC, 2009-10 5

FPGDST

OOSP (Object Oriented Software Engineering with Project)

Actors

Entities external to the system who interact with the system. Communicate with the system by sending and/or receiving messages.

Represents a role, not individuals; can be a person or a device or another system.

An actor may participate in many use cases; a use case may have several actors participating in it. Notation:
C-DAC, 2009-10 6

FPGDST

OOSP (Object Oriented Software Engineering with Project)

Finding Actors

Who uses the main functionality of the system? Who needs support from the system? Who will need to maintain, administrate, and keep the system working?

Which hardware devices the system needs to handle?

Which other systems does the system need to interact with?

C-DAC, 2009-10

FPGDST

OOSP (Object Oriented Software Engineering with Project)

Use Case

Is an abstraction of a set of sequences that yield some functionality. Represents some user-visible function. Is always initiated by an actor. Describes the interaction between the actors and the system for a system function. Achieves a discrete goal for the actor. Notation:
ParseQuery
C-DAC, 2009-10 8

FPGDST

OOSP (Object Oriented Software Engineering with Project)

Purpose of Use Cases

To capture functional requirements of a system. To communicate with end users and domain experts. To design test cases for validating system functionality. To provide traceability from requirements into actual classes and operations. To drive the development process. To plan iterations and releases
C-DAC, 2009-10 9

FPGDST

OOSP (Object Oriented Software Engineering with Project)

Finding Use Cases

What functions does the system perform? What functions do the actors require?

What input/output does the system need?

C-DAC, 2009-10

10

FPGDST

OOSP (Object Oriented Software Engineering with Project)

Use Case Diagram

A graphical representation of the Use Cases of a system, its actors, and the interaction between them.
It depicts the system boundary.

Diagram Model elements Actors Use cases Relationships between Actors and Use Cases between Use Cases themselves
C-DAC, 2009-10 11

FPGDST

OOSP (Object Oriented Software Engineering with Project)

Relationships between Use Cases

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

C-DAC, 2009-10

12

FPGDST

OOSP (Object Oriented Software Engineering with Project)

Relationships between Use Cases Contd..

Uses relationship : uses use case A uses use case B when use case B is a chunk of behavior that is required across several use cases. common behavior in several use cases can be factored out into a single use case that is used by the other use cases

C-DAC, 2009-10

13

FPGDST

OOSP (Object Oriented Software Engineering with Project)

Use Case Description

Is a text description of the use case functionality in the user language and terminology No specific UML format Describes WHAT and not HOW

Typically includes: Objectives of the use case How the use case is initiated The flow of events Alternate flow in the use case How the use case finishes with a value to the actor
C-DAC, 2009-10 14

FPGDST

OOSP (Object Oriented Software Engineering with Project)

Flow of Events

Use 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 slight detail what exactly the Use Case does.
Typically, flow of events specifies: the main flow of events (what happens and in what order when all is well). alternate flow(s) of events (what happens and in what order when something goes wrong).

C-DAC, 2009-10

15

FPGDST

OOSP (Object Oriented Software Engineering with Project)

Use Cases and Scenarios

A Use Case actually describes a set of sequence of actions, specified in primary & alternate flows. 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 use case. a Scenario is to a Use Case, what an Object is to a Class.

C-DAC, 2009-10

16

FPGDST

OOSP (Object Oriented Software Engineering with Project)

Use Case Documentation Template

Name- Specifies the name of the use case Identifier -A unique identifier may be assigned, e.g. UC10 Description A couple of sentences describing the basic idea of the use case Preconditions -List the behavior the system should satisfy before the use case begins Assumptions -List assumptions, if any Primary Flow ( Main Flow) - Describe the normal processing path - Use case begins when - Use case ends when Alternate Flow- Describes the alternate course of actions, if any
C-DAC, 2009-10 17

FPGDST

OOSP (Object Oriented Software Engineering with Project)

Use Case Documentation Template Contd..

Post conditions -List the state (s) the system can be in when this use case ends Actors - List of actors that participate in the use case Included Use Case (s) - List of use cases that the current use case includes, if any. Extended Use Case (s) List of use cases, that this use case extends, if any Note: The behavior of dependent uses cases might become the pre-condition of a particular use case

C-DAC, 2009-10

18

FPGDST

OOSP (Object Oriented Software Engineering with Project)

Steps in Use Case Modeling

Identify & List the Actors: Identify the entities which interacts with
the system.

Identify Use cases: Identify the behavior of each actor. These

behavior represents use cases.

Draw Use case diagram: Connect all the use cases to the respective
actor to form a preliminary use case diagram.

Refine Use case diagram: Identify the dependency between the use
cases (using stereotypes include, extends etc.)

Document use cases: Write the description of each use cases to

identify various scenarios.
C-DAC, 2009-10 19

FPGDST

OOSP (Object Oriented Software Engineering with Project)

Example
The Bookworm is a circulating library that lends books and journals for a specified period of time. Books are lent to members only. If available, the book is issued forthwith to the requesting member. If the book is not currently available, the member can reserve the same. If the member fails to return the book after the specified period and/or loses or damages the book, he is required to make good the loss/damage. Alternatively, at the end of the period, the borrower may renew the issue.

Membership is accorded for a period of one year, at the end of which the member has the option to renew his membership.
C-DAC, 2009-10 20

FPGDST

OOSP (Object Oriented Software Engineering with Project)

Actors ?

Librarian

Member

Identify Behavior of each actor - Librarian: Issues Book, Collect Dues, Renew Issue,
View Catalog - Member: Return Book, Reserve Book, Renew membership, View Catalog
C-DAC, 2009-10 21

FPGDST

OOSP (Object Oriented Software Engineering with Project)

Use Cases:

ReserveBook

IssueBook

ReturnBook

CollectDues

RenewIssue

RnwMship

ViewCatalog

C-DAC, 2009-10

22

FPGDST

OOSP (Object Oriented Software Engineering with Project)

Use Case Diagram (Preliminary)

IssueBook ReturnBook CollectDues Librarian RenewIssue ReserveBook Member

RnwMship
ViewCatalog
C-DAC, 2009-10 23

FPGDST

OOSP (Object Oriented Software Engineering with Project)

Use Case Diagram (After Refinement)

IssueBook
includes Updt Books-in-hand includes

CollectDues Librarian

ReturnBook RenewIssue
Includes

ReserveBook
includes

Permit Transaction

RnwMship ChgsDue

Member

BkReserved

extends

extends
C-DAC, 2009-10

24

FPGDST

OOSP (Object Oriented Software Engineering with Project)

Use Case Description

Name Identifier Description : : : ViewCatalog LIS 1.0 Allows the librarian or a member to browse through the catalog of books.

Primary Flow : -Use case begins when actor starts browsing for book - Actor enters Title (E-1) or Author name (E-2) or Publisher name (E-3) - Books satisfying the specified criteria are displayed - Actor may select one of the results or may refine the search(E-4). Alternate Flow : E-1: If the specified title is not available, re enter the title or terminate the use case E-2: If the displayed result doesnt fetch the required book, re-enter the author name or terminate the use case E-3: If the displayed result doesnt fetch the required book, re-enter the publisher name or terminate the use case E-4: If the displayed results doesnt fetch the required book or many titles by the same publisher or author are displayed then the search may be refined. Actors : Librarian, Member
C-DAC, 2009-10 25

FPGDST

OOSP (Object Oriented Software Engineering with Project)

Use Case Realization

The use case diagram is an external view of the system

A use case is realized in a collaboration A collaboration shows an internal implementationdependent solution of a use case in terms of: classes/objects their relationships their interaction
C-DAC, 2009-10 26

FPGDST

OOSP (Object Oriented Software Engineering with Project)

Use Case Realization Contd..

A Collaboration
:ClassA 1: msg1 :ClassB

Use Case A

2: msg2 :ClassC 3: msg3 :ClassD

Use Case A description 1. Step 1 2. Step 2 3. ...

<<implements>> Class A

<<implements>> Class B

<<implements>> Class C

Oper1() ...

Oper2() ...

Oper3() ...

C-DAC, 2009-10

27

FPGDST

OOSP (Object Oriented Software Engineering with Project)

Realization: Example
:UserInterface

1: parse(query) :Parser 2:optimize(postfix query) :Optimiser

Left Outer Join

3: GenCode (query tree)

:

Code Generator
4: Execute(code) : Database : Runtime Processor

C-DAC, 2009-10

28

FPGDST

OOSP (Object Oriented Software Engineering with Project)

Use-Cases: Points to Ponder

If I have a Use-Case that is associated with more than one actor such that each actor has a different interest in the same Use-Case, how do I model it? Model it as just one Use-Case in the top-level Use-Case Diagram. Also examine the functionality encapsulated in the Use-Case to find out whether some common behavior can be factored out. Is it necessary to explicitly associate an actor in a specialization with the Use-Cases that the super-type is associated with? No; the generalization hierarchy implies that the specialized actor is also associated with those Use-Cases
C-DAC, 2009-10 29

FPGDST

OOSP (Object Oriented Software Engineering with Project)

Use-Cases: Points to Ponder Contd..

Does every actor become a class? There is no such relationship. If some data/state of the actor needs to be stored by the system, then the actor finds expression as a class. Is there any mapping between a Use-Case and a class or 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 the classes and the interaction between them.

C-DAC, 2009-10

30

FPGDST

OOSP (Object Oriented Software Engineering with Project)

Summary
Requirements elicitation is the stepping stone to the project. Requirements must clearly and completely understood by the entire project team. Must be reviewed for semantic correctness and completeness.

Requirements elicitation must focus on the WHAT of the system and must be documented in the users vocabulary.
Use Case Diagrams is the UML mechanism for requirements capture. Use Case Diagrams are a graphical presentation of the actors in the domain and the use cases initiated by them.
C-DAC, 2009-10 31

FPGDST

OOSP (Object Oriented Software Engineering with Project)

Summary
Use cases are abstractions of discrete behaviour exhibited by the system; perform a specific goal for an actor. An actor is an abstraction of a role played by anyone or anything interacting with the system. 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 be factored out and is then either used or extended by other use cases.
C-DAC, 2009-10 32

FPGDST

OOSP (Object Oriented Software Engineering with Project)

EXERCISE

Write the Use Case Descriptin for the use cases of Bookworm Library

C-DAC, 2009-10

33

FPGDST

OOSP (Object Oriented Software Engineering with Project)

References

The Unified Modeling Language User Guide

Grady Booch, James Rumbaugh, Ivar Jacobson Addison-Wesley (International Student Edition)

The Unified Modeling Language Reference Guide

Grady Booch, James Rumbaugh, Ivar Jacobson Addison-Wesley (International Student Edition)

C-DAC, 2009-10

34

FPGDST

OOSP (Object Oriented Software Engineering with Project)

E-Resources
http://pnguyen.tigris.org/SER4505.pdf http://www.sparxsystems.com/downloads/w hitepapers/The_Use_Case_Model.pdf http://www.bredemeyer.com/pdf_files/funct req.pdf http://www.parlezuml.com/tutorials/usecase s/usecases_intro.pdf