Class Design –

Another Look – Part 11

Generalizations
Multiple Inheritance
(finishing up Class Design)

1
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

2
 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

3
 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

4
 Review: Generalization
 Is a ‘relationship where one class shares the structure
and/or behavior of one or more classes
 “Is-a-kind of” relationship ancestor
Account
 Should always be able to say that balance
your derived / child class ‘is a kind of’ parent class name
Superclass number
 Can us terms ‘ancestor’ and (parent)
‘descendent’ instead of Withdraw()
super-class and subclass. CreateStatement()

Generalization
 In analysis, generalization is
Relationship
used sparingly to model
shared behavioral semantics only.
(generalization must pass ‘is a’ test).
Checking Savings
Subclasses
GetInterest()

 Generalization cited in descendents

 analysis is used to support reuse in Design. 5
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)

6
 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
Abstract class
Animal
Discriminator {abstract}
Abstract
An operation can also be tagged as
abstract in UML. talk () {abstract} operation
Meaning: no implementation exists for
the operation in the class where it is There can be no direct
Communication
specified. instances of Animal

(A class that contains at least one

abstract operation must be an
abstract class.) Lion Tiger

A discriminator can be used

to indicate on what basis talk () talk ()
7
the generalization or the
specialization occurred. All objects are either lions or tigers
 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.
FlyingThing Animal

multiple
inheritance

Airplane Helicopter Bird Wolf Horse

Use multiple inheritance only when needed, and 8

always with caution !

 Multiple Inheritance
Problems in Design and Implementation.
Name clashes on inherited Repeated inheritance
attributes or operations
FlyingThing Animal AnimateObject
color color color

getColor getColor

FlyingThing Animal

Bird
Bird

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

and attributes are named in the ancestors.

 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;

Is this a correct use of

Window Scrollbar generalization?
If not, what would be a
better way to model the
info which maintains
generalization “is-a”
WindowWithScrollbar
semantics?
10
Generalization vs. Aggregation
Window Scrollbar

Consider: Which of these is/are true?

A WindowWithScrollbar “is a” Window
WindowWithScrollbar A WindowWithScrollbar “contains a” Scrollbar
Or
A WindowWithScrollbar “has a” Scrollbar

Window

WindowWithScrollbar Scrollbar
1 1

Notice: specialization and the aggregation

11
Generalization Uses
Share Common Properties and Behaviors
 This is the first use of generalization that we
have been talking about to this point.

12
 Generalization: Share Common
Properties and Behavior
 Follows the is-a style of programming
 Class substitutability List

insertTop (Item)
Animal insertBottom (Item)
removeTop ()
talk () removeBottom ()
insert (Item,
position)
???
Lion Tiger

talk () talk ()
Stack

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. 13
 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? List

Animal insertTop (Item)

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

Lion Tiger

talk () talk ()
Stack

 Do these classes follow the ‘is-a’ style of programming?

14
 Generalization: Share Common
Properties and Behavior (contd)
List
Animal
insertTop (Item)
talk () insertBottom (Item)
removeTop ()
removeBottom ()
insert (Item,
position)

Lion Tiger

talk () talk ()
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. 15

If the method is passed a Stack, then the insert(position) will fail.

 Generalization Uses
1. Share Common Properties and Behavior
2. 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?

16
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

SequentialContainer
List
insertTop (Item)
insertTop (Item) removeTop ()
insertBottom (Item)
removeTop ()
removeBottom ()
insert (Item, position)
List Stack
insertBottom (Item)
removeBottom ()
insert (Item, position)

Stack Can see we inherit insertTop() and removeTop()

17
from SequentialContainer;
Add those additional behaviors unique to List
 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.
18
 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?
19
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.

20
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.
21
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?

22