BTCS602N Object Oriented Analysis and Design

SHRI VAISHNAV VIDHYAPEETH

VISHWAVIDYALAYA

Session : Jan-2024 to June-2024

Object Oriented Analysis and

Design BTCS602N
Class and Section:

Submitted To:
Prof. Nikhil Chaturvedi
SubmittedBy:
Jaya Singh
BTCS602N Object Oriented Analysis and Design

Index
S.No. Practical

1. To study the concepts of Object-Oriented Technology.

2. Write a problem statement of your application domain.

3. To perform the system analysis: Requirement Analysis

and SRS.

4. To study about the Use Case Model and draw it.

5. Draw State Diagram for your Project Domain.

6. Draw Activity Diagram for your Project Domain.

7. Draw Sequence Diagram for your Project Domain.

8. Perform the function-oriented diagram: Data Flow

Diagram.

9. To perform structural view analysis of class and object

diagram.
BTCS602N Object Oriented Analysis and Design

Experiment 1:
Aim: To study the concepts of Object-Oriented Technology.
Introduction

OOP stands for Object-Oriented Programming. Procedural programming is about

writing procedures or functions that perform operations on the data, while object-
oriented programming is about creating objects that contain both data and functions.

Object-oriented programming has several advantages over procedural programming:

● OOP is faster and easier to execute.

● OOP provides a clear structure for the programs.
● OOP helps to keep the C++ code DRY "Don't Repeat Yourself", and makes the
code easier to maintain, modify and debug.
● OOP makes it possible to create full reusable applications with less code and
shorter development time.

Object-Oriented Programming (OOP) is the term used to describe a programming

approach based on objects and classes. The object-oriented paradigm allows us to organise
software as a collection of objects that consist of both data and behaviour. Since the 1980s
the word 'object' has appeared in relation to programming languages, with almost all
languages developed since 1990 having object-oriented features. Some languages have even
had
object-oriented features retro-fitted. It is widely accepted that object-oriented programming
is the most important and powerful way of creating software. The object-oriented
programming approach encourages:

● Modularisation: where the application can be decomposed into modules.

● Software re-use: where an application can be composed from existing and
new modules.

Object-oriented programming aims to implement real-world entities like inheritance, hiding,

polymorphism, etc in programming. The main aim of OOP is to bind together the data and
the functions that operate on them so that no other part of the code can access this data
except that function.

The major motivating factor in the invention of object-oriented approach is to remove some
of the flaws encountered in the procedural approach. OOP treats data as a critical element
in the program development and does not allow it to flow freely around the system. It ties
data more closely to the function that operate on it, and protects it from accidental
modification from outside function. OOP allows decomposition of a problem into a number
of entities called objects and then builds data and function around these objects.
BTCS602N Object Oriented Analysis and Design

History

The basis for OOP started in the early 1960s. A breakthrough involving instances and
objects was achieved at MIT with the PDP-1, and the first programming language to use
objects was Simula 67. It was designed for the purpose of creating simulations, and was
developed by Kristen Nygaard and Ole-Johan Dahl in Norway.

They were working on simulations that deal with exploding ships, and realized they
could group the ships into different categories. Each ship type would have its own class,
and the class would generate its unique behavior and data. Simula was not only
responsible for introducing the concept of a class, but it also introduced the instance of a
class.

The term "object-oriented programming " was first used by Xerox PARC in their Smalltalk
programming language. The term was used to refer to the process of using objects as the
foundation for computation. The Smalltalk team was inspired by the Simula 67 project, but
they designed Smalltalk so that it would be dynamic. The objects could be changed, created,
or deleted, and this was different from the static systems that were commonly used.
Smalltalk was also the first programming language to introduce the inheritance concept. It is
this feature that allowed Smalltalk to surpass both Simula 67 and the analog programming
systems. While these systems were advanced for their time, they did not use the inheritance
concept.

Simula 67 was a ground-breaking system that has inspired a large number of other
programming languages, and some of these include Pascal and Lisp. By the 1980s,
object-oriented programming had become prominent, and the primary factor in this is C++.
Object oriented programming was also important for the development of Graphical user
interfaces. The Cocoa structure that exists within Mac OS X is a good example of a
dynamic GUI that works with an object-oriented programming language. This paradigm of
programming has also played an important role in the development of event-driven
programming.

Niklaus Wirth and his associates were looking at areas such as modular programming and
data abstraction, and they developed two systems which incorporated these elements. These
two systems are Oberon and Modula-2. Oberon used a unique approach to classes and
object orientation that is much different than C++ or Smalltalk. Since the introduction of
OOP, a large number of modern programming languages are now using the concept. Some
of these are Fortran, BASIC, and Pascal. There have been some compatibility issues,
because many programs were not designed with a OOPs approach in mind. Object oriented
programming languages that were "pure" did not have many of the functions that
programmers needed.

To solve these problems, a number of researchers have been attempting to design new
programming languages that used object-oriented concepts but still retained many of the
functions that programmers needed. One example of a programming language that has
achieved this to some degree is Eiffel. Another programming language that has attempted to
solve this problem is Java. Java has become popular because it uses a virtual machine, and it
is very similar to C++ and C. The virtual machine is important because it allows code to be
run on multiple platforms without having to be changed. Another system that is similar is
Microsoft’s .NET. Many developers now understand the importance of OOP, and are
actively using it within their own programs. Many researchers have continued to make
advancements by using the object-oriented approach.
BTCS602N Object Oriented Analysis and Design

Difference between OOP and POP

BASIS FOR
POP OOP
COMPARISON

Basic Procedure/Structure oriented. Object oriented.

Approach Top-down. Bottom-up.

Basis Main focus is on "how to get the Main focus is on 'data

task done" i.e., on the procedure or security'. Hence, only objects

structure of a program. are permitted to access the

entities of a class.

Division Large program is divided into units Entire program is divided into

called functions. objects.

Entity accessing No access specifier observed. Access specifier are "public",

mode "private", "protected".

Overloading or Neither it overloads functions nor It overloads functions,

Polymorphism operators. constructors, and operators.

BTCS602N Object Oriented Analysis and Design

Inheritance There is no provision of Inheritance achieved in three

inheritance. modes public private and

protected.

Data hiding & There is no proper way of hiding Data is hidden in three modes

security the data, so data is insecure public, private, and protected.

hence data security increases.

Data sharing Global data is shared among the Data is shared among the

functions in the program. objects through the member

functions.

Friend functions or No concept of friend function. Classes or function can

friend classes become a friend of another

class with the keyword

"friend".

Note: "friend" keyword is

used only in c++

Virtual classes or No concept of virtual classes. Concept of virtual function

virtual function appear during inheritance.

BTCS602N Object Oriented Analysis and Design

Example C, VB, FORTRAN, Pascal C++, JAVA,

VB.NET, C#.NET.

Object Oriented Approach

