OBJECT ORIENTED ANALYASIS AND DESIGN UNIT -I 1. INTRODUCTION 1. AN OVERVIEW: OBJECT ORIENTED SYSTEM DEVELOPMENT 1.

1 What is Object Oriented System Development?  It refers to all activities that go into producing an information system solution.  It consists of system analysis, modeling, design, implementation, testing and maintenance. 1.2 What is software development methodology?  It is a series of process that, if followed, can lead to the development of an application.  The process describes how the work is carried out.  Each process consists of a number of steps and rules. 1.3 VIEW OF SOFTWARE: Algorithms +Data structures=Programs.    A software system is a set of mechanisms for certain action on certain data. Object Oriented System Development centers on the object, which combine data and functionality.

1.4 OBJECT ORIENTED SYSTEM DEVELOPMENT METHODOLOGY:  This development offers a different model from the traditional software which is based on Functions and Procedures.  Simply it is a way to develop software by building self contained modules or objects.  Object has attributes (data) and methods (functions). For example, Window object is responsible for things like opening, sizing and closing itself. 1.5 Why an Object Orientation? Advantages: The systems are easier to adapt to changing requirements, easier to maintain, more robust and promote greater design and code reuse.

An object orientation     Allows working at a higher level of abstraction. Provides a seamless transition among different phases of software development. Encourages good development practices. Promotes reusability.

1.6 OVERVIEW OF THE UNIFIED APPROACH: UA based on methodologies by Booch, Rumbaugh, Jacobson to combine the best practice, process and guidelines along with object. UML: (Unified Modeling Language) It is a set of notations and conventions used to describe and model an application. UA consists of following concepts: o o o o o o o Use-case driven development. Object Oriented Development. Object Oriented Design. Repository of reusable classes and maximum reuse. The layered approach. Incremental development and prototyping. Continuous testing.

2. INTRODUCTION 2.1 OBJECT BASICS: y y A car is an object. It is real world entity. Identifiably separated from its surroundings. A car has well defined set of attributes or properties (color, manufacture, cost, and owner) and well defined set of thing you normally do with it (drive it, lock it, tow it, and carry passengers in it). It is also called a procedures or methods. 2.2 AN OBJECT ORIENTED PHILOSOPHY:  A fundamental characteristic of object oriented program is that it allows the base concepts of the language to be extended to include ideas and terms closer to those of its application.  The fundamental difference between object oriented system and their traditional counter parts is the way in which you approach problems.  Traditional development methods are either Algorithm centric or Data centric. 1. Algorithm-Centric Methodology: Think of an algorithm that can accomplish the task, and then build data structure for that algorithm to use.
2

2. Data -centric Methodology:  Think how to structure the data, and then build the algorithm around the data.  In the object-oriented system, however the algorithm and data structures are packed together as an object.  The attributes and methods are equal and inseparable parts of the object. 2.3 OBJECTS: The term Object means a combination of data and logic represents some real world entity. For ex, Saab automobile o Saab represents object. o The data part is cars name, color, number of doors, price etc. o The logic part is the collection of programs such that show mileage, stop, go. In an object oriented system every thing is an object. When developing an Object Oriented Application two basics question arise. 1. What Objects does the application need? 2. What functionality should those objects have? For ex, every Window application needs window object. Each object is responsible for itself such that opening, sizing, closing itself. 2.4 OBJECTS ARE GROUPED IN CLASSES: A Class is a set of object s that shares a common structure and common behavior. A single object is simply an instance of a class. In an object oriented system a method or behavior of an object is defined by its class. Each object is an instance of a class. Each employee object is responsible for its own data such as number, address, salary, etc,
Employee Class

Sue Objects of class Employee Bill Ali Hal David FIGURE 2.1 Sue, Bill, Ali are instances or Objects of class Employee
3

2.5 ATTRIBUTES: OBJECT STATE AND PROPERTIES:  Properties represent the state of an object.
Fig2.2 The attributes of a car object: Car
Cost Color Model

   

We could represent each property in several ways. Cost-dollar ,rupees Color red ,Number of red paint Make-manufacture name, model number

2.6 OBJECT BEHAVIOR AND METHODS:     In the object model, object behavior is described in methods or procedures. Car-> We normally do with it (drive it, lock it) Elephant -> It can do on its own (eat a banana, etc..) Behavior-> collection of methods.

