SOFTWARE ENGINEERING I

Lecture 3
From Domain to Requirements; Use-Case & Activity
Diagrams

1
 TOPICS COVERED
• Business Processes Vs. Business Rules • Use-Case Models
•
• Business Rules representation techniques
•
Advantages
Elements & Symbols
• Business Processes representation • Descriptions
techniques • System Boundary

• Activity Diagrams • Scenarios

•
• Advantages
•
Generalization Among Actors
Relationships between Use-Cases
• Elements & Symbols • «Include» .. Sharing behaviour
2

• Examples • «Extend» Alternatives to main scenarios

•
•
Extending descriptions
Linking activities to user interfaces • Avoiding over-complex use case diagrams
• Use-Case as a planning aid
• Use-Case .. & Architecture
• Use-Case .. & Testing
 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);

3
 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.

4
 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:
• Using natural language to make it easy for business people to
understand it ( .. quite informal).
• Using UML and OCL;
• OCL is Object Constraint Language, which is a formal language used to represent
constraints in UML.

5
 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.
6
 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.

7
ACTIVITY DIAGRAMS .. ELEMENTS &
SYMBOLS

8
 ACTIVITY DIAGRAMS .. EXAMPLE 1

• 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.

9
ACTIVITY DIAGRAMS .. EXAMPLE 1

10
 ACTIVITY DIAGRAMS .. EXAMPLE 1
.. 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.
• In an activity diagram, activities are shown as rounded boxes; transitions are shown as lines with arrows.
• 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.
• The Figure shows two synchronisation bars, denoted by thick horizontal lines.
• 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.
• In UML, a note (with annotation) is shown as a rectangle with the top right- hand corner folded down.
• A dashed line is used to attach the note to the model element to which it refers.
11
 ACTIVITY DIAGRAMS .. EXAMPLE 2

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.

12
 ACTIVITY DIAGRAMS .. EXAMPLE 2
.. ELEMENTS & SYMBOLS
• 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.
• Each of the transitions leaving the first decision diamond has a guard to determine which
path should be taken under a given condition.
• One outgoing transition should always be taken – this means that exactly one of the relevant guards must always
evaluate to true.
• A diamond shape is also used as a merge node, which brings together alternative
mutually exclusive flows, as shown in Figure 2.
• A merge node will be reached only by one of the alternative flows and has a single outgoing flow.
• An activity has only one transition into and out of it.
• 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.

13
 ACTIVITY DIAGRAMS .. EXAMPLE 3

• Redraw the
activity
diagram of
example 1 to
allow the
choice
between coffee
with milk and
coffee without
milk.

14
 ACTIVITY DIAGRAMS
.. EXAMPLE 4

• Draw an activity diagram to

illustrate the preparation of a
pot of tea, which replaces the
activities relating to coffee
shown in example
• 1. The new diagram should
allow the
• choice of both milk and sugar
when the tea is poured.

15
 ACTIVITY DIAGRAMS .. EXAMPLE 5

• 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."

16
 ACTIVITY DIAGRAMS .. EXAMPLE 5

What are the business processes and business rules in the above system?

17
 ACTIVITY DIAGRAMS .. EXAMPLE 5
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.

18
ACTIVITY DIAGRAMS .. EXAMPLE 5

19
 ACTIVITY DIAGRAMS .. SWIM-LANES

Swim-lanes group activities associated with different roles.

• The swim-lanes show the role that is responsible for each activity.
• Activity diagrams represent the sequence of activities.
• 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.
• An activity diagram can help identify the stages at which each role requires some
interaction with the process.
In example 5 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’).
20
ACTIVITY DIAGRAMS ..
EXAMPLE 6

• An activity
diagram of
returning a
copy of a
book to the
library.

21
 ACTIVITY DIAGRAMS .. EXAMPLE 7

• Use examples 5 and 6 to produce a single activity diagram that models the
borrowing and returning of books, based on the following assumptions:
1. You do not need to consider fines for overdue books.
2. The librarian places returned books onto a trolley (which will be used to
carry the books back to the library’s shelves at certain times during the
day – an activity which need not be included at this stage).
3. There is just one queue to deal with members.

