1 Generalizations Multiple Inheritance Polymorphism Class Design – Another Look – Part 11.

1

GeneralizationsMultiple Inheritance

Polymorphism

Class Design – Another Look – Part 11

2

Class Design Steps

Create Initial Design Classes Identify Persistent Classes … Define Dependencies Define Associations Define Generalizations

In analysis, inheritance that was inherent to the problem domain may have been defined.

Class Design is where generalizations are defined to improve/ease the implementation.

Design is the real activity of inventing inheritance. Resolve Use-Case Collisions Handle Non-Functional Requirements in General Checkpoints

3

Generalization

Is a notational convenience allows us to define common

structure and behavior in one place and re-use it where we find repeated behavior and structure.

Makes ‘change’ and ‘maintenance’ easier: Extracts common properties into

classes of their own

4

Define Generalizations Purpose

Identify areas of reuse Refine existing inheritance hierarchies so that

they can be implemented efficiently Things to look for:

Abstract classes vs. concrete classes Multiple inheritance problems Generalization vs. Aggregation Generalization to support implementation reuse Generalization to support polymorphism Generalization to support metamorphosis Generalization simulation

5

Review: Generalization Is a ‘relationship where one class shares the structure

and/or behavior of one or more classes “Is-a-kind of” relationship

Should always be able to say that your generalized class ‘is a kind of’ parent class.

Can us terms ‘ancestor’ and ‘descendent’ instead of super-class and subclass.

In analysis, used sparingly to model shared behavioral semantics only (generalization that passes the ‘is a’ test). Generalization to promote

and support reuse is determined In Design.

Account

balancenamenumber

Withdraw()CreateStatement()

Checking Savings

GetInterest()

Superclass (parent)

Subclasses

Generalization Relationship

descendents

ancestor

6

Generalization in Analysis and in Design

In analysis, the generalization should be used to reflect shared definitions/semantics and promote “brevity of expression”

(i.e., the use of generalization makes the definitions of the abstractions easier to document and understand).

When generalization is found, a common super-class is created to contain the common attributes, associations, aggregations, and operations.

Common behavior is removed from the classes which become sub-classes of the common super-class.

A generalization relationship is drawn from the sub-class to the super-class

7

Lion

talk ()

Tiger

talk ()

Animal

{abstract}

talk () {abstract}

There are no direct instances of Animal

All objects are either lions or tigers

Abstract class

Abstract operation

Communication

Discriminator

Abstract and Concrete Classes Abstract classes cannot have any objects

Exist only for other classes to inherit from it Concrete classes are used to instantiate

objects

An operation can also be tagged as abstract. Meaning: no implementation exists for the op in the class where it is specified.

(A class that contains at least one abstract operation must be an abstract class.)

8

Lion

talk ()

Tiger

talk ()

Animal

{abstract}

talk () {abstract}

All objects are either lions or tigers

Abstract class

Abstract operation

Communication

Discriminator

Inheritance and implementation Classes inheriting from abstract classes must

provide implementation for the abstract operations, or the operations are considered abstract in subclass; the subclass is considered abstract, as well.

Concrete classes have implementations for all operations.

In UML, we designate as abstract w/tag {abstract}For abstract operations, {abstract} is as indicated.Can indicate abstract item in italics.

A discriminator can be used to indicate on what basis the generalization / specialization occurred.

Discriminator describes a characteristic that differs in each of the subclasses. Here: ‘communication’

9

Airplane Helicopter Wolf Horse

FlyingThing Animal

Bird

multipleinheritance

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

Multiple Inheritance – inheriting from more than one class.

Bird inherits from Flying Thing and Animal Conceptually simple; necessary for modeling real world accurately.

Potentially, implementation problems. Not all languages support it. This representation will probably need adjustment in design and

implementation. Generally, a class inherits from only one class.

10

Name clashes on attributes or operations

Repeated inheritance

FlyingThing

color

getColor

Animal

color

getColor

Bird

FlyingThing Animal

