You are on page 1of 67

Introduction Object-oriented Programming

 The object-oriented programming is basically a computer


programming design philosophy or methodology that organizes/
models software design around data, or objects rather than
functions and logic.
 An object is referred to as a data field that has unique attributes and
behavior. Everything in OOP is grouped as self-sustainable objects.
 It simplifies software development and maintenance by providing
major concepts such as abstraction, inheritance, polymorphism,
and encapsulation. These core concepts support OOP.
Meaning Object-oriented Programming
As the name suggests, 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.
OOPs Concepts:
•Class
•Objects
•Data Abstraction
•Encapsulation
•Inheritance
•Polymorphism
•Dynamic Binding
Class

 A class is a user-defined data type. It consists of data members and


member functions, which can be accessed and used by creating an
instance of that class. It represents the set of properties or methods
that are common to all objects of one type. 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, Car is the class, and wheels, speed
limits, mileage are their properties.
Objects
 A data field with unique characteristics and behaviors is called an object.
 An object is the basic building block of OOPs.
 An object can be considered a real-life entity having a state and behaviour.
 An object is an instance of a class, and you can create many objects of the
same class. OOP prioritizes objects that the developer wants to manipulate over
the logic needed to manipulate them.
 This approach is suitable for large and complicated programming.
 An object in OOPs can include:
• A Variable.
• A Data Structure.
• A Function or
Characteristics of Object

 Some characteristics of objects in OOPs.


1. State: The current values of each attribute continue to make up an
object's state.
It can be of two types: Static and Dynamic.
2. Behavior: Behavior describes how an object behaves and responds
regarding state transitions.
3. Identity: An object's identity is a quality that makes it distinct from all
other objects.
4. Responsibility: It is the function of an object that it performs within the
system
Difference between Object and class.
Data Abstraction

 Data abstraction is the reduction of a particular body of data to a


simplified representation of the whole. Abstraction, in general, is the
process of removing characteristics from something to reduce it to a
set of essential elements.
 Modern programming languages that incorporate OOP
methodologies commonly use data abstraction to hide the low-level
details of the programming constructs that define the underlying
logic, which in turn simplifies and streamlines the development
process. Object-oriented programming organizes software design
around data objects, rather than functions or logic. Data abstraction is
a key characteristic of OOP that's implemented using classes and
Types of Abstraction:

1.Data abstraction – This type only shows the


required information about the data and hides the
unnecessary data.
2.Control Abstraction – This type only shows the
required information about the implementation
and hides unnecessary information.
Encapsulation
 Encapsulation in C++ is defined as the wrapping up of data and
information in a single unit. In Object Oriented Programming,
Encapsulation is defined as binding together the data and the functions
that manipulate them.
 Consider a real-life example of encapsulation, in a company, there are
different sections like the accounts section, finance section, sales section,
etc. Now,
• The finance section handles all the financial transactions and keeps
records of all the data related to finance.
• Similarly, the sales section handles all the sales-related activities and
keeps records of all the sales.
Two Important property of Encapsulation

1. Data Protection: Encapsulation protects the internal state of an


object by keeping its data members private. Access to and
modification of these data members is restricted to the class’s
public methods, ensuring controlled and secure data
manipulation.
2. Information Hiding: Encapsulation hides the internal
implementation details of a class from external code. Only the
public interface of the class is accessible, providing abstraction
and simplifying the usage of the class while allowing the internal
implementation to be modified without impacting external code
Features of Encapsulation
1. We can not access any function from the class directly. We need an object to
access that function that is using the member variables of that class.
2. The function which we are making inside the class must use only member
variables, only then it is called encapsulation.
3. If we don’t make a function inside the class which is using the member
variable of the class then we don’t call it encapsulation.
4. Encapsulation improves readability, maintainability, and security by grouping
data and methods together.
5. It helps to control the modification of our data members.
Inheritance
 The capability of a class to derive properties and characteristics from another
class is called Inheritance.
 Inheritance is a feature or a process in which, new classes are created from the
existing classes. The new class created is called “derived class” or “child class”
and the existing class is known as the “base class” or “parent class”. The derived
class now is said to be inherited from the base class.
 When we say derived class inherits the base class, it means, the derived class
inherits all the properties of the base class, without changing the properties of
base class and may add new features to its own. These new features in the
derived class will not affect the base class. The derived class is the specialized
class for the base class.
• Sub Class: The class that inherits properties from another class is called
Subclass or Derived Class.
• Super Class: The class whose properties are inherited by a subclass is called
Modes of Inheritance
1. Public Mode: If we derive a subclass from a public base class. Then
the public member of the base class will become public in the
derived class and protected members of the base class will become
protected in the derived class.
2. Protected Mode: If we derive a subclass from a Protected base
class. Then both public members and protected members of the base
class will become protected in the derived class.
3. Private Mode: If we derive a subclass from a Private base class.
Then both public members and protected members of the base class
will become Private in the derived class.
Types Of Inheritance