22
ACTIVITY DIAGRAMS
.. EXAMPLE 7

23
 ACTIVITY DIAGRAMS ..
LINKING ACTIVITIES TO USER INTERFACES
Before prototyping, the developer needs identify the appropriate interfaces
from the users’ requirements and determine where and when they will be
needed.
• One way to achieve this goal is to use an activity diagram.
• To the users, the interface is the software system: an unacceptable interface can lead
to failure.
• The user interface is the link between what the users want and what the developers
produce in response

24
ACTIVITY DIAGRAMS .. LINKING ACTIVITIES
TO USER INTERFACES

25
 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

Thus the user interface for the use case enroll new member must be available to the librarian when dealing with the enrolment request.
27
28
 USE-CASE MODELS

.. introduces a means of defining what a proposed system should do from a user’s perspective.
• This can provide the basis for a contract between the customer and the developer
• Your aim is to construct a software system that will meet the needs of its users. Hence you must
identify ‘who does what’.
• 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.
• 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.
• You should ask yourself who the actual users will be and what tasks they must perform with the
aid of your software system.
27
 USE-CASE MODELS .. ADVANTAGES

• Capturing and eliciting requirements;

• Representing requirements;
• Planning iterations of development;
• Validating software systems.
• Defining the scope of a system, as they represent the interaction of a system with
its environment.
• Acting as a discussion tool between developer and user, and offer a common
language for agreeing on the functions of the software system.

28
USE-CASE MODELS .. ELEMENTS &
SYMBOLS

29
 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 musthold 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.
30
 USE-CASE DIAGRAMS .. EXAMPLE 1

• 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).

31
 USE-CASE DIAGRAMS .. SYSTEM
BOUNDARY
The system boundary determines the scope of the system.
• It distinguishes between internal and external components.
• The external components are actors and the internal components are the use cases.
• In UML it is optional to use system boundary notation.
• A solid box drawn around the use cases with the actors located outside it represents the
system boundary.
• We use system boundary notation when the system is complex and includes
several subsystems.

32
USE-CASE DIAGRAMS .. SYSTEM
BOUNDARY

33
 USE-CASE DESCRIPTIONS

A scenario describes a sequence of interactions between the system and some actors.
• 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:
• 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:
• 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.

34
 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. 35
 USE-CASE
DESCRIPTIONS

36
 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.
• 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.
• 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.
37
 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.

38
 USE-CASE MODELS .. GENERALIZATION
AMONG ACTORS
• We introduce a new actor called Reserver associated
with the 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.

39
 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.
 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.

41
 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).
42
 USE-CASE MODELS ..
«INCLUDE» .. EXAMPLE

43
 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».
44
 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.

45
 USE-CASE MODELS ..
«EXTEND» .. EXAMPLE

46
USE-CASE MODELS
.. EXTENDING
DESCRIPTIONS

47
 USE-CASE MODELS ..
TO EXTEND OR TO INCLUDE?

We could show the log on use-case as a component of every use case that is
associated with an actor.
Extend or Include?

48
 USE-CASE MODELS ..
TO EXTEND OR TO INCLUDE?

Note that: there is no

implication of
ordering: time
ordering is not shown
in use-case diagrams.

49
 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..
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.
51
 USE-CASE .. & ARCHITECTURE

• 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.
• Use cases can also be grouped in terms of similar functionality, therefore
influencing the architecture of the system.
• 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.

52
 USE-CASE .. & TESTING

• One way to validate a system is to use the walk-through technique,

checking the functionality related to each use case in turn.
• 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.

53
MHC-PMS: Transfer data

Actors Medical receptionist, patient records system (PRS)

Description A receptionist may transfer data from the MHC-PMS to a general patient
record database that is maintained by a health authority. The information
transferred may either be updated personal information (address, phone
number, etc.) or a summary of the patient’s diagnosis and treatment.

Data Patient’s personal information, treatment summary

Stimulus User command issued by medical receptionist

Response Confirmation that PRS has been updated

Comments The receptionist must have appropriate security permissions to access the 56
patient information and the PRS.
Use case Example

57
THANKS! .. QUESTIONS?

54