Lecture 3: Use-

Case & Activity

Diagram
BY: D R . S A R AH N A I E M
MATERIAL SOURCE:
DR. AMR GHONIEM
SYSTEMS ANALYSIS AND DESIGN IN A CHANGING WORLD, 7TH EDITION
 BUSINESS PROCESSES VS. BUSINESS
RULES
Business processes define what is done in a business, by
whom, in what order, needing which resources, and with
what consequences.
Business rules constrain how a business is run.
o There is a clear distinction between the business
processes and the constraints.
o Example, in a car rental company:
▪ renting a car (business process);
▪ the car allocated is the lowest mileage car that is
available in the chosen group (business rule);
FROM DOMAIN TO REQUIREMENTS; USE-CASE & ACTIVITY DIAGRAMS 2
 BUSINESS PROCESSES VS. BUSINESS
RULES
Business processes are important to:
-get an understanding of what a business does,
-and to gain the domain expertise needed to develop software
solutions in the business context.
Business rules need to be identified and recorded:
1. to provide quick and easy access whenever there is a change.
2. Business rules are the basis of decision making.
Traceability of business rules should be possible from the business
needs to the software solution.
FROM DOMAIN TO REQUIREMENTS; USE-CASE & ACTIVITY DIAGRAMS 3
BUSINESS RULES REPRESENTATION
TECHNIQUES
The language used in expressing business rules should be
well defined and structured, so that verification can be
made easier if not automatic:
[Link] natural language to make it easy for business
people to understand it ( .. quite informal).
2. Using UML and OCL;
OCL is Object Constraint Language, which is a formal
language used to represent constraints in UML.

FROM DOMAIN TO REQUIREMENTS; USE-CASE & ACTIVITY DIAGRAMS 4

 BUSINESS PROCESSES REPRESENTATION
TECHNIQUES
Business processes are represented using UML activity
diagrams.
-An activity diagram shows a process as a set of
activities, showing their sequences, and where activities
can be carried out in parallel.
-It can also be extended to show which person is
responsible for which activity.
-An activity could be a task that a person or a computer
might perform.

FROM DOMAIN TO REQUIREMENTS; USE-CASE & ACTIVITY DIAGRAMS 5

 ACTIVITY DIAGRAMS .. ADVANTAGES
1. Help investigate the workflow* (flow of control) from one
activity to another.
2. Help in understanding the basic behavior of a system, and
understand the business situation.
3. Can be used to model concurrent systems.
4. Can record scenarios of use cases.
5. Can help identify the stages at which each role requires
some interaction with the process. This is of particular benefit
when we want to investigate the steps that people take in
order to do their jobs.
*Workflow is defined as a sequence of activities that produces
a result of observable value.

FROM DOMAIN TO REQUIREMENTS; USE-CASE & ACTIVITY DIAGRAMS 6

ACTIVITY DIAGRAMS .. ELEMENTS &
SYMBOLS

FROM DOMAIN TO REQUIREMENTS; USE-CASE & ACTIVITY DIAGRAMS 7

 ACTIVITY DIAGRAMS .. EXAMPLE
Suppose, after a hard day’s work, you decide to make yourself
a hot drink. What do you do to achieve that goal? What are
the actions and how do you organise them?
We start with a process called make hot drink. At the centre of
this task is boiling water in a kettle.
Usually, there are two steps.
1. Fill the kettle with water.
2. Boil the water.
There are also some decisions to be made, such as the choice of
beverage. We will consider instant coffee (as a particular
scenario) to begin with. Finally, you need a cup to drink from.

FROM DOMAIN TO REQUIREMENTS; USE-CASE & ACTIVITY DIAGRAMS 9

ACTIVITY DIAGRAMS .. EXAMPLE

FROM DOMAIN TO REQUIREMENTS; USE-CASE & ACTIVITY DIAGRAMS 10

 ACTIVITY DIAGRAMS .. EXAMPLE
.. ELEMENTS & SYMBOLS
The basic elements of an activity diagram are activities and transitions. The
completion of an activity triggers an outgoing transition. Similarly, once the
incoming transition has been triggered an activity may commence.
o In an activity diagram, activities are shown as rounded boxes; transitions are
shown as lines with arrows.
o There are two predefined activities, start and stop, which is represented as
filled circles, a diagram may include more than one stop node if it makes it
clearer.
o The Figure shows two synchronisation bars, denoted by thick horizontal lines.
o The upper one denotes a fork and the lower one a join. The upper bar
allows for separate activities to be carried out in parallel, so between the two
synchronisation bars the two separate strands can be performed concurrently.
o In UML, a note (with annotation) is shown as a rectangle with the top right-
hand corner folded down.
o A dashed line is used to attach the note to the model element to which it
refers. FROM DOMAIN TO REQUIREMENTS; USE-CASE & ACTIVITY DIAGRAMS 11
 ACTIVITY DIAGRAMS .. EXAMPLE

