UNIT-1

Introduction to Object-Oriented Programming

Introduction of Object Oriented Programming

Object-Oriented Programming or OOPs refers to languages that use objects in programming.

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.

Basic Concepts of Object Orientation

 Class
 Object
 Attribute
 Operation (Function)
 Polymorphism

1. Class
It is a user-defined data type, which holds its data members and member functions, which can be
accessed and used by creating an instance of that class. A class is like a blueprint for an object.
For Example:
Consider the Class of Cars. There may be many cars with different names and brands but all of
them will share some common properties like all of them will have 4 wheels, Speed Limit,
Mileage range, etc. So here, the Car is the class, and wheels, speed limits, and mileage are their
properties.

Axis Institute of Technology & Management, Kanpur Page 1

 2. Object

An Object is an instance of a class that holds data (values) in its variables. Data can be accessed by
its functions. When a class is defined, no memory is allocated but when it is instantiated (i.e. an object
is created) memory is allocated.

Car carsObj = Car();

Real Life Examples of Class and Objects with its attributes and
behaviour

Axis Institute of Technology & Management, Kanpur Page 2

Difference between object and class:

There are many differences between object and class.

Object Class

Object is an instance of a class. Class is a blueprint or template from which

objects are created.
Object is a real world entity such as pen, laptop, Class is a group of similar objects.
mobile, bed, keyboard, mouse, chair etc.
Object is a physical entity. Class is a logical entity.

Object is created many times as per requirement. Class is declared once.

Object allocates memory when it is created. Class doesn't allocated memory when it is
created.
Example: Jaguar, BMW, Tesla, etc. Example: Car.

Page 3
Principles (or features) of object oriented programming:
 Abstraction
 Encapsulation
 Inheritance
 Polymorphism

Abstraction
Data abstraction is one of the most essential and important features of object-oriented programming.
Abstraction means displaying only essential information and hiding the details. Data abstraction
refers to providing only essential information about the data to the outside world, hiding the
background details or implementation.

Advantage
 Data Hiding
 It reduce the complexity

Axis Institute of Technology & Management, Kanpur Page 4

Encapsulation:
Encapsulation is defined as the wrapping up of data and information under a single unit. In Object
Oriented Programming, Encapsulation is defined as binding together the data and the functions that
manipulate them.
By default data is not accessible to outside world and they are only accessible through the functions
which are wrapped in a class. Prevention of data direct access by the program is called data hiding or
information hiding

Properties of Encapsulation

Data Protection Information hiding

1. Data Protection: It provides data integrity and maintains the consistency of the
object'sstate.
2. Information hiding: Encapsulation hides the internal details of an object, protecting
the datafrom unauthorized access or modification.

Inheritance:
 Inheritance is the process by which one object can acquire the properties of another.
 The capability of a class to derive properties and characteristics from another class is called
Inheritance. Inheritance is one of the most important features of Object Oriented Programming.
Sub Class: The class that inherits properties from another class is called Sub class or Derived
Class.
Super Class: The class whose properties are inherited by a sub-class is called Base Class or
Super class.

Axis Institute of Technology & Management, Kanpur Page 5

Axis Institute of Technology & Management, Kanpur Page 6
Axis Institute of Technology & Management, Kanpur Page 7
Polymorphism
 Polymorphism means having many forms. In simple words, we can define polymorphism as the
ability of a message to be displayed in more than one form.

 Polymorphism is considered one of the important features of Object Oriented Programming.

Example:

In a real-life example of polymorphism, a person at the same time can have different characteristics. A
man at the same time is a father, a husband, and an employee. So the same person possesses different
behavior in different situations. This is called polymorphism.

Polymorphism is mainly divided into two types:

1. Compile time Polymorphism
2. Runtime Polymorphism

Axis Institute of Technology & Management, Kanpur Page 8

Advantages of OOP:
 Reusability: It means reusing the same code again and again rather than building them.
OOP allows developers to create code that can be reused in different parts of an
application. This makes development faster and more efficient because developers do not
have to write new code from scratch each time they need to create a new feature.
 Modularity: OOP allows developers to break down complex systems into smaller, more
manageable modules. This makes it easier to develop, test, and maintain code because
changes made to one module do not affect other parts of the system.
 Data redundancy: OOP allow similar functionality in multiple classes to a user i.e., user
can write common definition and inherit them.
 Code Maintenance: Changes and bug fixes can be made to specific objects or classes
