Software

Engineering
(CSE 327)
Lecture 3
UML and Use
Case Diagram
 Analysis and Design
What to do ?

Analysis understand

Design
Object Oriented Programming
plan

How to do ? build

The more you understand Analysis and Design better,

the more easier the programming would be.
 Analysis and Design
• Analysis and design have been summarized in
the phase:
• do the right thing (analysis)
– Analysis emphasizes an investigation of the
problem and requirements, rather than a solution.
• do the thing right (design)
– Design emphasizes a conceptual solution that
fulfills the requirements, rather than its
implementation.
 Object-oriented analysis and design
• Object-oriented analysis emphasizes on
finding and describing the objects or concepts
in the problem domain.
• Object-oriented design emphasizes on
defining software objects and how they
collaborate to fulfil the requirements
Object-oriented analysis and design
 Software Development Process
• A set of disciplined activities, subject to
constraints and resources, to build a software
system with pre-defined purposes from
beginning to completion.
• AKA “Software Lifecycles”.
• Objectives – To understand the concept of
software development process and the
context in which software is developed
– Different approaches
– Different software process models
What is software development?
What is software development?
 Modelling the software process
• A software process model is an representation
of the software development process.
• The main purpose of the abstraction is to
explain different approaches to software
development.
• The model captures the primary activities that
we undertake in software development.
Why do we need a process model?
• Have a guideline for the development process.
• Help the team to understanding what to
expect during the software development
– The appropriateness of the development activities
– The resources and constraints involved in the
software development
– The goals of the current software project
• No single software process model is suitable
for all different types of software.
 Model

A model is a simplification of reality.

The model captures the important
aspects of the thing being modeled and
leaves out the rest of the details.
 Why do we model?
• We build models so that we can better
understand the system we are developing.
• Through modeling, we achieve four aims:
– 1. Models help us to visualize a system as it is or
as we want it to be.
– 2. Models permit us to specify the structure or
behavior of a system.
– 3. Models give us a template that guides us in
constructing a system.
– 4. Models document the decisions we have made.
Unified Modeling Language (UML)

• Not a programming language, a graphical

notation – specifically for drawing
diagrams for object oriented systems.
• UML diagrams are
– quick, useful communication tool
– Support system for brain
 Overview of UML
• The UML is a language for (overview of UML):
– Visualizing
– Specifying
– Constructing
– Documenting the artifacts of a software intensive
system.
 UML
• UML stands for Unified Modelling Language.
• An industry standard modelling language for object-
oriented software engineering.
• Developed in the mid-1990’s and standardised in
1997 (UML 1.1).
• UML 2.x is the current revision in use .
• UML includes a set of graphic notation techniques to
create visual models of object-oriented software-
intensive systems.
 History of UML
• In 1993 Booch was working in Rational Corporation along with other
members.
• In 1994, Rumbaugh joined Rational. The first attempt of unification was
made to combine Booch’s concepts, Rumbaugh’s OMT and CRC.
• In 1995, Jacobson joined Rational. Another unification attempt was
made to combine Booch’s concepts, Rumbaugh’s OMT and Jacobson’s
Objectory. This unification was named as Unified Modeling Language
(UML).
• In 1996, proposal was made to Object Management Group (OMG) for
recognizing UML as a standard language.
• In 1997, OMG recognized UML as a standard language.
• In 2000, ISO recognized UML as a standard language. The version of
UML was 1.0.
• In 2004, another major upgrade was made to UML’s specification which
is known as UML 2.0.
• The latest version of UML till date is UML 2.4.1 published in Aug 2011.
History of UML
Unified Process and UML
 Types of UML Diagrams
• There are two main categories:
• Structure diagrams
– analyze and depict the structure of a system or process.
– show different objects in a system.

• Behavioral diagrams
– show what should happen in a system.
– describe the behavior of the system, its actors, and its
building components.
– describe how the objects interact with each other to
create a functioning system.
Types of UML Diagrams
 Defining Requirements
• What the application
– requires to do
– What must the app. do
• Functional Requirements
– What does app do? Features / Capabilities
• Non Functional Requirements
– What else? Help
Performance
Support Security
 Functional Requirements Example
• Phrase starts with like
– System must or application must or program must

Programmust
System must
must
Application allow
must
display receipts
allow heartto
automatically
the user besearch
produce
to
rate, by customer’s
generated
monthly
temperatureby and
via e-maillast
comparative
analysis
blood report.of aReport
name pressure
or telephone number must be to
patient connected in the
PDF format
patient and
monitor
automatically emailed to everyone on first day of the month.
Non-Functional Requirements Example

Help
System
desk must
available
respond
by telephone.
to searches
Mon – Fri28seconds.
within am – 6 pm
 FURPS / FURPS+
• Functional requirements The features of the App

• Usability requirements Help, Documentation /

Tutorial
• Reliability requirements Failure recovery

Capacity, Resource,
• Performance requirements response time
• Supportability requirements Maintainability

+ Implementation requirements,
Physical requirements, Interface requirements
 FURPS / FURPS+
• Functional requirements The features of the App

• Usability requirements Help, Documentation /

We need absolute minimum Tutorial
• Reliability requirements Failure recovery
set of requirements
Capacity,
what Resource,
• Performance
Not whatrequirements
is nice to have, not is
response time
optional
• Supportability requirements Maintainability

+ Implementation requirements,
Physical requirements, Interface requirements
 Use case modeling
• Use case modeling (use case diagrams) describes
what a system does or what is the functionality
provided by the system to benefit the users.
• Use case modeling was created by Ivar Jacobson.
• More than any other diagrams in UML, use case
diagrams allow us to quickly gather the requirements
of the software system.
• The primary components of a use case model are use
cases, actors or roles and the system being modeled
also known as the subject.
 Use Cases
