Overview of Use Cases & Examples

1

• A use case is a way in which a user can use a system, i.e., perform some function on a system. • A use case describes a goal a user may want to do with the system and the sequence of steps a user does in the system to accomplish the goal, and also, the corresponding system response to each of the user’s actions. • A user of the system is called an actor, because it acts on the system. An actor can be a person or thing (software or hardware). • Use cases describe the functionality of a system, i.e., what the system does. And from this point of view, use cases specify the requirements of the system. • A complete set of use cases represents all of the system’s functionality from the point of view of an actor. 2

Ways of Describing Use Cases • Two ways: • Text Description • Diagram Description

3

• Title (goal) • Describe the overall goal of the use case

• Actors • Identify the actors for the use case. • A given use case may pertain to a smaller subset of actors or to all actors.

• Interaction • A sequential, numbered, and point form list of interactions between actor and system.

4

• Three main components • Actor

Diagrammatic Description

• Stick person

• Use Case • Oval, with text description inside • Description starts with a verb.

Use Case Description User

• Association • Line joining the actor and the use case

Description of use case Actor

Use Case

Association 5

 A use case describes what a user does to perform a particular task that the system offers, and also, it describe the system’s visible response.  Step 1: list all the actors. Actors are the users and/or other systems that will use the system.  Step 2: determine the tasks that each actor will need to do with the system. Each task is called a use-case because it represents a particular use of the system.  Step 3: For each use case, develop a description (in words) and/or diagram. In it, specify the 

Goal, actors, and sequence of steps

6

Example: Temperature Server • Consider an MX7cK board which senses temperature at 25 points in a sensing grid. • Consider designing a user interface (UI) on a PC connected to the system through a network. • What functionality should the UI present to the user? PC (UI) User

Sensor

Network

25

25 Sensor Temperature Sensing Grid

7

• Ordinary user • Any user who wants to use the temperature sensing system.

• Administrative user • May be required to do administrative tasks, which should not be done by an ordinary user, such as • Calibrate temperature for the sensors. • Set the temperature sampling period, i.e., the time between samples • Shutdown and restart the server for maintenance, etc.

8

• Set IP address and/or port of server – There could be many servers, each of which control their grid of sensors

• Connect to server • Disconnect from server • Get temperature readings • Calibrate temperature sensors • Others?

9

• Set ID of the server • The goal is to allow a user to specify the IP address and port number of the server.

• Actors • Any user, i.e., ordinary user or administrative user, may perform this use case.

• Interaction ACTOR 1. Actor enters an IP address and port number of the server.

SYSTEM 2. System acknowledges and displays back the entered IP address and port number of the server. 10

Use Case 2: Get Temp. Readings • Get temperature readings • The goal is to allow a user to obtain temperature sensor readings, but also which sensors to obtain.

• Actors • Any user, i.e., ordinary user or administrative user, may perform this use case.

• Interaction ACTOR 1. Actor specifies the combination of temperature sensor readings to get.

SYSTEM 2. System displays the temperature readings of the requested sensors. 3. System also displays the time stamp of when the readings were taken. 11

• Describe other use cases, if any.

12

“Set Server ID” Use Case Diagram Redundant Method • Note: this is redundant, especially if there are many actors with the same use case. • A better way to show this is through “Actor Generalization.”

Set IP and port of server User

Set IP and port of server Administrative User 13

Actor Generalization Relationship Useful in Defining Overlapping Roles Between Actors An actor is represented by a ‘stick person’, even if the actor is not a human being (could be software or hardware, or another system). User The generalization relationship between actors (if one exists) is represented by connecting the actors with lines, with the closed triangle pointing to the super actor.

A general name of the actor is written down underneath the stick person figure. Customer

Administrator 14

“Set Server ID” Use Case Diagram Better Way • The Administrator inherits the use case of the Ordinary user.

Set IP and port of server Ordinary

Administrative 15

 Used to handle exceptional or special cases.  For example, for the use-case called: “Set Server ID” – The user may enter an IP address which is incorrectly specified (i.e., not in 4 octet dot format)

 An extension allows keeping the description of the basic use case simple. 16

Set Server Id Extension Use Case Text Description • Set ID of the server • The goal is to allow a user to specify the IP address & port number of the server.

• Actors • Any user, i.e., ordinary user or administrative user, may perform this use case.

• Interaction ACTOR 1. Actor enters an IP address and port number of the server.

SYSTEM 2. If IP address and port number correct, System acknowledges and displays the requested IP address and port number of the server. 3. Else, the system displays a message that indicates which part (IP and/or port number) is incorrect and why. 17

“Set Server ID” Use Case Diagram With Extension

Set Server ID OD User

Specify ID incorrectly Administrator 18

 Used to express commonality between two or more different use cases.  Two or more uses cases may share a component behaviour.  Even very different use cases can share sequence of actions.

 Instead of repeating the component behaviour, the uses cases that can share the common component.  For example, the “Get temperature readings” and “Calibrate temperature sensors” would share a component “specify sensors.” 19

With Inclusion (And Administrator Specialization) Get temperature readings OD User

Specify sensors



Administrator

Calibrate temperature sensors 20

Summary: Use-case Relationships (Three Relationships)  Generalization  Actor and Use Case

 Extension  There can be many variations (scenarios) of the basic use case

 Inclusion  Two or more use cases may have some common sub components

21

• Help to define the scope of the system • Used to plan the development process – Allocation of uses cases to sub groups of developers – Hardware/software components breakdown

• Used to develop and define the requirements • Used to generate test cases for TPP • Used to structure user manuals 22