without affecting other parts of the system, reducing errors and improving debugging.
 Security: OOPs protects data integrity and privacy by restricting direct access and
allowing controlled access through methods.
 Design Benefits: It is to design better code with fewer flaws.
 Better Productivity: It leads to more work done, finishing a better program having more
inbuilt features and easy writing ,reading and maintenance.
 Easily Upgradable & Scalable: OOP enables easy addition and modification of features
without impacting the entire codebase. OOP makes it easier to scale a program to handle
an increasing amount of work or data.

Axis Institute of Technology & Management, Kanpur Page 9

Object Identity: -

 An object retains its identity even if some or all of the values of variables or definitions of
methods change over time.
 Object identity is a stronger notion of identity than typically found in programming languages or
in data models not based on object orientation.
 Several forms of identity:

 value: A data value is used for identity (e.g., the primary key of a tuple in a relational
database).
 name: A user-supplied name is used for identity (e.g., file name in a file system).
 built-in: A notion of identity is built-into the data model or programming languages, and
no user-supplied identifier is required (e.g., in OO systems)

Generosity:
 Generosity is a technique for defining software components that have m than one
interpretation depending on the data types of parameters.
 It allows the declaration of data items without specifying their exact data type.
 Such unknown data types (generic data type) are resolved at the time of their usage based
on the data type of parameters during a function call.
 It is a process that allows a function or a class to work with different-different data types.
That type of function is called Template Function.

Model-
A model is a simplification of reality. A model provides the blueprints of a system. Models may
encompass detailed plans, as well as more general plans. A model may be structural, emphasizing
the organization of the system, or it may be behavioral, emphasizing the dynamics of the system.
We build model so that we can better understand system we are developing.

Axis Institute of Technology & Management, Kanpur Page 10

What is UML?

The Unified Modeling Language (UML) is a general-purpose modeling language. The main
aim of UML is to define standard way visualize the design of a system. You can think of UML
as a way to create blueprints so that software is fully understood by the designer before any
coding begins. UML is not a programming language, it is a visual language.
Or
The UML is a graphical language for visualizing, specifying, constructing, and documenting the
artifacts of a software-intensive system. The UML gives you a standard way to write a system's
blueprints.

Importance of Modeling

A model is a simplification of reality. A model provides the blueprints of a system. A

model may be structural, emphasizing the organization of the system, or it may be
behavioral, emphasizing the dynamics of the system.

Aims of modeling
We build models so that we can better understand the system we are developing.
Through modeling, we achieve four aims.
1. Model help us to visualize a system

2. Model permit us to specify the structure or behavior of a system

3. Model give us a template for building a system

4. Models document the decisions we have made

Page 11
Principle of Modeling:
Four basic principles of modeling

1. The choice of what models to create has a profound influence on how a problem is
attacked and how a solution is shaped.
In other words, choose your models well. The right models will brilliantly illuminate the most
wicked development problems, offering insight that you simply could not gain otherwise; the
wrong models will mislead you, causing you to focus on irrelevant issues.

2. Every model may be expressed at different levels of precision.

This means all the user and developers both may visualize a system at different levels of detail at
different times.

3. The best models are connected to reality.

This means that the model must have things that are practically possible. They must satisfy the
real world scenarios.

4. No single model is sufficient. Every nontrivial system is best approached through a small
set of nearly independent models.

To understand the architecture of such a system, you need several complementary and interlocking
views: a use case view, a design view, implementation view, and a deployment view. Each of these
views may have structural, as well as behavioral, aspects. Together, these views represent the blueprints
of software.

Axis Institute of Technology & Management, Kanpur Page 12

 Object-Oriented Modelling

In software, there are several ways to approach a model. The two most common ways are
1. Algorithmic perspective
2. Object-oriented perspective.
1. Algorithmically
 The traditional view of software development takes an algorithmic perspective.
 In this approach, the main building block of all software is the procedure or function.
 This view leads developers to focus on issues of control and the decomposition of larger
algorithms into smaller ones.
 As requirements change and the system grows, systems built with an algorithmic focus turn out
to be very hard to maintain.

2. Object-Oriented
 The contemporary view of software development takes an object-oriented perspective.
 In this approach, the main building block of all software systems is the object or class.

 A class is a description of a set of common objects. Every object has identity, state, and
behavior.

An Overview of UML

 The Unified Modeling Language is a standard language for writing software blueprints. The
UML may be used to visualize, specify, construct, and document the artifacts of a software-
intensive system.

 The UML is a language for

 Visualizing

 Specifying

 Constructing

 Documenting