Redraw the
activity
diagram of
preparing a
cup coffee so
that it allows
to check if
cup
is clean
continue the
process, if not
wash the cup.
FROM DOMAIN TO REQUIREMENTS; USE-CASE & ACTIVITY DIAGRAMS 12
 ACTIVITY DIAGRAMS .. EXAMPLE..
ELEMENTS & SYMBOLS
o In Activity 2, the flow between activities is constrained with a Boolean test,
known as a guard, which is represented inside a pair of square brackets.
o Each of the transitions leaving the first decision diamond has a guard to
determine which path should be taken under a given condition.
o One outgoing transition should always be taken – this means that exactly one of
the relevant guards must always evaluate to true.
o A diamond shape is also used as a merge node, which brings together
alternative mutually exclusive flows, as shown in Figure 2.
o A merge node will be reached only by one of the alternative flows and has a
single outgoing flow.
o An activity has only one transition into and out of it.
o This is enforced by ‘decision’ and ‘merge’ nodes for alternative outgoing and
incoming transitions, and by synchronisation bars for concurrent outgoing (fork)
and incoming (join) transitions.
FROM DOMAIN TO REQUIREMENTS; USE-CASE & ACTIVITY DIAGRAMS 13
ACTIVITY DIAGRAMS .. EXAMPLE

Redraw the activity diagram

of example 1 to allow the
choice between coffee with
milk and coffee without milk.

FROM DOMAIN TO REQUIREMENTS; USE-CASE & ACTIVITY DIAGRAMS 14

 ACTIVITY DIAGRAMS .. EXAMPLE
Consider the lending process from a library :
"A typical lending library keeps a stock of books for the use of its
members. Each member can look on the library shelves to select a copy
to borrow. Then take out a number of books, up to a certain limit. After
a given period of time, the library expects members to return the
books that they have on loan.
When borrowing books, a member is expected to wait in queue, then
to hand their chosen books to the librarian, who records each new loan
before issuing the books to the member. After that the librarian will
prepare for next member in the queue. When a book is on loan to a
member, it is associated with that member: possession of the book
passes from the library to the member for a defined period. The
normal loan period for each book is two weeks. If the member fails to
bring the book back on or before the due date, the library imposes a
fine."
FROM DOMAIN TO REQUIREMENTS; USE-CASE & ACTIVITY DIAGRAMS 15
 ACTIVITY DIAGRAMS .. EXAMPLE
What are the business processes and business rules in the
above system?
Business processes: find book on a shelf; wait in the queue;
issue a book, and return a book.
Business rules:
- There is a limit to the number of books a member can take out.
- A loan is for a period that is normally two weeks.
- Late returns incur a fine.
Draw an activity diagram for issuing a copy of a book.

FROM DOMAIN TO REQUIREMENTS; USE-CASE & ACTIVITY DIAGRAMS 16

ACTIVITY
DIAGRAMS ..
EXAMPLE

FROM DOMAIN TO REQUIREMENTS; USE-CASE & ACTIVITY DIAGRAMS 17

 ACTIVITY DIAGRAMS .. SWIM-LANES
Swim-lanes group activities associated with different roles.
o The swim-lanes show the role that is responsible for each activity.
o Activity diagrams represent the sequence of activities.
o When you are modelling a workflow that involves more than one role, it is
possible to identify which role is responsible for a particular activity.
o An activity diagram can help identify the stages at which each
role requires some interaction with the process.
In THE PREVIOUSE example The left-hand swim-lane contains the activities
that a library member performs when borrowing a book, while the right- hand
swim-lane shows the library’s self-service system workflow for the same process
(‘issue copy of book’).

FROM DOMAIN TO REQUIREMENTS; USE-CASE & ACTIVITY DIAGRAMS 20

Use case example for
Ordering from warehouse
LINKING ACTIVITIES TO USER INTERFACES
ACTIVITY DIAGRAMS ..
The activity diagram shows the interactions involved in enrolling a new member and the
activities carried out.
•A nonmember of the library interacts with a librarian. The non-member requests to be
enrolled and provides information when requested by the librarian.
• The librarian then uses the system to record the enrolment information. Therefore the
librarian needs an interface with the software system for recording the information.
•This interface will be needed when a non-member request to enroll is dealt with by a
librarian.
• This transaction is complete when the library system:
• checks the information entered
• generates a membership number
• creates a new member record with the information entered and the membership number
• informs the librarian of the membership number

