20CS5103 – OBJECT

ORIENTED ANALYSIS
AND DESIGN
Syllabus
OBJECTIVES:
• To understand the Object-based view of Systems and develop robust object-
based models for Systems
Syllabus
UNIT I OOAD BASICS
Introduction - Overview of Object-Oriented system development - Object Basics – OO Themes – Evidence for the usefulness of OO Development – OO
Modeling – Unified Process -Inception – Use case Modeling - Relating Use cases – include, extend and generalization. Case Study: The Next Gen POS system,
The Monopoly Game system

UNIT II STATIC MODELING

Elaboration - Domain models - Finding conceptual classes and description classes – Associations – Attributes – Domain model refinement – Finding
conceptual class hierarchies- Aggregation and composition- UML class diagrams – Relationship – Inheritance – Abstract classes – Polymorphism - Operation
contracts

UNIT III DYNAMIC MODELLING

System sequence diagrams – Communication diagrams - Relationship between sequence diagrams and use cases - Logical architecture and UML package
diagram – Logical architecture refinement - UML activity diagrams and modelling-State Chart diagram- Component and Deployment diagram.

UNIT IV DESIGN PATTERNS

Object-oriented design methodology – Common base class - GRASP: Designing objects with responsibilities – Patterns– Creator – Information expert – Low
coupling –Controller – High cohesion – Designing for visibility - Applying GoF design patterns – Adapter – Singleton – Factory – Strategy – Composite - Facade
and observer patterns

UNIT V IMPLEMENTATION AND TESTING

Mapping design to code – Forward Engineering – Reverse Engineering –Object-Oriented Methodologies-Test driven development – Refactoring-Develop Test
Cases and Test Plans
Syllabus
OUTCOMES:
At the end of the course, the students will be able to:
• Express software design with UML diagrams
• Design software applications using OO concepts.
• Identify various scenarios based on software requirements
• Transform UML based software design into pattern based design using design
patterns
• Understand the various testing methodologies for OO software
Introduction to OOAD with OO Basics
Object-oriented analysis and design (OOAD) is a popular technical approach for

• analyzing,

• designing an application, system, or business

• by applying the object oriented paradigm and

• visual modeling throughout the development life cycles for better

communication and product quality.
Introduction to OOAD with OO Basics
Object-oriented programming (OOP) is a method

• based on the concept of “objects",

• which are data structures that contain data,

• in the form of fields,

• often known as attributes;

• and code, in the form of procedures,

• often known as methods.

Introduction to OOAD
What is OOAD
- Object-oriented analysis and design (OOAD) is a software engineering
approach that models a system as a group of interacting objects .
- Analysis — understanding, finding and describing concepts in the problem
domain.
- Design — understanding and defining software solution/objects that represent
the analysis concepts and will eventually be implemented in code.
- OOAD - A software development approach that emphasizes a logical solution
based on objects.
Introduction to OOAD
Software development is dynamic and always undergoing major change.

System development refers to all activities that go into producing information system solution.

System development activities consist of

• system analysis,

• modelling,

• design,

• implementation,

• testing and maintenance.

A software development methodology series of processes can lead to the development of

an application.
Introduction to OOAD
ORTHOGONAL VIEWS OF THE SOFTWARE

Two Approaches,

 Traditional Approach

 Objected-Oriented Approach

TRADITIONAL APPROACH

• Collection of programs or functions.

• A system that is designed for performing certain actions.

• Algorithms + Data Structures = Programs.

• Software Development Models (Waterfall, Spiral, Incremental, etc..)

Introduction to OOAD
OBJECT ORIENTED APPROACH

• OO development offers a different model from the traditional software based

on functions and procedures.

• software is a collection of discrete object that encapsulate their data as

well as the functionality.

• Each object has attributes (properties) and method (procedures).

• software by building self contained modules or objects that can be easily

REPLACED, MODIFIED AND REUSED.

Introduction to OOAD
BENEFITS OF OBJECT ORIENTATION