In the object-oriented approach, the focus is on capturing the structure and behaviour of
information systems into small modules that combines both data and process. The main
aim of Object-Oriented Design (OOD) is to improve the quality and productivity of system
analysis and design by making it more usable.

In analysis phase, OO models are used to fill the gap between problem and solution. It
performs well in situation where systems are undergoing continuous design, adaption, and
maintenance. It identifies the objects in problem domain, classifying them in terms of
data and behavior.

The OO model is beneficial in the following ways −

● It facilitates changes in the system at low cost.

● It promotes the reuse of components.

● It simplifies the problem of integrating components to configure large system.

● It simplifies the design of distributed systems.

BTCS602N Object Oriented Analysis and Design

Features of Object-Oriented Programming

Object-Oriented Programming is a methodology or paradigm to design a program

using classes and objects. The key features of object-oriented programming are as
follows:

● Object
● Class
● Inheritance
● Polymorphism
● Abstraction
● Encapsulation

1. Object

Any entity that has state and behaviour is known as an object. For example, a chair, pen,
table, keyboard, bike, etc. It can be physical or logical. An Object can be defined as an
instance of a class. An object contains an address and takes up some space in memory.
Objects can communicate without knowing the details of each other's data or code. The
only necessary thing is the type of message accepted and the type of response returned by
the objects.

Example: A dog is an object because it has states like colour, name, breed, etc. as well
as behaviours like wagging the tail, barking, eating, etc.
BTCS602N Object Oriented Analysis and Design

2. Class

Collection of objects is called class. It is a logical entity. A class can also be defined as a
blueprint from which you can create an individual object. Class doesn't consume any space.

3. Inheritance

When one object acquires all the properties and behaviours of a parent object, it is known
as inheritance. It provides code reusability. It is used to achieve runtime polymorphism.

4. Polymorphism
BTCS602N Object Oriented Analysis and Design

If one task is performed in different ways, it is known as polymorphism. For example: to

convince the customer differently, to draw something, for example, shape, triangle,
rectangle, etc.
In Java, we use method overloading and method overriding to achieve polymorphism.
Another example can be to speak something; for example, a cat speaks meow, dog
barks woof, etc.

5. Abstraction

Hiding internal details and showing functionality is known as abstraction.

For example, phone call, we don't know the internal processing.

In Java, we use abstract class and interface to achieve abstraction.

6. Encapsulation

Binding (or wrapping) code and data together into a single unit are known as encapsulation.
For example, a capsule, it is wrapped with different medicines. A java class is the example
of encapsulation. Java bean is the fully encapsulated class because all the data members are
private here.
Advantages of OOP
1. Re-usability
It means reusing some facilities rather than building it again and again. This is

done with the use of a class. We can use it ‘n’ number of times as per our need.

2. Data Redundancy
This is a condition created at the place of data storage (you can say Databases)

where the same piece of data is held in two separate places. So, the data

redundancy is one of the greatest advantages of OOP. If a user wants a similar

functionality in multiple classes, he/she can go ahead by writing common

class definitions for the similar functionalities and inherit them.

3. Code Maintenance
This feature is more of a necessity for any programming languages, it helps
BTCS602N Object Oriented Analysis and Design

users from doing re-work in many ways. It is always easy and time-saving to

maintain and modify the existing codes with incorporating new changes into it.

4. Security
With the use of data hiding and abstraction mechanism, we are filtering out limited

data to exposure which means we are maintaining security and providing

necessary data to view.

5. Design Benefits
If you are practicing on OOPs the design benefits a user will get is in terms of

designing and fixing things easily and eliminating the risks (if any). Here the

Object-Oriented Programs forces the designers to have a longer and extensive

design phase, which results in better designs and fewer flaws. After a time

when the program has reached some critical limits, it is easier to program all

the

non-OOP’s one separately.

6. Better productivity
With the above-mentioned facts of using the application definitely enhances its

user’s overall productivity. This leads to more work done, finish a better program,

having more inbuilt features and easier to read, write and maintain. An OOP

programmer cans stitch new software objects to make completely new programs.

A good number of libraries with useful functions in abundance make it possible.

7. Easy troubleshooting
This is the advantage of using encapsulation in OOP; all the objects are

self-constrained. With this modality behavior, the IT teams get a lot of work

benefits as they are now capable to work on multiple projects simultaneously

with an advantage that there is no possibility of code duplicity.

8. Polymorphism Flexibility
BTCS602N Object Oriented Analysis and Design

Let’s see a scenario to better explain this behavior. You behave in a different way

if the place or surrounding gets change. A person will behave like a customer if he

is in a market, the same person will behave like a student if he is in a school and as

a son/daughter if put in a house. Here we can see that the same person showing

different behavior every time the surroundings are changed. This means

polymorphism is flexibility and helps developers in a number of ways.

● It’s simplicity

● Extensibility

9. Problems solving
Decomposing a complex problem into smaller chunks or discrete components is a

good practice. OOP is specialized in this behavior, as it breaks down your software

code into bite-sized – one object at a time. In doing this the broken components can

be reused in solutions to different other problems (both less and more complex) or

either they can be replaced by the future modules which relate to the same

interface with implementations details. A general relatable real-time scenario – at a

high level a car can be decomposed into wheels, engine, a chassis soon and each

of those components can be further broken down into even smaller atomic

components like screws and bolts. The engine’s design doesn’t need to know

anything about the size of the tires in order to deliver a certain amount of power (as

output) has little to do with each other.

BTCS602N Object Oriented Analysis and Design

Experiment 2:
Aim: Write a problem statement of your application domain.
What is a Problem Statement?
A problem statement is usually one or two sentences to explain the problem your process
improvement project will address. In general, a problem statement will outline the
negative points of the current situation and explain why these matters. It also serves as a
great communication tool, helping to get buy-in and support from others.

A problem statement is a concise description of an issue to be addressed or a condition to be

improved upon. It identifies the gap between the current (problem) state and desired (goal)
state of a process or product. Focusing on the facts, the problem statement should be
designed to address the Five Ws. The first condition of solving a problem is understanding
the problem, which can be done by way of a problem statement.

Problem statements are widely used by most businesses and organizations to execute
process improvement projects. A simple and well-defined problem statement will be used
by the project team to understand the problem and work toward developing a solution. It
will also provide management with specific insights into the problem so that they can make
appropriate project-approving decisions. As such, it is crucial for the problem statement to
be clear and unambiguous.

Why is a Problem Statement important?

The main purpose of the problem statement is to identify and explain the problem. This
includes describing the existing environment, where the problem occurs, and what impacts it
has on users, finances, and ancillary activities. Additionally, the problem statement is used to
explain what the expected environment looks like. Defining the desired condition provides
an overall vision for the process or product. It makes clear the purpose for initiating the
improvement project and the goals that it is meant to accomplish.

Another important function of the problem statement is to be used as a communication