Bird

AnimateObjectcolor

Multiple Inheritance: Problems in Design and Implementation.

Resolution of these problems is implementation-dependent

In general, multiple inheritance causes problems if any of the multiple parents has structure or behavior that overlaps.If the class inherits from several classes, you must check how the relationships, operations, and attributes are named in the ancestors.

11

Name clashes on attributes or operations

Repeated inheritance

FlyingThing

color

getColor

Animal

color

getColor

Bird

FlyingThing Animal

Bird

AnimateObjectcolor

Multiple Inheritance: Problems in Design and Implementation.

Two issues associated with multiple inheritance:1. Name collisions: both ancestors have attributes / ops with same name.If same name appears in several ancestors, you must describe what this means to thespecific inheriting class, e.g., by qualifying the name to indicate source of declaration.2. Repeated inheritance: Same ancestor is being inherited by a descendant more once. When it occurs, the inheritance hierarchy will have a ‘diamond shape’ (above) Descendents end up with multiple copies of an ancestor.

12

A bit more on multiple inheritance

If you are using repeated inheritance, you must have a clear definition of its semantics; in most cases this is defined by the programming language supporting the multiple inheritance.

In general, the programming language rules governing multiple inheritance are complex, and often difficult to use correctly. Use multiple inheritance only when

needed, and always with caution. Delegation: Use delegation as a

workaround to multiple inheritance problems. (ahead)

13

Four Standard Generalization Constraints Complete

End of the inheritance tree All children in the generalization

relationship have been defined in the model.

No more children can be defined. The leaves of the inheritance hierarchy

cannot be specialized any further. Use the complete constraint to explicitly

note that the generalization hierarchy has not been fully specified in the model.

14

Four Standard Generalization Constraints Incomplete

Inheritance tree may be extended All children in the generalization

relationship have not been defined in the model.

More children may be defined. Leaves in the hierarchy may be

specialized. Use this constraint to explicitly note that

the generalization hierarchy has not been fully specified in the model.

15

Four Standard Generalization Constraints These only apply in the context of multiple

inheritance: Disjoint

An object of the parent cannot have more than of the children as its type.

Subclasses mutually exclusive Disjoint is used to support the modeling of static classification,

where an object cannot change its type at run-time. Doesn’t support multiple inheritance

Overlapping An object of the parent may have more than of the children as

its type. Overlapping is used to support the modeling of dynamic

classification, where an object can change its type at run-time. It shows the potential types of an object. Subclasses are not mutually exclusive Supports multiple inheritance

16

Example: Generalization Constraints

Asset

RealEstate

Bank Account

Security

Saving Checking Stock Bond

{disjoint}

{disjoint,complete}{disjoint}

End of inheritance hierarchy

Multiple inheritance not supported

Complete: The Saving and Checking classes cannot be specialized (a generalization relationship cannot be defined in which they are the parent). These classes (and siblings) mark the end of the inheritance hierarchy.Disjoint: A BankAccount object cannot be both a Saving and a Checking account (i.e., no multiple inheritance where parents in the multiple inheritance are the children of BankAccount).

17

Example: Generalization Constraints (cont.)

Vehicle

WaterVehicle

LandVehicle

Amphibious Vehicle

{overlapping}

Multiple inheritance supported

This example demonstrates the use of overlapping constraint. The AmphibiousVehicle class can inhierit from both LandVehicle and WaterVehicle, which both inherit from Vehicle.

18

Window

WindowWithScrollbar

ScrollbarIs this a correct use of generalization? If not, what would be a better way to model the info which maintains generalization “is-a” semantics?

Generalization vs. Aggregation

Generalization and aggregation are often confused Generalization represents an “is-a” or

“kind-of” relationship; one object. Aggregation represents a “part-of”

relationship Relates multiple objects;

19

Scrollbar

Window

WindowWithScrollbar11

Window

WindowWithScrollbar

Scrollbar

A WindowWithScrollbar “is a” WindowA WindowWithScrollbar “contains a” Scrollbar