Faster development,

Reusability,

Increased quality

 modeling the real world and provides us with the stronger equivalence of the
real world‘s entities (objects).

Raising the level of abstraction to the point where application can be

implemented in the same terms as they are described.
Introduction to OOAD
WHY OBJECT ORIENTATION

• Changing requirements

• Easier to maintain

• More robust

• Promote greater design

• Code reuse
OBJECT BASICS
Goals:

The developer should

Define Objects and classes

Describe objects, methods, attributes and how objects respond to messages,

Define Polymorphism, Inheritance, data abstraction, encapsulation, and

protocol,

Describe objects relationships,

Describe object persistence,

OBJECT BASICS
EXAMPLES OF OBJECT ORIENTED SYSTEMS

In OO system , “everything is object”.

A spreadsheet cell, bar chart, title in bar chart, report,

numbers, arrays, records, fields, files, forms, an invoice, etc.

A window object is responsible for things like opening, sizing, and closing
itself.

A chart object is responsible for things like maintaining data and labels even
for drawing itself.
OBJECT BASICS
EXAMPLES OF OBJECT ORIENTED SYSTEMS

In OO system , “everything is object”.

A spreadsheet cell, bar chart, title in bar chart, report,

numbers, arrays, records, fields, files, forms, an invoice, etc.

A window object is responsible for things like opening, sizing, and closing
itself.

A chart object is responsible for things like maintaining data and labels even
for drawing itself.
OBJECT BASICS
WHAT IS AN OBJECT?
Object is an instance of a class.

A class has represents collection of objects having same characteristics

properties that exhibit same properties.
Attributes or properties describe object‘s state (data) and methods (properties
or functions) define its behavior.
An object is an entity.

It knows things (has attributes)

