Software Design

1
Software Design

• Structured Design Techniques
• Object-Oriented Design Techniques

2
Agenda

• Schedule Reorganization
• Prototype due date
• Deliverables
• Design Review on Tuesday, 18 May 1999
• Software Design Lecture
• Structured Design Techniques
• Object-Oriented Design Techniques

3
Structured Design

• Data Flow-oriented Design Steps
• Establish type of information flow
• Determine information flow boundaries
• Map DFD into program structure
• Define control hierarchy by factoring
• Refine model using design measures and heuristics

4
Beginning the Design Process

• Review the fundamental system model
• Level 0 diagram
• SRS
• Review and refine data flow diagrams for the
  software
• Determine whether DFD exhibits transform or
  transaction characteristics

5
Transform vs. Transaction Flow

• Transform Flow
• Incoming Flow
• Transform Center
• Outgoing Flow

• Transaction Flow
• Transaction Center

6
Transform Mapping

• Isolate the transform center by specifying
  incoming and outgoing flow boundaries
• Perform first-level factoring
• Top-level modules decision making
• Middle-level modules some control and some work
• Low-level modules perform most input,
  computational, and output work
• Perform second-level factoring
• Mapping individual transforms of a DFD into
  appropriate modules
• Refine the first iteration program structure
  using design heuristics

7
Transaction Mapping

• Identify the transaction center and the flow
  characteristics along each action path
• Find transaction center
• Identify incoming path and isolate action paths
• Evaluate each action path for transform vs.
  transaction characteristics
• Map the DFD in a program structure amenable to
  transaction processing
• Factor and refine the transaction structure and
  the structure of each action path
• Refine the first iteration program using design
  heuristics

8
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

9
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.
10
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

11
Keeping the Right Classes

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

12
Tentative Associations

• Verb Phrases
• Banking network includes cashiers and ATMs
• Consortium shares ATMs
• Bank provides bank computer
• Bank computer maintains accounts
• Bank computer processes transaction against
  account
• Bank owns cashier station
• Cashier station communicates with bank computer
• Cashier enters transaction for account
• ATMs communicate with central computer about
  transaction
• Central computer clears transaction with bank

• ATM accepts cash card
• ATM interacts with user
• ATM dispenses cash
• ATM prints receipts
• System handles concurrent access
• Banks provide software
• Cost apportioned to banks
• Implicit/Problem Domain
• Consortium consists of banks
• Bank holds account
• Consortium owns central computer
• System provided record keeping
• System provides security
• Customers have cash cards
• Cash card accesses accounts

13
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

14
Initial Object Diagram
15
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

16
Keeping the Right Attributes

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

17
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

18
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

19
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
20
Coming Up Next...

• Deliverables
• Design Review - Tuesday, 18 May 1999
• Homework 3 - Design Review Reflection
• Due Thursday, 20 May 1999
• Design Document
• Due Tuesday, 25 May 1999
• Lecture None