1

GeneralizationsMultiple Inheritance

(finishing up Class Design)

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 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. 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. Discuss: What does ‘structure’ mean to you? Discuss: What does ‘behavior’ mean to you?

Makes ‘change’ and ‘maintenance’ easier: Generalization 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

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 derived / child class ‘is a kind of’ parent class

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

In analysis, generalization is used sparingly to model shared behavioral semantics only. (generalization must pass ‘is a’ test).

Generalization cited in analysis is used to support reuse 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”

(The use of generalization makes the definitions of the abstractions easier to document and understand).

Think boundary classes for interfacing…. May be used in the Domain Model (Business Object Model)

A common super-class is created when generalization is found.

Super class contains common attributes, associations and aggregations, and behaviors.

Subclasses have unique, individual attributes/behaviors not common to all subclasses of a super class.

We can draw a generalization relationship from the sub-class to the super-class as we saw in the preceding slide. (solid line, open triangle)

7

Lion

talk ()

Tiger

talk ()

Animal

{abstract}

talk () {abstract}

There can be 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 in UML. Meaning: no implementation exists for the operation in the class where it is specified.

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

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

8

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. Potential implementation problems.

Not all languages support it. We don’t care in design!! Why?

May need adjustment in design and implementation.

9

Name clashes on inheritedattributes 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 (see above).If a class inherits from several classes, you must check how relationships, operations, and attributes are named in the ancestors.

10

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 - often confused Generalization represents an “is-a” or “kind-of”

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

Relates multiple objects;

11

Scrollbar

Window

WindowWithScrollbar11

Window

WindowWithScrollbar

Scrollbar

Consider: Which of these is/are true?A WindowWithScrollbar “is a” WindowA WindowWithScrollbar “contains a” ScrollbarOrA WindowWithScrollbar “has a” Scrollbar

Generalization vs. Aggregation

Notice: specialization and the aggregation

12

Generalization Uses

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

have been talking about to this point.

13

List

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

Stack

Animal

talk ()

Lion Tiger

talk () talk ()

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.

???

14

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

The “is-a style of programming” states the descendent ‘is-a’ type of the ancestor and can fill in for all its ancestors in any situation. True? Converse?

15

Animal

talk ()

Lion Tiger

talk () talk ()

Generalization: Share Common Properties and Behavior (contd)

List

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

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.

16

Generalization Uses

1. Share Common Properties and Behavior2. Share Implementation

This use of generalization is where there are some services or structure provided by a class you want to leverage in the implementation of another class.

Several different ‘kinds’ of sharing implementations!

Side note: What is wrong grammatically with the sentence starred?

17

ListinsertBottom (Item)removeBottom ()insert (Item, position)

Stack

SequentialContainer

insertTop (Item)removeTop ()

List

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

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

Can see we inherit insertTop() and removeTop() from SequentialContainer; Add those additional behaviors unique to List

18

Checkpoints: Classes (look these over) 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? Why?

Are all specific requirements on the class addressed?

Are the demands on the class consistent with any state-charts 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 not, why have it?? 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.

19

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

behavior correct? Names of operations 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

(call by reference, call by value, others….) Ensure there are not too many parameters for an

operation. Are the implementation specifications (if any)

for an operation correct? (Got those from??) Do the operation signatures conform to the

standards of the target programming language?

20

Checkpoints: Attributes Does each attribute represent a single conceptual thing

(noun, noun clause)?

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.) Remember, any thing you have may cause problems later in

quality control, testing, configuration management, versioning, future maintenance, ….

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

21

Checkpoints: Relationships

Are the role names descriptive? Define roles?? Remember?

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.

22

Review: Class Design

What is the purpose of Class Design?

In what ways are classes refined?

What is the difference between an association and a dependency?

What is done with operations and attributes?