It does things (provides services or has methods

OBJECT BASICS
OBJECT’S ATTRIBUTES

Attributes represented by data type.

They describe objects states.

In the Car example the car’s attributes are:

color, manufacturer, cost, owner, model, etc.

OBJECT BASICS
Object Methods

Methods define objects behaviour and specify the way in which

an Object’s data are manipulated.

In the Car example the car’s methods are:

drive it, lock it, tow it, carry passenger in it

OBJECT BASICS
CLASSES

 The role of a class is to define the attributes and methods (the state and
behaviour) of its instances.

Used to distinguish one type of object from the other.

Set of objects, that share common methods, structure, behaviour.

Single object is simply an instance of class.

The class car, for example, defines the property color. Each individual car
(object) will have a value for this property, such as "maroon," "yellow" or
"white."
OBJECT BASICS
Polymorphism

 Polymorphism is the ability of an object to take on many forms.

public int mulNum (int x, int y) {

//

public int mulNum (double x, double y) {

//

}
OBJECT BASICS
Inheritance

 Classes can share, obtain or “inherit” properties and methods that belong to existing classes.

public class Flower {

String name;

String color;

void pollination() {

public class Rose extends Flower {

}
OBJECT BASICS
Data Abstraction
Data abstraction refers to the process of only displaying relevant properties
and methods to handle an object, while hiding the rest
Once a class has been declared as abstract, however, it cannot be instantiated.

public abstract class ExampleAbs {

// declare your fields

// declare normal methods

}
OBJECT BASICS
Encapsulation
• Encapsulation refers to keeping objects with their methods in one place.

public class Employeedetails {

private String employeeName;

private String employeeDept;

private int salary;

public void work () {

public void train () {

}
Unified Process
Unified Process (UP)
• The Unified Process is a popular iterative software development process for
building object oriented system.
• Iterative and evolutionary development involves relatively early programming and
testing of a partial system, in repeated cycles.
• It typically also means that development starts before the exact software
requirements have been specified in detail;
• Feedback (based on measurement) is used to clarify, correct and improve the
evolving specification
• Rational Unified Process (RUP) – Detailed Refinement of unified process
FOUR PHASES OF UNIFIED PROCESS
• Inception
• Elaboration
• Construction
• Transition
FOUR PHASES OF UNIFIED PROCESS
• Inception

estimatesApproximate vision, business case, scope, vague .

• Elaboration

Refined vision, iterative implementation of the core architecture, resolution of high risks,
identification of most requirements and scope, more realistic estimates.
• Construction

Iterative implementation of the remaining lower risk and easier elements, and preparation for
deployment.
• Transition

Beta tests, deployment.

UP PHASES DIAGRAM
UP Disciplines
• Several disciplines in the UP

Business Modelling - The Domain Model artifact, to visualize noteworthy

concepts in the application domain.

Requirements The Use-Case Model and Supplementary Specification artifacts to

capture functional and non-functional requirements.

Design The Design Model artifact, to design the software objects.

Implementation means programming and building the system, not deploying it.

The Environment setting up the tool and process environment.

Inception - Introduction
The primary goal inception phase is to establish the case viability of the
proposed system.
The Task perform during inception
 Establish

 Prepare a preliminary project schedule and cost estimate.

 Feasibility
 Buy or Develop it
Inception - Activities
• Formulate the scope of the project.

Needs of every stakeholder, scope, boundary conditions and acceptance criteria

established.

• Plan and prepare the business case.

Define risk mitigation strategy, develop an initial project plan and identify known cost,
schedule, and profitability trade-offs.

• Synthesize candidate architecture.

Candidate architecture is picked from various potential architectures

• Prepare the project environment.

Inception - Exit criteria
• An initial business case containing at least a clear formulation of the product
vision - the core requirements - in terms of functionality, scope, performance,
capacity, technology base.

• Success criteria (example: revenue projection).

• An initial risk assessment.

• An estimate of the resources required to complete the elaboration phase.

Elaboration - Entry criteria
• The products and artifacts described in the exit criteria of the previous phase.

• The plan approved by the project management, and funding authority, and the
resources required for the elaboration phase have been allocated.
Elaboration - Activities
• Define the architecture.

Project plan is defined. The process, infrastructure and development environment are
described.

• Validate the architecture.

• Baseline the architecture.

To provide a stable basis for the bulk of the design and implementation effort in the
construction phase.
Elaboration - Exit criteria
• A detailed software development plan, with an updated risk assessment, a management plan, a
staffing plan, a phase plan showing the number and contents of the iteration , an iteration plan,
and a test plan

• The development environment and other tools

• A baseline vision, in the form of a set of evaluation criteria for the final product

• A domain analysis model, sufficient to be able to call the corresponding architecture ‘complete’.
Construction - Entry criteria

• The product and artifacts of the previous iteration. The iteration plan must
state the iteration specific goals

• Risks being mitigated during this iteration.

• Defects being fixed during the iteration.

Construction - Activities
• Develop and test components.

Components required satisfying the use cases, scenarios, and other

functionality for the iteration are built. Unit and integration tests are done on
Components.

• Manage resources and control process.

• Assess the iteration

Satisfaction of the goal of iteration is determined.

Construction - Exit Criteria

• A release description document, which captures the results of an iteration

• Test cases and results of the tests conducted on the products,

• An iteration plan, detailing the next iteration

• Objective measurable evaluation criteria for assessing the results of the next
iterations.
Transition - Entry criteria

• The product and artifacts of the previous iteration, and in particular, a

software product sufficiently mature to be put into the hands of its users.
Transition - Activities

• Test the product deliverable in a customer environment.

• Fine tune the product based upon customer feedback

• Deliver the final product to the end user

• Finalize end-user support material

Transition - Exit criteria
• An update of some of the previous documents, as necessary, the plan being
replaced by a “post-mortem” analysis of the performance of the project
relative to its original and revised success criteria.

• A brief inventory of the organization’s new assets as a result this cycle.

UML DIAGRAM
AN INTRODUCTION TO UML DIAGRAM

• The Unified Modeling Language is a language for specifying, constructing,

visualizing, and documenting the artifacts of a software-intensive system.

WHAT IS UML .. ?
 Unified Modeling Language (UML) is a standardized general purpose
modeling language in the field of software engineering.

The standard is created and managed by, the Object Management Group.

UML includes a set of graphic notation techniques to create visual models of

software-intensive systems.
UML DEFINITION
The Unified Modeling Language is a standard diagramming notation for

specifying , visualizing, constructing and documenting the artifacts of

software system, as well as for business modeling and other non-software

systems.
GOALS OF UML
To provide ready to use and expensive visual modeling language for
developing the effective system model.

Modeling must be independent of programming language.

The tool should support high level concepts such as collaborations,

framework, patterns and components.

To integrate the organizational standards in the software systems.

THREE WAYS TO APPLY UML
UML as Sketch – Informal and Incomplete diagrams.

UML as blueprint – Detailed design for reverse and forward engineering.

 UML as Programming Language – Complete Executable specification of a

system.
THREE PERSPECTIVES TO APPLY UML
Conceptual Perspective – Diagrams are describe as interpreted as real world.

Specification Perspective – Diagrams are describe as software abstraction or

components.

 Implementation Perspective – Diagrams are describe software

implementation in particular technology.
Types of UML diagram:
 use case diagram
 class diagram
 Interaction diagram
sequence diagram

Collaboration diagram
 Activity diagram
 Component diagram
 Deployment diagram
CASE STUDY – THE NEXTGEN POS SYSTEM
 The NextGen point-of-sale (POS) system

A POS system is a computerized application used to record sales and handle

payments; it is typically used in a retail store.

 It includes hardware components – Computer, Bar code scanner, and

Software to run the system.

 It interfaces to various service applications, - third-party tax calculator and

inventory control.

These systems must be relatively fault-tolerant

CASE STUDY – THE NEXTGEN POS SYSTEM
 if remote services are temporarily unavailable. Example - the inventory
system, they must still be capable of capturing sales and handling cash
payments.

 Support multiple and varied client-side terminals and interfaces include a

thin-client Web browser terminal, touch screen input, wireless PDAs and so
forth.
INCEPTION
 Introduction

 What is Inception?

 Inception: An Analogy

 Inception May Be Very Brief

 Understanding Requirements

 Types of Requirements
INCEPTION
 Introduction

 Inception is the initial short step to establish a common vision and basic
scope of the project.

 It will include
 Analysis of 10% use cases.
 Analysis of non functional requirements.
 Creation of a business case.
 Preparation of the development environment.
INCEPTION
 Introduction

 Required in initial step for the kind of following questions.

 What is the vision and business case for the project?
 Feasible?
 Buy and/or Build?

 Rough unreliable range of cost : (10K$ - 100K$)?

 Should we start or stop?

INCEPTION
 What is Inception?

 Defining the vision and obtaining an doing some requirements exploration.

However, the purpose of the inception step is not to define all the
requirements, or generate a believable estimate or project plan.
INCEPTION
Inception: An Analogy

 The inception phase is like step one in this analogy.

 It is premature — there is insufficient information, but it gives able to answer

"how much" and "when" questions without the cost.

 In UP terms, the realistic exploration step is the elaboration phase.

 Inception phase is to a feasibility study to decide if it is even worth investing.

INCEPTION
Inception May Be Very Brief

 The intent of inception is to establish

 Common vision for the objectives of the project.

 Determine if it is feasible.

 Decide if it is worth some serious investigation in elaboration.

INCEPTION
UNDERSTANDING REQUIREMENTS

 Requirements are capabilities and conditions to which the system or project.

 The primary challenge of requirements work is to find, communicate, and

remember .

 The UP promotes a set of best practices, one of which is manage

requirements.

 Manage Requirements - a systematic approach to finding, documenting,

organizing, and tracking the changing requirements of a system
INCEPTION
Types of Requirements

 In the UP, requirements are categorized according to the FURPS+ model.

 Functional—features, capabilities, security.

Usability—human factors, help, documentation.

Reliability—frequency of failure, recoverability, predictability.

 Performance—response times, throughput, accuracy, availability, resource usage.

 Supportability—adaptability, maintainability, internationalization, configurability

INCEPTION
Types of Requirements

 The "+" in FURPS+ indicates

 Implementation—resource limitations, languages and tools, hardware, ...

 Interface—constraints imposed by interfacing with external systems.

 Operations—system management in its operational setting.

 Packaging

 Legal—licensing and so forth

USECASE MODELLING
USECASE MODEL
INTRODUCTION

 Use cases are a widely used mechanism to discover and record requirements.

 Writing use cases—stories of using a system(technique to understand and

describe requirements.)

 We will discuss
 how to write use cases and draw a UML use case diagram.

 knowing UML notation.

 to identify and write good use cases.

Goals and Stories
Customers and end users have goals – want computer systems to help meet
them.

 To capture these goals and system requirements - customers and end users—
to contribute to their definition or evaluation.
Example

Process Sale:
A customer arrives at a checkout with items to purchase. The
cashier uses the POS system to record each purchased item. The
system presents a running total and line-item details. The
customer enters payment information, which the system
validates and records. The system updates inventory. The
customer receives a receipt from the system and then leaves with
the items.
Definitions : What are Actors, Scenarios, and Usecases?

 Actor :

 An actor is something with behaviour, such as a person (identified by role),

computer system, or organization;

 For example, a cashier.

 Scenario :

 A scenario is a specific sequence of actions and interactions between actors

and the system under discussion; it is also called a use case instance.
Definitions : What are Actors, Scenarios, and Use cases?

 For example, the scenario of successfully purchasing items with cash, or the
scenario of failing to purchase items because of a credit card transaction
denial.

 use case

 A use case is a collection of related success and failure scenarios that

describe actors using a system to support a goal.
Example
For example, here is a casual format use case that includes some alternate scenarios:
Handle Returns
Main Success Scenario:
A customer arrives at a checkout with items to return. The cashier uses the
POS system to record each returned item ...
Alternate Scenarios:
If the credit authorization is reject, inform the customer and ask for an
alternate payment method.
If the item identifier is not found in the system, notify the Cashier and
suggest manual entry of the identifier code (perhaps it is corrupted).
If the system detects failure to communicate with the external tax
calculator system,…..
USECASES AND THE USE CASE MODEL

Use cases are text documents, not diagrams,

Use-case modelling is primarily an act of writing text, not drawing.

 UML defines a use case diagram to illustrate the names of use cases and
actors, and their relationships.
WHY USE CASES

 Simple

 Familiar

 Emphasize the user goals and perspectives.

 Sophistication and Formality

USE CASES AND FUNCTIONAL REQUIREMENTS

 Use cases are requirements; primarily they are functional or behavioural

requirements.

 The FURPS+ requirements types, they emphasize the "F" (functional or

behavioural), but can also be used for other types.

 Use cases are requirements (although not all requirements). Some think of
requirements only as "the system shall do..."
Actors
 An actor is anything with behavior, including the system under discussion
(SuD) itself when it calls upon the services of other systems.

 Actors are not only roles played by people, but organizations, software, and
machines.

 Three Kinds of Actors

 Primary actor

 Supporting actor

 Offstage actor
Actors
Primary actor

- has user goals fulfilled through using services of the SuD.

- For example, the cashier.

 Supporting actor

- provides a service (for example, information) to the SuD.

- For Example payment authorization service.

 Offstage actor

- has an interest in the behavior of the use case, but is not primary or supporting

- For example – Government Tax agency.

Use Case Types and Formats
Black-Box Use Cases

 - they do not describe the internal workings of the system, its components, or
design.

- it is possible to specify what the system must do without deciding

how it will do it
Black-box style Not
Example
The system writes the sale to a
The system records the database. ...or (even worse):
sale. The system generates a SQL INSERT
statement for the sale...
Use Case Types and Formats
 Use cases are written in different formats, depending on need.

 Brief

- one-paragraph summary, usually of the main success scenario.

- Example - Process Sale example was brief.

 casual

- Informal paragraph format. Multiple paragraphs that cover various scenarios.

- The prior Handle Returns example was casual.

 fully dressed

- the most elaborate. All steps and variations are written in detail, and there are supporting
sections, such as preconditions and success guarantees.
Fully Dressed Example
The Two-Column Variation
 Some prefer the two-column or conversational format, which emphasizes the
fact that there is an interaction going on between the actors and the system.
Finding Primary Actors,
Goals, and Use Cases
Finding Primary Actors, Goals, and Use Cases
 Use cases are defined to satisfy the user goals of the primary actors.

 Four Steps to find

1) Choose the system boundary

2) Identify the primary actors.

3) Identify their user goals

4) Define use cases

Finding Primary Actors, Goals, and Use Cases
 Step 1 : Choose the system boundary

- Is it just a software application, the hardware and application as a unit, that

plus a person using it, or an entire organization?

- Example - For this case study, the POS system itself is the system under
design.

- defining what is outside—the external primary and supporting actors.

- Once the external actors are identified, the boundary becomes clearer.
Finding Primary Actors, Goals, and Use Cases
Steps 2 and 3: Finding Primary Actors and Goals

- To find primary actors and goals then set up the framework for further investigation

- (1). Reminder Questions to Find Actors and Goals

- primary actors and user goals, the following questions help identify others.

Who starts and stops the system? Who does user and security
management?

Is there a monitoring process that restarts the system if it fails? How are software updates
handled?

Push or pull update? Who does system administration?

Is "time" an actor because the system does something in response to a time event?

Who evaluates system activity or performance? Who evaluates logs? Are they remotely
retrieved?
Finding Primary Actors, Goals, and Use Cases
- (2) Primary and Supporting Actors

- primary actors have user goals fulfilled through using services of the
system.

- supporting actors, which provide services to the system under design.

- (3) Primary Actor and User Goals Depend on System Boundary

- Why is the cashier, and not the customer, the primary actor in the use case
Process Sale?
Finding Primary Actors, Goals, and Use Cases
Step 4: Define Use Cases

 Name the use case similar to the user goal and Also, name use cases starting
with a verb.

 for example, Goal: process a sale; Use Case: Process Sale

What tests can helpful to find Usecases
 Three Tests useful to test the usecase

1. The Boss Test

2. The EBP Test

3. The Size Test

What tests can helpful to find Use cases
 The Boss Test

 Your boss asks, "What have you been doing all day?"

 You reply: "Logging in!"

 Is your boss happy?

 If not, the use case fails the Boss Test.

 If yes, the use case Pass the Boss Test.

What tests can helpful to find Use cases
 The Elementary Business Process (EBP) test

 A task performed by one person in one place at one time, in response to a

business event, which adds measurable business value and leaves data in a
consistent state

 Good Examples: Approve Credit or Price Order

 Bad Examples: delete a line item or print the document

What tests can helpful to find Use cases
 Size Test

 A use case typically contains many steps, and in the fully dressed format will
often require 310 pages of text.

 A common mistake in use case modelling is define in single step within it

has series of steps.
Use case Diagrams
 The UML provides use case diagram notation to illustrate the names of use
cases and actors, and the relationships between them.

 A use case diagram is a dynamic diagram in UML.

 Use case diagrams model the functionality of a system using actors and use
cases.

 A use case diagram is an excellent picture of the system context; it makes a

good context diagram, that is, showing the boundary of a system
Use Case Diagrams
Use case Diagrams Notations
Notation Description Visual Representation
Actor
 Someone interacts with use case (system function).
 Named by noun.
 Actor plays a role in the business
 Similar to the concept of user, but a user can play different roles
 For Example
 Customer
 Cashier
 Payment Authorization Service
Use case Diagrams Notations
Notation Description Visual Representation
Use Case
 System function (process - automated or manual)
 Named by verb
 i.e. Do something
 Each Actor must be linked to a use case, while some use cases
may not be linked to actors.
 Example
 Process sale
 Handle returns
 Login
Use case Diagrams Notations
Notation Description Visual Representation
Communication Link
 The participation of an actor in a use case is shown by
connecting an actor to a use case by a solid link.
Actors may be connected to use cases by associations, indicating
that the actor and the use case communicate with one another using
messages.
Use case Diagrams Notations
Notation Description Visual Representation
Boundary of system
 The system boundary is potentially the entire system as defined
in the requirements document.
 For large and complex systems, each module may be the system System
boundary.
 For example, for an ERP system for an organization, each of the
modules such as personnel, payroll, accounting, etc.
 can form a system boundary for use cases specific to each of
these business functions.
 The entire system can span all of these modules depicting the
overall system boundary
Example ATM Machine
 Develop a use case model for ATM Machine

Problem Statement

An automated teller machine (ATM) or the automatic banking machine

(ABM) is a banking subsystem (subject) that provides bank customers with
access to financial transactions in a public space without the need for a
cashier, clerk, or bank teller.
Example ATM Machine
Identify Actors

- Customer

- Bank

- ATM Technician

- ATM Operator
Example ATM Machine
 Define Use cases

- Check Balances

- Deposit Funds

- Withdraw Cash

- Transfer Funds

- Green Pin Verification

- Maintenance

- Repair

- Refill
Example ATM Machine
 UC1 - Check Balances

Scope – ATM Machine

Level – User goal

Primary Actor – Customer

Stakeholder and Interest –

Customer – Wants Fast, accurate display the bank balance

Bank – Wants accurately display the customer bank balance.

Example ATM Machine
UC1 - Check Balances

Precondition – Customer is identified and authenticated

Success Guarantee – Check balance transaction is display correctly in ATM machine

Main Success Scenario

1. Customer arrives at ATM Machine.

2. Customer insert the ATM card into ATM Machine.

3. Customer enters ATM card PIN No.

4. ATM Machine shows List of Transaction.

5. Customer Choose Check balance Transaction.

6. Customer View Balance amount

Example ATM Machine
 UC1 - Check Balances

Extension

3.a. Customer Enter Wrong Pin

3.b. ATM machine display Incorrect Pin.

3.c. ATM Machine opts to enter pin again

ATM Machine Use case Diagram
Relating Use cases
 Use cases can be related to each other.

 For example, a sub function use case such as Handle Credit Payment may be
part of several regular use cases, such as Process Sale and Process Rental.

 Relate use cases with three ways.

 Include

 Exclude

 Generalization
Relating Use cases – Include Relationship
 This is the most common and important relationship.

 It is common to have some partial behavior that is common across several

use cases.

 When ever the base use case happen then sub use case is also must happen.

<<include>>
Base Use case Sub Use case
Relating Use cases – Include Relationship
For example: UC1:
Process Sale
Main Success Scenario:
1 . Customer arrives at a POS checkout with goods and/or services to purchase.
7. Customer pays and System handles payment.
Extensions:
7b. Paying by credit: Include Handle Credit Payment. 7c. Paying by check:
Include Handle Check Pavment.
Relating Use cases – Include Relationship
For example: UC7: Process Rental
Extensions:
6b. Paying by credit: Include Handle Credit Payment

<<include>> Handle credit

Process sale
<<include>> payment
<<include>> <<include>>
Handle Check
<<include>> payment
Process Rental
<<include>>

Handle cash
payment
Relating Use cases – Include Relationship
 Summary

Use the Include relationship when:

• They are duplicated in other use cases.
• A use case is very complex and long, and separating it into subunits aids
comprehension.
Relating Use cases – Include Relationship
 Terminology:

 Concrete use case

 A concrete use case is initiated by an actor and performs the entire behavior
desired by the actor.

 Example : Process Sale is a concrete use case.

 Abstract use case

An abstract use case is never instantiated by itself; it is a sub function use case that is part
of another use case.

 Example : Handle Credit Payment is abstract.

Relating Use cases – Include Relationship
Relating Use cases – Extend Relationship
 The idea is to create an extending or addition use case, and within it, describe
where and under what condition it extends the behavior of some base use case.

 Example : UC1: Process Sale (the base use case)

Main Success Scenario:
 1 . Customer arrives at a POS checkout with goods and/or services to purchase.
7. Customer pays and System handles payment.

UC15: Handle Gift Certificate Payment (the extending use case)

Relating Use cases – Extend Relationship
 Example : UC15: Handle Gift Certificate Payment (the extending use
case)
Trigger: Customer wants to pay with gift certificate.
Extension Points: Payment in Process Sale. Level:
Subfunction Main Success Scenario:
1 . Customer gives gift certificate to Cashier.
2. Cashier enters gift certificate ID.
…
 The use of an extension point, and that the extending use case is triggered by
some condition.

 Extension points are labels in the base use case which the extending use case
references as the point of extension
Relating Use cases – Extend Relationship

<<extend>>
Base Use case Sub Use case
Relating Use cases – Extend Relationship
Relating Use cases

<<include>> Close Eyes

Sneeze

<<extend>>

Say Excuse me
Relating Use cases – Generalization
 Generalization is the activity of identifying commonality among concepts
and defining super class (general concept) and subclass (specialized concept)
relationships.

 Identifying a superclass and subclasses is of value in a domain model.

 A generalization relationship is a parent-child relationship between use cases.

 Generalization is shown as a directed arrow with a triangle arrowhead.

Relating Use cases – Generalization
UC Handle Returns

Main success Scenario:

• A customer arrives at a checkout with items to return. The cashier
uses the POS system to record each returned item …
• Alternate Scenarios:
• if the customer paid by credit ...
• If the item identifier is not found in the system …
• If the system detects failure to communicate with the external
accounting system …
When to Use use cases
 Use case diagrams are typically developed in the early stage of development
and people often apply use case modeling for the following purposes:

Specify the context of a system

Capture the requirements of a system

Validate a systems architecture

Drive implementation and generate test cases

Developed by analysts together with domain experts

Previous Year University Questions
1. Lets you own a small Baking company where you make and design custom
cakes for different occasions. You now wish to take your business online, so
that you could cater to a large customer base. You hire a web development
company to build an online cake store for you. This software product is
build on the basis of Unified Process Model(UPM).

Define and Explain UPM with its phase for developing the above online
baking company.
Ordering food in a restaurant
Identify Actors.
Ordering food in a restaurant
Identify Use case.
Ordering food in a restaurant
Write use case modelling choose any use case write fully dressed format

UC1 -

Scope –

Level –

Primary Actor –

Stakeholder and Interest –

Precondition

Success Guarantee –

Main Success Scenario

Extension
Ordering food in a restaurant
Draw Use case Diagram
 Monopoly Game
• Text for this use case is very different than the NextGen POS problem, as it is a simple simulation.
– Game rules are captured in another document, rather than in the use case.
• Use Case UC1: Play Monopoly Game
• Scope: Monopoly application
• Level: user goal Primary
• Actor: Observer
• Stakeholders and Interests: - Observer: Wants to easily observe the output of the game
simulation.
• Main Success Scenario:
• 1. Observer requests new game initialization, enters number of players.
• 2. Observer starts play.
• 3. System displays game trace for next player move
Repeat step 3 until a winner or Observer cancels.
Extensions
At any time , system fails
(to support recovery, system logs after each completed move)
1. observer restarts system
2. system detects prior failure, reconstructs state and promotes to
continue
3. observer chooses to continue
Special Requirements
provide both graphical and text trace modes