device. A problem statement helps with obtaining buy-in from those involved in the project.
Before the project begins, the stakeholders verify the problem and goals are accurately
described in the problem statement. Once this approval is received, the project team
reviews it to ensure everyone understands the issue at hand and what they are trying to
accomplish. This also helps define the project scope, which keeps the project concentrated
on the overall goal.

The problem statement is referenced throughout the project to establish focus within the
project team and verify they stay on track. At the end of the project, it is revisited to
confirm the implemented solution indeed solves the problem. A well-defined problem
statement can also aid in performing root-cause analysis to understand why the problem
occurred and ensure measures can be taken to prevent it from happening in the future.

It is important to note that the problem statement does not define the solution or methods of
reaching the solution. The problem statement simply recognizes the gap between the
problem and goal states. It can be said that “a problem well stated is half solved”. However,
there are
BTCS602N Object Oriented Analysis and Design

often multiple, viable solutions to a problem. Only after the problem statement is written
and agreed upon should the solution(s) be discussed and the resulting course of action
determined.

One of the most important goals of any problem statement is to define the problem
being addressed in a way that's clear and precise. Its aim is focusing the process
improvement
team’s activities and steer the scope of the project.

How to write a Problem Statement?

The problem statement will be used to gain project support and approval from stakeholders.
As such, it must be action-oriented. More importantly, the problem statement must be
written clearly and accurately in order to deliver successful results. A poorly crafted or
incorrect problem statement will lead to a faulty solution, as well as wasted time, money, and
resources.
There are several basic elements that can be built into every problem statement to decrease
the risk of project failure. First, the problem statement must focus on the end user. A
common mistake is focusing on “how” a problem will be solved rather than the current gap.
Second,
the problem statement shouldn’t be too broad. A benefit of using the “5 Why’s” approach
is that it avoids over-simplicity by providing the details needed for understanding the
problem and developing an appropriate solution. Finally, the problem statement shouldn’t
be too narrow. Solution-bias stifles the creativity that arises while brainstorming a solution,
which may result in a less-than-optimal experience for the user.
It is useful to design and follow a specific format when writing a problem statement. While
there are several options for doing this, the following is a simple and straightforward
template often used in Business Analysis to maintain focus on defining the problem.

1. IDEAL: This section is used to describe the desired or “to be” state of the
process or product. It identifies the goals of the stakeholders and customers
as well as assists in defining scope. At large, this section should illustrate
what the expected environment would look like once the solution is
implemented.
2. REALITY: This section is used to describe the current or “as is” state of the
process or product. It explains the pain points expressed by the stakeholders
and customers. It should also include the insights and expertise of the
project team and subject matter experts provided during problem analysis.
3. CONSEQUENCES: This section is used to describe the impacts on the
business if the problem is not fixed or improved upon. This includes costs
associated with loss of money, time, productivity, competitive advantage,
and so forth. The magnitude of these effects will also help determine the
priority of the project.
4. PROPOSAL: This section is used to describe potential solutions. Once the
ideal, reality, and consequences sections have been completed, understood,
and approved, the project team can start offering options for solving the
problem. It can also include suggestions by the stakeholders and
customers, although further discussions and research will be needed before
a specific course of action can be determined.
One should be able to apply the 5 'W's (Who, What, Where, When and Why) to the
problem statement. A problem statement can be refined as we start to further investigate
root cause. Finally, review your new problem statement against the following criteria:
BTCS602N Object Oriented Analysis and Design

● It should focus on only one problem.

● It should be one or two sentences long.
● It should not suggest a solution.

Problem Statement of Application Domain

The problem statement of OCBS project is to develop an online process of Cab Booking
Service. Present system is manual and it is time consuming as well as non-standardized in
terms of returns. Currently, customers need to make a manual call-in order to rent / reserve
preferred vehicle. The software of Online Cab Booking System will check their file to see
which vehicle is available for rental. The objective of OCBS project is to automate vehicle
rental and reservation. So, customers do not need to call & spend unnecessary time in order
to reserve preferred vehicle.
BTCS602N Object Oriented Analysis and Design

Experiment 3:
Aim: To perform the system analysis: Requirement Analysis
and SRS.
Introduction
Cab booking service is a major transport service provided by the various transport
operators in a particular city. Mostly peoples use cab service for their daily transportation's
need. The company must be a registered and fulfills all the requirements and security
standards set by the transport department.
In a nutshell your Taxi Booking Software should be able to:
o Provide the functionality to make your own bookings
o Give your customers the facility to make payments and deposits online with their
credit / debit card.
o Generate Invoice so Update your web site without the need to get a web designer involved.
o Provide the customer with taxi availability
o Track your customers.
o Engage your customers through interaction such as feedback forms
Purpose
The purpose of this case study is to describe the cab booking system which provides the
cab booking details, billing, and cancellation on various types of booking namely.
▪ Confirm booking.
▪ Online booking.
▪ Phone booking.

Intended Audience and reading suggestions:

The different types of readers are:

(a). Customers
(b). Developers
(c). Management people Specifically, Passengers
Definitions, Acronyms, and Abbreviation:
Following abbreviation has been used throughout this document:
CBS: Cab booking system.
PDA: Personal Digital
Assistant IVRS: Voice
Response System
BTCS602N Object Oriented Analysis and Design

1. Cab Details
2. Booking Form
3. Billing
4. Cancellation
Scop
e
▪ Passenger Revenue Enhancement.
▪ Improved and Optimized service
System Development Life Cycle
The systems development life cycle is a project management technique that divides complex
projects into smaller, more easily managed segments or phases. Segmenting projects allows
managers to verify the successful completion of project phases before allocating resources to
subsequent phases. Software development projects typically include initiation, planning,
design, development, testing, implementation, and maintenance phases. However, the
phases may be divided differently depending on the organization involved. For example,
initial project activities might be designated as request, requirements-definition, and
planning phases, or initiation, concept-development, and planning phases. End users of the
system under development should be involved in reviewing the output of each phase to
ensure the system is being built to deliver the needed functionality.
Overall description
It enables us to maintain the cab details like this
Product Perspective
Their timing number of seat available, and booking billing and cancelling the cab.
User Interface
Mobile Application, tablets
Development Hardware Interface
Minimum system requirements for Cab Management:
Processor
Intel Core 2Duo or AMD equivalent, 2Gz or better

RA
M
2GB
HDD
160 GB, 7200k spin
Operating systems used in development
Windows XP sp3 / Windows 7
BTCS602N Object Oriented Analysis and Design

Business broadband connection with static IP (8mb

download) Online backup
Logmein, or Windows Remote Desktop Connectivity. Other suggested
components 17 inch or larger display
Secondary hard drive–for additional local backups
Minimum system requirements for Mobile
Operating system:
Android Smartphone
GPS Enabled
Internet Active

