UML Object-Oriented Analysis and Design

Object-Oriented Analysis and Design Using UML
Objectives

In this session, you will learn to:
Set system boundaries and project scope
Refine the system definition

Ver. 1.0 Slide 1 of 27

Setting Boundaries and Project Scope

System boundaries are set for each iteration of the system
to depict the functionality in terms of the use cases and
actors.
When designing a complex system, system boundary
enables you to clearly demarcate which sub-system is being
modeled.
After setting the system boundary, scope for the software
system is established.


Identifying System Boundary

To identify system boundary:
Prioritize use cases of the system.
Identify iterations for developing the system.
Identify the interaction between use cases and actors of each
iteration.
You represent the system boundary using a rectangular box
around the use cases in the use case diagram.


Establishing Project Scope

Establishing project scope before implementing the project
ensures that all the requirements of the project are fulfilled
in time and with the available resources.
Project scope is a function of:
Project functionality
Project resources
Available time
To establish the project scope:
Identify the requirements of the system.
Set priorities for the requirements to identify successive
iterations.
Assess the efforts required to implement the requirements.
Analyze the impact of implementing each requirement of the
system.


Just a minute

Which of the following refers to the objectives that the
deliverable product should fulfill?
1. Project Functions
2. Project Reports
3. System Boundary
4. Available Time

Answer:
Project Functions


Refining the System Definition

Use cases defined in the initial iterations of the development
process may not be elaborate and specific due to
inadequate information about the software system.
You need to refine software system definition to obtain
detailed and specific information that enables you to design,
code, and test the software system.
To refine the software system definition, you refine use
cases and establish relationships among use cases.


Refining Use Cases

The steps to refine use cases are:
Review the actors of the use cases.
Review the names of the use cases.
Refine the description of the use cases.
Define and refine the flow of events.
Identify alternate paths.
Identify preconditions and post conditions.
Identify the non-functional requirements.


Establishing Relationship among Use Cases

Relationships that can be established among use cases
are:
– Extend: Indicates that an existing use case is extended by
additional behavior to obtain another use case. The direction of
the arrow in the extend relationship points to the use case that
is extended to obtain another use case.


Establishing Relationship among Use Cases (Contd.)

Include: Indicates that the functionality of a use case is
included in the functionality of another use case. The direction
of the arrow in the include relationship points to the use case
that is included in another use case.


Realizing Use Cases in the Design Phase

Design phase requires understanding of how the
functionality of a use case can be implemented using
classes, interfaces, and sub-systems.
UML provides specific modeling constructs, known as
collaboration, to model use case realizations in the design
phase.
Collaboration is a collection of classes, interfaces, and
sub-systems that interact with each other to accomplish the
functionality of a use case.


Using Use Cases for Generating Test Cases

A test case developed for a particular function of the
software system includes a set of test input, execution
conditions, and expected results.
The role of test cases in the testing phase is:
Test cases form the foundation on which the test procedures
are designed and developed.
The effort required for testing is proportional to the number of
test cases.
The design and development of tests and the resources
required for the testing depends on the test cases.


Using Use Cases for Generating Test Cases (Contd.)

To generate test cases from use cases:
Identify the instances of a use case.
Identify the test input and expected results for each instance of
the use case.
Identify the conditions required to execute of each use case
instance.
Add test input values to complete the test cases.


Identifying Instances of a Use Case

A use case instance represents the execution of the
sequence of actions that a use case specifies.
Instances of each use case needs to be organized using a
test matrix which should contain the following information:
The instances of each use case in a numbered list.
The basic and alternate flows represented by each instance of
a use case.


Identifying the Execution Conditions for the Use Case Instances

You need to identify the execution conditions to execute
each use case instance, and then specify the state of the
execution condition.
States that can occur for an execution condition are:
– Valid (V): Specifies a condition that must be true for the basic
flow of events in the use case to execute.
– Invalid (I): Specifies a condition that invokes the alternate flow
of events in a use case.
– Not applicable (N/A): Specifies that the specified condition is
not applicable to a particular test case.


Adding Test Input Values

Adding test input values to the test matrix for a particular
test case completes the information required for executing
the test case.
Each row of the test matrix should indicate a particular test
case.
The columns of the test matrix should indicate:
Use case instances
Execution conditions
Test input values for test cases
Expected result
Actual result


Tracing Requirements

• You should trace requirements for the following two
reasons:
The customer requirements may change during the SDLC of a
project.
The implementation of a use case in an iteration may affect the
functionality of other use cases of the system.
The two approaches to perform requirements traceability
are:
– Backward: Tracing requirements from testing phase to
requirement gathering phase.
– Forward: Tracing requirements from requirement gathering
phase to testing phase.