2.7 OBJECT RESPOND TO MESSAGES: o However, to do an operation, a message is sent to an object. o Object performs operations in response to messages. o For example, when you press on the break pedal of a car, you send a stop message to the car object. o The car object knows how to respond to the stop message. o Breaks have been designed with specialized parts. MESSAGES:    Its essentially a nonspecific function calls. A message is a different from of subroutine call, since different object can respond to the same message in different ways. For example, car , motorcycle, bicycle all are respond to stop message, but actual operations performed are object specific.

Fig 2.3 Object responsible to messages: Car object Brake

5 object

*7

Employee object

Compute payroll

 Methods are similar to functions, procedures or subroutines.  To draw chart  Draw -> message  Draw chart or draw line or draw circle -> chart, line, and circle is different object.  Each object could act differently  It is important to understand the difference between methods and messages.  For example, you want to tell to make you tomato soup.  Instruction is message.  Way of preparation is method.  Tomato soup is an object  In other words, message is the instruction and method is the implementation. 2.8 ENCAPSULATION AND INFORMATION HIDING:  The wrapping up of data and functions in to a single unit is known as encapsulation.  Encapsulation protection mechanism, with public, private and protected members. y Public members accessed from anywhere. y Private members access within a class. y Protected members can be accessed only from subclass.  An object is said to encapsulate the data and program.  This means the user cannot see the inside of the object capsule, but can use the object by calling the objects methods.    An important factor in achieving encapsulation, using common protocol. Example: A car engine. Although engines may differ in implementation. The interface between the driver and the car is through common protocol. y Step on the gas to increase power or star the car. y Let up on the gas to decrease power. Since all drivers know this protocol. All drivers can use this method in all cars, no matter what engine is in the car.

 

2.9 CLASS HIERARCHY: Object oriented system organizes classes in to subclass-super class hierarchy.
Motor Vehicle

Bus

Truck

Car

Bus

Air bus

Omni 8 wheeler

car

sports car

Fig: 2.4 Class Hierarchy

5

A subclass inherits all the properties and methods defined in its super class.     Motor vehicle-> super class Bus, Truck, Car-> subclass Consider the Bus. Bus is- super class. Air bus, passenger bus Sub class. Sub class modifies the attributes of its super class car.

Fig: 2.5 Class hierarchy for ford class:

Vehicle

Car

Ford

Mustang

Taurus

Thunder bird

 The Mustang class defines the behaviors of mustang.  The Ford class defines the behaviors of Ford. The term Super class-> base class. The term sub class-> derived class. 2.9.1 INHERITANCE Inheritance is a relationship between different classes which share common characteristics. If class B inherits class A, then both the operations and information structure in class A will become part of class B Major benefits are simpler, clearer classes, at higher levels of abstraction Employee, Managing, Director, Truck, Driver "is an", "inherits from" Generalization means extracting common properties from a collection of classes and placing them higher in the inheritance hierarchy, in a super class. Much care has to be taken when generalizing (as in the real world) that the property makes sense for every single subclass of the super class. If this is not the case the property must not be generalized. Inheritance:  It allows objects to be built from other objects. (Objects of one class acquire the properties of object of another class).  Inheritance is a relationship between classes where one class is the parent class or super class or base class. Another one is the derived class.  Inheritance allows classes to share and reuse behaviors and attributes.
6

 It allows reusability. For ex, The car class defines the general behavior of the car.  The ford class inherits the general behavior and adds specific behaviors.
Vehicle

Car
I know how to stop

Ford
Stop method is reusable

Mustang

Taurus

Thunder bird

Fig: 2.6 Inheritance allows Reusability

Stop (my Mustang)

Assume, all ford use same breaking system, behaviors share. However the stop method is not defined in the Mustang class, its invoked from ford Class. But, Thunder bird has its own antilock breaking system. This class would redefine the stop method so, the stop method of the ford class never be invoked. Types of Inheritance: 1. Dynamic Inheritance. 2. Multiple Inheritance. 2.9.1 Dynamic Inheritance:    It allows objects to change and evolve over time. Since base classes provide properties and attributes for objects, changing base classes changes the properties and attributes of a class. It refers to the ability to add, delete or change parents from objects at run time.

2.9.2 Multiple Inheritance: It permits a class to inherit its state and behaviors from more than one super class.
Motor Vehicle

Truck

Car

Bus

