08-08-2012, 11:54 AM
Learning UML
use-case-diagrams.pdf (Size: 774.54 KB / Downloads: 49)
Use-Case Diagrams
This chapter focuses on use-case diagrams, which depict the functionality of a system.
First, I introduce use-case diagrams and how they are used. Next, I discuss
actors and use cases. Finally, I go over various relationships relating to actors and use
cases. Many details that were not fleshed out in Chapter 2are more fully elaborated
here, and throughout the chapter I include suggestions relating to use-case diagrams.
Use-case modeling is a specialized type of structural modeling concerned with modeling
the functionality of a system. You usually apply use-case modeling during
requirements activities to capture requirements that define what a system should do.
Use-case modeling typically starts early in a project and continues throughout a system
development process. It is usually done as a series of workshops between users
and analysts of a system in which ideas can be explored and requirements may be
fleshed out over time.
As a use-case driven process uses use cases to plan and perform iterations, it is
important to understand how use cases are related to one another, including what
use cases have in common, which use cases are options of other use cases, and which
use cases are similar to each other. Given that every project has limited resources,
you can use this information about use cases to determine how best to execute a
project. Use cases that are common to two or more other use cases need only be
implemented once, and then they can be reused. Use cases that are options of other
use cases may be implemented at a later time, and use cases that are similar allow us
to implement one use case that may be reused. An understanding of how use cases
are related allows users and analysts to negotiate and reach agreement concerning
the scope and requirements of a system.
A use-case diagram may be considered a “table of contents” for the functional requirements
of a system. The details behind each element on the use case diagram may be
captured in textual form or using other UML modeling techniques. All the use-case
diagrams and their associated details for a specific system form the functional requirements
of the system. However, the UML does not provide any explicit guidance on
how to capture the textual details, but focuses more on the notation.
This is the Title of the Book, eMatter Edition
Actors
As discussed in Chapter 2, an actor is a user or external system with which a system
being modeled interacts. For example, our project management system involves various
types of users, including project managers, resource managers, human resources,
and system administrators. These users are all actors.
Actors follow the type-instance dichotomy first discussed in Chapter 2and applied
to classes and objects in Chapter 3. You can use the UML to talk about classes of
actors, as well as specific actors of a class. When speaking of a class of actors, it’s
customary to use the terms actor or actor class. Thus, while you might think of an
actor as a specific thing, in the UML, an actor really represents a class of things.
When speaking of a specific actor of a class, use the term actor instance.
An actor is external to a system, interacts with the system, may be a human user or
another system, and has goals and responsibilities to satisfy in interacting with the
system. Actors address the question of who and what interacts with a system. In the
UML, an actor is shown as a “stick figure” icon, or as a class marked with the actor
keyword and labeled with the name of the actor class.
Figure 4-1 shows various actors associated with the project management system:
A project manager
Responsible for ensuring that a project delivers a quality product within specified
time and cost, and within specified resource constraints
A resource manager
Responsible for ensuring that trained and skilled human resources are available
for projects
A human resource
Responsible for ensuring that worker skills are maintained, and that quality
work is completed for a project
A system administrator
Responsible for ensuring that a project management system is available for a
project
A backup system
Responsible for housing backup data for a project management system
Use Cases
As discussed in Chapter 2, a use case is a functional requirement that is described
from the perspective of the users of a system. For example, functional requirements
for the project management system include: security functionality (such as allowing
users to log in and out of the system), inputting of data, processing of data, generation
of reports, and so forth.
Use cases follow the type-instance dichotomy first discussed in Chapter 2and
applied to classes and object in Chapter 3. You can use the UML to talk about
classes of use cases, and you can use the UML to talk about specific use cases of a
class. When speaking of a class of use cases, it’s customary to use the term use case
or use-case class. Thus, while you might think of a use case as a specific thing, in the
UML, a use case really represents a class of things. When speaking of a specific use
case of a class, use the term use-case instance.
A use case defines a functional requirement that is described as a sequence of steps,
which include actions performed by a system and interactions between the system
and actors. Use cases address the question of how actors interact with a system, and
describe the actions the system performs.
Communicate Associations
actors associated with the project management system and
use cases associated with the project management system, but how
are actors and use cases related? A specialized type of association, called a communicate
association, addresses the question of how actors and use cases are related and
which actors participate in or initiate use cases. (Associations are discussed in
Chapter 3.)
Dependencies
A model may have many use cases, so how do we organize the use cases that define
what a system should do? And how do we use this information about use cases to
determine how best to execute a project while considering how use cases are related
to one another, including what some use cases might have in common, and also taking
into account use cases that are options of other use cases? Specialized types of
dependencies, called include and extend dependencies, address these questions;
dependencies are discussed in Chapter 3. The next few sections discuss these specialized
types of dependencies.
Include Dependencies
Perhaps we wish to log the activities of project managers, resources managers, and
system administrators as they interact with the project management system.
Figure 4-5 elaborates on the use cases in Figure 4-4 to show that the activities of the
project manager, resource managers, and system administrators are logged when they
are performing the use cases shown in the diagram. Thus, logging activities are common
to these three use cases. We can use an include dependency to address this type
of situation by factoring out and reusing common behavior from multiple use cases.