FROM DOMAIN TO REQUIREMENTS; USE-CASE & ACTIVITY DIAGRAMS 26

 USE-CASE MODELS
.. introduces a means of defining what a proposed system should do from a user’s
perspective.
o This can provide the basis for a contract between the customer and the developer
o Your aim is to construct a software system that will meet the needs of its users.
Hence you must identify ‘who does what’.
o To do this, you explore the problem description, any domain models and the
initial set of user requirements to determine the people involved, the work that they
do and the events that trigger some work to be done.
o You are likely to identify a variety of people, some of whom may be playing a
number of different roles and may be associated with different business events.
o You should ask yourself who the actual users will be and what tasks they must
perform with the aid of your software system.
FROM DOMAIN TO REQUIREMENTS; USE-CASE & ACTIVITY DIAGRAMS 21
 USE-CASE MODELS .. ADVANTAGES
o Capturing and eliciting requirements;
o Representing requirements;
o Planning iterations of development;
o Validating software systems.
o Defining the scope of a system, as they represent the interaction of
a system with its environment.
o Acting as a discussion tool between developer and user, and offer
a common language for agreeing on the functions of the software
system.

FROM DOMAIN TO REQUIREMENTS; USE-CASE & ACTIVITY DIAGRAMS 22

USE-CASE MODELS .. ELEMENTS &
SYMBOLS

FROM DOMAIN TO REQUIREMENTS; USE-CASE & ACTIVITY DIAGRAMS 23

 USE-CASE MODELS .. DESCRIPTIONS
Each use case description should contain the following parts in minimum:
-Use case identifier and name
- Initiator: name of the actor who initiates the process
-Pre-condition(s): a condition that must hold before this use case can be carried
out..
-Post-condition(s): a condition that must hold after the use case has been
completed.
-Main Success Scenario: a single sequence of steps that describe the main success
scenario. You can number the steps. A scenario is an instance of a use case.
- Goal: a short description of the goal of the use case;
Exceptions to the normal behavior for a use case are common, especially where
actors decide to cancel a use case without completing it.
FROM DOMAIN TO REQUIREMENTS; USE-CASE & ACTIVITY DIAGRAMS 30
A simple use
case diagram
for the main
tasks in a hotel
system: make
reservation,
check-in, and
check-out,
where the
reservation can
be done by the
receptionist or a
guest (by
Phone/Web).

FROM DOMAIN TO REQUIREMENTS; USE-CASE & ACTIVITY DIAGRAMS 25

 USE-CASE DIAGRAMS .. SYSTEM BOUNDARY

The system boundary determines the scope of the system.

o It distinguishes between internal and external
components.
o The external components are actors and the
internal components are the use cases.
o In UML it is optional to use system boundary notation.
o A solid box drawn around the use cases with the actors
located outside it represents the system boundary.
o We use system boundary notation when the system is
complex and includes several subsystems.
FROM DOMAIN TO REQUIREMENTS; USE-CASE & ACTIVITY DIAGRAMS 26
FROM DOMAIN TO REQUIREMENTS; USE-CASE & ACTIVITY DIAGRAMS 27
 USE-CASE DESCRIPTIONS
A scenario describes a sequence of interactions between the system and some
actors.
o In Each use case there is a set of possible scenarios. Where the main scenario
is the successful scenario where nothing goes wrong and the use case is
achieved.
For example: there are two scenarios for making reservation in a hotel:
Main Success Scenario:
o The guest wants to reserve a double room at the Hotel for 14 July. A double
room is available for that date, and the reservation is done.
Unsuccessful Scenario:
o The guest wants to reserve a single room at the Hotel for the first week of
August. There is no single room that is free for seven days in August, but there
is one room available for four days and another one for the following three
days. The system presents that option to the guest, who rejects it.
FROM DOMAIN TO REQUIREMENTS; USE-CASE & ACTIVITY DIAGRAMS 28
 USE-CASE DESCRIPTIONS
