04 ooad uml-04

Object-Oriented Analysis and Design Using UML
Objectives

In this session, you will learn to:
Analyze a problem by using business and system modeling
Create use case diagrams for system modeling

Ver. 1.0 Slide 1 of 29

Defining the System

Defining a new software system consists of the following
phases:
Analyzing a problem
Identifying stakeholders
Identifying, gathering, organizing, and documenting
requirements


Analyzing a Problem

Analyzing a problem involves preparing a concise problem
statement that:
Defines the workflow of the existing processes of the
organization.
Defines the constraints that exist for the proposed solution.
Defines the goals that need to be achieved by the new
software system.
To analyze a problem, two types of modeling techniques
are used:
Business modeling
System modeling


Business Modeling

Business modeling describes the working of the existing
process of an organization and the role that each person
plays in the process.
Business modeling provides two models for analyzing the
existing system:
– Business use case model: Represents the functionality of the
existing process using business actors and use cases.
– Business object model: Represents detailed interaction
between business workers and business entities. A business
object model uses the following diagrams for a representation
of the workflow of the existing processes:
Class diagram
Activity diagram
Interaction diagram


Business Modeling (Contd.)

Consider the following case study of Analyzing a Hospital
Administration System and identify business use cases,
business workers, and business actors to analyze the
existing process of the hospital administration system.

Microsoft Word
Document


System Modeling

System modeling shows the flow of information between the
proposed software system and its environment at different
levels of hierarchy.
The business modeling constructs that you can derive and
use for system modeling are:
Business use cases
Business actors
Behaviors of business workers
Business entities


System Modeling (Contd.)

Use the business use cases identified for the hospital
administration system case study to derive the system use
cases for the hospital administration system.


Just a minute

Which of the following diagrams of Business Object Model
shows the static or internal structure of the business in the
form of relationships among various classes for the existing
system?
1. Class diagrams
2. Use-case diagrams
3. Activity diagram
4. Interaction diagram

• Answer:
Class diagram


Identifying Stakeholders

Identifying the needs of stakeholders enables a software
team to make better decisions in the definition and
implementation phases of the development process.
Guidelines that you should follow when you interview the
stakeholders are:
Ask direct questions.
Probe stakeholders to define the conflicting requirements in
detail.
Document the input gathered from interviews in a universally
accepted language, such as English.
The input provided by stakeholders during the interview is
documented as the required features of the software
system.


Identifying Stakeholders (Contd.)

The attributes of the features that you should document are:
Status
Rank
Effort
Uncertainty
Stability
Target release
Assigned to
Source


Identifying and Managing Requirements

Requirement management is a systematic approach for
managing the requirements of a project.
The various phases of requirement management are:
Requirements gathering
Requirements analysis and negotiation
Requirements specification
Requirements validation


Requirements Gathering

The various activities involved in gathering requirements
are:
Assessing the economic, technical, and operational feasibility
for the proposed software system
Identifying the stakeholders and end users who specify
requirements and jargons appearing in the existing process
Identifying the domain constraints in the proposed software
system
Identifying methods for requirement elicitation
Identifying ambiguous requirements
Identifying the trivial requirement


Requirement Analysis and Negotiation

Requirement analysis is the process of categorizing and
organizing requirements into functional and non-functional
requirements.
Functional requirements are derived from the need of the
stakeholders and include the functions and features of the
software system.
Non-functional requirements address the implied features of
the software system.
Non-functional requirements do not directly indicate the
functions of a software system.


Requirements Specification

Requirement specification is an activity that involves
documenting the requirements analyzed in the analysis
phase.
The Software Requirements Specification (SRS) is a
document produced at the culmination of the analysis task.
The information that an SRS must provide is:
Definition of the software system
Purpose of the SRS document
Scope of the software system
Functional requirements
Non-functional requirements
Conditions under which the proposed software system
operates


Requirement Validation

Requirement validation is an activity that involves validating
all the requirements after they are specified.
Validating the requirements involves:
Identifying all the ambiguous requirements
Identifying the source of each requirement
Stating the requirements quantitatively
Identifying the dependence among requirements
Verifying if the requirements are concise, testable, and
traceable
Verifying that no requirement is conflicting with the constraints
imposed on the software system


Requirement Gathering Techniques

To gather requirements effectively, you need to follow a
predefined approach. For example, you need to perform the
following activities to gather requirements:
Interview stakeholders.
Conduct brainstorming sessions among stakeholders.
Prepare questionnaires.
Observe the existing processes of the organization.
Appoint a domain expert.


Identifying Storyboarding Techniques