Axis Institute of Technology & Management, Kanpur Page 13

 Visualizing The UML is more than just a bunch of graphical symbols. Rather, behind each
symbol in the UML notation is a well-defined semantics. In this manner, one developer can
write a model in the UML, and another developer, or even another tool, can interpret that model
unambiguously

Specifying means building models that are precise, unambiguous, and complete.

Constructing the UML is not a visual programming language, but its models can be directly
connected to a variety of programming languages

Documenting a healthy software organization produces all sorts of artifacts in addition to raw
executable code. These artifacts include

 Requirements

 Architecture

 Design

 Source code

 Project plans

 Tests

 Prototypes

 Releases

The Conceptual model of UML:

To understand the UML, you need to form a conceptual model of the language, and this
requires three major elements:

1. Building block of the UML

2. Rules

3. Common Mechanisms

Axis Institute of Technology & Management, Kanpur Page 14

Conceptual Model of UML

1. Basic Building Blocks of the UML:-

Vocabulary of the UML can be defined

1. Things

2. Relationships

3. Diagrams

Axis Institute of Technology & Management, Kanpur Page 15

Things in the UML: -
There are four kinds of things in the UML:
1. Structural things

2. Behavioral things

3. Grouping things

4. Annotational things

These things are the basic object-oriented building blocks of the UML. You use them to write well-
formed models.

1. Structural Things:
They are nouns of UML model. These are the static parts that represent elements that are either
conceptual or physical. It includes class, interface, collaboration, use case, active class, component, and
node.

2. Behavioral Things:
 Behavioral things are the dynamic parts of UML models. These are the verbs of a model.
 There are two primary kinds of behavioral things
1. Interaction
2. state machine.

3. Grouping Things:
 These are the organizing parts of UML models. These are the boxes into which a model can be
decomposed
 It includes packages.

4. Annotational Things:
 These are the explanatory parts of UML models.
 It includes notes.

Axis Institute of Technology & Management, Kanpur Page 16

Relationships in the UML
There are four kinds of relationships in the UML:

1. Dependency
2. Association
3. Generalization
4. Realization
These relationships are the basic relational building blocks of the UML. We use them to write well- formed
models.

1. Dependency:
 A dependency is a semantic relationship between two things in which a change to one thing may
affect the semantics of the other thing
 Graphically a dependency is rendered as a dashed line, possibly directed, and occasionally including
a label.

2. Association:
 An association is a structural relationship that describes a set of links, a link being a connection
among objects.
 Graphically an association is rendered as a solid line, possibly directed, occasionally including a
label, and often containing other adornments, such as multiplicity and role names.

3. Generalization:
A generalization is a specialization/generalization relationship in which objects of the specialized
element (the child) are substitutable for objects of the generalized element (the parent).

Axis Institute of Technology & Management, Kanpur Page 17

 4. Realizations

 A realization is a semantic relationship between classifiers, wherein one classifier specifies a

contract that another classifier guarantees to carry out.

 Graphically, a realization relationship is rendered as a cross between a generalization and a

dependency relationship, as in Figure 2-15

Diagrams in the UML

Diagram is the graphical presentation of a set of elements, most often rendered as a connected graph of vertices
(things) and arcs (relationships).
In theory, a diagram may contain any combination of things and relationships.

The UML includes some kinds of diagrams:

1. Class diagram
2. Object diagram
3. Use case diagram
4. Sequence diagram
5. Collaboration diagram
6. State diagram
7. Activity diagram
8. Component diagram
9. Deployment diagram

Axis Institute of Technology & Management, Kanpur Page 18

Class diagram
 A class diagram shows a set of classes, interfaces, and collaborations and their relationships.

 Class diagrams that include active classes address the static process view of a system.

Object diagram
 Object diagrams represent static snapshots of instances of the things found in class diagrams

 These diagrams address the static design view or static process view of a system

 An object diagram shows a set of objects and their relationships

Use case diagram

 A use case diagram shows a set of use cases and actors and their relationships

 Use case diagrams address the static use case view of a system.

 These diagrams are especially important in organizing and modeling the behaviors of a system

Interaction Diagrams
 Both sequence diagrams and collaboration diagrams are kinds of interaction diagrams

 Interaction diagrams address the dynamic view of a system

 A sequence diagram is an interaction diagram that emphasizes the time-ordering of messages

 A collaboration diagram is an interaction diagram that emphasizes the structural organization of