1.Single inheritance
2.Multilevel inheritance
3.Multiple inheritance
4.Hierarchical inheritance
5.Hybrid inheritance
Polymorphism

 The word “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.
 A real-life example of polymorphism is a person who 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 exhibits different behavior
in different situations. This is called polymorphism.
 Polymorphism is considered one of the important features of Object-
Oriented Programming.
Types of Polymorphism

• Compile-time Polymorphism
• Runtime Polymorphism
Dynamic Binding

 Dynamic binding in C++ is a practice of connecting


the function calls with the function definitions by
avoiding the issues with static binding, which occurred
at build time. Because dynamic binding is flexible, it
avoids the drawbacks of static binding, which
connected the function call and definition at build
time.
 In simple terms, Dynamic binding is the connection
between the function declaration and the function call.
Message Passing
 The object-oriented programming (oops) concepts in C++ involves the use
of objects which are real-life instances of classes. Message passing in C++
is the communication between two or more objects using a logical entity
called a message.
 What is a Message?
• A message is a form of request that is made to an object to perform a
function specific to the object to which the request was made.
• A message is a form of communication between objects that make an object
perform a task for the system.
• The message is an abstract entity and will not hold the information of the
function that is going to be performed and only plays the role of invoking
the function.
Generosity/Template

 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)
Benefits of OOPs Concepts
 Provides modularity and enhances program for easier troubleshooting as objects exist
independently
 - Real world programming
 - Code reusability through inheritance
 - OOPs concepts designed with lesser limitations for larger programs are hard to write.
 - Enhances easier and clear modular structure for programs.
 - Flexibility through polymorphism
 - Effective problem solving and better software quality
 - Lower maintenance cost & resilience to change and hides information
 - Flexibility of upgrading systems of any size
 - Improvise the creation of Graphical User Interface (GUI) applications
 Faster goals achieved for programmers
 - Greater programmer productivity & data become active
 - Faster, accurate, better written applications compared to a procedural program
 - Simple to develop and implement
Model Making

 Model making is a crucial step in the process of


creating products and structures that meet specific
requirements and function as intended.
 A model is a three-dimensional representation of
an object, system, or design that can be used to
test its feasibility, functionality, and performance.
Importance of Modeling

• Permits you to specify the structure or behavior of a


system.
• Helps you visualize a system.
• Provides template that guides you in constructing a
system.
• Helps to understand complex system part by part.
• Document the decisions that you have made.
Principles of Modeling

1. The choice of model is important


2. Every model may be expressed at different
levels of precision
3. The best models are connected to reality
4. No single model is sufficient
Object-Oriented Modeling
 Object-oriented modeling (OOM) is the construction of objects
using a collection of objects that contain stored values of the
instance variables found within an object. Unlike models that
are record-oriented, object-oriented values are solely objects.
 Intention of object oriented modeling and design is to learn
how to apply object -oriented concepts to all the stages of the
software development life cycle. Object-oriented modeling and
design is a way of thinking about problems using models
organized around real world concepts.
 The fundamental construct is the object, which combines both
data structure and behavior.
Purpose of Models
1.Testing a physical entity before
building it
2.Communication with customers
3.Visualization
4.Reduction of complexity
Types of Models
1.Class Model: The class model shows all the classes present in the system.
The class model shows the attributes and the behavior associated with the
objects.

2.State Model: State model describes those aspects of objects concerned with
time and the sequencing of operations – events that mark changes, states that
define the context for events, and the organization of events and states.

3.Interaction Model: Interaction model is used to show the various


interactions between objects, how the objects collaborate to achieve the
behavior of the system as a whole.
The following diagrams are used to show the interaction model:
1. Use Case Diagram
2. Sequence Diagram
Unified Modeling Language (UML)
 Unified Modeling Language (UML) is a general-purpose modeling
language.
 The main aim of UML is to define a standard way to visualize the way a
system has been designed. It is quite similar to blueprints used in other
fields of engineering.
 UML is not a programming language, it is rather a visual language.
• We use UML diagrams to portray the behavior and structure of a system.
• UML helps software engineers, businessmen, and system architects with
modeling, design, and analysis.
• The Object Management Group (OMG) adopted Unified Modelling
Language as a standard in 1997. It’s been managed by OMG ever since.
• The International Organization for Standardization (ISO) published UML
as an approved standard in 2005. UML has been revised over the years and
is reviewed periodically.
Types of UML Diagrams
Creating Unified Modeling Language (UML) diagrams involves
a systematic process that typically includes the following steps
Conceptual model of UML
 The conceptual model consists of three parts. They are:
1) Building blocks of UML (syntax / vocabulary)
2) Rules (semantics)
3) Common Mechanisms
1) Building blocks of UML (syntax / vocabulary)

 The building blocks of UML contains three


