Lection 3
Use case diagram
Plan:
1. Use cases.
2. Actors.
3. Interfaces.
4. Notes.
5. Relationships in use-case diagram.
6. An example of use-case diagram
7. Recommendations for the development of use-case diagram
Question 1.
Development of a use-case diagrams aims to:
• Identify the common border and the context of a model in the initial stages of
system design.
• Formulate general requirements to the functional behavior of the developing
system.
• To develop the original conceptual model of the system for its further detail in the
form of logical and physical models.
• Prepare background documentation for the interaction between the developers of
the system and its customers and users.
The essence of this diagram is as follows: the system is represented in the form of
many entities or actors that interact with a system with the help of the so-called use cases.
We name any entity as an actor or acting person if this entity interacts with the system
from the outside. It may be a person, a technical device, a program, or any other system,
which can serve as a source of impact on the simulated system. In turn, the use case is
used to describe the services that the system provides an actor. In other words, each use
case defines a set of actions done by the system during the dialogue with the actor. It says
nothing about how interaction of actors with the system would be realized.
1
In the most general case, the diagram of use cases is a count of a special form,
which is a graphic notation for the submission of specific use cases, actors, and perhaps
some of the interfaces, and the relationships between these elements. Some components
of the diagram can be enclosed in a rectangle, which indicates the projected system at
whole. It should be noted that the relations of the graph can be only some fixed types of
relationships between actors and use cases, which together describe the services or
functional requirements of the modeling system.
The rational unified process of developing the model of a complex system is a
splitting it into component parts with a minimum of relations on the basis of packages. In
the UML package “Use case” is a subpackage of a package “Elements of behavior”.
Basic elements of this package are an use case and an actor. With these concepts, we
begin to study the diagrams of use cases.
1. Use cases
Standard element of UML “use case” is used for the specification of the common
features of the system behavior or any other entity without consideration of the internal
structure of that entity. Each use case defines the sequence of actions that must be
performed by a designed system while interaction with the actor. Use case diagram may
be supplemented by explanatory text, which reveals the meaning or semantics of its
components. The explanatory text is called the notes or the script.
A separate use case is indicated in the diagram by ellipse, inside of which it
contains its short name, or a name in the form of the verb with explanatory words
(Fig. 1).
check the state of the
current account of the bank
client
Fig. 1. Use case
The purpose of the use case is to determine the finished aspect or a piece of
behavior of some entity without revealing the internal structure of the entity. As such an
entity it can be the source system or any other element of the model, which has its own
behavior, like subsystem or class.
2
Each use case corresponds to an individual service, which provides the simulated
entity or system on request of the user (the actor), i.e. determines the mode of application
of this entity. The service, which is initialized by user request, represents a complete
sequence of actions. This means that once the system has finished processing the request
of the user, it should return to its original state, which is ready to perform the following
queries.
Use cases describe not only the interaction between the users and entities, but also
the reaction of the entity when it receives individual messages from users. Use cases may
include a description of specific ways of implementation of the service and a variety of
exceptional situations, such as the correct handling of system errors. Use cases at whole
should identify all possible expected behavior of the system. For the convenience a set of
use cases may be regarded as a separate package.
Examples of use cases can be the following: checking the status of the client's
current account, registration of the order for purchase of goods, receipt of additional
information about the creditworthiness of a client, displaying the graphical form on the
monitor screen and other actions.
Question 2.
Actors
The actor is any external in relation to the modeling system entity that interacts
with the system and use its functionality to achieve certain goals or solve particular
problems. Each actor can be regarded as a separate role for a particular use case. The
standard graphic symbol of the actor on the diagrams is the figure of a «man», under
which is recorded specific name of the actor (Fig. 2).
Fig. 2. A graphic symbol of the actor
In some cases, the actor may be expressed in the form of a rectangle (like class)
with the keyword «actor» and normal components of the elements of the class. The names
of the actors should be written in capital letters and follow the recommendations of the
3
use of names for types and classes of model. The symbol of the individual actor connects
the corresponding description of the actor with a specific name. It is recommended to
indicate the names of abstract actors, as well as other abstract elements of language UML,
in italics.
Examples of actors can be the following: a client of a bank, a bank employee, a
seller of a store, a manager of a sales department, the passenger air route, a driver of a
car, an administrator of a hotel, phone number and other entities relevant to the
conceptual model of the subject area.
Actors are used for modeling entities external to the system that interact with the
system and use it as a separate user. Other systems (i.e. a subsystem of the projected
system or separate classes) can perform as actors. It is important to understand that each
actor defines a consistent set of roles that users of this system can serve in the process of
interaction. In each moment of time well-defined user interacts with the system, while he
plays in one of these roles. The most obvious example of the actor is a specific user of a
system with its own authentication parameters.
Any entity of this kind is an instance or example of the actor. For modeled system
actors can be as subjects-users, as well as other systems. Since the users of the system are
always external to the system, they are always presented in the form of the actors.
As in general case, the actor is always out of the system, its internal structure could
not be determined. Only actor’s external representation is important, i.e., how it is
perceived by the system. Actors interact with the system through the transmission and
reception of messages from the use cases. The message is a request of a service by an
actor from the system and receipt of this service. In addition, interfaces may be associated
with the actors, they determine how other elements of the model are interacting with these
actors.
Two or more actors may have properties in common, i.e. interact with one and the
same set of use cases in the same way. This generality of the properties and behavior
appears in the form of an abstract actor.
3. Interfaces
4
The interface is used for the specification of the model parameters, which are
visible from the outside without the guidance of their internal structure. In UML interface
is a classifier and characterizes only a limited part of behavior of modeling entity.
Interfaces define a set of operations, which provide for the necessary set of services or
functionality for the actors. Interfaces cannot contain any attributes, neither states, nor
aimed associations. They contain only the operations without specifying the specific
features of their implementation. Formally, the interface is equivalent to an abstract class
without attributes and methods but with the presence only the abstract operations.
Interface is depicted in the form of a small circle, near which we record its name
(Fig. 3). As the name it may be a noun, which characterizes some information or service
(for example, the «transmitter», «camcorder»), but more often it is a line of text (for
example, «a database query», «input form», «device beep»). The name should start with a
capital letter I, for example, ISecurelnformation, ISensor.
ISensor
ISecureInformation
Fig. 3. Interfaces in use case diagrams
Graphic symbol of a separate interface can be connected at the diagram by a solid
line with that use case, which supports it. The solid line in this case points to the fact that
the use case associated with the interface must implement all operations necessary for the
interface, and possibly more (Fig. 4a). In addition, the interfaces can be connected with
use cases by dotted line with an arrow (Fig. 4b), which means that the use case is
designed for the specification only of that service, which is necessary for implementation
of this interface.
making a purchase order for the
computer
IOrderForm
check the identity of a client
IInformationAboutClient
Fig. 4. Interfaces with use cases
5
Further interface can be specified explicitly indicating those operations, which
specify a particular aspect of the behavior of the system. In this case, it is depicted in the
form of rectangle (class) with the key word «interface» in the name, with an empty
section of the attributes and with non-empty section of the operations. Such graphic
representation is used on the diagrams of classes or diagrams, characterizing the behavior
of the system to be modeled.
The importance of interfaces is that they define connecting nodes in the system,
which is absolutely necessary for the organization of collective work on the project.
Moreover, the specification of the interfaces contributes to the «painless» modification of
existing systems during the transition to new technological solutions. In this case, the
change shall be subject only to the implementation of operations, but not the functionality
of the system itself. And this ensures the compatibility of the subsequent versions of the
programs with the original in a spiral technologies software development systems.
4. Notes
Notes (notes) in the UML are intended for inclusion in the model of arbitrary
textual information. As such information it may be developer’s comments (for example,
the date and version of the diagram development), restrictions (for example, on the values
of the individual relationships or copies of entities) and the marked values. When we
speak about use case diagrams it may be the most general information related to the
general context of a system.
Graphically, the notes are indicated by a rectangle with a «kink» of the upper right
corner (Fig. 5). Inside the rectangle we write the text of the notes. Note can refer to any
element of the diagram, in this case, they are connected by a dotted line. If the note refers
to several elements, then there are several lines. Of course, the notes may be presented
not only in use-case diagram, but also at other diagrams.
6
Fig. 5. Examples of notes
5. Relationships at use case diagram
Between the components of the use-case diagrams there can be various relations
that describe the interaction of copies of some of the actors and use cases with specimens
of the other actors and options. One actor can interact with several variants of use. In this
case, the actor turns to the multiple services of this system. In turn one use case can
interact with several actors, providing for all of them, of their service. It should be noted
that the two use cases defined for one and the same essence, can't interact with each other,
since each of them independently describes the finished version of the use of this entity.
We have already studied the main types of relationships in the UML. Use case diagrams
typically use the following relationships:
• Association
• Dependency
• Generalization
• Inclusion
Association
It serves to identify the specific role of the actor in a separate use case. In other
words, association specifies the semantic peculiarities of interaction between actors and
use cases in a graphic model of a system. Thus, this attitude sets, what specific role actor
plays in the interaction with the instance of the use case. In use-case diagram, as well as
other diagrams, the relationship of Association is indicated by the solid line between the
7
actor and the option use. This line can contain additional symbols, such as the name and
the multiplicity (Fig. 6).
formalize a credit for the bank client
1
*
Основной пакет::Bank client
Fig. 6. An example of a graphical representation of the relationship Association
between the actor and the use case
The multiplicity of Association is indicated near that component the component
diagram, which is a participant in the Association. Multiplicity characterizes the total
number of specific instances of the component, which may act as elements of this
Association.
The most common are four main forms of recording the multiplicity of the
Association:
• Integer non-negative number (including the digit 0). In this case, the number of
instances of the actors or the use cases, which may act as elements in the relations of the
Association, is exactly equal to the specified number.
An example of this form of recording the multiplicity of Association is an
indication "1" for the actor «Bank Client» (Fig. 6). This record means that every instance
of the use case «formalize a credit for the bank client» can have as its element only one
copy of the actor «Bank Client».
• Two non-negative integers numbers, separated by two points and recorded in the
form of: «the first number .. the second number». This entry in UML corresponds to the
notation for the set or range of integers. The first number may be 0.
I.e. “1..5” means that the number of separate instances of the component, which
may act as elements of this Association, are equal to some pre-unknown number from the
set of integers {1, 2, 3, 4, 5}. This situation can occur, for example, in the case of
consideration client of the Bank as an actor, and the procedure for opening Bank accounts
8
as a use case. The number of individual accounts of each client in the Bank, on the basis
of some additional considerations may be no more than 5.
• Two characters, separated by two dots. The first of them is a non-negative integer
or 0, and the second - the special "*". The symbol "*" stands for an arbitrary nonnegative
integer, the value of which is not known at the moment of entering the relations of the
Association.
An example of such a form recording the multiplicity of the Association is «2..*».
• The only symbol "*", which is a reduction of the recording interval «0..*». In this
case, the number of separate instances of the component of Association can be any
integer non-negative number. While 0 means that for some copies of the relevant
component of Association may not take place.
For example, you can lead the multiplicity of Association for the use case
«formalize a credit for the bank client» (Fig. 6). Here multiplicity "*" means that each
client of the Bank can take a credit (loan), while their total number is not known and is
not limited.
If the multiplicity of relations Association is not specified, the default value of its
value is 1.
Expansion relationship
Expansion relationship determines the interaction of copies of a separate use case
with the more general use case, the properties of which are determined on the basis of the
method of the joint association of these copies. In the metamodel expansion relationship
is designed and indicates that in relation to specific examples of some use case it should
be met specific conditions defined for the expansion of the use case. So, if there is an
expansion relationship from the use case A to the use case B, it means that the properties
of B may be amended from the expanded variant of use A.
Expansion relationship between use cases is indicated by a dotted line with an
arrow, directed from the use case, which is the extension for the source use case. This line
with the arrow marked the key word «extend» («expands»), as shown in Fig. 7.
9
extend
ask a catalogue of all goods
make an order for buying a good
Fig. 7. Expansion relationship
In the above example (Fig. 7) during purchasing order of the goods only in some
cases it may be required to provide the client catalog of all goods. The condition of the
expansion is a request from a client to receive the catalogue of the goods. It is obvious,
that after receipt of the catalogue the client needs some time to study it, during which the
registration of the order is suspended. After getting acquainted with the catalogue the
client decides to buy some product, or to refuse buying at all. The service or the use case
«Make an order for buying goods» can respond to the client choice after the client
receives the catalog of goods.
check whether the
client asked a
catalogue
give a catalogue
only at the
request of a client
extend
ask a catalogue of all goods
make an order for buying a good
Fig. 8. Expansion relationship with notes
The relationship of generalization
The relationship of generalization is used to specify the fact that some variant use
case A can be generalized to the use case B. So, the variant A will be a specialization of
use case B. B is called an ancestor or parent in respect of A, and A is a descendant for use
case B. It should be emphasized that a descendant inherits all the properties and behavior
of their parents, and may also be supplemented with new properties and behaviors. This
relationship is indicated by a solid line with an arrow in the form non filled triangle,
10
which points to the parent use case (Fig. 9). This line with the arrow has a special name arrow «generalization».
make an order for buying a good
make an order for buying a
computer
Fig. 9. Relationship of generalization
The generalization relationship applies in the case, when it should be noted that the
children use cases possess all of the attributes and behavior features of parental use case.
The children use cases are involved in all relationships of parental use cases. In turn, they
may be vested with the new behavior features, which are absent from the parent use case,
as well as they may refine or modify the inherited features.
One use case can have multiple parent use cases. In this case, it is being
implemented multiple inheritance properties and behavior of ancestors relations. On the
other hand, one use case can be ancestral to several use.
Among the individual actors there may also exist generalizations. This
relashionship is directed and pointed to the fact of specialization of some of the actors on
the other. For example, the relationship of generalization from the actor A to the actor B
notes the fact that every instance of the actor A is at the same time an instance of an actor
И and has all of its properties. In this case, the actor B is a parent to the actor A and actor
A, accordingly, is a descendant of the actor B. Graphically this relationship is also
indicated by solid line with an arrow in the form of non filled triangle, which is near the
parent actor (Fig. 10).
Bank employee
Cashier
Fig. 10. Generalization between actors
Inclusion relationship
11
Inclusion relationship between the two use cases indicates that a certain behavior
for one use case is included as a component in the sequence of another use case behavior.
The semantics of this relationship is determined as follows. When an instance of
the first use case in the process of its execution reaches the switching point of the second
use case, then the copy of the first use case performs a sequence of actions, which
determines the behavior of the second use case, after which continues the implementation
of the actions of his own behavior. It is supposed, that even if the copy of the first use
case can have multiple included use cases, they must be completed by a certain time, after
which it should be continued the interrupted actions of the first use case in accordance
with its specified behavior.
One use case may be included in several other options, but also include other
options.
Graphically this relationship is indicated by a dotted line with an arrow, directed
from the basic use case to the includeв use case. This line with an arrow is marked by the
key word «include» («contains»), as shown in Fig. 11.
include
make an order for buying a
computer
write an invoice for payment of the
computer
Рис. 4.11. Пример графического изображения отношения включения между
вариантами использования
6. An example of use-case diagrams
As an example, let us consider the process of modeling the system for saling the
goods by the catalogue.
As the actors of this system we can choose two entities, one of which is a seller,
and the other is a buyer. Each of these actors interacts with the system and is its user, i.e.,
they both turn to the service «Making an order for the purchase of goods». This service
acts as a use case in the the developed diagram, the initial structure of which may include
only two of these actors and the only use case (Fig. 12).
12
Fig. 12. The original use case diagram
The multiplicators indicated on the diagram reflect the general rules or logic to
place orders for the purchase of goods. According to the rules, one seller can participate
in making several orders, at the same time each order can be issued only by one seller,
who shall be responsible for the correctness of the order and there will be only one buyer
for it. On the other hand, every customer can form many orders, but, at the same time,
each order must be executed at the single buyer, to which the right of ownership to the
goods is transferred after payment.
At the next stage of development of this diagram the use case «Making an order for
the purchase of goods» may be specified on the basis of the introduction of four
additional variants of use. This follows from a more detailed analysis of the process of
sailing goods, which allows to single out as separate services such action as to provide the
consumer information about the product, to negotiate the terms of payment for the goods
and to order the goods from the warehouse.
On the other hand, the sale of goods by the catalogue presupposes the existence of
an independent informational object - catalog of products, which in a sense, does not
depend on the implementation of the customer service. In our case, the catalogue of the
goods may be requested by the buyer or the seller if necessary during the choice of goods
and looking for details of its sale. It is reasonable to submit a service “Request catalog of
the goods” as a separate use case.
The obtained use case diagram will contain 5 use cases and 2 actors (Fig. 13),
between which then relationships of inclusion and aggregation are established.
13
Fig. 13. An updated version of the use case diagram
The diagram above can be detailed further in order to better refine requirements to
the system requirements and determine the details of its subsequent implementation. Such
a detailing may be performed in two main directions.
On the one hand, detailization may be performed on the basis of the establishment
of
additional
relationships
«generalization-specialization»
for
already
existing
components use-case diagram. Thus, within the framework of our system it may have an
independent significance and specific features of the separate category of goods computers. In this case, the diagram can be complemented by the use case «Making an
order to buy a computer» and actors «buyer of a computer» and «seller of computers»,
that is connected with the components of the diagram by the relationship of generalization
(Fig. 14).
There is a very important feature in our model now. Although in the given diagram
(Fig. 14) there are no lines showing the relations “Association” between the actor « Seller
of computers» and the use case «Making an order to buy a computer», as well as between
the actor «Buyer of computer» and the use case «Making an order to buy a computer»,
the existence of relations of generalization between the components allows them to
14
inherit the relationship “Association” from their ancestors. As the principle of inheritance
is one of the fundamental principles of object-oriented programming, in our example, we
can state with certainty that these lines are present in the diagram, in a hidden way.
Fig. 14. Further clarification of use-case diagram
The second directions of detailing use case diagram is connected with subsequent
structuring of the individual components in the form of other diagrams. For it we can use
the diagram of cooperation and shall back to this question later.
Building a use-case diagram is the first step in the process of object-oriented
analysis and design, the purpose of which is to present a set of requirements to behavior
of the projected system. Specification of requirements to the system in the form of a usecase diagram is an independent model, which in UML has received the name of the usecase model and has its own special standard name «useCaseModel».
Subsequently, all requirements set in this model shall be submitted in the form of a
general model of system, which consists of the package System. The latter in its turn may
be a hierarchy of packages, which contains at the top level many classes of model of the
projected system.
15
7. Recommendations for the development of use case diagrams
The main purpose of use-case diagrams is the formalization of functional
requirements to the system using the concepts of the appropriate package and the
agreement of the model with the client at an early stage of design. Any use case may be
further decomposed into many sub-use cases of the individual elements. Recommended
total number of actors in the model - not more than 20, and use cases - not more than 50.
Otherwise, the model loses its visibility.
A separate instance of use case is the implementation of sequences of actions,
which is initialized through message instance from the actor instance. As a response or
reaction to the message of the actor the use-case instance performs a sequence of actions
established for this use case.
This kind of interaction will continue until the execution of the sequence of actions
the use case instance, and the corresponding actor instance (and no other) does not
receive the required service instance.
Variants of use of classes correspond to the operations of this class. Some of use
cases may correspond to the use of only one operation, while other - the final set of
operations defined in the form of a sequence of operations. At the same time one
operation may be needed for the implementation of several services class and therefore it
will appear in a few variants of use of this class.
So you must always strive to make an accurate representation of the model in the
form of a use-case diagrams.
It is important to understand that all system services should be clearly defined in a
use-case diagram, and any other services, which are not available in this diagram, the
designed system cannot perform at all.
16