7 Utility Vehicle

Fig: 2.7 Utility vehicles inherit attributes from both the car and truck classes. 2.10 POLYMORPHISM:      Poly means many. Morph means Form. In the OO- System, it means objects that can take on or assume many different forms. It means that the same operation may behave differently on different classes. For ex, The driving is a behavior perform with all cars, the specific behavior can be different, depending on the kind of car we are driving. Polymorphism allows writing generic, reusable code more easily. For ex, In a payroll system, Manager, production worker, office worker objects all will respond to compute payroll message, but the actual operation performed are object specific.

2.11OBJECT RELATIONSHIPS AND ASSOCIATION: o Associations represent the relationship between objects and classes. For ex, A pilot can fly planes
Pilot

Can fly

flown by

Planes

o Associations are bidirectional. It can traverse in both directions. o An important issue in association is cardinality. This specifies how many instances of one class may relate to a single instance of an associated class. Ex: client-Account relationship where one client can have one or more accounts.

2.11.1 CONSUMER-PRODUCER ASSOCIATION:      Its a special form of association. Also known as a client server association or a use relationship. It can be viewed as one way interaction. One object requests the service of another object. The object makes the request is the customer (or) Client, and object receives the request and provides the service is the producer or server.
Print Server

Request for Printing

Item

Fig: 2.9 The Consumer-Producer Association

2.12 AGGREGATION AND OBJECT CONTAINMENT  All objects are composed of and may contain other objects.  For ex, (i) Spread sheet is an object composed of cells. (ii) Cells are objects that may contain text, mathematical Formulas, video, etc.,
8

 Breaking down objects into the objects from which they are composed is called Decomposed.  Object attributes need not be simple data fields.  Attributes can reference other objects. This is known as Aggregation, Where an attribute can be an object itself. Example:
Car

Engine

Seat

Wheel

Fig: 2.10 A car is an aggregation of other objects such as engine, seat and wheel objects. 2.13 CASE STUDY- PAYROLL PROGRAM It process employees records. It consists of several classes of employees with particular payroll requirements and rules for processing each. This company has three types of employees: 1. Managers receive a regular salary. 2. Office workers receive an hourly wage and are eligible for overtime after 40 hours. 3. Production Workers are paid according to apiece rate. 2.13.1 Structured Approach: (Refer Book) 2.13.2 The Object Oriented Approach: The Object Oriented System development consists of      Object Oriented Analysis Object Oriented Information Modeling Object Oriented Design Implementation Testing, Iteration, Documentation

Each object is entirely responsible for itself. For ex., Employee object is responsible for things like, computing payroll, printing paychecks, storing data.    First task in the Object Oriented analysis to find the class of objects. To identify the attributes of objects. To identify the behavior.
9

Fig 2.11 Class Hierarchy:

Employee Name Address Salary

Office Worker

Manager
Data Entry Compute Payroll Print Report

Production Worker

Data Entry Compute Payroll Print Report

Data Entry Compute Payroll Print Report

2.14 ADVANCED TOPICS: 2.14.1 Object and Identity:       It is a special feature. Every object its own unique identity. This identity is never confused with another object. This identity name never change even if all the properties of the object change Object identity is implemented through some kind of object identifier (OID) or Unique identifier(UID) OIDs never reused.
Person Instance (object) Name: Raj Age: 30 Owns

Car Instance (object) Make: Saab Color: red Model:90os Owner

Fig 2.12 The owner property of a car contains a reference to the person instance named Raj.  In the object system, the relationship between the car and Raj can be implemented and maintained by references. A reference is similar to the Pointer in other programming languages.  Object references directly denote the object to which they refer.  Owner is the property of car Instance, referred to the person instance.  Owns is the property of person instance, referred to a car instance.

2.14.2 STATIC AND DYNAMIC BINDING:  Binding refers to the linking of a procedure call to the code to be executed in response to the call.  The process of determining at run time which function to invoke is termed Dynamic binding.
10

 It occurs when polymorphic call issued.  Making this determination earlier, at compile time is called static binding. It optimizes the calls.
Shape Draw ()

Circle Object Draw (circle)

Box Object Draw (box)

Triangle Object Draw (Triangle)

