generalizations multiple inheritance finishing up class design n.
Download
Skip this Video
Loading SlideShow in 5 Seconds..
Generalizations Multiple Inheritance (finishing up Class Design) PowerPoint Presentation
Download Presentation
Generalizations Multiple Inheritance (finishing up Class Design)

Loading in 2 Seconds...

play fullscreen
1 / 22

Generalizations Multiple Inheritance (finishing up Class Design) - PowerPoint PPT Presentation


  • 104 Views
  • Uploaded on

Generalizations Multiple Inheritance (finishing up Class Design). Class Design – Another Look – Part 11. Class Design Steps. Create Initial Design Classes Identify Persistent Classes … Define Dependencies Define Associations Define Generalizations

loader
I am the owner, or an agent authorized to act on behalf of the owner, of the copyrighted work described.
capcha
Download Presentation

PowerPoint Slideshow about 'Generalizations Multiple Inheritance (finishing up Class Design)' - Albert_Lan


An Image/Link below is provided (as is) to download presentation

Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author.While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server.


- - - - - - - - - - - - - - - - - - - - - - - - - - E N D - - - - - - - - - - - - - - - - - - - - - - - - - -
Presentation Transcript
generalizations multiple inheritance finishing up class design

GeneralizationsMultiple Inheritance(finishing up Class Design)

Class Design –

Another Look – Part 11

class design steps
Class Design Steps
  • Create Initial Design Classes
  • Identify Persistent Classes
  • Define Dependencies
  • Define Associations
  • Define Generalizations
    • In analysis, inheritance inherent to the problem domainmay have been defined.
    • Class Design is where generalizations are defined to improve/ease the implementation.
    • Design is the real activity of inventing inheritance.
  • Checkpoints
generalization
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
define generalizations
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
review generalization
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’ parentclass

  • Can us terms ‘ancestor’ and

‘descendent’ instead of

super-class and subclass.

  • In analysis, generalization is

usedsparingly to model

shared behavioral semantics only.

(generalization must pass ‘is a’ test).

  • Generalization cited in
  • analysis is used to supportreuse in Design.

ancestor

Account

balance

name

Superclass (parent)

number

Withdraw()

CreateStatement()

Generalization Relationship

Savings

Checking

Subclasses

GetInterest()

descendents

generalization in analysis and in design
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)
abstract and concrete classes

Animal

{abstract}

talk () {abstract}

Lion

Tiger

talk ()

talk ()

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

Discriminator

Abstract operation

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.

There can be no direct

instances of Animal

Communication

All objects are either lions or tigers

multiple inheritance inheriting from more than one class
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 !

multiple inheritance problems in design and implementation

AnimateObject

color

FlyingThing

Animal

Bird

Multiple Inheritance Problems in Design and Implementation.

Name clashes on inherited

attributes or operations

Repeated inheritance

FlyingThing

Animal

color

color

getColor

getColor

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,

and attributes are named in the ancestors.

generalization vs aggregation

WindowWithScrollbar

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

generalization?

If not, what would be a

better way to model the

info which maintains

generalization “is-a”

semantics?

Window

Scrollbar

generalization vs aggregation1

Window

Scrollbar

Window

WindowWithScrollbar

Scrollbar

1

1

WindowWithScrollbar

Generalization vs. Aggregation

Consider: Which of these is/are true?

A WindowWithScrollbar “is a” Window

A WindowWithScrollbar “contains a” Scrollbar

Or

A WindowWithScrollbar “has a” Scrollbar

Notice: specialization and the aggregation

generalization uses
Generalization Uses

Share Common Properties and Behaviors

  • This is the first use of generalization that we have been talking about to this point.
generalization share common properties and behavior

Animal

talk ()

List

Lion

Tiger

insertTop (Item)

insertBottom (Item)

talk ()

talk ()

removeTop ()

removeBottom ()

insert (Item,

position)

Stack

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 descendentis a type of the ancestor and

must follow the rules of the is-a style of programming.

generalization share common properties and behavior1

Animal

talk ()

List

Lion

Tiger

insertTop (Item)

insertBottom (Item)

talk ()

talk ()

removeTop ()

removeBottom ()

insert (Item,

position)

Stack

Generalization: Share Common Properties and Behavior
  • The “is-a style of programming” states the descendent ‘is-a’ type of the ancestor and can fill infor all itsancestors in any situation. True? Converse?

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

generalization share common properties and behavior contd

Animal

talk ()

List

Lion

Tiger

insertTop (Item)

insertBottom (Item)

talk ()

talk ()

removeTop ()

removeBottom ()

insert (Item,

position)

Stack

Generalization: Share Common Properties and Behavior (contd)

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.

generalization uses1
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?
generalization share implementation factoring

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

insertTop (Item)

removeTop ()

List

Stack

insertBottom (Item)

removeBottom ()

insert (Item, position)

Can see we inherit insertTop() and removeTop() from SequentialContainer;

Add those additional behaviors unique to List

checkpoints classes look these over
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 functionallycoupled?
  • 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.
checkpoints operations
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?
checkpoints attributes
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.
checkpoints relationships
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.
review class design
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?