1. From Iteration-1 to Iteration-2 (Further analysis and Refactoring) Larman, chapters 23 and 24 Glenn D. Blank, CSE432

2. Where are we with the projects? 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?

3. Planning Iteration-2 • 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?

4. NextGen POS Iteration-2 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

5. SSD for external systems Fig. 24.1

6. Monopoly Iteration-2 • 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

7. New class diagram for Monopoly • What design pattern has been incorporated? • Why is polymorphism a good idea here? • Subclasses (of square) have additional attributes (state) • Subclasses have additional operations

8. Refactoring • 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

9. When to Refractor? • 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

10. Refactoring and testing • 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