SOFTWARE INTERFACE
Front end -> C#, WCF,
MapsAPi Back end -> MSSql
UserApp -> Mobile Interface

Communication Interfaces
The website www.uber.com offers CBS enquiries on the internet availability,
status , fare,service area etc.
Mobile based inquiry service.
Setting up of voice response
system.

Operating Environment
The OS types are:
Windows Phone, iPhone, blackberry,Android
BTCS602N Object Oriented Analysis and Design

Operations
Any booking can be done 24
hours. One form for single
booking.
Booking is done through pre-defined logic.

Product Functions
It tells the short note about the product.

Cab Details
Customers may view the cab timing at a date their name and their type of booking.

Booking
After checking the number of cab available the customers book a cab or number of
cabs according to their requirements.

Billing
After reserving the required cab, the customer pays the amount in advance(optional).

Cancelation
If the customer wants to cancel the cab then 10% of the amount per person is deducted if
the booking is cancelled before 30 mins of the service time.

User characteristics
Knowledge userNo voice userExpert user

Conscabts
Less than 1 sec for local
transactions. 3 sec for network
transaction.
Uptime of CBS is 99.5+%. SOFTWARE CONSCABTS:Designing->Rational Rose

❖ SPECIFIC
REQUIREMENTS EXTERNAL
INTERFACES
Cab Delay Alert Service.Booking Terminals Interactive voice Response System.

PERFORMANCE REQUIREMENTS:
BTCS602N Object Oriented Analysis and Design

It is available during all 24 hours.

Application interface of our system was unit tested at all levels of implementation, right
from start of code writing, to integrating the code with other modules. Every module was
tested fully to check its syntax and logical correctness. Error handling was implemented into
relevant modules so that the code doesn’t crash on errors.

Integration Testing
Integration testing is a systematic technique for constructing the program structures, while
conducting test to uncover errors associated with interfacing, the objective is to take unit
tested modules and build a program structure that has been dictated by design. User interface
of i-Admit was developed in modules. All of them were joined together to make the
complete running application. While integrating these modules, integration testing was
performed on them to verify that they meet all interfacing requirements and that they pass
relevant information among themselves. In the end the complete program structure was
tested to ensure interoperability of all the modules.

Validation Testing
At the culmination of integration testing software is completely assembled as a
package: interfacing errors have been uncovered and corrected and a final series of
software tests
–Validation Testing may begin. Validation can be defined in many ways, but a simple
definition is that validation succeeds when software functions in a manner that can be
reasonably expected by the customer. Software validation is achieved through a series of
Black Box tests that demonstrate conformity with requirements.

Alpha Testing
It is virtually impossible for a software developer to foresee how the customer will really use
a program. When custom software is built for one customer a series of acceptance tests are
conducted to enable the customer to validate all requirements. A customer conducts the
alpha test at the developer site. The software is used in a natural setting with the developer
“looking over the shoulder” of the user and recording errors and usage problem. Alpha tests
are conducted in a controlled environment. Alpha tests were performed at our development
site with the help of our friends, who were called and asked to run the program in the manner
they like, without our guidance and errors and usage problems were noted and code was
updated to remove all of them.

Beta Testing
The Beta test is conducted at one or more customer sites by the end user of the software.
Unlike alpha testing the developer is generally not present. Therefore the beta test is a live
application of the software in an environment that cannot be controlled by the developer.
The customer records all problems that are encountered during beta testing and reports these
to the developer at regular intervals. As a result of problems reported during beta test the
software developer makes modification and then prepares for the release of software product
to the entire customer base. Beta testing of our system is not performed as the product is not
yet
BTCS602N Object Oriented Analysis and Design

fully developed and has not been installed at the user site as it still is in the development phase.
Beta testing will be performed when the software
is deployed at the user’s site.

System Testing
Ultimately software is incorporated with other system elements (new hardware,
information) and a series of system, integration and validation tests are conducted. It is
actually a series of different tests whose primary purpose is to fully exercise the computer-
based system.
Although each test has a different purpose all work to verify that all system elements have
been properly integrated and perform allocated functions. System testing of this system
was performed at the development lab of this system by integrating the functional systems
to imitate the actual work environment. Since no special hardware was needed for this
purpose, the testing proceeded and succeeded with no errors.

Recovery Testing
Many computer-based systems must recover from faults and resume processing within a
pre-specified time. In some cases a system must be fault tolerant that is processing faults
must not cause overall system function to cease. Recovery testing is a system test that forces
the software to fail in a variety of ways and verifies that recovery is properly performed. If
recovery is automatic, re-initialization, check pointing mechanism, data recovery, and restart
are each evaluated for correctness. If recovery requires human intervention the meantime to
repair is evaluated to determine whether it is within acceptable limits.

Security Testing
Security Testing attempts to verify protection mechanism built into system will in fact protect
it from improper penetration. Security is provided for each user by giving them their login
name and password. Security testing was done, as any other anonymous user can’t log in
with a user password if the user is already logged in.
Performance Testing
Performance Testing is designed to test run time performance of software within the
context of an integrated system. Performance Testing occurs throughout all steps in the
testing process. Performance tests are often coupled with stress testing and often require
both hardware and software instrumentation. That is it is often necessary to measure
resource utilization in an exacting fashion. External instrumentation can monitor execution
intervals, log events as they occur, and sample machines take on a regular Basis. By
instrumenting a system the tester can uncover situations that lead to degradation and
possible system failure.
BTCS602N Object Oriented Analysis and Design

Experiment 4:
Aim: To study about the Use Case Model and draw it.
Introduction
A use case is a methodology used in system analysis to identify, clarify and organize system
requirements. The use case is made up of a set of possible sequences of interactions
between systems and users in a particular environment and related to a particular goal. The
method creates a document that describes all the steps taken by a user to complete an
activity.

Use cases are typically written by business analysts and can be employed during several
stages of software development, such as planning system requirements, validating design,
testing software and creating an outline for online help and user manuals. A use case
document can help the development team identify and understand where errors may
occur during a transaction so they can resolve them.
Every use case contains three essential elements:

● The actor. The system user -- this can be a single person or a group of
people interacting with the process.
● The goal. The final successful outcome completes the process.
● The system. The process and steps taken to reach the end goal, including
the necessary functional requirements and their anticipated behaviors.
Characteristics of use case
Use cases describe the functional requirements of a system from the end user's perspective,
creating a goal-focused sequence of events that is easy for users and developers to follow.
A complete use case will include one main or basic flow and various alternate flows. The
alternate flow, also known as an extending use case, describes normal variations to the
basic flow as well as unusual situations.

A use case should display the following characteristics:

● Organizes functional requirements.

● Models the goals of system/actor interactions.
● Records paths -- called scenarios -- from trigger events to goals.
● Describes one main flow of events and various alternate flows.
● Multi-level, so that one use case can use the functionality of another one.
How to write a use case
There are two different types of use cases: business use cases and system use cases.

