Use Case Modeling

Use Case Modeling

• What is use case modeling?• Core concepts• Diagram tour• When to model use cases• Modeling tips• Example: Online HR System

Use Case modelling

• use case model:

Gives the view of a system that emphasizes the behavior as it appears to outside users. – A use case model partitions system

functionality into transactions (‘use cases’) that are meaningful to users (‘actors’)

– .

Use case diagram• They simply illustrate the main functionality of the

SUD and the actors that interact with it.• The diagram includes Actors which are people or

things that derive value from the system and use cases that represent the functionality of the system.

• Actors and use cases are separated by the system boundary and connected by lines representing associations.

• Creating a use case diagram is a four step process where by the analyst draws the system boundary, adds the use cases to the diagram,identifies the actors and then finally adds appropriate associations to connect use cases and actors.

Use Case Modeling: Core Elements

Construct Description Syntax

use case A sequence of actions, including variants, that a system (or other entity) can perform, interacting with actors of the system.

actor A coherent set of roles that users of use cases play when interacting with these use cases.

system boundary

Represents the boundary between the physical system and the actors who interact with the physical system.

UseCaseNam e

ActorNam e

Construct Description Syntax

association The participation of an actor in a usecase. i.e., instance of an actor andinstances of a use case communicatewith each other.

extend A relationship from an extension usecase to a base use case, specifyinghow the behavior for the extensionuse case can be inserted into thebehavior defined for the base usecase.

generalization A taxonomic relationship between amore general use case and a morespecific use case.

Use Case Modeling: Core Relationships

<<extend>>

Construct Description Syntax

include An relationship from a base use caseto an inclusion use case, specifyinghow the behavior for the inclusion usecase is inserted into the behaviordefined for the base use case.

Use Case Modeling: Core Relationships (cont’d)

<<include>>

• Shows use cases, actor and their relationships

• Use case internals can be specified by text and/or interaction diagrams

• Kinds– use case diagram– use case description

Use Case Diagram Tour

Fig. 3-44, UML Notation Guide

Customer

Supervisor

SalespersonPlace

Establishcredit

Check

Telephone Catalog

F ill orde rs

Shipping Clerk

status

order

Use Case Diagram

Fig. 3-45, UML Notation Guide

Use Case Relationships

additional requests :

OrderProduct

SupplyArrange

«include»«include»«include»

RequestCatalog

«extend»Extension points

PaymentCustomer Data

after creation of the order

Place Order

1 * the salesperson asks forthe catalog

Fig. 3-46, UML Notation Guide

Actor Relationships

EstablishCredit

PlaceOrder

Salesperson

Supervisor

1 *

1 *

System behavior• The behavior of the system under development is

documented in a use case model.• The use case model illustrates the system’s

intended functions [Use cases] its surroundings [actors] and the relationships between the use cases and actors (use case diagram).

• The most import role of the use case model is communication

• It provides a vehicle used by the customers or end users and the developers to discuss the system’s functionality and behavior

Actors

• Actors are not part of the system– They represent anyone or anything that must interact

with the system.

– Actors are the users of the system

• An actor may;– Only input information to the system

– Only receive information from the system

– Input and receive information to and from the system.

How to identify actors

• Typically the actors are found in the problem statement and by conversations with the customers and domain experts.

• The following question may help you identify the actors of the system.– Who is interested in a certain requirement?– Where in the organisation is the system used?– Who will be benefit from the use of the system?– Who will supply the system with this information, use

this information, and remove this information

How to identify actors

• Who will support and maintains the system?

• Does the system use an external resource?

• Does one person play several diffferent rolles?

• Do several people play the same role?

• Does the system interact with a legacy system?

How do you represent?

• In UML an actor is represented as a stickman

ActorNam e

Actors In the ESU course registration system

• Students want to register for courses• Professors want to select courses to teach• The registrar must maintain all the information

about courses, professors and students.• The billing system must receive billing

information from the system.• Based on the answers to the questions posed the

following actors have been identified:– Student, Professor, registrar, and the Billing system.

Actor documentation

• A brief description for each actor should be added to the model.

• The description should identify the role of the actor plays while interacting with the system.

Actor documentation-example

• Student: A person who is registered to take classes at the university

• Professor- A person who is certified to teach classes at the university

• Registrar- the person who is responsible for the maintenance of the course registration system.

• Billing system-the external system responsible for the student billing.

Use Cases

• Use cases model a dialogue between an actor and the system.

• A use case is a task which an actor needs to perform with the help of the system.

• They represent the functionality provided by the system that is– What capabilities will be provided to an actor by the

system.– The collection of use cases for a system constitute all

the defined ways.

Use case definition

• A sequence of transactions performed by a system that yields a measurable result of values for a particular actor.

• The following questions may use to help identify the use cases for a system.– What are the tasks of each actor?– Will any actor create, store change, remove or read this

information?– What use cases will create, store change, remove or read this

information?– Will any actor need to inform the system about sudden

external changes.

Use case definition

– Does any actor need to be informed about certain occurrences in the system

– What use cases will support and maintain the system?

– Can all functional requirements be performed by the use cases?

Use case representation

