1 / 10

From Iteration-1 to Iteration-2

From Iteration-1 to Iteration-2. (Further analysis and Refactoring) Larman, chapters 23 and 24 Glenn D. Blank, CSE432. Where are we with the projects? . End of iteration-1 (see Larman, p. 402):

kipp
Télécharger la présentation

From Iteration-1 to Iteration-2

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  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

More Related