Use-case Modeling. Sharif Univ. of Tech.2 Outline Introduction Use case model Unified Modeling Language Actor Use cases UC Description Properties Relationships

Use-case Modeling

Sharif Univ. of Tech. 2

Outline

• Introduction• Use case model• Unified Modeling Language• Actor• Use cases• UC Description Properties• Relationships between Actors• Use Case Relationships


Introduction• The main purpose of the Requirements discipline is

to establish and maintain agreement with the customers and other stakeholders on what the system should do.

• To this aim, the discipline produces some artifacts such as: Vision, Stakeholder requests, requirements management plan, supplementary specifications, Use-Case model, etc.

• But the one which is more useful in the next steps of the process is Use-Case Model. Because it is a common language between people in the project team and also other stakeholders.


Introduction (Cont.)

• One of the most important artifacts of the requirements disciplines is use-case model.


Use case model

• Use cases are usually described in a textual document that accompanies a use case diagram; the combination of these use case diagrams & their supporting documentation is known as a use case model

• Illustrate a system’s intended functions (use cases), its surroundings (actors) & the relationships between them (use case diagrams)

• Are used to communicate• Provide a vehicle used by customers &

developers to discuss the system’s functionality


Unified Modeling Language

• The Unified Modeling Language (UML) is the industry-standard language for specifying, visualizing, constructing & documenting artifacts of complex software systems

• The UML:– Is a language– Applies to modeling and systems– Is based on the object-oriented paradigm


Actor• Someone or something that interacts with

the system (exchanges information with the system)

• Typically, an actor represents a role that a human, a hardware device, or even another system plays with a system.

• use case is always initiated by an actor• Finding the actors also means that you

establish the boundaries of the system • A single user may play more than one role


Identifying Actors

• Who will use the main functionality of the system?

• Who is interested in a certain requirement? • Who will need to maintain, administrate and

keep the system working?• With which other software/hardware systems

does the system need to interact?– Other computer systems– Other applications on the same computer (I.e. X

client/server)– Pitfall: don’t confuse interaction with input


Notation

OperationOperator

• A simple Use-Case Model:

• Operator is the only actor of the model.

• Operator is the initiator of the Operation Use Case.


Use cases• A use case describes a set of sequences, in which each

sequence represents the interaction of the things outside the system (its actors) with the system itself

• Use cases form the basis of how the system interacts with the outside world (users, other systems, etc.)

• “A use case is a sequence of transactions in a system whose task is to yield a measurable value to an individual actor of the system”

• Describes WHAT the system (as a “Black Box”) does from a user’s perspective

• A set of scenarios tied together by a common user goal


Why Use Case?

• Captures functional requirements from user’s perspective

• Gives a clear and consistent description of what the system should do

• A basis for performing system tests• Provides the ability to trace functional

requirements into actual classes.• Serves as a unit of estimation• The smallest unit of delivery


People who use use cases. • Customers will use the use cases to understand the system's behavior,

and, since they must approve the use case's flow of events, customer will also use the use cases to approve the result of use-case modeling.

• Potential users will use the use case to understand the system's behavior. • Software Architects will use the use cases to identify architecturally

significant functionality. • People who analyze, design, and implement the system will use the use

case to understand the required system behavior and to refine the system. • Use-case designers will use the use cases' flows of events to find classes.

(These are the most important artifacts for use-case designers.) • Testers will use the use cases as a base for identifying test cases. • Managers will use the use cases to plan and follow up the use-case

modeling. • Documentation writers will use the use cases to understand what

sequence of use should be described in the documentation (such as the system user guide).


Finding Use Cases

• For each of the actors previously defined:– Which services does the actor require from

the system?• Read, create, destroy, modify, store information

– Does the actor have to be notified about events in the system, or does the actor need to notify the system about something?

– Could the actor’s daily work be simplified? • Don’t concentrate only on the current system


Validating Use Cases

Is the use case complete? Is the actor’s goal going to be met? Are there any changes that would simplify

the process depicted in the use case? Are there any additional goals that are not

addressed?

• Are there any additional actors that are not represented?


UC Description Properties

• Name– Name of use case, usually close to the user’s goal– Forward traceability (unique)

• Description – A brief description of the role and purpose of the use case.

• Flow of Events (Main Flow)– A textual description of what the system does in regard to the

use case (not how specific problems are solved by the system). The description is understandable by the customer.

• Alternative flows– A textual description of the exceptional paths in the main flow of

the use-case


UC Description Properties (cont.)• Pre-conditions

– The necessary conditions that have to be met before the use case can be performed

– Could be other Use Cases as well (not equivalent to <<include>> at the beginning of the description)

• Post-conditions– The state of the system after the use case is performed

– The value delivered to the actor

– Distinguishes between variations and exceptions

• Special Requirements – A textual description that collects all requirements, such as non-functional

requirements, on the use case, that are not considered in the use-case model, but that need to be taken care of during design or implementation.

• Reference to requirements– Backward traceability


Some Notes

• The first four properties construct UC outline.

• Business UC are which describe current system.

• Basic flow denotes successful scenario which should also contain:– How the UC will be started.– How the UC will be finished.


Recommended Workflow

1. Identify actors (and their relationships if necessary)

2. For each actor identified and until no new UC is discovered do

a. Find all the goals of the actor

b. Decide on the main course of success for each goal

c. Create a Use Case for each of the goals• New actors/goals may be discovered

d. Validate/correct existing Use Cases

3. Draw the Use Case diagram– Simplify model by repeating the process incase the

produced diagram is too complex


Relationships between Actors

• When several actors as part of their roles, also play a more generalized role, it is described as generalization

• The behavior of the general role is described in an actor super-class

• The specialized actors inherit the behavior of the super-class and extend it in some way

• Relationships between actors are not always necessary

ClerkSupervisorManager


Use Case Relationships

• Include relationship (“uses” in older versions)– When a number of Use Cases have common

behavior, this behavior can be modeled in a single use case that is used by the other use cases

– X << includes >> Y indicates that the process of doing X always involves doing Y at least once

– Beware of functional decompositions– The included Use Case must be complete– X must satisfy the pre-conditions of Y before

including it

<< include >>X Y


Use Case Relationships (cont.)

• Generalization relationship– Used when a number of Use Cases all have some subtasks in

common, but each one has something different about it that makes it impossible to lump them all in a single use case

– The generalized and specialized use cases must share the same goal

– A specialized Use Case may capture an alternative scenario of the generalized Use Case

– The generalized Use Case must be complete– The Specialized use case may interact with new actors. – The Specialized use case may add pre-conditions and post-

conditions (AND semantics).

Specialized Generalized



• Extend relationship– Model conditional, or optional behavior in a business

use case by describing the workflows in different use cases, where conditional or optional behavior is distinguished from mandatory behavior.

– Model a complex workflow that seldom occurs. – Model a separate subflow that is only run under

certain conditions. – Model several different business use cases that can

be inserted at a certain point (the order being governed by the business actor



• Extend relationship

• The business use cases being extended have to be meaningful and complete in themselves, even if the workflow of the added business use case is not executed.

Documents

Use-case Modeling. Sharif Univ. of Tech.2 Outline Introduction Use case model Unified Modeling Language Actor Use cases UC Description Properties Relationships