types of elements. They are:
1) Things (object oriented parts of uml)
2) Relationships (relational parts of uml)
3) Diagrams
1) Things (object oriented parts of uml)

 A diagram can be viewed as a graph containing vertices and edges.


In UML, vertices are replaced by things, and the edges are replaced
by relationships. There are four types of things in UML. They are:
 1) Structural things (nouns of uml – static parts)
 2) Behavioral things (verbs of uml – dynamic parts)
 3) Grouping things (organizational parts)
 4) Annotational things (explanatory parts)
1) Structural things (nouns of uml – static parts)

 Represents the static aspects of a software system. There are


seven structural things in UML. They are:
 Class
 Interface
 Use Case
 Collaboration
 Component
 Node
 Active Class
Class
 A class is a collection of similar
objects having
similar attributes, behavior,
relationships and semantics.
 Graphically class is
represented as a rectangle with
three compartments.
Interface
 An interface is a collection
of operation signatures
and/or attribute definitions
that ideally define a
cohesive set of behavior.
 Graphically interface is
represented as a circle or a
class symbol stereotyped
with interface.
Use Case
 A use case is a collection
of actions, defining the
interactions between a
role (actor) and the
system.
 Graphically use case is
represented as a solid
ellipse with its name
written inside or below
the ellipse.
Collaboration

A collaboration is the
collection of interactions
among objects to achieve
a goal.
 Graphically collaboration
is represented as a dashed
ellipse. A collaboration
can be a collection of
classes or other elements.
Component
 A component is a physical
and replaceable part of a
system.
 Graphically component is
represented as a tabbed
rectangle.
 Examples of components
are executable files, dll files,
database tables, files and
documents.
Node
 A node is a physical
element that exists at run
time and represents a
computational resource.
 Graphically node is
represented as a cube.
Examples of nodes are PCs,
laptops, smartphones or any
embedded system.
Active Class
 A class whose objects can
initiate its own flow of
control (threads) and work
in parallel with other
objects.
 Graphically active class
is represented as a
rectangle with thick
borders.
2) Behavioral things (verbs of uml – dynamic parts)

 Represents the dynamic aspects of a software


system. Behavior of a software system can be
modeled as interactions or as a sequence of state
changes.
 Interaction
 State Machine
Interaction
 A behavior made up of a
set of messages
exchanged among a set of
objects to perform a
particular task.
 A message is represented
as a solid arrow. Below is
an example of interaction
representing a phone
conversation
State Machine
 A behavior that specifies
the sequences of states an
object or interaction goes
through during its’ lifetime
in response to events.
 A state is represented as a
rectangle with rounded
corners. Below is an
example of state machine
representing the states of a
phone system:
3) Grouping things (organizational parts)

 Elements which are used for organizing


related things and relationships in models.
 Package
 A general purpose mechanism for
organizing elements into groups.
Graphically package is represented as a
tabbed folder.
 When the diagrams become large and
cluttered, related are grouped into a
package so that the diagram can become
less complex and easy to understand.
4. Annotational things (explanatory parts)

 Note: A symbol to display


comments. Graphically note is
represented as a rectangle with
a dog ear at the top right
corner.
2) Relationships (relational parts of uml)

 The things in a diagram are connected through relationships.


So, a relationship is a connection between two or more things.
 Dependency
 Association
 Generalization
 Realization
Dependency
 A semantic relationship, in
which a change in one thing
(the independent thing) may
cause changes in the other
thing (the dependent thing).
 This relationship is also
known as “using”
relationship. Graphically
represented as dashed line
with stick arrow head.
Association

A structural relationship
describing connections
between two or more
things.
 Graphically represented
as a solid line with
optional stick arrow
representing navigation.
Generalization
 Is a generalization-
specialization relationship.
 Simply put this describes
the relationship of a parent
class (generalization) to its
subclasses
(specializations).
 Also known as “is-a”
relationship.
Realization
 Defines a semantic
relationship in which
one class specifies
something that another
class will perform.
 Example: The
relationship between an
interface and the class
that realizes or executes
that interface.
3) Diagrams
 A diagram is a collection of elements often represented as a graph consisting of vertices and edges
joining these vertices. These vertices in UML are things and the edges are relationships. UML
includes nine diagrams:
 1) Class diagram
 2) Object diagram
 3) Use case diagram
 4) Component diagram
 5) Deployment diagram
 6) Sequence diagram
 7) Collaboration diagram
 8) Statechart diagram and
 9) Activity diagram.
Class Diagram

 The class diagram is a central modeling


technique that runs through nearly all
object-oriented methods. This diagram
describes the types of objects in the system
and various kinds of static relationships
which exist between them.
 Relationships
 There are three principal kinds of