What pre and post condition(s) you can obtain from the below description
of a hotel check-in process?
Upon arrival, each guest provides the reservation number for his or her
reservation to the hotel’s receptionist, who enters it into the software system.
The software system reveals the details of that reservation so that each guest
can confirm them. The software system allocates an appropriate room to that
guest and opens a bill for the duration of the stay. The receptionist issues a
key for the room.
Precondition(s): There must be a reservation for the guest, and there must be
at least one room available (of the desired type), and the guest must be able
to pay for the room.
Post-condition(s): The guest will have been allocated to a room for the
period identified in the reservation, the room will have been identified as
being in use for a specific period, a bill will have been opened for the
duration of the stay, and a key will have been issued.
FROM DOMAIN TO REQUIREMENTS; USE-CASE & ACTIVITY DIAGRAMS 29
USE-CASE
DESCRIPTIONS

FROM DOMAIN TO REQUIREMENTS; USE-CASE & ACTIVITY DIAGRAMS 30

 USE-CASE SCENARIOS
For each use case there is a set of possible scenarios. A scenario is an instance
of a use case. A scenario describes a sequence of interactions between the
system and some actors. Here are two examples of scenarios.
o A member of a lending library wishes to borrow a book, and is allowed to
do that as long as they have no outstanding loans.
o Another member wishes to borrow a book, but has exceeded the quota for
the number of books that can be borrowed.
In each scenario the member wishes to borrow a book, but both the circumstances
and outcomes of events are different in each instance.
A use case includes a complex set of requirements that the system must meet in
order to cope with every eventuality.
The main success scenario shows the steps normally followed to achieve the
stated goal of the use case. But there can be other scenarios for the same use
case, each one having different outcomes depending upon circumstances.
FROM DOMAIN TO REQUIREMENTS; USE-CASE & ACTIVITY DIAGRAMS 31
USE-CASE MODELS ..
GENERALIZATION AMONG ACTORS
UML provides a notation to use generalisation between actors.
-When two actors share the same behaviour (interacting with the same use
cases) and one of them has some extra behaviour, then the common behaviour
can be associated with a generalised actor and the more specific behaviour
with the specialised actor.
For example, in the hotel system both the receptionist and the guest are
allowed to make reservation.
- Guest can make reservation through online system;
-the receptionist can do reservation on behalf of guest when a guest do
reservation through phone or a fax.

FROM DOMAIN TO REQUIREMENTS; USE-CASE & ACTIVITY DIAGRAMS 32

USE-CASE MODELS .. We introduce a new actor called
GENERALIZATION AMONG Reserver associated with the
ACTORS make reservation use case.
- The actors Guest and
Receptionist specializes
Reserver.
- Guest can do the same things
that a Reserver can, but may
do other things too.
- By using the open-headed
arrow from Guest to Reserver,
you are saying that a Guest
can do the same things that a
Reserver can, but may do
something else that a
Reserver does not. Reserver is
a generalised actor and
Guest a specialised one.
FROM DOMAIN TO REQUIREMENTS; USE-CASE & ACTIVITY DIAGRAMS 33
 USE-CASE MODELS ..
RELATIONSHIPS BETWEEN USE-CASES
Use cases can be related to one another. There are two very common and
important forms of relationship between use cases: inclusion and extension.
Inclusion: This is when two or more use cases have a common area of
functionality that can be factored out as a distinct use case.
The new use case can be used by each of the original use cases, so avoiding
duplication.
Extension: This is when a use case has a main success scenario but also
alternative scenarios which demand a variation on the original use case –
different or additional actions.
Each variation can be separated out as a use case that is distinct from but
related to the original use case.
An extension is conditional while an inclusion is not.
In UML we use «include» and «extend» stereotypes for representing inclusion
and extension. FROM DOMAIN TO REQUIREMENTS; USE-CASE & ACTIVITY DIAGRAMS 40
 USE-CASE MODELS ..
«INCLUDE» .. SHARING BEHAVIOUR
In the process of eliciting and specifying requirements, you may
find a certain amount of common behaviour in two or more of
your use cases.
-You can record the shared behaviour in a new use case and
connect it to the use cases that it came from with a dashed arrow
(indicating a dependency relationship) pointing from the original
use case to the new one.
- Hence the dependency arrow is labelled with the «include»
stereotype.

FROM DOMAIN TO REQUIREMENTS; USE-CASE & ACTIVITY DIAGRAMS 35

 USE-CASE MODELS ..
«INCLUDE» .. EXAMPLE
Members of a lending library can borrow a certain number of books and, for
any book borrowed, renew the loan up to three times. A loan can only be
renewed if there are no existing reservations for that book by other members,
when all other copies are on loan.
Let us assume that when a member returns a book there must be a check to
see whether there are outstanding reservations for that book by other
members. In this case the book will not be returned to the shelf, but will instead
be assigned to the highest priority reservation.
This same check needs to be carried out when a member extends a loan. The
reservation check is a shared piece of behaviour, a common scenario, which
can be developed separately as the check reservation use case.
Note that this is unconditional behaviour – the reservation check must
be performed whenever a loan is extended or a book is returned. A
dependency arrow has a source (where it comes from) and a target (where it
goes to). FROM DOMAIN TO REQUIREMENTS; USE-CASE & ACTIVITY DIAGRAMS 36
USE-CASE MODELS ..
«INCLUDE» .. EXAMPLE

