Use Case Modeling

Use Case ModelingWhat is use case modeling?Core conceptsDiagram tourWhen to model use casesModeling tipsExample: Online HR System

Use Case modellinguse 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 diagramThey 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.

Use Case Modeling: Core Relationships

Construct

Description

Syntax

association

The participation of an actor in a use case. i.e., instance of an actor and instances of a use case communicate with each other.

extend

A relationship from an extension use case to a base use case, specifying how the behavior for the extension use case can be inserted into the behavior defined for the base use case.

generalization

A taxonomic relationship between a more general use case and a more specific use case.

Use Case Modeling: Core Relationships (contd)

Construct

Description

Syntax

include

An relationship from a base use case to an inclusion use case, specifying how the behavior for the inclusion use case is inserted into the behavior defined for the base use case.

Use Case Diagram TourShows use cases, actor and their relationshipsUse case internals can be specified by text and/or interaction diagramsKindsuse case diagramuse case description

Use Case DiagramFig. 3-44, UML Notation Guide

Use Case RelationshipsFig. 3-45, UML Notation Guideadditional requests :OrderProductSupplyArrangeincludeincludeincludeRequestCatalogextendExtension pointsPaymentCustomer Dataafter creation of the orderPlace Order1*the salesperson asks forthe catalog

Actor RelationshipsFig. 3-46, UML Notation Guide

System behaviorThe behavior of the system under development is documented in a use case model.The use case model illustrates the systems 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 communicationIt provides a vehicle used by the customers or end users and the developers to discuss the systems functionality and behavior

ActorsActors are not part of the systemThey represent anyone or anything that must interact with the system.Actors are the users of the systemAn actor may;Only input information to the systemOnly receive information from the systemInput and receive information to and from the system.

How to identify actorsTypically 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 actorsWho 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

Actors In the ESU course registration systemStudents want to register for coursesProfessors want to select courses to teachThe 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 documentationA 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-exampleStudent: A person who is registered to take classes at the universityProfessor- A person who is certified to teach classes at the universityRegistrar- the person who is responsible for the maintenance of the course registration system.Billing system-the external system responsible for the student billing.

Use CasesUse 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 isWhat 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 definitionA 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 definitionDoes any actor need to be informed about certain occurrences in the systemWhat use cases will support and maintain the system?Can all functional requirements be performed by the use cases?

Use case representationIn UML a use case is represented as an oval as shown below.

Use cases in the ESU course registration systemThe 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 systemThe 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 casesBased on the needs identified, the following use cases have been identified.Register for coursesSelect courses to teachRequest course rosterMaintain professor informationMaintain student informationCreate course catalog

System BoundaryThis 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 casesModel user requirements with use cases.Model test scenarios with use cases.If you are using a use-case driven methodstart with use cases and derive your structural and behavioral models from it.If you are not using a use-case driven methodmake sure that your use cases are consistent with your structural and behavioral models.

Use case relationshipsAn 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

Billing system

Select Courses toteach

Request courseroster

Professor

Create coursecatologue

uses

Maintain Professorinformation

Maintain Courseinformation

Maintain studentinformation

Registra

uses

uses

uses

uses

uses

uses

uses

Register forcourses

Student

Billing system

uses

uses

Select Courses toteach

Request courseroster

Professor

uses

uses

Create coursecatologue

Maintain Professorinformation

Maintain Courseinformation

Maintain studentinformation

Registra

uses

uses

uses

uses

Types of relationshipsExtendIncludeNote: 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 relationshipInclude 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 relationshipUsed to show optional behaviorBehavior that is run only under certain conditions such as triggering an alarmSeveral different flows that may be run based on actor selectionE.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

Professor

Select course toteach

Request courseroster

Validate user

uses

uses

uses

uses

StereotypeProvides 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 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

External use caseThe included use caseA base use caseAnother base use case

Use Case Modeling TipsMake sure that each use case describes a significant chunk of system usage that is understandable by both domain experts and programmersWhen defining use cases in text, use nouns and verbs accurately and consistently to help derive objects and messages for interaction diagramsFactor out common usages that are required by multiple use casesIf the usage is required use If the base use case is complete and the usage may be optional, consider use A use case diagram shouldcontain only use cases at the same level of abstractioninclude only actors who are requiredLarge numbers of use cases should be organized into packages

Example: Online HR System

Online HR System: Use Case Relationships

Use Case NamePrimary ActorStakeholders and Interests:PreconditionsMain Success Scenario (or Basic Flow) Extensions (or Alternative Flows) Special RequirementsTechnology and Data Variations ListFULLY 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 optionBasic 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 employees area the employee is informed and asked to select another plan...

Use Case Description: Change FlightActors: traveler, client account db, airline reservation systemPreconditions: Traveler has logged on to the system and selected change flight itinerary optionBasic course System retrieves travelers 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 sectionsExplaining 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 SectionsThe 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 sectionsA 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 sectionsMain 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 sectionStep 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 sectionsExtensions (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 itExample 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 sectionsAt 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 RequirementsIf 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 sectionsTechnology and Data variation ListOften 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 systemThis section should not contain multiple steps to express varying behaviour for different cases. If that is necessary include it in the extension section.

Ideas to Take AwayUML is effective for modeling large, complex software systemsIt is simple to learn for most developers, but provides advanced features for expert analysts, designers and architectsIt can specify systems in an implementation-independent manner10-20% of the constructs are used 80-90% of the timeStructural modeling specifies a skeleton that can be refined and extended with additional structure and behaviorUse case modeling specifies the functional requirements of system in an object-oriented manner