Generalization vs. Aggregation

20

Generalization Uses: Generalization can be used to support

multiple goals: Some are: Share Common Properties and

Behavior Share Implementation Implement Polymorphism Implement Metamorphosis

Will look at each of these uses of generalization ahead…

21

Project Guidelines for using Generalization.

A project should have guidelines for determining the good use of generalization. The best class approach is to articulate the various styles of generalization.

These goals/uses can be used to help define these different styles, as well as assist in identifying where generalization can be used in the model.

Take care to keep the use of generalization understandable. At the very least you should know the purpose of each

22

Generalization Uses

Share Common Properties and Behavior This is the first use of generalization that

we have been talking about to this point. Share Implementation Implement Polymorphism Implement Metamorphosis

23

List

insertTop (Item)insertBottom (Item)removeTop ()removeBottom ()insert (Item, position)

Stack

Animal

talk ()

Lion Tiger

talk () talk ()

Do these classes follow the IS-A style of programming?

Generalization: Share Common Properties and Behavior

Follows the Is-A style of programming Class substitutability

A subtype is a type of relationship expressed with inheritance.A subtype specifies that the descendent is a type of the ancestor and must follow the rules of the Is-A style of programming.

24

List


Stack

Animal

talk ()

Lion Tiger

talk () talk ()

Do these classes follow the IS-A style of programming?

Generalization: Share Common Properties and Behavior

The Is-A style of programming states that the descendent is-a type of the ancestor and can fill in for all its ancestors in any situation.

The Is-A style passes the Liskov Substitution Principle: “If for each object O1 of type S there is an object O2 of type T such that for all programs P defined in terms of T, the behavior of P is unchanged when O1 is substituted for O2 then S is a subtype of T.”

SO???

25

Animal

talk ()

Lion Tiger

talk () talk ()

Generalization: Share Common Properties and Behavior (contd)

List


Stack

The classes on the left-hand side of the diagram do follow the is-a style of programming: a Lion is-an Animal and a Tiger is-an animal.The classes on the right-hand side of the diagram do NOT follow the Is-A style of programming: a Stack is not a List. A Stack needs some of the behavior of a List but not all of the behavior. If a method expects a List, then the operation insert(position) should be successful. If the method is passed a Stack, then the insert(position) will fail.

26

Generalization Uses

Share Common Properties and Behavior

Share Implementation This use of generalization is where there

are some services or structure provided by a class that you want to leverage in the implementation of another class.

Implement Polymorphism Implement Metamorphosis

27

List

insertBottom (Item)removeBottom ()insert (Item, position)

Stack

SequentialContainer

insertTop (Item)removeTop ()

List


Stack

Generalization: Share Implementation-Factoring Factoring is useful if there are some services provided

by one class that you want to leverage in the implementation of another class.

When you factor, extract the functionality you want to reuse and inherit it from the new base class.

Supports the reuse of the implementation of another class

Cannot be used if class you want to “reuse” cannot be changed

28

List

insertBottom (item)removeBottom ()insert (Item, position) remove (position)

Stack

push (Item)pop (): Item 11

ListinsertTop (Item)insertBottom (Item)removeTop ()removeBottom ()insert (Item, position)

Stack

Generalization Alternative: Share Implementation: Delegation (1 of 2)

Supports the reuse of the implementation of another class. Use a composition relationship to reuse desired functionality

Can be used if the class you want to “reuse” cannot be changed. All operations that require the “reused” service are ‘passed through’ to the contained class instance.

29

List

insertBottom (item)

removeBottom ()insert (Item, position)

remove (position)Stack

push (Item)pop (): Item 11

ListinsertTop (Item)insertBottom (Item)removeTop ()removeBottom ()insert (Item, position)

Stack

Generalization Alternative: Share Implementation: Delegation (2 of 2)

With delegation, you lose the benefit of polymorphic behavior, but you do have a model that more clearly expresses the nature of the domain (being that its NOT is-a)