Draw ( ) ->Procedure Call 2.14.3 Object Persistence:  Objects have a life time.  A file or database can provide support for objects having a longer life time longer than a duration of the process for which they were created.  This Characteristic is called Object persistence. 2.14.4 Meta Classes:  In the O-O-System everything is an object. Numbers ,array, records, fields, file, form etc.  A class belongs to a class called meta class (or) Class of Classes.  All objects are instances of a class and all classes are instances of Meta class.

OBJECT ORIENTED SYSTEM DEVELOPMENT LIFE CYCLE: 3.1 INTRODUCTION:  Software development process consists of analysis, design, implementation, testing and refinement is to transform user needs in to software solution.  The emphasis is intended to promote the building of high quality software. 3.2 SOFTWARE DEVELOPMENT PROCESS:  System development can be viewed as a process.  The development itself, is a process of change, refinement, transformation or addition to the existing product.

11

 With in the process, its possible to replace one sub process with in a new one.  With this method of change, its possible to adapt a new process. The process can be divide in to small,  Interacting phases called Sub process.  The sub process must be clear and defined.  Sub process must have the following:  A description in term of how it works.  Specification of the input required for the process.  Specification of the output to be produced.  The software development process also can be divided in to smaller, interacting sub process.  The software development process can be viewed as a series of transformation.  The output of the transformation becomes the input of the subsequent transformation.

What are the uses of the system?

Transformation 1 Problem

Statement Analysis

Transformation 2
Design Implementation Detail System Software Product

Transformation 3

TRANSFORMATION 1(ANALYSIS):   It translates the user needs into system requirements and responsibilities. They use the system can provide insight into users requirements.

TRANSFORMATION 2(DESIGN):    Begins with a problem statement and ends with a detailed design. This transformation includes bulk of the software development activity ,how to build the software, Its development and its testing. Also include design description, program, testing materials.

TRANSFORMATION 3(IMPLEMENTATION):     It refines the detailed design into the system development that will satisfy the users needs. This takes in to account the equipment, procedure and people. For ex, the new compensation method is programmed, new forms are put to use and new reports can be printed. An example of the Software development process is the Water fall approach.

12

THE WATER FALL SOFTWARE DEVELOPMENT PROCESS:

What How Do It Test Use

(i) What is to be done? (What is the problem) (ii) How to accomplish them? (iii) Which we do it? (iv) Must test the result? (v) Finally we use.  The Water fall model is the best way to manage a project with a well understood product.  Its based on well established engineering principles. DISADVANTAGES:  In the real world, the problems are not always well defined.  For example, if a company has experience in building accounting systems, then building accounting systems, then building another such product based on the existing design is the best managed with water fall model, as it has been described.  Where there is uncertainty regarding, what is required or how it can be built, the water fall model fails. ADVANTAGES: It is a best way to manage a project with a well understood product. Its based on well established engineering principles. However ,its failure can be traced its inability to accommodate Softwares special properties, and its inappropriateness for resolving partially understood issues.  In neither emphasis nor encourage software reusability. 3.3 BUILDING HIGH QUALITY SOFTWARE:  The software process transforms the user needs via application domain to a software solution that satisfies those needs.  Once the system exists, we must test its a free of bugs.  High quality products must meet users and expectations.  The ultimate goal of building high quality software is user satisfaction.    

13

To achieve high quality in software we need to answer the following. y y y How do we determine when the system is ready for delivery? Is it an operation system that satisfies users need? Does it pass an evaluation process?

There are 2 basic approaches to system testing. 1. How it has been built. 2. What it should do. In Blum describes system evaluation in terms of four quality Measures 1. 2. 3. 4. Correspondence Correctness Verification Validation Validation Verification

Fig: 3.3 Quality Measures:

Needs

Requirements

Design

Software

Correctness

Correspondence CORRESPONDENCE: Measure how well the delivered system matches the needs of the operational environment as described in original requirement statement. VALIDATION: It is the task of predicting correspondence. It begins as soon as project starts. CORRECTNESS: Measures the consistency of the product requirements with respect to the design specifications. VERIFICATION: It is the exercise of determining the correctness. Verification & Validation answer to the following questions: Verification: Am I building the product right? Validation: Am I building the right product?
14

y y y

Validation begins as soon as the project starts. But verification can begin only after a specification has been accepted. Both are independent of each other.

3.4 OBJECT ORIENTED SYSTEM DEVELOPMENT: A USE-CASE DRIVEN APPROACH: The object oriented software development life cycle (SDLC) consists of three macro process. 1. Object Oriented Analysis 2. Object Oriented Design 3. Object Oriented Implementation The use case model can be employed throughout most activities of software development.