relationships which are important:
1. Association - represent relationships
between instances of types (a person works
for a company, a company has a number of
offices.
2. Inheritance - the most obvious addition to
ER diagrams for use in OO. It has an
immediate correspondence to inheritance
in OO design.
3. Aggregation - Aggregation, a form of object
composition in object-oriented design.
Object Diagram
 An object diagram is a graph of
instances, including objects and data
values.
 A static object diagram is an instance
of a class diagram; it shows a
snapshot of the detailed state of a
system at a point in time.
 Object Diagram Example
 The following Object Diagram
example shows you how the object
instances of User and Attachment
class "look like" at the moment Peter
(i.e. the user) is trying to upload two
attachments. So there are two
Instance Specification for the two
attachment objects to be uploaded.
Use Case Diagram
 A use-case model describes a
system's functional
requirements in terms of use
cases.
 It is a model of the system's
intended functionality (use
cases) and its environment
(actors).
 Use cases enable you to relate
what you need from a system
to how the system delivers on
those needs.
Component Diagram
 In the Unified Modeling
Language, a component
diagram depicts how
components are wired together
to form larger components or
software systems.
 It illustrates the architectures of
the software components and
the dependencies between them.
 Those software components
including run-time components,
executable components also the
source code components.
Deployment Diagram
 The Deployment Diagram helps
to model the physical aspect of an
Object-Oriented software system.
 It is a structure diagram which
shows architecture of the system
as deployment (distribution) of
software artifacts to deployment
targets.
 Artifacts represent concrete
elements in the physical world
that are the result of a
development process.
Sequence Diagram
 The Sequence Diagram models
the collaboration of objects
based on a time sequence.
 It shows how the objects
interact with others in a
particular scenario of a use
case.
 With the advanced visual
modeling capability, you can
create complex sequence
diagram in few clicks.
Collaboration Diagram

 The collaboration diagram is used


to show the relationship between
the objects in a system.
 Both the sequence and the
collaboration diagrams represent
the same information but
differently.
 Instead of showing the flow of
messages, it depicts the architecture
of the object residing in the system
as it is based on object-oriented
programming.
Statechart Diagrams
 A Statechart diagram
describes a state machine.
 State machine can be
defined as a machine
which defines different
states of an object and
these states are controlled
by external or internal
events
Activity Diagram
 Activity diagrams are
graphical representations of
workflows of stepwise
activities and actions with
support for choice, iteration
and concurrency.
 It describes the flow of
control of the target system,
such as the exploring
complex business rules and
operations, describing the
use case also the business
process.
Package Diagram
 Package diagram is UML
structure diagram which
shows packages and
dependencies between the
packages.
 Model diagrams allow to
show different views of a
system, for example, as
multi-layered (aka multi-
tiered) application - multi-
layered application model.
Composite Structure Diagram
 Composite Structure Diagram is
one of the new artifacts added to
UML 2.0.
 A composite structure diagram is
similar to a class diagram and is a
kind of component diagram mainly
used in modeling a system at micro
point-of-view, but it depicts
individual parts instead of whole
classes.
 It is a type of static structure
diagram that shows the internal
structure of a class and the
collaborations that this structure
Profile Diagram
 A profile diagram enables you
to create domain and platform
specific stereotypes and define
the relationships between
them.
 You can create stereotypes by
drawing stereotype shapes and
relate them with composition
or generalization through the
resource-centric interface.
 You can also define and
visualize tagged values of
Communication Diagram
 Similar to Sequence Diagram, the
Communication Diagram is also
used to model the dynamic behavior
of the use case.
 When compare to Sequence
Diagram, the Communication
Diagram is more focused on
showing the collaboration of objects
rather than the time sequence.
 They are actually semantically
equivalent, so some of the modeling
tool such as, Visual Paradigm
allows you to generate it from one
to the other.
Interaction Overview Diagram
 The Interaction Overview
Diagram focuses on the
overview of the flow of
control of the interactions.
 It is a variant of the
Activity Diagram where the
nodes are the interactions
or interaction occurrences.
 The Interaction Overview
Diagram describes the
interactions where
messages and lifelines are
hidden.
Rules (conceptual model of UML)

 The rules of UML specify how the UMLs building blocks come together to develop diagrams. The
rules enable the users to create well-formed models. A well-formed model is self-consistent and
also consistent with the other models.
 UML has rules for:
 Names – What elements can be called as things, relationships and diagrams
 Scope – The context that gives a specific meaning to a name
 Visibility – How these names are seen and can be used by the other names
 Integrity – How things properly relate to one another
 Execution – What it means to run or simulate a model
Common Mechanisms in UML (conceptual model of uml)

 Why UML is easy to learn and use? It’s because of the four common mechanisms that
apply throughout the UML. They are:
1. Specifications
2. Adornments
3. Common divisions
4. Extensibility mechanisms

You might also like