A business use case is a more abstract description that's written in a technology-agnostic

way, referring only to the business process being described and the actors that are involved in
the activity. A business use case identifies the sequence of actions that need to be performed
by the business to provide a meaningful, observable result to the end user.

On the other hand, a system use case is written with more detail than a business use case,
BTCS602N Object Oriented Analysis and Design

referring to the specific processes that must happen in various parts of the system to reach
the final user goal. A system use case diagram will detail functional specifications, including
dependencies, necessary internal supporting features and optional internal features.

When writing a use case, the design scope should be considered to identify all elements that
lie within and outside the boundaries of the processes. Anything essential to the use case that
lies outside its boundaries should be indicated with a supporting actor or by another use
case. The design scope can be a specific system, a subsystem or the entire enterprise. Use
cases that describe business processes are typically of the enterprise scope.

As mentioned, the three basic elements that make up a use case are actors, the system and
the goal. Other additional elements to consider when writing a use case include:
● Stakeholders, or anybody with an interest or investment in how the
system performs.
● Preconditions, or the elements that must be true before a use case can occur.
● Triggers, or the events that cause the use case to begin.
● Post-conditions, or what the system should have completed by the end of
the steps.

The use case is written using narrative language, describing the functional requirements of a
system from the end user's perspective. A use case diagram is created using a unified
modeling language, with each step represented by its name in an oval; each actor
represented by a stick figure with their name written below; each action indicated by a line
between the actor and step; and the system boundaries indicated by a rectangle around the
use case.

The writing process includes:

1. Identifying all system users and creating a profile for each one. This
includes every role played by a user who interacts with the system.
2. Selecting one user and defining their goal -- or what the user hopes to
accomplish by interacting with the system. Each of these goals becomes a use
BTCS602N Object Oriented Analysis and Design

case.
3. Describing the course taken for each use case through the system to reach
that goal.
4. Considering every alternate course of events and extending use cases -- or
the different courses that can be taken to reach the goal.
5. Identifying commonalities in journeys to create common course use cases
and write descriptions of each.
6. Repeating steps two through five for all other system users.

When writing a use case, developers may use a sequence diagram -- which shows how
objects react along a timeline -- to model the interactions between objects in a single use
case. Sequence diagrams allow developers to see how each part of the system interacts with
others to perform a specific function as well as the order in which these interactions occur
to complete a use case.

Benefits of use case

A single use case can benefit developers by revealing how a system should behave while
also helping identify any errors that could arise in the process.

Other benefits of use case development include:

● The list of goals created in the use case writing process can be used to
establish the complexity and cost of the system.
● By focusing both on the user and the system, real system needs can be
identified earlier in the design process.
● Since use cases are written primarily in a narrative language they are easily
understood by stakeholders, including customers, users and executives -- not
just by developers and testers.
● The creation of extending use cases and the identification of exceptions to
successful use case scenarios saves developers time by making it easier to
define subtle system requirements.
● By identifying system boundaries in the design scope of the use case,
developers can avoid scope creep.
● Premature design can be avoided by focusing on what the system should do
rather than how it should do it.

In addition, use cases can be easily transformed into test cases by mapping the common
course and alternate courses and gathering test data for each of the scenarios. These
functional test cases will help the development team ensure all functional requirements of
the system are included in the test plan.

Furthermore, use cases can be used in various other areas of software development,
including project planning, user documentation and test case definitions. Use cases can also
be used as a planning tool for iterative development.
BTCS602N Object Oriented Analysis and Design
BTCS602N Object Oriented Analysis and Design

Experiment 5:
Aim: Draw State Diagram for your Project Domain.
A state diagram is used to represent the condition of the system or part of the system at
finite instances of time. It’s a behavioral diagram and it represents the behavior using finite
state transitions. State diagrams are also referred to as State machines and State-chart
Diagrams. These terms are often used interchangeably. So simply, a state diagram is used to
model the dynamic behavior of a class in response to time and changing external stimuli. We
can say
that each and every class has a state but we don’t model every class using State diagrams.
We prefer to model the states with three or more states.
Uses of state chart diagram –
● We use it to state the events responsible for change in state (we do
not show what processes cause those events).
● We use it to model the dynamic behavior of the system .
● To understand the reaction of objects/classes to internal or
external stimuli.
Basic components of a state chart diagram –
1. Initial state – We use a black filled circle to represent the initial
state of a System or a class.

2. Transition – We use a solid arrow to represent the transition or

change of control from one state to another. The arrow is labelled with the
event which causes the change in state.

3. State – We use a rounded rectangle to represent a state. A state

represents the conditions or circumstances of an object of a class at an
instant of time.

4. Fork – We use a rounded solid rectangular bar to represent a Fork

notation with incoming arrows from the parent state and outgoing arrows
towards the newly created states. We use the fork notation to represent a
state splitting into two or more concurrent states.
BTCS602N Object Oriented Analysis and Design

5. Join – We use a rounded solid rectangular bar to represent a Join

notation with incoming arrows from the joining states and outgoing arrow
towards the common goal state. We use the join notation when two or more
states concurrently converge into one on the occurrence of an event or

events.

6. Self transition – We use a solid arrow pointing back to the state

itself to represent a self transition. There might be scenarios when the state
of the object does not change upon the occurrence of an event. We use self
transitions to represent such cases.
BTCS602N Object Oriented Analysis and Design

7. Composite state – We use a rounded rectangle to represent a

composite state also. We represent a state with internal activities using
a composite state.

8. Final state – We use a filled circle within a circle notation to

represent the final state in a state machine diagram.

Steps to draw a state diagram –

1. Identify the initial state and the final terminating states.
2. Identify the possible states in which the object can exist (boundary
values corresponding to different attributes guide us in identifying
different states).
3. Label the events which trigger these transitions.
BTCS602N Object Oriented Analysis and Design

Experiment 6:
Aim: Draw Activity Diagram for your Project Domain.
An activity diagram portrays the control flow from a start point to a finish point
showing the various decision paths that exist while the activity is being executed. We
can depict both sequential processing and concurrent processing of activities using
an activity diagram. They are used in business and process modelling where their
primary use is to depict the dynamic aspects of a system.

Activity Diagram Notations –

1. Initial State – The starting state before an activity takes place
is depicted using the initial state.

2. Action or Activity State – An activity represents execution of an action

on objects or by objects. We represent an activity using a rectangle with
rounded corners. Basically any action or event that takes place is represented
using an activity.

3. Action Flow or Control flows – Action flows or Control flows are

also referred to as paths and edges. They are used to show the transition from
one activity state to another.

4. Decision node and Branching – When we need to make a decision

before deciding the flow of control, we use the decision node.

5. Guards – A Guard refers to a statement written next to a decision node

on an arrow sometimes within square brackets.
BTCS602N Object Oriented Analysis and Design