Build a Use-Case Model

Object Analysis

Analysis Ana
Using Tools CASE &/ OO Programming Languages

Analysis

Validate /Test

User Satisfaction Usability & QA Test

Design Classes, Define Attributes & Methods

Build Object & Dynamic Model

Build User Interface & Prototype

IIIiiiii

Implementation Design

User Satisfaction Test, Usability Test & QA Test

Fig 3.4: The OOSD Approach.

JACOBSON LIFE CYCLE MODEL: Use Case Model OOOooo

OOA: Identify Actors OOA: Use Case Model OOA: Course of Action

Dynamic Model
Object Interaction Diagram, etc .

OOA: Object Model

OOD: Dynamic Model Design Classes

Testing: Usage Scenarios

15

 In the lifecycle model of Jacobson , one can produce design that are traceable across requirements, Analysis , design, and implementation and testing.  The main advantage is that , all design decisions can be traced back directly to user requirements.  Usage scenarios can be come test scenarios.  In the Object Oriented System development includes these activities. 1. Object Oriented Analysis- Use Case Driven 2. Object Oriented Design 3. Prototyping. 4. Component Based Development 5. Incremental Testing. 3.4.1 OBJECT ORIENTED ANALYSIS- USE-CASE DRIVEN: Use Case: A description of the set of sequences of actions, including variants, that a system performs that yield an observable result of value to an actor. Use Case Driven: In the Software development life cycle a process, in which use cases are used and establish desired behavior of the system, for verify, validate the system architecture for testing and for communicating among the stakeholders of the project.  It is concerned with determining the system requirements and their relationships to other classes in problem domain.  To understand the system requirements, we need to identify the users or the actors.  Who are the actors and how do they use the system?  In the object oriented analysis, scenarios are used to help analysts to understand the requirements.  In the Jacobson concept of the use case, his name for a scenario to describe the user computer system interaction. Eg: Application domain might be a payroll system.

Tangible Object Pay Check Employee Worker Supervisor Office administrator

Intangible object Tables Data Entry Data Structures

16

   

Documentation is another activity. 80-20 rule generally applies for the documentation. Documentation and modeling are not separate activities. Good modeling implies good documentation.

3.4.2 OBJECT ORIENTED DESIGN:  The goal is to design the classes identified during the analysis phase and the user interface.  During this phase, we identify and define additional objects and classes that support the implementation of the requirements.  Eg: During the design phase, need to add objects for the user interface (E.G data entry windows & Browse windows).  Object Oriented Design & Object Oriented Analysis is distinct disciplines. But they can intertwine.  Activities are also intertwined.  In the Object Oriented Development 1. You start with Object Oriented Analysis. 2. Model it. 3. Create an Object Oriented Design. 4. Then do some more of each. 5. Refining? & completing the models of the system. First build the object model based on objects, then iterate and refine the model.      Design & Refine classes. Design & Refine attributes Design & Refine methods. Design & Refine structures. Design & Refine associations.

Four guidelines to use Object Oriented Design: 1. Reuse- Rather than build a new class. 2. Design a large number of simple classes rather than a small number of complex classes. 3. Design methods. 4. Critique what you have proposed. If possible go back & refine the classes. 3.4.3 PROTOTYPING:  It is a version of the software product development in early stage of the product life cycle.  It provides the developer to test and refine the user interface.  Increases the usability of the system.

17

1. Horizontal Prototyping: y Prototyping provides the developer a means to test and refine the user interface and increase the usability of the system. y It is a simulation of the interface. y Contains no functionality. y Very quick to implement. 2. vertical Prototype: y It is a subset of system features with complete functionality. y Advantage: Implemented function can be tested in great depth. 3. Analysis Prototype: y It is an aid for exploring the problem domain. y It is used to inform the user and demonstrate the proof of a concept. 4. Domain Prototype: y y y It is an aid for the incremental development of the ultimate software solution. Prototyping is a useful exercise at almost any stage of the development. Prototyping should be done in parallel with preparation of functional specification.

