domain model special associations – composition and inheritance sys466

DOMAIN MODELSPECIAL ASSOCIATIONS –

COMPOSITION AND INHERITANCE

SYS466

To begin our discussion, let’s look at an Order

Product

productIDproductNameingredientSet : Ingredientcategory : Category

OrderLine

product : Productquantity

11..* 11..*

orders quantity of

Order

orderIDorderDateorderTotalcustomer : CustomerproductOrderedSet : OrderLine

1..*

1

1..*

1

contains

Order and OrderLine

ORDER contains many OrderLine objects.OrderLine objects have no “life” outside of

order.OrderLine objects have no meaning outside

of order.If you delete Order, all OrderLine objects will

be gone.Order “encapsulates” OrderLine.

Order and OrderLine

What does “Order ‘encapsulates’ OrderLine mean? Order takes responsibility for creation of OrderLine

objects Order controls all communication to OrderLine

objects No other class knows that OrderLine exists But OrderLine knows about other classes (e.g.

Product) OrderLine might not even appear in higher level

models; only Order.

public class Order {

private int orderID;private Customer customer;private List<OrderLine> productOrderedSet;

public Order(int newOrdID) {orderID = newOrdID;customer = new Customer();productOrderedSet = new ArrayList<OrderLine>();

}

public Order() {orderID = 0;customer = new Customer();productOrderedSet = new ArrayList<OrderLine>();}

public void addOrderLine(int inQty, Product inProd) {OrderLine newOrderLine = new OrderLine(inQty,inProd);productOrderedSet.add(newOrderLine);

}public String getOrderedProduct(int orderLineInd) {

return productOrderedSet.get(orderLineInd).getProductName();}public int getOrderedQty(int orderLineInd) {

return productOrderedSet.get(orderLineInd).getQty();}

public void addCustomer(Customer setCustomerTo) {this.customer=setCustomerTo;

}

public String getCustName() {return customer.getCustName();

}

public int getOrderID() {return orderID;

}

}

The Order class(simplified version)

public class Order {

private int orderID;private Customer customer;private List<OrderLine> productOrderedSet;

…………………………………………………………..

public void addOrderLine(int inQty, Product inProd) {OrderLine newOrderLine = new OrderLine(inQty,inProd);productOrderedSet.add(newOrderLine);

}public String getOrderedProduct(int orderLineInd) {

return productOrderedSet.get(orderLineInd).getProductName();}public int getOrderedQty(int orderLineInd) {

return productOrderedSet.get(orderLineInd).getQty();}

………………………………………………………………

}

Order is responsible for creating OrderLine objects and for getting OrderLine information

public class OrderLine {

private int qtyOrdered;private Product product;

public OrderLine(int qty,Product prod) {qtyOrdered = qty;this. product = prod;}

public OrderLine() {qtyOrdered = 0;product = new Product();}

public int getQty() {return qtyOrdered;

}public String getProductName() {

return product.getProductName();

}}

OrderLine knows about Product and can execute Product functions (e.g. product.GetProductName)

public class Product {

private int productID;private String productName;

public Product(int setToID,String setToName) {productID = setToID;productName = setToName;

}public Product() {}

public String getProductName() {return productName;

}public int getProductID() {

return productID;}public void setProductName(String setToName) {

productName = setToName;}public void setProductID(int setToID) {

productID = setToID;}}

Product does not know anything about OrderLine; it does not know that OrderLine exists.

Composition

Order

orderIDorderDateorderTotalcustomer : CustomerproductOrderedSet : OrderLine

OrderLine

product : Productquantity

1..*

1

1..*

1

contains

This strong relationship between Order and OrderLine is called a COMPOSITION and is shown using the “filled in diamond” symbol.

Order is the container.

OrderLine is the component or contained class.

The Composition Symbol

In order to specify composition we need to do two things: First we use the aggregation symbol in Rose to create

a relationship between Container (Order) and Component (OrderLine). We draw from Order to OrderLine.

The Composition Symbol

Then we select the “aggregate” relationship that we just drew and make it a composition by selecting “containment of OrderLine” and choosing “by value”.

A Note About Aggregation

The aggregation symbol on its own is used to denote a weaker relationship—weaker than composition but stronger than association.

It has limited use in modeling and has no definite “meaning” when translated to code.

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 special associations – composition and inheritance sys466

Documents

orderline order

product orderline

public class orderline

order slide

public class product

orderline information

orderline neworderline

component orderline