Storyboarding is a technique that involves the task to design
the user interface on paper before you develop the software
system.
The user interface storyboards match the definitions of the
use case paths described in the basic course of events and
provide the graphic presentations of various processes.
Storyboarding enables you to obtain customer feedback on
how the system should work at a very early stage.
The objective of storyboarding is to:
Understand data visualization.
Define and understand business rules.
Model algorithms and other mathematical constructs.
Demonstrate reports.


Identifying Storyboarding Techniques (Contd.)

Types of storyboards:
Passive
Active
Interactive


Creating Use Case Diagrams for System Modeling

A use case diagram for system modeling describes:
The interaction between use cases and actors of the proposed
software system.
The relationships, such as associations and generalizations,
existing between use cases and the actor.
The use cases are text descriptions of the interaction
between outside entities and the software system.
The use cases for the proposed software system should
contain the following characteristics:
Provide value to actors
Provide a brief description of the desired functionality


Creating Use Case Diagrams for System Modeling (Contd.)

The information that a use case should contain is:
Name
Summary
Basic course of events
Alternative paths
Exception paths
Triggers
Assumptions
Preconditions
Post conditions
Business rules
Non-functional requirements
Authors
Date



System actors are external entities that interact with the
software system and affect the system functionality.
System actors can be classified as:
– Primary actors: Directly interact with the system and initiate
the use case.
– Secondary actors: Do not directly interact with the system but
can initiate interaction of a primary actor with the system.



The relationship among actors represents their interaction
with other actors and use cases.
The various types of relationships that exist among actors
are:
– Generalization relationship: Exists among actors that have
similar behavior and similar properties.
– Association relationship: Shows the communication path
between the use case and the actor.
• Association is represented using an arrow or a simple line.
• The arrow show the direction of communication and the line
indicates that the communication is occurring in both the
directions.


Demo: Identifying Requirements and Creating a Use Case Diagram for InfoSuper Bank

Problem Statement:
The InfoSuper bank is a leading financial institution having its
clientele across the globe. The bank offers following services to
the customers:
Corporate banking
Personal banking
Mutual funds
Financer
Home loans
The InfoSuper bank earns 45% of its total revenue from the
personal banking service. As a result, they want to improve
their customer satisfaction level and put efforts for retaining
and gaining customer loyalty. The bank conducts a survey to
find the customer requirements in terms of process time,
satisfaction level, and resource requirement for personal
banking.


Demo: Identifying Requirements and Creating a Use Case Diagram for InfoSuper Bank (Contd.)

The result of the survey highlights that on an average a
customer visits the bank 10 to 15 times per month for
transactions, such as cash withdrawal, check deposit, and
acquiring transaction summary.
The bank needs to have a software system, which can reduce
customer visits and improve customer service through
improved facilities. The representatives of the InfoSuper bank
presented the requirements for the software system to Janes
Technologies After analyzing the requirement document, the
project manager, Jennifer, of Janes Technologies suggested
that the bank should incorporate an Automatic Teller Machine
(ATM) system with the following features:
– Cash withdrawal
– Cash deposit
– Transaction summary
– Changing the PIN



Fund transfer within the same bank
Information about various other services provided by the bank
– The place where the ATM system will be deployed should also
provide boxes where customers can drop the checks and
request for checkbooks.
– Jennifer needs to design the ATM system highlighting the
system advantages and constituents.



Solution:
To design the ATM system, you need to perform the following
tasks:
Identify requirements.
Create SRS.
Identify use cases.
Identify actors.
Depict the relationship between use cases and actors.
Save the model.


Summary

In this session, you learned that:
Business modeling and system modeling enable you to
construct the behavioral as well as functional models of a
system. As a result, they enable you to identify the problems of
the existing system and the requirements of the proposed
system.
It is essential to identify the stakeholders and their needs to
develop a system.
Requirement management is an activity that enables you to
systematically manage requirements that evolve during the
development of a system.
Requirement management consists of various activities, such
as requirement gathering, requirement analysis and
negotiation, requirement specification, and requirement
validation.


Summary (Contd.)

An SRS is a formal document that contains all the final
requirements gathered through various processes, such as
stakeholder interviews.
The requirements validation phase enables you to identify and
remove ambiguous requirements.
Requirements can be classified as functional and non-
functional. The customer explicitly states the functional
requirements as opposed to the non-functional requirements,
which are the extensions of functional requirements.
Use cases are used to model both, functional as well as non-
functional requirements.
The use case diagram shows the interaction between actors
and use cases.
Actors represent any external entity that has an effect on the
output of the system.


Summary (Contd.)

There are two types of relationships in which an actor
participates, generalization and association.


04 ooad uml-04

Recommended

Recommended

More Related Content

What's hot

What's hot (20)

Similar to 04 ooad uml-04

Similar to 04 ooad uml-04 (20)

More from Niit Care

More from Niit Care (20)

Recently uploaded

Recently uploaded (20)

04 ooad uml-04

Editor's Notes