• In UML a use case is represented as an oval as shown below.

UseCaseNam e

Use cases in the ESU course registration system

• The following needs must addressed by the system:– The student actor needs to use the system to register for

courses.– After the course selection process is completed, the billing

system must be supplied with billing information.– The professor actor needs to use the system to select the

courses to teach for a semester and must be able to receive a course roster from the system

– The registrar is responsible for the generation of the course catalog for a semester and for the maintenance of all the information about the curriculum, the students, and the professors needed by the system

Use cases

• Based on the needs identified, the following use cases have been identified.– Register for courses– Select courses to teach– Request course roster– Maintain professor information– Maintain student information– Create course catalog

System Boundary

• This can be useful when modelling a complex system which is split into different subsystems.

• You may have one use case diagram for each subsystem.

When to model use cases• Model user requirements with use cases.• Model test scenarios with use cases.• If you are using a use-case driven method

– start with use cases and derive your structural and behavioral models from it.

• If you are not using a use-case driven method– make sure that your use cases are consistent with

your structural and behavioral models.

Use case relationships• An association may exist between an actor and a use

case. • This type of association is referred to as a communicate association since it represents communication between an actor and a use case.

• May be in both directions (Actor to use case and use case to actor.

• The navigation direction represents who initiates the communication.

• An association is represented as a line connecting the related elements.

Main ESU use case diagram

Register forcourses

Student

«uses»

Billing system

Select Courses toteach

Request courseroster

Professor

Create coursecatologue

Maintain Professorinformation

Maintain Courseinformation

Maintain studentinformation

Registra

«uses»

«uses»

«uses»

«uses»

«uses»

«uses»

«uses»

Register forcourses

Student

«uses»

Billing system

«uses»

Select Courses toteach

Request courseroster

Professor

«uses»

«uses»

Create coursecatologue

Maintain Professorinformation

Maintain Courseinformation

Maintain studentinformation

Registra

«uses»

«uses»

«uses»

«uses»

Types of relationships

• Extend

• Include

• Note: Multiple use case may share pieces of the same functionality.– This functionality is placed in a separate use

case rather than documenting it in every use case that needs it.

The Include relationship

• Include relationships are created between the new use case and any other use case that uses its functionality.

• E.g each use case in the ESU course registration system starts with the verification of the user.

• This functionality can be captured in a user verification use case, which is then used by other use cases as needed.

The extend relationship

• Used to show – optional behavior

– Behavior that is run only under certain conditions such as triggering an alarm

– Several different flows that may be run based on actor selection

• E.g A use case that monitors the flow of packages on a conveyor belt can be extended by a trigger Alarm use case if the packages jam

Example

Select course toteach

Request courseroster

Validate user

«uses»

Professor

«uses»«uses»

«uses»

<<include>><<include>>

Stereotype• Provides the capability of extending the basic modelling

elements to create new elements.• Stereotype elements are included within guillemets(<<

>>) and placed along the relationship line.• Stereotypes are used to create the needed use case

relationships.• The stereotype<<communicate>> may be added to an

association to show that the association is a communicate association.– This is optional since an association is the type of relationship

allowed between an actor and a use case.– Include and extend relationships must use stereotypes since

they are both represented by a dependence relationship.

Use case relationships

ActorNam e

<<communicate>>

<<include>>

<<extend>>

External use case

The included use case

A base use case

Another base use case

Use Case Modeling Tips• Make sure that each use case describes a significant chunk of system

usage that is understandable by both domain experts and programmers

• When defining use cases in text, use nouns and verbs accurately and consistently to help derive objects and messages for interaction diagrams

• Factor out common usages that are required by multiple use cases– If the usage is required use <<include>>

– If the base use case is complete and the usage may be optional, consider use <<extend>>

• A use case diagram should– contain only use cases at the same level of abstraction

– include only actors who are required

• Large numbers of use cases should be organized into packages

Example: Online HR System

Online HR System

LocateEm ployees

UpdateEm ployee

Profile

Update Benefits

Access TravelSystem

Access PayRecords

Em ployee

M anager

Healthcare P lan System

{if currentM onth = O ct.}

{readO nly}

Insurance P lan System

Online HR System: Use Case Relationships

Update M edicalP lan

Update DentalP lan

Update Benefits______________Extension pointsbenefit options:

after required enrollm ents

UpdateInsurance P lan

Em ployee

<<include>> <<include>> <<include>>

ElectReim bursem entfor Healthcare

Elect StockPurchase

<<extend>>em ployee requestsstock purchase option

<<extend>>em ployee requestsreim bursem ent option

extensioncondition

extension pointname andlocation

• Use Case Name• Primary Actor• Stakeholders and Interests:• Preconditions• Main Success Scenario (or Basic Flow) • Extensions (or Alternative Flows) • Special Requirements• Technology and Data Variations List

FULLY DRESSED USECASE MODEL

Online HR System: Update Benefits Use Case Actors: employee, employee account db, healthcare plan system, insurance plan systemPreconditions:

Employee has logged on to the system and selected ‘update benefits’ option

Basic course System retrieves employee account from employee account db System asks employee to select medical plan type; include Update Medical Plan. System asks employee to select dental plan type; include Update Dental Plan. …

Alternative courses If health plan is not available in the employee’s area the employee is informed and asked to select another plan...

Use Case Description: Change Flight

Actors: traveler, client account db, airline reservation systemPreconditions:

Traveler has logged on to the system and selected ‘change flight itinerary’ option

Basic course System retrieves traveler’s account and flight itinerary from client account database System asks traveler to select itinerary segment she wants to change; traveler selects itinerary segment. System asks traveler for new departure and destination information; traveler provides information. If flights are available then … System displays transaction summary.

Alternative courses If no flights are available then …

Note:Use case detail should be written in a third person, active-voice English.

Explaining the sections• Explaining the sections:

– Preface Elements:• Only place elements at the start which are important to read before the

main success scenario.

– Primary Actor: principal actor that calls upon system services to fulfil a goal.

– Stakeholders and interests list is very important. It creates the basis upon which the system requirements are identified. This is because the system under development operates a contract between the stakeholders, with the use cases detailing the behavioural parts of that contract. The use cases as a contract for behaviour, captures all and only the behaviours related to satisfying the stakeholders’ interests.

– The question of our interest is what should be included in the use case?

Explaining the Sections– The use case should include anything that satisfies all the

stakeholders’ interests.– By starting with the stakeholders and their interests before writing

the remainder of the use case, we have a method to remind us what the more detailed responsibilities of the system should be. For example is it possible to identify the responsibility for sales person commission handling if you did not list the salesperson as a stakeholder and specified his or her interests?

– The stakeholder interest viewpoint provides a thorough and methodical procedure for discovering and recording all the required behaviours.

• Preconditions and Success Guarantee (Post conditions)– Pre Conditions:state what must always be true before beginning a

scenario in the use case. Preconditions are not tested within the use case; rather, they are conditions that are assumed to be true.

Explaining the sections– A precondition implies a scenario of another use case that

has successfully completed, such as logging in or in more general “cashier has been identified and authenticated”.

– Note that there are many other conditions that have to be true but not all them need to be mentioned. We only mention those with high practical value. There is not practical value involved in stating that the system power must be on.

– We only state the noteworthy assumptions that the use case writer thinks readers should be alerted to.

• Success Guarantee (or Post conditions)– State what must be true on successful completion of the use

case.– Either consider the main success scenario or some alternate

path. – The guarantee should meet the needs of all the stakeholders.

Explaining the sections

• Main success scenario and steps (or Basic Flow)– It is called the happy path scenario.

– It describes the typical success path that satisfies the interests of the stakeholders.

– It is advisable to defer all conditional and branching statements to the extensions section

– Step one of the success scenario indicates the trigger event that starts the scenario.

– It is a common idiom to always capitalize the actors’ names for ease of identification.

– Note also the style used for steps that have to be repeated.

Explaining the sections• Extensions (or Alternative Flows)

– These are equally important.

– Indicate all the other branches or scenarios or both success and failure.

– These are more complex and longer than the success scenario section.

– These are also called alternative flows.

– The combination of the happy path and the extension flows should satisfy nearly all the interests of the stakeholders. We state nearly because some interests may best be captured as non functional requirements expressed in the supplementary specification rather than the use cases.

– Extension scenarios are branches from the main success scenario, and so can be notated with respect to it

– Example at step 3 of the main success scenario there may be an invalid item identifier, either because it was incorrectly entered or unknown to the system. Its extension is labeled 3a. It first indicates the condition and then the response.

Explaining the sections– At the end of the extension handling, by default the scenario merges

back with the main success scenario, unless the extension indicates otherwise such as by halting the system.

– If an extension appears too complex, we try to define it as a separate use case.

• Special Requirements– If a non functional requirement, quality attribute or constraint relates

specifically to a use case, record it with the use case. These include qualities such as performance, reliability and usability and design constraints (I/O devices) that have been mandated or considered likely.

– Many analysts find it useful to ultimately consolidate all non functional requirements in supplementary specification, for content management, comprehension and readability, because these requirements have to be considered as a whole during architectural analysis.

Explaining the sections• Technology and Data variation List

– Often there are technical variations in how something must be done, but not what, and it is noteworthy to record this in the use case.

– Example is a technical constraint imposed by stakeholders regarding input or output technologies. E.g. a stake holder may suggest the POS must support Credit Account Input using a card reader and the key board.

– These are early design decisions or constraints. It is skilful to avoid premature design decisions but sometimes they are obvious or unavoidable especially concerning I/O technologies.

– This list is also available for us to understand the data variations, so it is a place we record anything to do with data variation schemes such as UPCs or, encoded in bar code system

– This section should not contain multiple steps to express varying behaviour for different cases. If that is necessary include it in the extension section.

• UML is effective for modeling large, complex software systems

• It is simple to learn for most developers, but provides advanced features for expert analysts, designers and architects

• It can specify systems in an implementation-independent manner

• 10-20% of the constructs are used 80-90% of the time• Structural modeling specifies a skeleton that can be refined

and extended with additional structure and behavior• Use case modeling specifies the functional requirements of

system in an object-oriented manner

Ideas to Take Away