Object-Oriented Programming Approaches

Presented By-Arihant Kumar Jain

Hirendra DeoraManeesh Kumar Singhal

I Semester, M.Tech, Computer Engineering

A

Seminar On

1

Procedural vs. Object-Oriented Programming The unit in procedural programming is function,

and unit in object-oriented programming is class

Procedural programming concentrates on creating functions, while object-oriented programming starts from isolating the classes, and then look for the methods inside them.

Procedural programming separates the data of the program from the operations that manipulate the data, while object-oriented programming focus on both of them

figure1: procedural figure2: object-oriented 2

3

Object-Oriented Analysis and Design

“A system of objects interacting to perform the given tasks”

4

What is Object Oriented Programming?

An object is like a black box.

The internal details are hidden.

Identifying objects and assigning responsibilities to these objects.

Objects communicate to other objects by sending messages.

Messages are received by the methods of an object

Definition

Object-Oriented Programming is an approach that provides a way of modularizing programs by creating partitioned memory areas of both data & functions that can be used as templates for creating copies of such modules on demand.

5

6

Objectives

To introduce the basic concepts of object-oriented analysis and design

To understand the difference between object-oriented analysis and design and other analysis and design methods

To describe the main characteristics of object-oriented system

7

An Object-Oriented System

Object

Message

8

Object-Orientation

Object-Oriented Analysis

Object-Oriented Design

Object-Oriented Programming

Problem

Solution

Object-OrientedConcepts

ADT

Identity

Inheritance

9

Object-Oriented Analysis

“A method of analysis that examines requirements from the perspective of classes and objects found in the vocabulary of the problem domain”

(Booch, 1994)

10

Object-Oriented Analysis

Examining the problem domain/statement to identify objects

Identify entities, relationships and operations of the problem domain

Understanding the role of the objects by examining the relevant data and processes

11

Object-Oriented Design

“[Object-oriented] design is that portion of the lifecycle that prepares definitions as to how the system will accomplish its requirements. The models prepared in analysis are either refined, or transformed, into design models that depict the physical nature of the software product.”

(Berard, 1992)

12

Object-Oriented Design

Build the logical models and hierarchy of the objects and classes for implementation

Creating new classes to complete the functionality of the solution

Refining the classes for smoother operation and efficiency e.g. through migration of operations and creating of subclasses

13

What is Object?Representation of real-world objects and

concepts in software domainTypically a producer or consumer of

information item in computer systemAn object consists of attributes and

operationsAttributes - data structures/elementsOperations - processes for

controlling/manipulating attributes

14

What is an object?

Tangible Things as a car, printer, ...Roles as employee, boss, ...Incidents as flight, overflow, ...Interactions as contract, sale, ...Specifications as colour, shape, …

15

Why do we care about objects?

Modularity - large software projects can be split up in smaller pieces.

Reuseability - Programs can be assembled from pre-written software components.

Extensibility - New software components can be written or developed from existing ones.

16

Example of Object

Object: Chair

Cost : Rs 300Dimensions : 1X1X2Weight: 1kgLocation: (2,2,3)Color: black

Move Buy Sell Weigh

17

Typical objects

External entities that produce or consume information in a computer-based system

Things that are part of the information domain for the problem

Occurrences or events that occur within the context of system operation

Roles played by people who interact with the system

18

Typical objects (Continued)

Organisational units that are relevant to an application

Places that establish the context of the problem and the overall function of the system

Structures that define a class of objects or, in the extreme, related classes of objects

19

The two parts of an object

Object = Data + Methods or to say the same differently:

An object has the responsibility to know and the responsibility to do.

= +

20

Class

Set of objects with similar attributes and operations

Objects are instances of classes

Classes are ‘frames’ for objects (basically the ‘types’ for the objects)

21

Example of Class

Class: Furniture

CostDimensionsWeightLocationColour

MoveBuySellWeigh

22

Object-Oriented Concepts

Abstraction: Identifying the important features of objects to be represented

Modularity: software is separated into individual elements that can be grouped together to form the solution

Information Hiding: the details of implementation are hidden from all program elements outside the object

23

Object-Oriented Concepts (Continued)

Encapsulation: Combination of attributes and operations into a single entity

Message passing: Mechanism to communicate between objects

Inheritance: Relationship between classes that allows a class to inherit all attributes and operations of another class

Polymorphism: Different response to the same message by similar objects

Order Processing System

Billing

OrderEntry

OrderFulfillment

Manages Complexity

What is Modularity?The breaking up of something complex

into manageable pieces

24

Decreasing abstraction

Increasing abstraction

Asset

RealEstate

Savings

BankAccount

Checking Stock

Security

Bond

Elements at the same level of the hierarchy should be at the same level of abstraction

What is Hierarchy? Levels of abstraction

25

26

Message Passing

Program

Student

Report

store marks

done

done

print report

give marks marks

27

Inheritance

Furniture

TableChair

Yeoh’s chair Ali’s chair

28

Polymorphism

Program

Hare

Tortoise

run

done

done

run

29

Basic Terminology:Aggregation

Aggregation describes a “has a” relationship. One object is a part of another object.

We distinguish between composite aggregation (the composite “owns” the part) and shared aggregation (the part is shared by more then one composite).

A car has wheels.

30

Basic Terminology:Behaviour and Messages

The most important aspect of an object is its behaviour (the things it can do). A behaviour is initiated by sending a message to the object (usually by calling a method).