Types of Use Cases used in an Iterative Process

Use case that can be created for an iterative model are:
– Facade use case: Created in the initial phase of requirements
gathering and captures the ad-hoc and most basic
requirements for the new system.
– Filled use case: Contain detailed information, which is not
provided in the facade use cases.
– Focused use case: Derived from the filled use cases and
describes the interaction of an actor with the software system.


Types of Use Cases used in an Iterative Process (Contd.)

Facade use cases describe software system in three terms,
information, input, and output.
Attributes that facade use cases contain are:
Use case name.
Description
Role name
Input and output



The information that a filled use case contains is:
Pre-conditions
Triggers
Actors
Basic coarse of events
Exceptions
Business rules



Activities involved in creating focused use cases are:
Merge duplicate processes
Focus on each use case
Manage scope changes
Manage risks and assumptions
Review


Demo: Refining the System Definition for the InfoSuper Bank ATM System

Problem Statement:
The InfoSuper bank needs to develop a bank ATM system to
improve their customer satisfaction level and to expand their
customer base. The task of developing the bank ATM system
has been entrusted on a development team of Janes
Technologies. The project manager of Janes Technologies
identifies the following use cases for the InfoSuper bank ATM
system:
Cash Withdrawal: Enables the bank customers to withdraw cash.
Cash Deposit: Enables the bank customer to deposit cash.
Check Deposit: Enables the bank customer to deposit check.
Transaction Summary: Enables the bank customer to get a
transaction summary.
Change PIN: Enables the bank customer to change the Personal
Identification Number (PIN) of their accounts.


Demo: Refining the System Definition for the InfoSuper Bank ATM System (Contd.)

Fund Transfer: Enables the bank customer to transfer funds within
the same bank
Checkbook Request: Enables the bank customer to request for a
checkbook.
Validation: Validates the ATM card and PIN of bank customer.
– The actors identified for the InfoSuper bank ATM system are:
– Centralized Bank System: Enables the ATM system to validate the
ATM card and PIN and verify the balance of the bank customer. It
also enables the ATM system to make transactions, such as cash
withdrawal and cash deposit. Centralized Bank System is external
to the ATM system and interacts with the ATM system. Therefore,
it is an actor.
– Bank Customer: Requests for the various services, such as cash
withdrawal and deposit, offered by the system. In addition, enters
the PIN number for accessing the services.



InfoSuper bank wants Janes Technologies to develop a
prototype of the few basic functionalities of the proposed
software system before proceeding with the final software
development. The functionalities that the InfoSuper bank wants
in the ATM prototype are:
The ATM should allow customers to withdraw cash from the
current and savings account
The ATM should allow customers to change their PIN
The ATM should allow customers to obtain a transaction summary



The project manager of Janes Technologies, Jennifer, adopts
an iterative approach for the development of the software
system. Jennifer decides to deliver the prototype after the
second iteration of the software development life cycle. In the
first iteration, Jennifer plans to implement the required
functionalities for the savings accounts only. In the second
iteration, she plans to implement the required functionalities for
the current accounts as well. Before developing the prototype,
Jennifer needs to create a design for the prototype.



Solution:
To design the prototype for the ATM system, you need to
perform the following tasks:
Identify the System Boundary for the first iteration and create the
corresponding Use Case diagram.
Refine the Use Case diagram for the first iteration.
Identify the System Boundary for the second iteration.
Create the Use Case diagram for the first and second iterations
using Visio.


Summary

In this session, you learned that:
The system boundary enables you to identify the iterations
involved in SDLC based on the priority of use cases.
The scope of a project depends on the objective of the project,
the available resources, and the time specified for its
completion. You need to establish the project scope before
implementing the design of the system.
To refine the system definition, you refine the use cases
identified for the system.
The extend and include relationships are established among
use cases to refine the system definition.


Summary (Contd.)

In the design phase, you realize a use case to understand how
the functions of the use case, which cannot be translated
directly into code, can be achieved.
In UML, use case realizations are modeled using
collaborations.
Collaboration is a collection of classes, interfaces, and sub-
systems that interact to implement the functions of a use case.
Use Cases are used to generate test cases.
Requirements are traced to ensure that the developed system
fulfills the needs of the customer adequately.
There are two approaches to trace requirements, backward
and forward requirements traceability.


UML Object-Oriented Analysis and Design

Recomendados

Recomendados

Más contenido relacionado

La actualidad más candente

La actualidad más candente (19)

Destacado

Destacado (19)

Similar a UML Object-Oriented Analysis and Design

Similar a UML Object-Oriented Analysis and Design (20)

Más de Niit Care

Más de Niit Care (20)

Último

Último (20)

UML Object-Oriented Analysis and Design

Notas del editor