bank domain

8/8/2019 Bank Domain

http://slidepdf.com/reader/full/bank-domain 1/6

Bank Domain Model 2/10/2003 at 2:51 PM

1 of 6 Dr. Paul Grabow

Bank Domain Model: Version 2

Version 1

Customer CustomerID

SavingsAccountAccountCheckingAccount

LoanAccount

Bank

Title: Bank

Version: 1.0Author: P. Grabow

Modified:

By:

Version 2

Bank CustomerIDCustomer

Account LoanAccount

SavingsAccountCheckingAccount

0,1

1..*1 has 1 has

1..*

1

Owns

1

1

MayBe

1MayBe

MayBe 0,1

0,1

1

Title: BankVersion: 2.0

Author: P. Grabow

Modified:

By:





Version 3

+ID : long

Customer

+Number : long

Account

+Balance : double

CheckingAccount

+Balance : double

SavingsAccount

+LoanAmount : double+AmountPaid : double

+InterestRate : double

+LastPayment : double+PaymentDate : date

LoanAccount

+Name : String+Address : String

Bank

has

Owns

MayBe

0,1MayBe

MayBe

1

1 1

1..*

1..*

1

0,1 0,1

1

Title: BankVersion: 3.0

Author: P. GrabowModified:

By:

Version 4

+ID : long

Customer

+Name : String

+Address : String

Bank

+LoanAmount : double

+AmountPaid : double


LoanAccount

+Balance : double

CheckingAccount

+Number : long

Account

+Amount : double

+WithdrawalDate : date

Withdrawal

+CheckNumber : long

WrittenCheck

+Amount : double

+DepositDate : date

Deposit

+Amount : double

+PaymentDate : date

Payment

+Balance : double

SavingsAccount

1

1..*

1

*

1

0,1

1..*has

Owns

0,1MayBe

MayBe

1

1

1

hasHad

10,1 Is

1

1

Ha s

11 Ha s

1..*

1

1..*

Ha s AssociatedWith

Title: Bank

Version: 4.0

Author: P. Grabow

Modified:

By:





Version 5

+ID : long

Customer

+Name : String

+Address : String

Bank




LoanAccount

+Balance : double

CheckingAccount

+Number : long

Account

+Balance : double

SavingsAccount+CheckNumber : long

+CheckDate : date

WrittenCheck

+Number : long

+Amount : double

+TransactionDate : date

Transaction

0,1

* 1..*

1..*

1*

1..*has

1..*

Owns

0,1MayBe1Is

Has MayBe

1

1

0,1

1

1

1

1 1

1

1

1

HasDepositHasWithdrawal

HasDeposit

AssociatedWith

HasPayment

*

Title: Bank

Version: 5.0Author: P. Grabow

Modified:

By:

Comments

1. Because the domain model is constructed during analysis (not design), there areno operations listed, no navigation arrows identified, and no inheritance.

2. Ideally there should also be no reference to data types, e.g., double or int.

However, Rhapsody insists that the data type be identified when an attribute isdefined. Consequently, the above diagrams include data types.

3. Also, the current version of Rhapsody forces you to identify the visibility of an

attribute within a class (e.g., private, public, or protected: ‘-’, ‘+‘, or ‘#’,respectively). Since the default is public, all of the above diagrams indicate public

visibility of the attributes – even though they would undoubtedly be lateridentified as private or protected.

4. A domain model should be assumed to be “in process” – and does not represent ablueprint for implementation. As the sequence diagrams are constructed, theoperations associated with particular classes will be uncovered – as well as the

navigation and the refinement of relationships – resulting in the so-called “class





diagram”. (This distinction is used in Craig Larman’s text and I have found it tobe a useful distinction.)

5. Inheritance should not appear until after the construction of the class diagram – just prior to actual implementation. The primary reason is that inheritance

represents a version of “strong coupling” – greatly influencing the reusability and

maintainability of the implemented objects. Unfortunately, many object-orientedtexts introduce inheritance into the design process too early – often before any

consideration of coupling has occurred.

Main Success Scenario

Customer Bank

1. request withdrawal from savings

2. ask for customer ID, account number,and amount to withdraw

3. give customer ID, account number, andamount to withdraw

4. withdrawFromSavings

5. return result to customer

Subordinate Scenario

Customer Bank

1. withdrawFromSavings

2. create Customer object

3. determine whether Customer exists

4. create Account object

5. determine whether Account exists

6. create CheckingAccount

7. get Customer’s CheckingAccount

8. withdraw from Customer’s

CheckingAccount

9. replace Customer’s CheckingAccount

10. report new balance





Sequence Diagram: WithdrawFromSavings

Savings

Account

Customers:

CustomerSet

Customer myCaccount:

SavingsAccount

AccountmyBank:Bank CAccounts:

SavingsAccount

Accounts:

AccountSet

withdrawFromSavings(CustomerID, Amount, AccountNumber, Success, NewBalance)

isIn(anAccount)

isIn(aCustomer)

create(AccountNumber)

create(CustomerID)

get(anAccount)

create()

replace(myCaccount)

withdraw(Amount)

Title: WithdrawFromSavings

Version: 1.0

Created: 2/10/2003

Author: P. GrabowModified: 2/11/2003

By: P. Grabow

return myCaccount

create anAccount

Version 6

+Balance : double

+withdraw(double Amo+create():void

SavingsAccount

+ID : long

Customer

+Number : long

+create(long Acco

Account+Balance : double

CheckingAccount

+Name : String

+Address : String

+createSavingsAccount(int+withdrawFromSavings(lo

Bank

+Number : long

+Amount : double+TransactionDate : date

Transaction

+CheckNumber : long

+CheckDate : date

WrittenCheck




LoanAccount

MayBe

1

0,1

has1 1..*

Is0,1 1

HasDeposit

1

1..*

Has

1

*

AssociatedWith

1

1

MayBe1 0,1

HasDeposit1

1..*HasWithdrawal1

*

HasPayment

1

*

Owns

1

1..*

Title: Bank

Version: 6.0Date: 2/11/2003

Author: P. Grabow

Modified: 2/11/2003By: P. Grabow





Sets

Bank SavingsAccountSet

AccountSet

CustomerSet

SavingsAccount

Customer

Account

1

1

1

1

1 *

1 *

contains

contains

11 1 *contains

bank domain

Documents