Introduction

• is the process of developing abstract models of a system, with each

model presenting a different view or perspective of that system.
• representing the system using some kind of graphical notation,
– Unified Modeling Language (UML).
Models
• Used during the requirements engineering process
– to help derive the requirements for a system,
• During the design process
– to describe the system to engineers implementing the system-
communicating desired structure & behavior of system
• Implementation
– to document the system’s structure and operation.
• Not possible to comprehend complex system in total entirely

• Need to develop common understanding of problem and solution

• Cant afford a trial-error approach

Different models to represent the system
1. An external perspective, where you model the context or
environment of the system. i.e ERP(Financial, data source
2. An interaction perspective where you model the interactions
between a system and its environment or between the components
of a system.
3. A structural perspective, where you model the organization of a
system or the structure of the data that is processed by the
system{systems architecture}.
4. A behavioral perspective, where you model the dynamic behavior of
the system and how it responds to events/external stimuli
Types of Diagrams
1. Activity diagrams,
– show the activities involved in a process or in data
processing.
2. Use case diagrams,
– show the interactions between a system and its
environment.
3. Sequence diagrams,
– show interactions between actors and the system and
between system components.
4. Class diagrams,
– show the object classes in the system and the associations
between these classes.
5. State diagrams,
– show how the system reacts to internal and external
events
Interaction models-Use case modeling
• Represents how a system interacts with its environment
by illustrating the activities that are performed by the
users of the system and the system’s responses.

• aim to present a graphical overview of the functionality

provided by the system

• Describe the system’s activities from the user’s

perspective in words

• Goal is to create a set of use cases that describe all the

tasks that users need to perform with the system.
Purpose of Use case Diagrams
1. As a means of facilitating discussion about an existing or proposed
system amongst the software engineers
2. As a way of documenting an existing system.
3. As a detailed system description that can be used to generate a
system implementation.
4. Use cases help us understand and clarify the users’ required
interactions with the system
5. Reveal functional requirements of the new system.
Usecase
• A use case depicts a set of activities performed to produce some
output result.

• Each use case describes how an external user triggers an event to

which the system must respond.

• i.e a customer might rent a DVD or return a DVD, or a DVD

might become overdue.
Elements of a Use Case
• Use case

• Actor
• Subject/System

• Relationship
SYSTEM
• Its simply the system under consideration. It can be a website,
Software component, business process or application.
Banking app
• Represented with a rectangle

• Name of System is put at top

• Inside rectangle shows the scope of the Banking app, what

happens inside the banking app

• Anything outside the rectangle doesn’t happen in the banking app

ACTOR
• Object/Set of objects that interacts with the
system to achieve a given task
• Can be a person,organization, another system etc
– Represented as stick figures
– In our banking app-the actors are customer, bank(never use
Real Names)
– The actors are external to the system. Both Customer and Bank
will be using our app
– We have primary and secondary actors.
– Primary-Initiates the use with the system(Customer)Lauch the
banking app and do something with it.
– Secondary-reactionary to the system(Bank) will only react
once a customer does something.i.e check balance the app will
connect to their systems to get the balance.
Actor
• Primary actor should be to the left and secondary to the Right

• Customer engages with the banking app and then the Bank reacts.
USECASE
• Represents the functionality that is provided by
the system. It describes what the system does.
• Its represented as a named ellipse
• Are placed inside the rectangle as they are
functionalities that occur within the banking app.
• The banking app will allow customers to
– Login
– Check Account Balance
– Transfer Funds
– Make payments via bills
USECASE
• Considering our Banking app does the above, we shall
have a use case to illustrate each of the above.

• Each use case starts with a verb then noun/pronoun

• Always put usecases in a logical order if possible

RELATIONSHIPS
• A line that shows the interaction between actors and use cases.

• This relationship is called association.

• No line for the Login since this occurs within the Banking app and
doesn’t involve the Bank
RELATIONSHIPS
• Apart from Association other types of rship include
– Include

– Extend

– Generalization

• Once a user log in into the app, the password is verified before
completing the login process

• If the password is wrong the banking app returns an error message

Cont’
• We shall thus have two use cases for verify password and
for return error message.

• If a customer wants to make payment/transfer funds the

banking app must verify if there are sufficient funds to
complete the transactions.
Cont’
• While making the payment, a user may select to pay from
savings account or checking account
• None of the actors directly initiates the verify password/
return error message. These use cases happen within the
banking app every time there’s an attempt to login.
• We refer to this as an include relationship-Are used to show
relationship between base and included usecase. Everytime
base usecase is executed the included usecase is executed
too. Base usecase needs the include usecase to be
completed
Include
• We use a dashed arrow from the base usecase to included
usecase

• Everytime a user logs in, the banking app will automatically

verify the password.

• To represent this we do as follows

Include usecase
• The Transfer funds and make payment must first check if
the funds are available everytime and can be represented as
EXTEND RELATIONSHIP
• It has a base usecase and an extend usecase.
• When the base usecase is executed, the extend usecase is executed
sometimes but not every time.

• Extend usecase is only executed based on certain conditions

• We draw a dashed arrow from the extend use case to the base use case
as shown
EXTEND
• In our example the Login is base use case and Display login
error the extend use case.

• The app wont display the login error every time a user logs
in. It will only occur once in a while when the customer
enters incorrect password.
Include
• A better example

• Include happens all the time. Extend happens sometimes

GENERALIZATION
• When making a payment from the banking app we can do
so fro the checking account or savings account. Same case
with buying bundles from airtime or mpesa.

• Make Payment is the general/parent usecase and pay from

checking/savings are the specialized/child usecase.

• We use this arrow to represent generalization

• Cont’
• To show the generalization for the savings/checking
account we represent as follows

• It can also be used on actors i.e if you want to indicate a

new customer/returning customer as shown
Complet Use case Diagram
Usecase for Library Management System
• Identify Actors, usecases
• Actors Usecase

Consider a library, where a member can perform two

operations: issue book and return it. A book is issued to
a member only after verifying his credentials. Draw a
use case diagram for the problem.