Transcript Class Design 2

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
ancestor
 “Is-a-kind of” relationship
Account
 Should always be able to say that
your derived / child class ‘is a kind of’ parent class
Superclass
(parent)
 Can us terms ‘ancestor’ and
‘descendent’ instead of
super-class and subclass.
balance
name
number
Withdraw()
CreateStatement()
Generalization
 In analysis, generalization is
Relationship
used sparingly to model
shared behavioral semantics only.
(generalization must pass ‘is a’ test).
Subclasses
Checking
Savings
GetInterest()
 Generalization cited in
 analysis is used to support reuse in Design.
descendents
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
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.
{abstract}
Abstract
operation
talk () {abstract}
There can be no direct
instances of Animal
Communication
Lion
talk ()
Tiger
talk ()
7
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
always with caution !
8
Multiple Inheritance
Problems in Design and Implementation.
Name clashes on inherited
attributes or operations
FlyingThing
color
Animal
color
getColor
getColor
Repeated inheritance
AnimateObject
color
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).
9
If a class inherits from several classes, you must check how relationships, operations,
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;
Window
Scrollbar
WindowWithScrollbar
Is this a correct use of
generalization?
If not, what would be a
better way to model the
info which maintains
generalization “is-a”
semantics?
10
Generalization vs. Aggregation
Window
Scrollbar
WindowWithScrollbar
Consider: Which of these is/are true?
A WindowWithScrollbar “is a” Window
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
List
 Class substitutability
Animal
talk ()
???
Lion
talk ()
insertTop (Item)
insertBottom (Item)
removeTop ()
removeBottom ()
insert (Item,
position)
Tiger
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
13
must follow the rules of 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?
List
Animal
insertTop (Item)
insertBottom (Item)
removeTop ()
removeBottom ()
insert (Item,
position)
talk ()
Lion
talk ()
Tiger
talk ()
Stack
 Do these classes follow the ‘is-a’ style of programming?
14
Generalization: Share Common
Properties and Behavior (contd)
List
Animal
insertTop (Item)
insertBottom (Item)
removeTop ()
removeBottom ()
insert (Item,
position)
talk ()
Lion
talk ()
Tiger
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.
15
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.
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
List
insertTop (Item)
insertBottom (Item)
removeTop ()
removeBottom ()
insert (Item, position)
SequentialContainer
insertTop (Item)
removeTop ()
List
insertBottom (Item)
removeBottom ()
insert (Item, position)
Stack
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.
18
 The classes should offer the behavior the use-case realizations
and other classes require.
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