A Seminar On Object-Oriented Programming Approaches Presented By

A Seminar On Object-Oriented Programming Approaches Presented By. Arihant Kumar Jain Hirendra Deora Maneesh Kumar Singhal I Semester, M. Tech, Computer Engineering 1

Procedural vs. Object-Oriented Programming z The unit in procedural programming is function, and unit in object-oriented programming is class z Procedural programming concentrates on creating functions, while object-oriented programming starts from isolating the classes, and then look for the methods inside them. z Procedural programming separates the data of the program from the operations that manipulate the data, while object-oriented programming focus on both of them figure 1: procedural oriented figure 2: object 2

Object-Oriented Analysis and Design “A system of objects interacting to perform the given tasks” 3

What is Object Oriented Programming? z Identifying objects and assigning responsibilities to these objects. z Objects communicate to An object is like a other objects by sending black box. messages. The internal z Messages are received by details are the methods of an object hidden. 4

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

Objectives z To introduce the basic concepts of object-oriented analysis and design z To understand the difference between objectoriented analysis and design and other analysis and design methods z To describe the main characteristics of objectoriented system 6

An Object-Oriented System Object Message 7

Object-Orientation Problem Object-Oriented Concepts Object-Oriented Analysis ADT Object-Oriented Design Object-Oriented Programming Inheritance Identity Solution 8

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) 9

Object-Oriented Analysis z Examining the problem domain/statement to identify objects z Identify entities, relationships and operations of the problem domain z Understanding the role of the objects by examining the relevant data and processes 10

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) 11

Object-Oriented Design z Build the logical models and hierarchy of the objects and classes for implementation z Creating new classes to complete the functionality of the solution z Refining the classes for smoother operation and efficiency e. g. through migration of operations and creating of subclasses 12

What is Object? z Representation of real-world objects and concepts in software domain z Typically a producer or consumer of information item in computer system z An object consists of attributes and operations z Attributes - data structures/elements z Operations processes for controlling/manipulating attributes 13

What is an object? z. Tangible Things z. Roles z. Incidents z. Interactions z. Specifications as a car, printer, . . . as employee, boss, . . . as flight, overflow, . . . as contract, sale, . . . as colour, shape, … 14

Why do we care about objects? z. Modularity - large software projects can be split up in smaller pieces. z. Reuseability - Programs can be assembled from pre-written software components. z. Extensibility - New software components can be written or developed from existing ones. 15

Example of Object: Chair Cost : Rs 300 Dimensions : 1 X 1 X 2 Weight: 1 kg Location: (2, 2, 3) Color: black Move Buy Sell Weigh 16

Typical objects z External entities that produce or consume information in a computer-based system z Things that are part of the information domain for the problem z Occurrences or events that occur within the context of system operation z Roles played by people who interact with the system 17

Typical objects (Continued) z Organisational units that are relevant to an application z Places that establish the context of the problem and the overall function of the system z Structures that define a class of objects or, in the extreme, related classes of objects 18

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. = + 19

Class z Set of objects with similar attributes and operations z Objects are instances of classes z Classes are ‘frames’ for objects (basically the ‘types’ for the objects) 20

Example of Class: Furniture Cost Dimensions Weight Location Colour Move Buy Sell Weigh 21

Object-Oriented Concepts z Abstraction: Identifying the important features of objects to be represented z Modularity: software is separated into individual elements that can be grouped together to form the solution z Information Hiding: the details of implementation are hidden from all program elements outside the object 22

Object-Oriented Concepts (Continued) z Encapsulation: Combination of attributes and operations into a single entity z Message passing: Mechanism to communicate between objects z Inheritance: Relationship between classes that allows a class to inherit all attributes and operations of another class z Polymorphism: Different response to the same message by similar objects 23

What is Modularity? z The breaking up of something complex into Order manageable pieces Entry Order Processing System Order Fulfillment Billing Manages Complexity 24

What is Hierarchy? Asset z Increasing abstraction Levels of abstraction Bank. Account Savings Checking Decreasing abstraction Security Stock Real. Estate Bond Elements at the same level of the hierarchy should be at the same level of abstraction 25

Message Passing store marks Student done Program give marks print report done Report 26

Inheritance Furniture Chair Yeoh’s chair Table Ali’s chair 27

Polymorphism run Hare done Program run done Tortoise 28

Basic Terminology: Aggregation z Aggregation describes a “has a” relationship. One object is a part of another object. A car has wheels. z We distinguish between composite aggregation (the composite “owns” the part) and shared aggregation (the part is shared by more then one composite). 29

Basic Terminology: Behaviour and Messages z 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). 30

Relationships z. Association y. Aggregation y. Composition z. Dependency z. Generalization z. Realization 31

Relationships: Association z Models a semantic connection among classes Association Name Professor Works for Association Class University Role Names University Professor Employee Employer 32