FROM DOMAIN TO REQUIREMENTS; USE-CASE & ACTIVITY DIAGRAMS 37

 USE-CASE MODELS ..
«EXTEND» ALTERNATIVES TO MAIN
SCENARIOS
The «extend» stereotype indicates a conditional extension to the original use
case, known as alternative behaviour.
-This is used to illustrate a case where there are two or more significantly
different scenarios, so that the main case and the additional subsidiary cases are
clearly differentiated. The main purpose of this classification is to separate out a
special case.
-You should add a condition to each extension – by a note for instance – to
specify when the variant behaviour will be included.
- This could be done with either a note or an extension point.
-The new use case (Alternative one) depends on the original. This is a conditional
behavior.
- The new use case (the source) is connected to the original (the target) with a
dashed arrow pointing to the original and labelled with the stereotype «extend».
FROM DOMAIN TO REQUIREMENTS; USE-CASE & ACTIVITY DIAGRAMS 38
 USE-CASE MODELS ..
«EXTEND» .. EXAMPLE
A typical lending library will set an upper limit on the number of
books that its members can borrow at any one time. A librarian
will not be allowed to issue a copy of a book if that limit would
be exceeded.
- The next figure shows a fragment of a use case diagram that
identifies a new use case, refuse loan, as it is only performed
when the member would have too many books.
Note that: the refuse loan is a conditional behavior which is
only performed when the member would have too many books.
The note symbol is used to record the event that trigger the
subsidiary use case.
FROM DOMAIN TO REQUIREMENTS; USE-CASE & ACTIVITY DIAGRAMS 39
USE-CASE MODELS ..
«EXTEND» .. EXAMPLE

FROM DOMAIN TO REQUIREMENTS; USE-CASE & ACTIVITY DIAGRAMS 40

USE-CASE MODELS ..
EXTENDING
DESCRIPTIONS

FROM DOMAIN TO REQUIREMENTS; USE-CASE & ACTIVITY DIAGRAMS 41

 USE-CASE MODELS ..
AVOIDING OVER-COMPLEX USE CASE
DIAGRAMS
The general approach to managing complexity is to partition a problem into
sub-problems, and use abstraction to reduce the detail and extract what is
most significant to the problem.
Reduce the complexity of your use-case diagram by:
1. redrawing it at a higher level of abstraction
2. splitting it up into smaller modules.
Example: In the case of the hotel chain, we might partition our solution into
three sub-problems, usually called packages (a way of grouping cases):
1. reservations, 2. checking guests in and out of their rooms, 3. system access
Each package may then be assigned to a separate developer for
implementation, the project team must then deal with the dependencies
between the three packages as they work towards a solution..
FROM DOMAIN TO REQUIREMENTS; USE-CASE & ACTIVITY DIAGRAMS 50
 USE-CASE AS A PLANNING AID

One of the difficulties that developers face is planning delivery times.

The use case descriptions help the developer to:
❑ Understand the complexity of each use case.
❑ Determine which actors interact with each use case and to what extent.
❑ Establish which use cases carry the most risk.
❑ Estimate how long each use case is likely to take to implement.

FROM DOMAIN TO REQUIREMENTS; USE-CASE & ACTIVITY DIAGRAMS 43

 USE-CASE .. & ARCHITECTURE
o Use cases, as standalone chunks of system specification, dictate the sorts of
functionality that need to be provided by the system and constitute an aid for
identifying interfaces in an architecture.

o Use cases can also be grouped in terms of similar functionality, therefore

influencing the architecture of the system.

o Scenarios can be used to check how an architecture meets non-functional

requirements, in particular those that can be affected by the architecture, such
as security and safety requirements.

FROM DOMAIN TO REQUIREMENTS; USE-CASE & ACTIVITY DIAGRAMS 44

 USE-CASE .. & TESTING
o One way to validate a system is to use the walk-through technique, checking
the functionality related to each use case in turn.

o The walkthrough technique can also be used to elicit system tests where each
use case is required to deal with a number of scenarios – a process known as
verification.

FROM DOMAIN TO REQUIREMENTS; USE-CASE & ACTIVITY DIAGRAMS 45