6. Fork – Fork nodes are used to support concurrent activities.

7. Join – Join nodes are used to support concurrent activities converging

into one. For join notations we have two or more incoming edges and one
outgoing edge.

8. Final State or End State – The state which the system reaches when a
particular process or activity ends is known as a Final State or End State. We use
a filled circle within a circle notation to represent the final state in a state machine
diagram. A system or a process can have multiple final states.
BTCS602N Object Oriented Analysis and Design
BTCS602N Object Oriented Analysis and Design

Experiment 7:
Aim: Draw Sequence Diagram for your Project Domain.
Unified Modelling Language (UML) is a modeling language in the field of software
engineering which aims to set standard ways to visualize the design of a system. UML
guides the creation of multiple types of diagrams such as interaction , structure and behavior
diagrams.
A sequence diagram is the most used interaction diagram.
Interaction diagram –
An interaction diagram is used to show the interactive behavior of a system. Since
visualizing the interactions in a system can be a cumbersome task, we use different types
of interaction diagrams to capture various features and aspects of interaction in a system.
Sequence Diagrams –
A sequence diagram simply depicts interaction between objects in a sequential order i.e. the
order in which these interactions take place. We can also use the terms event diagrams or
event scenarios to refer to a sequence diagram. Sequence diagrams describe how and in
what order the objects in a system function. These diagrams are widely used by businessmen
and software developers to document and understand requirements for new and existing
systems.

Sequence Diagram Notations –

1. Actors – An actor in a UML diagram represents a type of role where it interacts

with the system and its objects. It is important to note here that an actor is
always outside the scope of the system we aim to model using the UML
diagram.

Figure – notation symbol for actor

We use actors to depict various roles including human users and other external
subjects. We represent an actor in a UML diagram using a stick person
notation. We can have multiple actors in a sequence diagram.
For example – Here the user in seat reservation system is shown as an actor
where it exists outside the system and is not a part of the system.
BTCS602N Object Oriented Analysis and Design

Figure – an actor interacting with a seat reservation system

2. Lifelines – A lifeline is a named element which depicts an individual participant
in a sequence diagram. So basically each instance in a sequence diagram is
represented by a lifeline. Lifeline elements are located at the top in a sequence
diagram. The standard in UML for naming a lifeline follows the following
format
– Instance Name : Class Name
BTCS602N Object Oriented Analysis and Design

Figure – lifeline
We display a lifeline in a rectangle called head with its name and type. The head
is located on top of a vertical dashed line (referred to as the stem) as shown above.
If we want to model an unnamed instance, we follow the same pattern except now
the portion of lifeline’s name is left blank.
Difference between a lifeline and an actor – A lifeline always portrays an
object internal to the system whereas actors are used to depict objects external to
the system. The following is an example of a sequence diagram:
BTCS602N Object Oriented Analysis and Design

Figure – a sequence diagram

3. Messages – Communication between objects is depicted using messages. The
messages appear in a sequential order on the lifeline. We represent messages
using arrows. Lifelines and messages form the core of a sequence diagram.
Messages can be broadly classified into the following categories :

Figure – a sequence diagram with different types of messages

● Synchronous messages – A synchronous message waits for a reply
before the interaction can move forward. The sender waits until the
receiver has completed the processing of the message. The caller
continues only when it knows that the receiver has processed the
previous message i.e. it receives a reply message. A large number of
calls in object oriented programming are synchronous. We use a
solid arrow head to represent a synchronous message.
BTCS602N Object Oriented Analysis and Design

Figure – a sequence diagram using a synchronous message

● Asynchronous Messages – An asynchronous message does not wait
for a reply from the receiver. The interaction moves forward
irrespective of the receiver processing the previous message or not.
We use a lined arrow head to represent an asynchronous message.

● Create message – We use a Create message to instantiate a new

object in the sequence diagram. There are situations when a particular
message call requires the creation of an object. It is represented with a
dotted arrow and create word labelled on it to specify that it is the
create Message symbol.
For example – The creation of a new order on a e-commerce
website would require a new object of Order class to be created.
BTCS602N Object Oriented Analysis and Design

Figure – a situation where create message is used

● Delete Message – We use a Delete Message to delete an object.

When an object is deallocated memory or is destroyed within the
system we use the Delete Message symbol. It destroys the occurrence
of the object in the system. It is represented by an arrow terminating
with a x. For example – In the scenario below when the order is
received by the user, the object of order class can be destroyed.

Figure – a scenario where delete message is used

● Self Message – Certain scenarios might arise where the object needs
to send a message to itself. Such messages are called Self Messages
and are represented with a U shaped arrow.
BTCS602N Object Oriented Analysis and Design

Figure – self message

For example – Consider a scenario where the device wants to access
its webcam. Such a scenario is represented using a self message.

Figure – a scenario where a self message is used

● Reply Message – Reply messages are used to show the message
being sent from the receiver to the sender. We represent a return/reply
message using an open arrowhead with a dotted line. The interaction
moves forward only when a reply message is sent by the receiver.
BTCS602N Object Oriented Analysis and Design

Figure – reply message

For example – Consider the scenario where the device requests a
photo from the user. Here the message which shows the photo being
sent is a reply message.

Figure – a scenario where a reply message is used

● Found Message – A Found message is used to represent a scenario
where an unknown source sends the message. It is represented using
an arrow directed towards a lifeline from an end point. For example:
Consider the scenario of a hardware failure.
BTCS602N Object Oriented Analysis and Design

Figure – found message

It can be due to multiple reasons and we are not certain as to
what caused the hardware failure.

Figure – a scenario where found message is used

● Lost Message – A Lost message is used to represent a scenario
where the recipient is not known to the system. It is represented using
an
BTCS602N Object Oriented Analysis and Design

arrow directed towards an end point from a lifeline. For

example: Consider a scenario where a warning is generated.

Figure – lost message

The warning might be generated for the user or other software/object
that the lifeline is interacting with. Since the destination is not known
before hand, we use the Lost Message symbol.

Figure – a scenario where lost message is used

4. Guards – To model conditions we use guards in UML. They are used when we
need to restrict the flow of messages on the pretext of a condition being met.
Guards play an important role in letting software developers know the
constraints attached to a system or a particular process.
BTCS602N Object Oriented Analysis and Design

For example: In order to be able to withdraw cash, having a balance greater

than zero is a condition that must be met as shown below.

Figure – sequence diagram using a guard

A sequence diagram for an emotion based music player –

Figure – a sequence diagram for an emotion based music player

The above sequence diagram depicts the sequence diagram for an emotion based
music player:
BTCS602N Object Oriented Analysis and Design

1. Firstly the application is opened by the user.

2. The device then gets access to the web cam.
3. The webcam captures the image of the user.
4. The device uses algorithms to detect the face and predict the mood.
5. It then requests database for dictionary of possible moods.
6. The mood is retrieved from the database.
7. The mood is displayed to the user.
8. The music is requested from the database.
9. The playlist is generated and finally shown to the user.

