(Further analysis and Refactoring)
Larman, chapters 23 and 24
Glenn D. Blank, CSE432
End of iteration-1 (see Larman, p. 402):




For a selected, high risk use case scenario,
SSD, domain class diagrams and operation
contracts (ADTs) were developed
Software implemented and tested (unit,
acceptance, usability)
Customers have evaluated the partial system
Are you there yet?

Decide what to work on next, resolve
questions, identify major tasks:
◦ Reverse engineer from Iteration 1 source code to new
class and interaction diagrams: how and why?
◦ Usability analysis for the user interface under way
◦ Database modeling and implementation under way

Another requirements workshop occurs:
◦ Write more use cases in fully dressed format
◦ Decide which use case(s) will be analyzed, designed,
implemented and tested in second iteration
◦ How and why should customer be involved in this
workshop?
Iteration-2 will handle additional requirements:
 Support for third-party external services (i.e.,
different tax collectors)
 Complex pricing rules
 GUI window refreshes when sale total changes
Constraint: only consider these requirements in
context of Process Sale use case
Process Sale
Pay by Credit Scenario
:NextGenPOS
System
«actor»
:TaxCalculator
: Cashier
«actor»
:CreditAuthorization
Service
«actor»
:Accounts
makeNewSale
enterItem(itemID, quantity)
description, total
endSale
taxLineItems =
getTaxes( sale )
total with taxes
makeCreditPayment
(credNum, expiryDate)
reply = requestApproval(request)
postReceivable( receivable )
postSale( sale )
Fig. 24.1

Expand basic players moving around board
scenario to handle some special square rules:
◦
◦
◦
◦
Each player starts with $1500
When player lands of Go, player receives $200
When player lands on Go-To-Jail, move to Jail
When player lands on Income-Tax, player pays
minimum of $200 or 10% of worth


What design pattern has been incorporated?
Why is polymorphism a good idea here?
◦ Subclasses (of square) have additional attributes (state)
◦ Subclasses have additional operations

Refactoring changing a software system by
improving its internal structure without
changing its external behavior
 I.e., restructure code in a disciplined way
 Make code easier to understand and cheaper to
modify
 Counteracts entropy of software by promoting
more order
 Identify heavily used or time consuming code

Refactoring leads to design patterns: why?
 Smalltalk community used refactoring to develop
the Model-View-Controller and other frameworks

When you do a Code Review or Walkthrough
◦ I.e., in subsequent iterations (polymorphism in
Monopoly)

When you add a function

When you need to fix a bug
◦ Helps you to understand the code you are
modifying
◦ Sometimes existing design does not allow you
to easily add the feature
◦ A bug report is a sign code needs refactoring: Why?
◦ Code was not clear enough to see the bug in the
first place



Why does test-driven programming support
refactoring?
Code to be refactored should already have tests
that we can recheck to assure new design
doesn’t break anything!
Begin refactoring by designing a solid test set
for anything new in code under analysis