Download presentation
Presentation is loading. Please wait.
Published byMarlene Stewart Modified over 8 years ago
1
(Further analysis and Refactoring) Larman, chapters 23 and 24 Glenn D. Blank, CSE432
2
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
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
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
Fig. 24.1
6
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
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 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 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
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
Similar presentations
© 2024 SlidePlayer.com Inc.
All rights reserved.