Uses of sequence diagrams –

● Used to model and visualize the logic behind a sophisticated function, operation
or procedure.
● They are also used to show details of UML use case diagrams.
● Used to understand the detailed functionality of current or future systems.
● Visualize how messages and tasks move between objects or components in
a system.
BTCS602N Object Oriented Analysis and Design

Experiment 8:
Aim: Perform the function-oriented diagram: Data
Flow Diagram.
DFD is the abbreviation for Data Flow Diagram. The flow of data of a system or a process
is represented by DFD. It also gives insight into the inputs and outputs of each entity and
the process itself. DFD does not have control flow and no loops or decision rules are
present.
Specific operations depending on the type of data can be explained by a flowchart. Data
Flow Diagram can be represented in several ways. The DFD belongs to structured-analysis
modeling tools. Data Flow diagrams are very popular because they help us to visualize the
major steps and data involved in software-system processes.

Components of DFD
The Data Flow Diagram has 4 components:
● Process
Input to output transformation in a system takes place because of process
function. The symbols of a process are rectangular with rounded corners, oval,
rectangle or a circle. The process is named a short sentence, in one word or a
phrase to express its essence
● Data Flow
Data flow describes the information transferring between different parts of the
systems. The arrow symbol is the symbol of data flow. A relatable name should
be given to the flow to determine the information which is being moved. Data
flow also represents material along with information that is being moved.
Material shifts are modeled in systems that are not merely informative. A given
flow should only transfer a single type of information. The direction of flow is
represented by the arrow which can also be bi-directional.
● Warehouse
The data is stored in the warehouse for later use. Two horizontal lines represent
the symbol of the store. The warehouse is simply not restricted to being a data
file rather it can be anything like a folder with documents, an optical disc, a filing
cabinet. The data warehouse can be viewed independent of its implementation.
When the data flow from the warehouse it is considered as data reading and
when data flows to the warehouse it is called data entry or data updation.
● Terminator
The Terminator is an external entity that stands outside of the system and
communicates with the system. It can be, for example, organizations like banks,
groups of people like customers or different departments of the same
organization, which is not a part of the model system and is an external entity.
Modeled systems also communicate with terminator.
BTCS602N Object Oriented Analysis and Design

Rules for creating DFD

● The name of the entity should be easy and understandable without any
extra assistance(like comments).
● The processes should be numbered or put in ordered list to be referred easily.
● The DFD should maintain consistency across all the DFD levels.
● A single DFD can have maximum processes upto 9 and minimum 3
processes. Levels of DFD
DFD uses hierarchy to maintain transparency thus multilevel DFD’s can be created. Levels
of DFD are as follows:
● 0-level DFD
● 1-level DFD:
● 2-level
DFD: Advantages of
DFD
● It helps us to understand the functioning and the limits of a system.
● It is a graphical representation which is very easy to understand as it
helps visualize contents.
● Data Flow Diagram represent detailed and well explained diagram of
system components.
● It is used as the part of system documentation file.
● Data Flow Diagrams can be understood by both technical or nontechnical
person because they are very easy to understand.
Disadvantages of DFD
● At times DFD can confuse the programmers regarding the system.
● Data Flow Diagram takes long time to be generated, and many times due to
this reasons analysts are denied permission to work on it.
BTCS602N Object Oriented Analysis and Design
BTCS602N Object Oriented Analysis and Design

Experiment 9:
Aim: To perform structural view analysis of class and
object diagram.
Class diagram is a static diagram. It represents the static view of an application. Class
diagram is not only used for visualizing, describing, and documenting different aspects of a
system but also for constructing executable code of the software application.
Class diagram describes the attributes and operations of a class and also the constraints
imposed on the system. The class diagrams are widely used in the modeling of object-
oriented systems because they are the only UML diagrams, which can be mapped directly
with object-oriented languages.
Class diagram shows a collection of classes, interfaces, associations, collaborations, and
constraints. It is also known as a structural diagram.
Purpose of Class Diagrams
The purpose of class diagram is to model the static view of an application. Class diagrams
are the only diagrams which can be directly mapped with object-oriented languages and thus
widely used at the time of construction.
UML diagrams like activity diagram, sequence diagram can only give the sequence flow of
the application, however class diagram is a bit different. It is the most popular UML diagram
in the coder community.
The purpose of the class diagram can be summarized as −
● Analysis and design of the static view of an application.
● Describe responsibilities of a system.
● Base for component and deployment diagrams.
● Forward and reverse engineering.

Vital components of a Class Diagram

The class diagram is made up of three sections:

o Upper Section: The upper section encompasses the name of the class. A class
isa representation of similar objects that shares the same relationships, attributes,
operations, and semantics. Some of the following rules that should be taken into
account while representing a class are given below:

1. Capitalize the initial letter of the class name.

2. Place the class name in the center of the upper section.
3. A class name must be written in bold format.
4. The name of the abstract class should be written in italics format.
o Middle Section: The middle section constitutes the attributes, which describe
the quality of the class. The attributes have the following characteristics:
BTCS602N Object Oriented Analysis and Design