• The primary purpose of use cases are:
– To describe the functional requirements of the system,
resulting in an agreement between the stakeholders and
the software developers who are developing the system.
– To give a clear and consistent description of what the
system should do.
– To provide a basis for conducting system tests to verify
whether the system works appropriately or not.
– To provide the ability to transform functional requirements
into classes and operations in the system.
 Use Cases
• A set of scenarios related by a common actor and a goal
• A description of sequences of actions performed by a
given system to produce a result for an actor
• Use cases specify the expected behaviour [what], and
not the exact method of making it happen [how]
• Use Cases should have the following three things:

Title What is the goal ?

Actor Who desires it ?
Scenario How it is accomplished ?
 Use Cases : Title
• Short Phrase, active verb

Register new member

Transfer funds

Purchase items

Collect late payments

 Use Cases : Actor
• Represent roles that humans, hardware devices, or
external systems play while interacting with a given
system User
Customer

Member

Administrator

ATM Machine
 Use Cases: Scenario as paragraph
Title: Purchase Items
Actor: Customer
Scenario: Customer reviews items in shopping cart.
Customer provides payment and shipping
information. System validates payment information
and responds with confirmation of order and
provides order number that Customer can use to
check on order status. System will send Customer a
confirmation of order details and tracking number in
an email.
 Use Cases: Scenario as Steps
Title: Purchase Items
Actor: Customer
Scenario:
1. Customer chooses to enter the checkout process.
2. Customer is shown a conformation page for their order,
allowing them to change quantities, remove items, or cancel.
3. Customer enters his/her shipping address.
4. System validates the customer address.
5. Customer selects a payment method.
6. System validates the payment details
7. System create an order number that can be used for tracking
8. System displays a confirmation screen to the customer
9. Email is sent to the customer with order details.
 Use Cases: Scenario Additional Details
Title: Purchase Items
Actor: Customer
Scenario:
Scope:
Level:
Extensions: Describe steps for out-of-stock situations
Extensions: Describe steps for order never finalized
Preconditions: Customer has added at least 1 item to the
shopping cart
Postconditions:
Stakeholders:
Example of Use Cases
Example of Use Cases
 Use Case Diagram
• Use Case diagram shows a set of use cases
and actors and their relationships.
• A use case diagram at its simplest is a
representation of a user's interaction with the
system and depicting the specifications of a
use case.
• These diagrams are important in organizing
and modeling the behaviors of a system.
 Use Case Diagram
• Use Case Diagrams have only 4 major
elements:
– The actors that the system you are describing
interacts with,
– the system boundary itself, Identify an implicit
separation between actors (external to the
system) and use cases (internal to the system)
– the use cases, or services, that the system knows
how to perform, and
– the lines that represent relationships between
these elements.
 Use Case Diagram
• Actor is represented by a labeled stick figure,
or a class rectangle.

• Use cases are represented by a labeled ellipse.

 Use Case Diagram
• A typical UML Use Case Diagram will be
composed of many diagrams and sub-diagrams,
and should contain use case ovals, one for each
top-level service that the system provides to its
actors. Any kind of internal behavior that the
system may have that is only used by other parts
of the system should not appear in the system
boundary.
• The system boundary only appears on the top-
level diagram.
Use Case Diagram
System Boundary
System Name
 Use Case Relationships

• Include
• Extend
• Generalizations
 Use Case Relationships (Include)
• Include relationship
– The include relation is drawn from a use case X to
another use case Y to indicate that the process of doing
X always involves doing Y at least once.
– If a certain use case includes several others, that means
that all of the component use cases must be completed
in the process of completing the aggregate use case
(although there is no specification in UCDs of the order
in which these are completed).
– In brief, it can be read X uses Y means that "X has a Y" as
part of it's behavior.
Use Case Relationships (Include)

<<include>>

<<include>>

<<include>>

<<include>>

<<include>>
Use Case Relationships (Include)
Use Case Relationships (Include)
 Use Case Relationships (Extend)
• Extend relationship
– used for extracting alternative courses from a base
use case into a new use case and attaching it to the
base use case.
– connects an extension use case to a base use case.
– extending use case continues the behavior of a base
use case. The extending use case accomplishes this
by conceptually inserting additional action
sequences into the base use-case sequence.
– Extending use case typically defines optional
behavior.
 Use Case Relationships (Extend)
Condition

Condition
Use Case Relationships (Extend)

Registration use case is complete and meaningful on its own.

It could be extended with optional Get Help On Registration use case.
 Use Case Relationships (Generalizations)
• Generalizations relationship
– The generalizations relationship is drawn from a use
case X to a use case Y to indicate that the process X
is a special case behavior of the same type as the
more general process Y.
– A generalization relationship is a parent-child
relationship between use cases in which the child
use case is an enhancement of the parent use case.
– Child use case is effectively, an alternate course of
the base use case.
– Base use case could be abstract use case
Use Case Relationships (Generalizations)

<<include>>

<<include>>
Use Case Relationships (Generalizations)
 Difference between use case relationships

Base use case could be Base use case is Base use case is
abstract use case complete (concrete) by incomplete.
(incomplete) or itself, defined
concrete (complete). independently.
Specialized use case is Extending use case is Included use case
required, not optional, optional, required, not optional.
if base use case is supplementary.
abstract.
No explicit condition to Could have optional No explicit inclusion
use specialization. extension condition. condition.
Bank ATM
Bank ATM

ATM Help
Bank ATM