domain model—part 4b: special associations - inheritance bts430 systems analysis and design using...

DOMAIN MODEL—PART 4B:SPECIAL ASSOCIATIONS -

INHERITANCE

BTS430 Systems Analysis and Design using UML

Copyright © 1997 by Rational Software Corporation

Inheritance

Inheritance is a relationships between a base class and its derived classes

There are two ways to find inheritance: Generalization Specialization

Common attributes, operations, and/or relationships are shown at the highest applicable level in the hierarchy


Inheritance

GeneralizationThe capability to create base classes that encapsulate

structureand behaviour common to several classes.


Inheritance

SpecializationThe ability to create derived classes that represent refinements to the base class—typically structure and behaviour are added to the new derived class.

Base Classes and Derived Classes

Derived classes must know who their base class is, and they depend on their base class.

Base classes should know nothing about their derived classes.

Let’s look at a Bill Payment Example

AccountType

Customer

custIDcustName

Account

accountIDaccountType : AccountTypeaccountBalance 11..* 11..*

described by

1..*

1

1..*

1

owns

BillPayment

paymentIDdateamountbill : Billaccount : Account

1..*

1

1..*

1

debited by

Bill

billIDbillName

1

1

1

1

paid by

Notes: 1) It would also be OK to show accountSet:Account as an attribute of Customer.2) You could also have an address class and make address:Address an attribute of Customer.

Inheritance in the Bill Payment Example

A better way to handle the account types might be with inheritance.

First, let’s look at all the different types of accounts we might have:

Types of Accounts

NoInterestChequingInterestChequingAnnualBonusSavingsHighYieldSavingsWithdrawAnyTimeSavingsTaxFreeSavingsBusinessAccountand so on…

What do these accounts look like?

Each of the accounts shares at least some of the same attributes and operations. The operations may “act” differently (e.g. interest calculations will be different) but will have the same name.

NoInterestChequing

accountNuminterestRatetotalBalanceaccessibleBalance

calculateInterest()withdraw()

InterestChequing



HighYieldSavings



AnnualBonusSavings



WithdrawAnyTimeSavings



TaxFreeSavings



BusinessChequing



BusinessSavings



Inheritance

To use inheritance we create a “base” class which is a generalization of all account classes

Account



Inheritance

If the base class has no objects (is never instantiated) then we call it abstract and show it as follows:

That means there will be no such thing as an account:Account object—only specific account objects will be instantiated e.g. taxFreeSavings:TaxFreeSavings.

Account



<<Abstract>>

To Show Inheritance:

NoInterestChequing

InterestChequing

HighYieldSavingsAnnualBonusSavings

WithdrawAnyTimeSavings

TaxFreeSavingsBusinessChequing

BusinessSavings

Account



<<Abstract>>

This is the “generalization” symbol

When you see the generalization symbol you know that all derived classes will carry the defined attributes and operations, so there is no need to show them.

Inheritance

A child class “is a” special type of the more general parent class

E.g. “A video is a type of library item” “A part-time student is a type of student” “A reserve item screen is a type of library screen”

Inheritance

Each of the DERIVED or CHILD classes is inherited from the BASE or PARENT class.

Each derived class “is a” specialization of the base class.

The base class is a generalization of all of the derived classes

Inheritance

Each class that is derived from the base class must implement the attributes and operations of the base class but can have its own version of each—for example most of the “calculateInterest” operations will be different, but they will all be called calculateInterest.

Any program that uses any derived account object will be able to use the calculateInterest operation on any objects derived from account.

The derived classes might have their own ADDITIONAL operations and attributes.

Inheritance in the Bill Payment example

AccountType

Customer

custIDcustName

Account

accountIDaccountType : AccountTypeaccountBalance 11..* 11..*

described by

1..*

1

1..*

1

owns

BillPayment

paymentIDdateamountbill : Billaccount : Account

1..*

1

1..*

1

debited by

Bill

billIDbillName

1

1

1

1

paid by

Notes: 1) It would also be OK to show accountSet:Account as an attribute of Customer.2) You could also have an address class and make address:Address an attribute of Customer.

Account



<<Abstract>> We could show the parent class in our diagram but we would have to be sure that the relationships were true of every child class e.g. could we pay bills from our savings accounts? Otherwise we would show child classes.

Monopoly Example

public abstract class Square{

public String sqName;public Boolean loseTurn;

public MSquare(){}public abstract void landOn(Player p, boolean passGo);public String getName(){

return sqName;}

}

Square

sqNameloseTurn

landOn()getName()

<<Abstract>>

RegularSquare IncomeTaxSquare GoToJailSquare

Monopoly Example from Larman

Square

sqNameloseTurn

landOn()getName()

<<Abstract>>


public class RegularSquare extends Square{

public RegularSquare(){

sqName = "Regular";loseTurn = false; // for later

}

public void landOn(Player p, boolean passGo){

//if pass go collect $200 else do nothingif (passGo) {p.setNetWorth(p.getNetWorth() +

200.00); }}

}

Monopoly Example

Square

sqNameloseTurn

landOn()getName()

<<Abstract>>


public class IncomeTaxSquare extends Square{

public IncomeTaxSquare(){

sqName = "IncomeTax";loseTurn = false; // for later

}

public void landOn(Player p, boolean passGo){

double amount;double deduct;double defaultAmt = 100.00;amount = p.getNetWorth();deduct = min(defaultAmt, amount * .1);p.setNetWorth(amount - deduct); //deduct the

lesser of 100 and 10% of net worthif (passGo){p.setNetWorth(p.getNetWorth() +

200.00);} //collect $200 if go was passed//don't reset position

}}

Monopoly Example

Square

sqNameloseTurn

landOn()getName()

<<Abstract>>


public class GoToJailSquare extends Square{

public GoToJailSquare(){

sqName = "GoToJail";loseTurn = true; // for later

}public void landOn(Player p, boolean passGo){

p.setNetWorth(p.getNetWorth() - 200.00); //fine of $200

p.setPosition(0); //go back to the start//do nothing if PassGo is true; do not collect

$200}

}

Monopoly Example

In the java code you see that each child class only has to contain code for the operation that is not specified or is different from that specified in the parent.

Child classes would also have to include code for any additional attributes and operations they carry.

Why Use Inheritance?

Less duplicationMore reusabilityMore standardization ******Less change impactClasses are more focusedEasy to add a child…and so on…

domain model—part 4b: special associations - inheritance bts430 systems analysis and design using...

Documents

base classes

new derived class

derived classesderived

derived account object

derived classesthere

child classes

inheritancea child class

base classtypically