3.4.4 IMPLEMENTATION: Component Based Development:    The s/w components are built and tested, using a wide range of techniques. For Eg: Computer Aided Software Engineering (CASE) tools allow their users to rapidly develop the information system goal of CASE. CASE : Develop the system development life cycle using a set of interrelated s/w tools (such as modeling ,methodology, automatic code generation) CASE tools give the skeleton of applications. New generations of CASE tools support Component Based Development (CBD) It is an industrial approach to the s/w development process. Application development moves from custom development to assembly of prebuilt, pretested reusable s/w components that operate with each other.

  CBD:  

Two basic ideas underlie CBD: 1. The application development can be improved significantly; applications can be assembled quickly from prefabricated s/w components. 2. Increasingly large collection of s/w components made available to the developer in both general and specialized catalogs.
18

o A CBD Developer can assemble components to construct a complete s/w system. o Component themselves may be constructed from other components. o The CBS is more efficient and less development effort. o Most Legacy-complex. o The CBD approach to legacy integration involves application wrapping, in particular wrapping technology.
Component Wrapper Component Wrapper

Legacy Program

Legacy Data

Open Connectivity
Component Wrapper

Component Wrapper

Legacy Screens

Legacy software Package

Fig : 3.6 Reusing legacy system via component wrapping technology. Software Components: y y y y Software components are the functional units of a program, building blocks. A software component can request a service from another component or deliver its own service. In short the object oriented concept addresses analysis, design, and programming. The component based development (CBD) is concerned with implementation and system integration.

Rapid Application Development (RAD): y y y y It is a set of tools and technology that can be used to build an application faster than traditional methods. It is often used in conjunction with software prototyping. RAD ->quick delivery. But quality is good. RAD -> does not replace the system development life cycle, but complements it.

Task of RAD: 1. 2. Build application quickly. Incrementally implement the design and user requirements, through tools (VB).

19

Main objectives: y y y y y y To build a version of an application rapidly. It involves a number of iteration. Each iteration we might understand the problem, a little better. RAD encourages the incremental development approach of grow, do not build software. Prototyping and RAD do not replace the object oriented software development model. Instead in a RAD, you go through in rapid in the next iteration of prototype.

3.4.5 INCREMENTAL TESTING:  The developer would turn over applications to a quality assurance (QA) group for testing only after development was completed.  QA group not included in the initial plan. 3.5 REUSABILITY:   The major benefit in object oriented system is reusability. The potential benefits of reuse are, 1. Increased Reliability. 2. Reduce Time. 3. Reduce cost for development. 4. Improved Consistency. You must effectively evaluate existing software components for reuse by ask questions, 1. Has my problem already been solved? 2. Has my problem been partially solved? 3. What has been done before to solve a problem similar to this one? So we need detailed summary information about existing software components. The reuse strategy can be based on following: 1. Information Hiding 2. Performance to naming standards. 3. Creation and administration of an object repository. 4. Establishing targets for a percentage of the objects, in the project to be reused.

-------------------------------------------------------------------------------------------------------------20

GENERALISATION & SPECIALISATION

21

Generalisation Creation of an 'ancestor' Creation of a 'descendant' City University, School of Informatics, Object-Oriented Analysis & Design 2- 23 Ambigouities can arise through multiple inheritance as in the examples above. The simplest form of these ambiguities are name clashes as displayed on the left hand side of the slide. A name clash arises when the subclass inherits two properties (irregardless whether attribute,

relationship or operation) with the same name from two independent branches. If instances of that class receive a message identifying that property it is then ambigous whether they should react according to the definition in the left or the right superclass. A more subtle form of ambiguity that may arise through multiple inheritance is an incorrect repeated inheritance as displayed on the right hand side. Here an ambiguity arises because a property that has been repeatedly inherited via two branches from a common superclass is redefined, i.e. given a new semantics, in one branch. Then it becomes ambigous whether the original declaration of the property is valid in the subclass or the property that has been redefined in one branch. The problem with these name clashes is that they very often cannot be rectified at their origin as the classes to be re-used often cannot be changed. Then renaming concepts are used to rectify them. If these ancestors themselves have no common ancestor, names have to be changed or one definition chosen. If these ancestors themselves

22

have a common ancestor, then it is also necessary to ensure than no redefintions have taken place higher in the hierarchy, thus effectively demanding a choice of definition. Detection of such circumstances is a major issue. The final concept to be explained is polymorphism...
OOAD Introduction 2. 23

AMBIGUITIES THROUGH MULTIPLE INHERITANCE

23

24