Object-Oriented Programming Approaches

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

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

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

4. 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 What is Object Oriented Programming?

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

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 Problem Object-Oriented Concepts Object-Oriented Analysis ADT Object-Oriented Design Inheritance Object-Oriented Programming Identity Solution

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 domain • Typically a producer or consumer of information item in computer system • An object consists of attributes and operations • Attributes - data structures/elements • Operations - 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 300 Dimensions : 1X1X2 Weight: 1kg Location: (2,2,3) Color: black Move Buy Sell Weigh

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

18. Typical objects (Continued) • Organisational unitsthat 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 Cost Dimensions Weight Location Colour Move Buy Sell Weigh

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

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

25. Increasing abstraction Decreasing abstraction What is Hierarchy? Asset • Levels of abstraction Security RealEstate BankAccount Savings Checking Stock Bond Elements at the same level of the hierarchy should be at the same level of abstraction

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

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

28. Polymorphism Hare run done Program run done Tortoise

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

31. Relationships • Association • Aggregation • Composition • Dependency • Generalization • Realization

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

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

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

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

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

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

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

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

40. Account balance name number Withdraw() CreateStatement() Savings Checking GetInterest() Withdraw() Withdraw() Example: Single Inheritance Ancestor • One class inherits from another Superclass (parent) Generalization Relationship Subclasses Descendents

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

42. What Gets Inherited? • A subclass inherits its parent’s attributes, operations, and relationships • A 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 hierarchy Inheritance leverages the similarities among classes

43. Person Trailer Example: What Gets Inherited GroundVehicle owner weight Superclass (parent) 0..* 1 licenseNumber register( ) generalization Truck Car size Subclass tonnage getTax( )

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

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.

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

47. OOPL: Simula • Developed for discrete event simulation (1967) • Simulation modeling is a hard problem for conventional languages • Simulated 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

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

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

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