DOMAIN MODEL SPECIAL ASSOCIATIONS – COMPOSITION AND INHERITANCE SYS466.
-
Upload
kayli-mecum -
Category
Documents
-
view
236 -
download
0
Transcript of 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
Copyright © 1997 by Rational Software Corporation
Inheritance
GeneralizationThe capability to create base classes that encapsulate
structureand behaviour common to several classes.
Copyright © 1997 by Rational Software Corporation
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
accountNuminterestRatetotalBalanceaccessibleBalance
calculateInterest()withdraw()
HighYieldSavings
accountNuminterestRatetotalBalanceaccessibleBalance
calculateInterest()withdraw()
AnnualBonusSavings
accountNuminterestRatetotalBalanceaccessibleBalance
calculateInterest()withdraw()
WithdrawAnyTimeSavings
accountNuminterestRatetotalBalanceaccessibleBalance
calculateInterest()withdraw()
TaxFreeSavings
accountNuminterestRatetotalBalanceaccessibleBalance
calculateInterest()withdraw()
BusinessChequing
accountNuminterestRatetotalBalanceaccessibleBalance
calculateInterest()withdraw()
BusinessSavings
accountNuminterestRatetotalBalanceaccessibleBalance
calculateInterest()withdraw()
Inheritance
To use inheritance we create a “base” class which is a generalization of all account classes
Account
accountNuminterestRatetotalBalanceaccessibleBalance
calculateInterest()withdraw()
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
accountNuminterestRatetotalBalanceaccessibleBalance
calculateInterest()withdraw()
<<Abstract>>
To Show Inheritance:
NoInterestChequing
InterestChequing
HighYieldSavingsAnnualBonusSavings
WithdrawAnyTimeSavings
TaxFreeSavingsBusinessChequing
BusinessSavings
Account
accountNuminterestRatetotalBalanceaccessibleBalance
calculateInterest()withdraw()
<<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
accountNuminterestRatetotalBalanceaccessibleBalance
calculateInterest()withdraw()
<<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>>
RegularSquare IncomeTaxSquare GoToJailSquare
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>>
RegularSquare IncomeTaxSquare GoToJailSquare
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>>
RegularSquare IncomeTaxSquare GoToJailSquare
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…