the objects that send and receive messages

 Sequence diagrams and collaboration diagrams are isomorphic, meaning that you can take one
and transform it into the other

State chart diagram

 A state chart diagram shows a state machine, consisting of states, transitions, events, and
activities

 State chart diagrams address the dynamic view of a system

 They are especially important in modeling the behavior of an interface, class, or collaboration
and emphasize the event-ordered behavior of an object.

Axis Institute of Technology & Management, Kanpur Page 19

 Activity diagram

 An activity diagram is a special kind of a state chart diagram that shows the flow from activity to
activity within a system

 Activity diagrams address the dynamic view of a system

 They are especially important in modeling the function of a system and emphasize the flow of
control among objects.

Component diagram

 A component diagram shows the organizations and dependencies among a set of components.

 Component diagrams address the static implementation view of a system

 They are related to class diagrams in that a component typically maps to one or more classes,
interfaces, or collaborations.

Deployment diagram
 A deployment diagram shows the configuration of run-time processing nodes and the
components that live on them

 Deployment diagrams address the static deployment view of an architecture

Rules of the UML:

The UML has semantic rules for:
1. Names – What you can call things, relationships, and diagrams.
2. Scope – The context that gives specific meaning to a name.
3. Visibility – How those names can be seen and used by others.
4. Integrity – How things properly and consistently relate to one another.
5. Execution – What it means to run or simulate a dynamic model.

Axis Institute of Technology & Management, Kanpur Page 20

Common Mechanisms in the UML:
The UML is made simpler by the four common mechanisms that apply consistently throughout the language.
They are as follows:

1. Specifications

2. Adornments

3. Common divisions

4. Extensibility mechanisms

1. Specifications
 They provide a textual statement of the syntax and semantics of that building block.

 The UML's specifications provide a semantic backplane that contains all the parts of all the
models of a system, each part related to one another in a consistent fashion

2. Adornments
 Most elements in the UML have a unique and direct graphical notation that provides a visual
representation of the most important aspects of the element.

 A class's specification may include other details, such as whether it is abstract or the visibility of
its attributes and operations.

3. Common Divisions
In modeling object-oriented systems, the world often gets divided in at least a couple of ways.

4. Extensibility Mechanisms
The UML's extensibility mechanisms include
1. Stereotypes
2. Tagged values
3. Constraints

Axis Institute of Technology & Management, Kanpur Page 21

Architecture of the UML:
A system's architecture is perhaps the most important artifact that can be used to manage these different
viewpoints and so control the iterative and incremental development of a system throughout its life cycle.
Architecture is the set of significant decisions about
 The organization of a software system
 The selection of the structural elements and their interfaces by which the system is composed
 Their behavior, as specified in the collaborations among those elements
 The composition of these structural and behavioral elements into progressively larger subsystems
 The architectural style that guides this organization: the static and dynamic elements and their
interfaces, their collaborations, and their composition

As Figure illustrates, the architecture of a software-intensive system can best be described by five interlocking
views. Each view is a projection into the organization and structure of the system, focused on a particular
aspect of that system.

Use case view

 The use case view of a system encompasses the use cases that describe the behavior

of the system as seen by its end users, analysts, and testers.

 With the UML, the static aspects of this view are captured in use case diagrams

Axis Institute of Technology & Management, Kanpur Page 22

  The dynamic aspects of this view are captured in interaction diagrams, state chart diagrams, and
activity diagrams.

Design View

 The design view of a system encompasses the classes, interfaces, and collaborations that form the
vocabulary of the problem and its solution.

 This view primarily supports the functional requirements of the system, meaning the services that
the system should provide to its end users.

Process View

 The process view of a system encompasses the threads and processes that form the system's
concurrency and synchronization mechanisms.

 This view primarily addresses the performance, scalability, and throughput of the system.

Implementation View
 The implementation view of a system encompasses the components and files that are used to
assemble and release the physical system.

 This view primarily addresses the configuration management of the system's releases, made up of
somewhat independent components and files that can be assembled in various ways to produce a
running system.
Deployment View
 The deployment view of a system encompasses the nodes that form the system's hardware topology on
which the system executes.
 This view primarily addresses the distribution, delivery, and installation of the parts that make up the
physical system.
 Each of these five views can stand alone so that different stakeholders can focus on the issues of
the system's architecture that most concern them.
 The UML permits you to express every one of these five views and their interactions.

Axis Institute of Technology & Management, Kanpur Page 23