Relationships

Association Aggregation Composition

DependencyGeneralizationRealization

31

Professor UniversityWorks for

Class

Association

Association Name

Professor University

EmployerEmployee

Role Names

Relationships: Association Models a semantic connection among classes

32

Student Schedule

Whole

Aggregation

Part

Relationships: Aggregation

A special form of association that models a whole-part relationship between an aggregate (the whole) and its parts

33

Student Schedule

Whole

Aggregation

Part

Relationships: Composition

A form of aggregation with strong ownership and coincident lifetimes The parts cannot survive the whole/aggregate

34

Association: Multiplicity and Navigation

Multiplicity defines how many objects participate in a relationships The number of instances of one class related to

ONE instance of the other class Specified for each end of the association

Associations and aggregations are bi-directional by default, but it is often desirable to restrict navigation to one direction If navigation is restricted, an arrowhead is

added to indicate the direction of the navigation

35

Association: Multiplicity

2..4

0..1

1..*

0..*

1

*

Unspecified Exactly one Zero or more (many, unlimited)

One or more Zero or one Specified range Multiple, disjoint ranges

2, 4..6

36

Student Schedule1 0..*

Multiplicity

Navigation

Example: Multiplicity and Navigation

37

Client Supplier

Package

ClientPackage SupplierPackage

Client Supplier

Class

Dependency relationship

Dependency relationship

Component

Relationships: Dependency

A relationship between two model elements where a change in one may cause a change in the other

Non-structural, “using” relationship

38

Relationships: Generalization

A relationship among classes where one class shares the structure and/or behavior of one or more classes

Defines a hierarchy of abstractions in which a subclass inherits from one or more superclasses Single inheritance Multiple inheritance

Generalization is an “is-a-kind of” relationship

39

Accountbalancenamenumber

Withdraw()CreateStatement()

Checking

Withdraw()

Savings

GetInterest()Withdraw()

Superclass (parent)

Subclasses

Generalization Relationship

Ancestor

Descendents

Example: Single Inheritance

One class inherits from another

40

Airplane Helicopter Wolf Horse

FlyingThing Animal

Bird

multipleinheritance

Use multiple inheritance only when needed, and always with caution !

Example: Multiple InheritanceA class can inherit from several other

classes

41

Inheritance leverages the similarities among classes

What Gets Inherited?A subclass inherits its parent’s attributes,

operations, and relationshipsA subclass may:

Add additional attributes, operations, relationships

Redefine inherited operations (use caution!)

Common attributes, operations, and/or relationships are shown at the highest

applicable level in the hierarchy42

Truck

tonnage

GroundVehicle

weight

licenseNumber

Car

owner

register( )

getTax( )

Person

0..*

Trailer

1Superclass

(parent)

Subclass

generalization

size

Example: What Gets Inherited

43

Component

Interface

Use Case Use-Case Realization

Elided form

Class

InterfaceSubsystem

Interface

Canonical form

Relationships: RealizationOne classifier serves as the contract that

the other classifier agrees to carry outFound between : Interfaces and the

classifiers that realize them

Use cases and the collaborations that realize them

44

45

The two steps of Object Oriented Programming

Making Classes: Creating, extending or reusing abstract data types.

Making Objects interact: Creating objects from abstract data types and defining their relationships.

Object Cohesion & Coupling

Cohesion of a component is a measure of how well it fits together. Each operation provides functionality which allows the attributes of the object to be modified, inspected or used as a basis for service provision.

Coupling is an indication of the strength of interconnections between program units. Highly coupled systems have strong interconnections, with program units dependent on each other (shared variables, interchange control function). Loosely coupled system which are independent .

46

OOPL: Simula

Developed for discrete event simulation (1967)Simulation modeling is a hard problem for

conventional languagesSimulated objects must interact and change

state in many different and often unpredictable ways

Simulation can solve problems that are too complex for mathematical equations

Simulation objects are usually easy to identify and communicate via message passing

47

OOPL: Smalltalk

From Xerox PARC, by Alan Kay and Adele Goldberg

Towards a small language for anyone to use on a PC

Influenced by Simula: objects and classes Influenced The WIMP interface (Windows, Icons, Menu, Pointing device) Influenced Apple’s design of Lisa and

Macintosh

48

OOPL: C++

From AT&T Bell Labs – invented by Bjorne Stroustru

Adds object-oriented features to CClasses in C++ correspond to types in C

49

OOPL: Ada95

DOD support for embedded systemsEnforces Abstract Data Types (ADTs)

Data, operations on data, constraints on operations

E.g., formal specification languages - Larch, Z, VDM

Support for multitasking and exceptionsLarge and complex

50

OOPL: Java Like C++ in syntax Like Smalltalk in Structure and design Without the drawbacks to C++ and Smalltalk

Frees the programmer from having to manage memory (accidental complexity)

Small footprint (memory requirement) No pointers, pointer arithmetic, structs,

typedefs, preprocessor directives (#define), malloc and free

With extensive type checking, true arrays with array bounds checking, null pointer checking, automatic garbage collection

51

52

References

“Software Engineering: A Practitioner’s Approach” 5th Ed. by Roger S. Pressman, Mc-Graw-Hill, 2001

“Object-Oriented Modeling and Design” by James Rumbaugh et al, Prentice Hall, 1991

“Object Orientation” by Setrag Khoshafian & Razmik Abnous, John Wiley & Sons, 1995