Object Oriented Design

1
Object Oriented Design

• Object Oriented Design Heuristics
• Object Oriented Design Exercise

2
Object Modeling Steps

• Identify objects and classes
• Prepare a data dictionary
• Identify associations between objects
• Identify attributes of objects and links
• Organize and simplify object classes using
  inheritance
• Verify that access paths exist for likely queries
• Iterate and refine the model
• Group classes into modules

3
Object Oriented Design Exercise
Design the software to support a computerized
banking network including both human cashiers and
ATMs to be shared by a consortium of banks. Each
bank provides its own computer to maintain its
own accounts and process transactions against
them. Cashier stations are owned by individual
banks and communicate directly with their own
banks computers. Human cashiers enter account
and transaction data. ATMs communicate with a
central computer which clears transactions with
the appropriate banks. An ATM machine accepts a
cash card, interacts with the user, communicates
with the central system to carry out the
transaction, dispenses cash, and prints receipts.
The system requires appropriate record keeping
and security provisions. The system must handle
concurrent accesses to the same account
correctly. The banks will provide their own
software for their own computers you are to
design the software for the ATMs and the network.
The cost of the shared system will be
apportioned to the banks according to the number
of customers with cash cards.
4
Tentative Object Classes

• Suggested in Class
• ATM, Customer, Cashier, Account, Card Reader,
  Bank, UI, Receipt, Transaction, Cash Card,
  Security, Records, Station, Consortium
• Other possibilities (good and bad)
• Software, Banking Network, Bank computer, Cashier
  Station, Account data, Transaction data, Central
  computer, User, Cash, System, Record keeping
  provision, Access, Cost, Communications line,
  Transaction log

5
Keeping the Right Classes

• Remove/Rename/Reorganize
• Redundant classes
• Irrelevant classes
• Vague classes
• Attributes
• Operations
• Roles
• Implementation Constructs

6
Tentative Associations

• Suggested in class
• Bank owns Cashier station
• Customers own cash cards
• Account is owned by customer
• Consortium shares ATMs
• Bank maintains accounts
• Accounts contain transactions
• ATM accepts cash card
• ATM communicates with central bank
• Bank processes transactions
• ATM prints receipts
• ATM interacts with customer
• Customer creates transaction
• Cashiers enter account data
• Consortium shares transaction data
• ATM communicate with consortium about transaction
• Consortium clears transactions with bank

• Other possibilities
• Banking network includes cashiers and ATMs
• Bank provides bank computer
• Bank computer maintains accounts
• Bank computer processes transaction against
  account
• Cashier station communicates with bank computer
• Cashier enters transaction for account
• ATM dispenses cash
• System handles concurrent access
• Bank provides software
• Cost apportioned to banks
• Consortium consists of banks
• Consortium owns central computer
• System provided record keeping
• System provides security
• Cash cards accesses accounts
• Bank employs cashiers

7
Keeping the Right Associations

• Remove/Rename/Reorganize
• Associations between eliminated classes
• Irrelevant or implementation associations
• Actions
• Ternary associations
• Derived associations
• Misnamed associations
• Qualified associations
• Multiplicity
• Missing associations

8
Initial Object Diagram (in class)
consists of
Consortium
Bank
owns
Cashier Station
maintains
owns
Customer
Account
owns
interacts with
own
contains
processes
Cash Card
Transaction
ATM
enters
accepts
Cashier
9
Tentative Attributes

• Possibilities (good and bad)
• Consortium - Bank code
• Bank - Name, card code, account code, employee
  code, station code
• Account - Balance, credit limit, type
• Customer - name, address
• Central Computer - station code, bank code
• Bank Computer - station code
• Cashier - Name
• Cashier transaction - kind, date-time, amount
• ATM - cash on hand, dispensed
• Remote transaction - kind, date-time, amount
• Cash card - password

10
Keeping the Right Attributes

• Remove/Rename/Reorganize
• Objects
• Qualifiers
• Names
• Identifiers
• Link attributes
• Internal values
• Fine detail
• Discordant attributes

11
Object Model with Attributes
12
Refining with Inheritance

• Generalizing into super-class
• Share common features
• May suggest themselves from real world taxonomy
• Symmetry
• Refining into sub-class
• Apparent from application domain
• Enumerated sub-cases
• Multiple Inheritance

13
Object Model with Inheritance
14
Iterating Object Modeling

• Missing objects
• assymetries
• disparate attributes operations on classes
• difficulty generalizing
• operation, no target
• duplicate associations, same name purpose
• role shapes class semantics
• Extra classes
• lack of attributes, operations associations

• Missed Association
• no operation access paths
• Extra Associations
• redundant information
• lack of operations that traverse association
• Incorrect Placements
• Associations role names are too broad or too
  narrow for class
• Attributes access object by one of its
  attribute values

15
Revised Object Model
Transaction
Entered on
Consists of
date-time
Entry station
Update
Concerns
amount kind
Cashier Transaction
Remote Transaction
Started by
ATM
Cashier station
Issues
Entered by
cash on hand dispensed
Card authorization
Has
Customer
Cashier
Identifies
password limit
name address
Owns
name
Owns
Cash Card
station code
Has
station code
Consists of
Employs
bank-code card-code serial number
Accesses
Account
Consortium
employee code
bank code
Bank
balance credit limit type
name
card code
account code
Holds
16
Coming Up Next...

• User Interface Design
• Deliverables
• Interim Presentation - Thursday, February 18
• Design Document - Tuesday, February 23