(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

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 ◦ Helps you to understand the code you are modifying ◦ Sometimes existing design does not allow you to easily add the feature  When you need to fix a bug ◦ 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