Relationships: Aggregation z A special form of association that models a whole-part relationship between an aggregate (the whole) and its parts Whole Part Schedule Student Aggregation 33

Relationships: Composition z A form of aggregation with strong ownership and coincident lifetimes y. The Whole parts cannot survive the whole/aggregate Part Schedule Student Aggregation 34

Association: Multiplicity and Navigation z Multiplicity defines how many objects participate in a relationships y. The number of instances of one class related to ONE instance of the other class y. Specified for each end of the association z Associations and aggregations are bi-directional by default, but it is often desirable to restrict navigation to one direction y. If navigation is restricted, an arrowhead is added to indicate the direction of the navigation 35

Association: Multiplicity z Unspecified z Exactly one z Zero or more (many, unlimited) 1 0. . * * z One or more z Zero or one z Specified range z Multiple, disjoint ranges 1. . * 0. . 1 2. . 4 2, 4. . 6 36

Example: Multiplicity and Navigation Multiplicity Student 1 0. . * Schedule Navigation 37

Relationships: Dependency z A relationship between two model elements where a change in one may cause a change in the other z Non-structural, “using” relationship Class Client Package Client. Package Supplier Dependency relationship Client Supplier. Package Component Supplier Dependency relationship 38

Relationships: Generalization y. A relationship among classes where one class shares the structure and/or behavior of one or more classes z Defines a hierarchy of abstractions in which a subclass inherits from one or more superclasses y. Single inheritance y. Multiple inheritance z Generalization is an “is-a-kind of” relationship 39

z Example: Single Inheritance One class. Ancestor inherits from another Superclass (parent) Account balance name number Withdraw() Create. Statement() Generalization Relationship Checking Subclasses Savings Withdraw() Get. Interest() Withdraw() Descendents 40

Example: Multiple Inheritance z. A class can inherit from several other classes Flying. Thing Animal multiple inheritance Airplane Helicopter Bird Wolf Horse Use multiple inheritance only when needed, and always with caution ! 41

What Gets Inherited? z A subclass inherits parent’s attributes, operations, and relationships z A subclass may: y. Add additional attributes, operations, relationships y. Redefine inherited operations (use caution!) z Common attributes, operations, and/or relationships are shown at the highest z applicable level in the hierarchy Inheritance leverages the similarities among classes 42

Example: What Gets Inherited Ground. Vehicle Superclass (parent) weight license. Number owner 0. . * Person 1 register( ) generalization Subclass Car size Truck Trailer tonnage get. Tax( ) 43

Relationships: Realization z One classifier serves as the contract that the other classifier agrees to carry out z Found between : Interfaces and the classifiers that realize them Class Subsystem Interface Component Interface Elided form y. Use cases and Canonical form the collaborations that realize them Use Case Use-Case Realization 44

The two steps of Object Oriented Programming z. Making Classes: Creating, extending or reusing abstract data types. z. Making Objects interact: Creating objects from abstract data types and defining their relationships. 45

Object Cohesion & Coupling z 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. z 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 z Developed for discrete event simulation (1967) z Simulation modeling is a hard problem for conventional languages z Simulated objects must interact and change state in many different and often unpredictable ways z Simulation can solve problems that are too complex for mathematical equations z Simulation objects are usually easy to identify and communicate via message passing 47

OOPL: Smalltalk z From Xerox PARC, by Alan Kay and Adele Goldberg z Towards a small language for anyone to use on a PC z Influenced by Simula: objects and classes z Influenced The WIMP interface (Windows, Icons, Menu, Pointing device) z Influenced Apple’s design of Lisa and Macintosh 48

OOPL: C++ z From AT&T Bell Labs – invented by Bjorne Stroustru z Adds object-oriented features to C z Classes in C++ correspond to types in C 49

OOPL: Ada 95 z DOD support for embedded systems z Enforces Abstract Data Types (ADTs) y. Data, operations on data, constraints on operations y. E. g. , formal specification languages - Larch, Z, VDM z Support for multitasking and exceptions z Large and complex 50

OOPL: Java y. Like C++ in syntax y. Like Smalltalk in Structure and design y. Without the drawbacks to C++ and Smalltalk x. Frees the programmer from having to manage memory (accidental complexity) x. Small footprint (memory requirement) y. No pointers, pointer arithmetic, structs, typedefs, preprocessor directives (#define), malloc and free y. With extensive type checking, true arrays with array bounds checking, null pointer checking, automatic garbage collection 51

References z“Software Engineering: A Practitioner’s Approach” 5 th Ed. by Roger S. Pressman, Mc-Graw-Hill, 2001 z “Object-Oriented Modeling and Design” by James Rumbaugh et al, Prentice Hall, 1991 z “Object Orientation” by Setrag Khoshafian & Razmik Abnous, John Wiley & Sons, 1995 52