This is commonly used by mix-ins. Implementing mix-ins with composition permits run-time binding to objects rather than compile time binding enforced by inheritance.

Note: You can also use delegation as a workaround to multiple inheritance problems discussed earlier. Have the subclass inherit from one of the super classes, and then use aggregation from the subclass to access the structure and behaviors of the other classes.

30

List

insertBottom (Item)removeBottom ()insert (Item, position)remove (position)insertTop (Item)

Stack

push (Item)pop ()

<<implementation>>

Sharing Implementation: Implementation InheritanceThe use of an <<implementation>> stereotype can be used to

model implementation inheritance. Implementation inheritance is where the implementation of

a specific element is inherited/reused. Implementation inheritance often leads to illogical inheritance hierarchies that are difficult to understand and to maintain.

Thus it is not recommended that you use inheritance only for implementation reuse, unless something else is recommendedin using your programming language.

Maintenance of this kind of reuse is usually quite tricky. In the example, any change in the class List can imply large changes of all classes inheriting the class List. Beware of this and inherit only stable classes.Inheritance will actually freeze the implementation of the classList, because changes to it are too expensive.

31

List

insertBottom (Item)removeBottom ()insert (Item, position)remove (position)insertTop (Item)

Stack

push (Item)pop ()

push() and pop() can access methods of List but instances of Stack cannot

<<implementation>>

Sharing Implementation: Implementation Inheritance

Ancestor public operations, attributes and relationships are NOT visible to clients of descendent class instances

Descendent class must define all access to ancestor operations, attributes, and relationships

32

Generalization Uses


Share Implementation Implement Polymorphism

Generalization can also be used to implement polymorphism.

In the Architectural Design module, we discussed how interfaces directly implement polymorphism

Here, we will discuss how generalization can also be used to implement polymorphism.

Implement Metamorphosis

33

Manufacturer AManufacturer B Manufacturer C

OO Principle:Encapsulation

Review: What is Polymorphism? The ability to hide many different implementations

behind a single interface

Polymorphism was introduced in the Intro to OO module. This is a review slide.Comes from Greek: poly – many; morph – forms.Every implementation of the interface must implement at least the interface.The implementation can in some cases implement more than the interface.

34

Generalization: Implement Polymorphism

Without Polymorphism

With Polymorphism

Animal

talk ()

Lion Tiger

talk () talk ()

if animal = “Lion” thendo the Lion talk

else if animal = “Tiger” thendo the Tiger talk

end

do the Animal talk

•Inheritance provides a way to implement polymorphism in cases where poly is implemented the same way for a set of classes.•This means that abstract base classes that simply declareinherited operations, but which have no implementationsof the operations, can be replaced with interfaces.•Inheritance now can be (but need not be)restricted to inheritance of implementations only.