1. The attributes are written along with its visibility factors, which are public (+),
private (-), protected (#), and package (~).
2. The accessibility of an attribute class is illustrated by the visibility factors.
3. A meaningful name should be assigned to the attribute, which will explain
its usage inside the class.
o Lower Section: The lower section contain methods or operations. The methods
are represented in the form of a list, where each method is written in a single line.
It demonstrates how a class interacts with data.

Relationships

In UML, relationships are of three types:

o Dependency: A dependency is a semantic relationship between two or more

classes where a change in one class cause changes in another class. It forms a
weaker relationship.
In the following example, Student_Name is dependent on the Student_Id.

o Generalization: A generalization is a relationship between a parent class

(superclass) and a child class (subclass). In this, the child class is inherited from the
parent class. For example, The Current Account, Saving Account, and Credit
Account are the generalized form of Bank Account.
BTCS602N Object Oriented Analysis and Design

o Association: It describes a static or physical connection between two or more objects.

It depicts how many objects are there in the relationship.
For example, a department is associated with the college.

Multiplicity: It defines a specific range of allowable instances of attributes. In case if a

range is not specified, one is considered as a default multiplicity.

For example, multiple patients are admitted to one hospital.

Aggregation: An aggregation is a subset of association, which represents has a relationship.

It is more specific then association. It defines a part-whole or part-of relationship. In this
kind of relationship, the child class can exist independently of its parent class.
BTCS602N Object Oriented Analysis and Design

The company encompasses a number of employees, and even if one employee resigns,
the company still exists.

Composition: The composition is a subset of aggregation. It portrays the dependency

between the parent and its child, which means if one part is deleted, then the other part
also gets discarded. It represents a whole-part relationship.

A contact book consists of multiple contacts, and if you delete the contact book, all
the contacts will be lost.

Abstract Classes

In the abstract class, no objects can be a direct entity of the abstract class. The abstract class
can neither be declared nor be instantiated. It is used to find the functionalities across the
classes. The notation of the abstract class is similar to that of class; the only difference is that
the name of the class is written in italics. Since it does not involve any implementation for a
given function, it is best to use the abstract class with multiple objects.

Let us assume that we have an abstract class named displacement with a method declared
inside it, and that method will be called as a drive (). Now, this abstract class method can
be implemented by any object, for example, car, bike, scooter, cycle, etc.
BTCS602N Object Oriented Analysis and Design

An Object Diagram can be referred to as a screenshot of the instances in a system and the
relationship that exists between them. Since object diagrams depict behaviour when objects
have been instantiated, we are able to study the behavior of the system at a particular instant.
Object diagrams are vital to portray and understand functional requirements of a system.
In other words, “An object diagram in the Unified Modeling Language (UML), is a
diagram that shows a complete or partial view of the structure of a modeled system at a
specific time.”
Difference between an Object and a Class Diagram –
An object diagram is similar to a class diagram except it shows the instances of classes in
the system. We depict actual classifiers and their relationships making the use of class
diagrams. On the other hand, an Object Diagram represents specific instances of classes and
relationships between them at a point of time.
What is a classifier?
In UML a classifier refers to a group of elements that have some common features like
methods, attributes and operations. A classifier can be thought of as an abstract
metaclass which draws a boundary for a group of instances having common static and
dynamic features. For example, we refer a class, an object, a component, or a
deployment node as classifiers in UML since they define a common set of properties.
An Object Diagram is a structural diagram which uses notation similar to that of
class diagrams. We are able to design object diagrams by instantiating classifiers.

Object Diagrams use real world examples to depict the nature and structure of the
system at a particular point in time. Since we are able to use data available within objects,
Object diagrams provide a clearer view of the relationships that exist between objects.

Figure – a class and its corresponding

object Notations Used in Object Diagrams –

1. Objects or Instance specifications – When we instantiate a classifier in a

system, the object we create represents an entity which exists in the system. We
can represent the changes in object over time by creating multiple instance
specifications. We use a rectangle to represent an object in an Object Diagram.
An object is generally linked to other objects in an object diagram.
BTCS602N Object Oriented Analysis and Design

Figure – notation for an Object

For example – In the figure below, two objects of class Student are linked to
an object of class College.

Figure – an object diagram using a link and 3 objects

Notation Meaning

0..1 Zero or one

1 One only

0..* Zero or more

* Zero or more

1..* One or more

7 Seven only
BTCS602N Object Oriented Analysis and Design

0..2 Zero or two

4..7 Four to seven

2. Links – We use a link to represent a relationship between two objects.

Figure – notation for a link

We represent the number of participants on the link for each end of the link. We
use the term association for a relationship between two classifiers. The term link
is used to specify a relationship between two instance specifications or objects.
We use a solid line to represent a link between two objects.
3. Dependency Relationships – We use a dependency relationship to show
when one element depends on another element.

Figure – notation for dependency relationship

Class diagrams, component diagrams, deployment and object diagrams use

dependency relationships. A dependency is used to depict the relationship
between dependent and independent entities in the system. Any change in the
definition or structure of one element may cause changes to the other. This is
a unidirectional kind of relationship between two objects.
Dependency relationships are of various types specified with
keywords (sometimes within angular brackets”).
Abstraction, Binding, Realization, Substitution and Usage are the types
of dependency relationships used in UML.
For example – In the figure below, an object of Player class is dependent (or
uses) an object of Bat class.
BTCS602N Object Oriented Analysis and Design

Figure – an object diagram using a dependency relationship

4. Association – Association is a reference relationship between two objects
(or classes).

Figure – notation for association

Whenever an object uses another it is called an association. We use
association when one object references members of the other object.
Association can be uni-directional or bi-directional. We use an arrow to
represent association.
For example – The object of Order class is associated with an object of
Customer class.

Figure – an object diagram using association

5. Aggregation – Aggregation represents a “has a” relationship.

Figure – notation for aggregation

Aggregation is a specific form of association. On relationship; aggregation is
more specific than ordinary association. It is an association that represents a part-
whole or part-of relationship. It is a kind of parent -child relationship however it
isn’t inheritance. Aggregation occurs when the lifecycle of the contained objects
does not strongly depend on the lifecycle of container objects.
BTCS602N Object Oriented Analysis and Design

Figure – an object diagram using aggregation

For example – A library has an aggregation relationship with books. Library has
books or books are a part of library. The existence of books is independent of the
existence of the library. While implementing, there isn’t a lot of difference
between aggregation and association. We use a hollow diamond on the containing
object with a line which joins it to the contained object.
6. Composition – Composition is a type of association where the child cannot
exist independent of the other.

Figure – notation for composition

Composition is also a special type of association. It is also a kind of parent child

relationship but it is not inheritance. Consider the example of a boy Gurkaran:
Gurkaran is composed of legs and arms. Here Gurkaran has a composition
relationship with his legs and arms. Here legs and arms cant exist without the
existence of their parent object. So whenever independent existence of the child
is not possible we use a composition relationship. We use a filled diamond on the
containing object with a line which joins it to the contained object.

Figure – an object diagram using composition

For Example – In the figure below, consider the object Bank1. Here an
account cannot exist without the existence of a bank.

Figure – a bank is composed of accounts

BTCS602N Object Oriented Analysis and Design

Difference between Association and Dependency –

Association and dependency are often confused in their usage. A source of confusion was the
use of transient links in UML 1. Meta-models are now handled differently in UML 2 and the
issue has been resolved.
There are a large number of dependencies in a system. We only represent the ones which
are essential to convey for understanding the system. We need to understand that every
association implies a dependency itself. We , however, prefer not to draw it separately. An
association implies a dependency similar to a way in which generalization does.

How to draw an Object Diagram?

1. Draw all the necessary class diagrams for the system.

2. Identify the crucial points in time where a system snapshot is needed.
3. Identify the objects which cover crucial functionality of the system.
4. Identify the relationship between objects drawn.

Uses of an Object Diagram –

● Model the static design(similar to class diagrams ) or structure of a system

using prototypical instances and real data.
● Helps us to understand the functionalities that the system should deliver to
the users.
● Understand relationships between objects.
● Visualise, document, construct and design a static frame showing instances
of objects and their relationships in the dynamic story of life of a system.
● Verify the class diagrams for completeness and accuracy by using
Object Diagrams as specific test cases.
● Discover facts and dependencies between specific instances and depicting
specific examples of classifiers.
BTCS602N Object Oriented Analysis and Design

Class Diagram of Cab Booking System:

BTCS602N Object Oriented Analysis and Design

Object Diagram of Cab Booking System: