Ooad File Btit604-Lab Manual

BTIT-604 Object Oriented Analysis and Design
SHRI VAISHNAV VIDHYAPEETH

VISHWAVIDYALAYA
Session : July-2023 to Dec-2023
Object Oriented Analysis and Design

BTIT-604
Class and Section:
Submitted To: Submitted By:

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.
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.
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.
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.

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.

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.

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.
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
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 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
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.

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
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:
● 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.
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
1. Cab Details
2. Booking Form
3. Billing
4. Cancellation
Scope
▪ 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
RAM
2GB
HDD
160 GB, 7200k spin
Operating systems used in development
Windows XP sp3 / Windows 7
Business broadband connection with static IP (8mb download)

Online backup
Logmein, or Windows Remote Desktop Connectivity. Other suggested
components17 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
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:
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
BlackBox 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
“lookingover 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 toremove 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
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.
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,
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 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.
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.
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.
7. Composite state – We use a rounded rectangle to represent a

composite state also. We represent a state with internal activities using
acomposite 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.
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.
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.
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.
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
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:
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.
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.
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
theuser, 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.
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.
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.
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
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.
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:
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
orprocedure.
● 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.
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.
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.
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:
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.
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.
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.
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.
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
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
ofdependency relationships used in UML.
For example – In the figure below, an object of Player class is dependent (or uses)
an object of Bat class.
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.
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

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.
Class Diagram of Cab Booking System:

Object Diagram of Cab Booking System:

Ooad File Btit604-Lab Manual

Uploaded by

Document Information

Original Title

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

Ooad File Btit604-Lab Manual

Uploaded by

Copyright:

Available Formats

BTIT-604 Object Oriented Analysis and Design

SHRI VAISHNAV VIDHYAPEETH

Session : July-2023 to Dec-2023

Object Oriented Analysis and Design

Submitted To: Submitted By:

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

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

9. To perform structural view analysis of class and object

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

Object-oriented programming has several advantages over procedural programming:

● OOP is faster and easier to execute.

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

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

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

Difference between OOP and POP

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

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.

Inheritance There is no provision of Inheritance achieved in three

inheritance. modes public private and

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

hence data security increases.

functions in the program. objects through the member

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

friend classes become a friend of another

class with the keyword

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.

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

Object Oriented Approach

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.

Features of Object-Oriented Programming

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

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

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.

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.

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

non-OOP’s one separately.

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

an advantage that there is no possibility of code duplicity.