•Polymorphism is not generalization; generalization is one way to implement polymorphism.• Poly via generalization is the ability to define alternate methods for operations of the ancestor class in the descendent classes.• This can reduce the amount of code to be written, and help abstract the interface to descendent classes.•Poly is an advantage of inheritance realized during implementation and at run-time. (Environments use dynamic binding, meaning that the actual code to execute is determined at run-time vs. compile time.

35

Polymorphism: Use of Interfaces vs. Generalization (i.e., abstract base classes)

Interfaces allow us to define poly in a declarative way, unrelated to implementation. Two elements are polymorphic with respect to a set

of behaviors if they realize the same interfaces. Interfaces support implementation-independent

representation of polymorphism Interfaces are orthogonal to class inheritance

lineage; two different classifiers may realize the same interface but be unrelated in their class hierarchies.

Interfaces are pure specifications of behavior (i.e., a set of operation signature); an abstract base class may define attributes and associations as well.

36

Polymorphism: Use of Interfaces vs. Generalization (i.e.,abstract base classes)

Interfaces are totally independent of inheritance

Generalization: used to re-use implementations

Interfaces are used to re-use and formalize behavioral specifications

Generalization provides a way to implement poly in cases where poly is implemented the same way for a set of classes.

The use of generalization to support poly was discussed earlier.

37

Polymorphism via Generalization Design Decisions

If designing the use of generalization to support polymorphism, there are three decisions to make: Provide interface only to descendant classes?

Design ancestor as an abstract class and only design methods for the descendent classes.

Provide interface and default behavior to descendent classes? Design ancestor as a concrete class with a default

method and allow descendents to refine the method. (Allow polymorphic operations)

Provide interface and mandatory behavior to descendent classes? Design ancestor as a concrete class and disallow

descendents from defining their own method for the operations (Do not allow polymorphic operations)

38

Generalization Uses


Share Implementation Implement Polymorphism Implement Metamorphosis

Generalization can also be used to implement metamorphosis.

This term and the use of generalization to implement it, are the subjects of the next few slides.

39Metamorphosis exists in the real worldHow should it be modeled?

What is Metamorphosis? Metamorphosis

1. a change in form, structure, or function; specifically the physical change undergone by some animals, as of the tadpole to the frog

2. any marked change, as in character, appearance, or condition

Webster’s New World Dictionary, Simon & Schuster, Inc., 1979

40

FulltimeStudentnameaddressstudentIDgradDate

ParttimeStudentnameaddress

maxNumCoursesstudentID

Example: Metamorphosis

In the university, there are full time students and part time students Full time students have an expected

graduation date but part time students do not

Part time students may take a maximum of 3 courses where there is no maximum for full time students

41

What happens if a part-time student

becomes a full-time student?

FulltimeStudent

Student

nameaddressstudentID

gradDate

ParttimeStudent

maxNumCourses

Modeling Metamorphosis: One Approach

An generalization relationship may be created

42

1 1 Classification

ParttimeClassification

maxNumCourses

Student


FulltimeClassification

gradDate

FulltimeStudent

Student


gradDate

ParttimeStudent

maxNumCourses

Modeling Metamorphosis: Another Approach Inheritance may be used to model

common structure, behavior and/or relationships to the “changing” parts

This example shows the ‘before’ and ‘after’ with regards to I implementing metamorphosis.

43

: Student : FulltimeClassification

: StudentManager

: ParttimeClassification

delete

create

change to full time

Modeling Metamorphosis: Another Approach (contd) Metamorphosis is accomplished by the

object “talking” to the changing parts

44

studentID

11

ResidentInformationdormroomroomKeyID

Studentnameaddress10..1 10..1

Classification1

Metamorphosis and Flexibility

This technique also adds to the flexibility of the model

ParttimeClassification

maxNumCourses

FulltimeClassification

gradDate

In this example, a student may also live on campus. In this case, there is a dorm identifier, a room number, and a room key number.

ResidentInformation is just a hypothetical class. It does not exist in the CourseRegistration model.

45

Class Design Steps

Create Initial Design Classes Identify Persistent Classes Define Operations Define Attributes … Define Associations Define Generalizations Resolve Use-Case Collisions

Purpose is to prevent concurrency conflicts caused when two or more use cases access may potentially access instances of the design class simultaneously, and in potentially inconsistent ways.

Handle Non-Functional Requirements in General Checkpoints

46

Resolve Use-Case Collisions Multiple use cases may simultaneously access

design objects – perhaps in conflicting ways. Concurrency conflicts must be identified and

resolved explicitly. Options

Use synchronous messaging => first-come first-serve order processing (blocks others…) Good if message is same priority or where

execution runs within same execution thread.

47

Resolve Use-Case Collisions Options (continued) Where objects may be accessed concurrently by

different threads of execution: Identify operations (or code) to protect from

simultaneous access. Apply access control mechanisms to prevent

conflicting simultaneous access. Message queuing (serializes access) Semaphores (or 'tokens') (allow access only to one

thread at a time) Other locking mechanism

Resolution is highly dependent on implementation environment – may vary with programming language and operating environment.

48

Class Design Steps

Create Initial Design Classes Identify Persistent Classes Define Operations Define Class Visibility Define Methods … Resolve Use-Case Collisions Handle Non-Functional Requirements in General

Purpose: to make sure the design classes are refined to handle general, non-functional requirements (make sure that all mechanisms mapped to the class have been taken into account)

Checkpoints

49

Handle Non-Functional Requirements in General

Analysis Class Analysis Mechanism(s)

Student

Schedule

CourseOffering

Course

RegistrationController

Persistency, Security

Persistency, Legacy Interface

Persistency, Legacy Interface

Distribution

Persistency, Security

Analysis Design Implementation

Remote Method Invocation (RMI)

Persistency

Analysis

Mechanism

(Conceptual)

Design

Mechanism

(Concrete)

Implementation

Mechanism

(Actual)

OODBMS

RDBMSJDBC

ObjectStore

Java 1.2 from Sun

Legacy Data

New Data

Distribution

Persistency

DesignGuidelines

Some Design Class

Here, the designer should, for each designmechanism needed, qualify as many characteristics as possible, giving ranges where appropriate.

50

Classes in non-functional requirements:

There can be several design guidelines and mechanisms that need to be taken into consideration when classes are designed: How to use existing products and

components How to adapt to the programming language How to distribute objects How to achieve acceptable performance How to achieve certain security levels How to handle errors, … and more.

51

Class Design Steps

…. Define Dependencies Define Associations Define Generalizations Resolve Use-Case Collisions Handle Non-Functional Requirements in General Checkpoints

Here we verify that the design model fulfills the requirements on the system, is consistent with respect to the general design guidelines, and that it serves as a good basis for its implementation.

We need to check the design model carefully to verify that all work is headed in the right direction.

Consider the check points ahead…

52

Checkpoints: Classes Does the name of each class clearly reflect the role it plays?

The class should only define attributes, responsibilities or operations that are functionally coupled to the other attributes, responsibilities, or operations defined by that class.

Does the class represent a single well-defined abstraction? Are all attributes and responsibilities functionally coupled?

Are there any class attributes, operations or relationships that should be generalized, that is, moved to an ancestor?

Are all specific requirements on the class addressed?

Are the demands on the class consistent with any statecharts which model the behavior of the class and its instances?

Is the complete life cycle of an instance of the class described?

Does the class offer the required behavior? If the class does not represent a well-defined abstraction, you should

consider splitting it.

The complete lifecycle of an instance of the class should be described.

Each object should be created, used, and removed by one or more use-case realizations.

The classes should offer the behavior the use-case realizations and other classes require.

53

Checkpoints: Operations Are the operations understandable? Is the state description of the class and its objects' behavior

correct? Names of ops should be descriptive and the operations

should be understandable to those who want to use them. Does the class offer the behavior required of it? Have you defined the parameters correctly

Ensure there are not too many parameters for an operation. Have you assigned operations for the messages of each object

completely? Are the implementation specifications (if any) for an operation

correct? Do the operation signatures conform to the standards of the

target programming language?

54

Checkpoints: Attributes

Does each attribute represent a single conceptual thing?

Are the names of the attributes descriptive?

Are all the attributes needed by the use-case realizations?

(Remove any attributes that are redundant and not needed by the use-case realizations.

Be sure to identify and define any applicable default attribute values.

55

Checkpoints: Relationships

Are the role names descriptive?

Are the multiplicities of the relationships correct?

The role names of the aggregations and associations should describe the relationship between the associated class to the relating class.

56

Review: Class Design What is the purpose of Class Design?

In what ways are classes refined?

Are statecharts created for every class?

What are the major components of a statechart? Provide a brief description of each.

What kind of relationship refinements occur?

What is the difference between an association and a dependency?

What is done with operations and attributes?

1 Generalizations Multiple Inheritance Polymorphism Class Design – Another Look – Part 11.

Documents

Transcript of 1 Generalizations Multiple Inheritance Polymorphism Class Design – Another Look – Part 11.