Iterating And TestingKenneth M. AndersonUniversity of Colorado, BoulderCSCI 4448/6448 — Lecture 14 — 10/11/2007© University of Colorado, 20071Wednesday, October 17, 2007Lecture Goals• Review material from Chapter 9 of the OO A&D textbook• Iteration is fundamental• Feature driven development• Use case driven development• Testing is fundamental• Test driven development• Proving yourself to the customer• Programming by Contract• Defensive Programming• Discuss the examples in Chapter 9• Emphasize the OO concepts and techniques encountered in Chapter 92Wednesday, October 17, 2007Software Life Cycles (aka Design Methods)• Software life cycles break up the development process into stages• Each stage has a goal and an associated set of tasks and documents• Traditional stages:• analysis, design, imp, test, deploy, maintenance, retirement• To move forward in a life cycle, two things are fundamental• Iteration• You won’t get it right the first time; Enables Divide and Conquer• Testing• How do you show your customer that progress is being achieved?3Wednesday, October 17, 2007Goal: Make Customer Happy• We’ve given you lots of “tools” over the last nine lectures• OO Principles• Requirements, Analysis, and Design Techniques• Simple Software Life Cycle• aka “the three steps to writing great software”• Software Architecture Techniques• feature lists, use case diagrams, decomposing problem space• None of them matter, if you can’t keep your customer happy• Iteration and testing provide the means for externalizing results to the customer, demonstrating concrete progress• The book equates progress with “test cases applied to working code”4Wednesday, October 17, 2007Iteration (I)• The key question is how do you “organize” your iterations• Two Approaches• Feature Driven Development• Pick a specific feature in your app; Then plan, analyze, and develop that feature to completion in one iteration• Use Case Driven Development• Pick a scenario in a use case (one path) and write code to support that complete scenario through the use case in one iteration• If it makes sense to tackle the entire use case, then do so• The former focuses on functionality; the latter focuses on tasks• The former will often be limited to a single class or a small set of classes• The latter may touch a lot of classes on multiple layers of your architecture5Wednesday, October 17, 2007Iteration (II)• Both feature driven development and use case driven development• depend on good requirements (which come from the customer)• deliver what the customer wants• In feature driven development, you start with your feature list then• pick a feature• implement it• repeat (until done)• In use case driven development, you start with your use case diagram• pick a use case and write it• implement it• repeat (until done)6Wednesday, October 17, 2007Iteration (III)• Feature driven development is more granular• Works well when you have a lot of different features with minimal overlap• Allows you to show working code faster (smaller chunks)• Use case driven development is more “big picture”• Works well when your app has lots of tasks and actors it must support• Allows you to show the customer bigger pieces of functionality (i.e. tasks)after each iteration• Is user centric; focus is on a single task for a single user on each iteration• Iterations will likely be shorter for feature driven development (days; weeks) than use case driven development (weeks; months)• Consider that in use case driven development, during your FIRST iteration, you may have to develop a user interface, controller classes, model classes, and handle persistence!7Wednesday, October 17, 2007Example: Feature Driven DevelopmentFeatures for Gary’s Game System1. Supports different time periods, including fictional periods like sci-fi and fantasy2. Supports add-on modules for additional campaigns or battle scenarios3. Supports different types of terrain4. Supports multiple types of troops or units that are game-specific5. Each game has a board, made up of square tiles, each with a terrian type.6. The framework keeps up with whose turn it is an coordinates basic movementLets try feature driven development, starting with feature four of the Game System FrameworksetType(String)getType(): StringsetProperty(String, Object)getProperty(String): Objecttype: Stringproperties: MapUnitHere’s our Unit class from Lec. 128Wednesday, October 17, 2007Is it complete?setType(String)getType(): StringsetProperty(String, Object)getProperty(String): Objecttype: Stringproperties: MapUnitThe book returns to Gary’s vision statement and discovers that our initial design work missed some requirements!1. Each unit has game-specific properties (done, well maybe)2. Each unit can move from one tile to another on the board (punt)3. Units can be grouped together into armies (whoops!)9Wednesday, October 17, 2007Skipping A SectionsetType(String)getType(): StringsetProperty(String, Object)getProperty(String): Objecttype: Stringproperties: MapUnitsetType(String)getType(): StringgeId(): intsetName(String)getName(): StringaddWeapon(Weapon)getWeapons(): Weapon [*]setProperty(String, Object)getProperty(String): Objecttype: Stringid: intname: Stringweapons: Weapon [*]properties: MapUnitvs.The book has a section on whether Unit needs to be redesigned, pulling properties common to all Units out of the properties Map.The point is to examine the trade-offs with each of these design choices and to emphasize the need to always evaluate your past design decisions. Questions?10Wednesday, October 17, 2007How to Show Progress?• Tests!• As we iterate on our design/code, we can demonstrate progress to our customer with test cases applied to working code• Different types of tests• Unit tests: applied to individual classes• Integration tests: applied to groups of classes that interact to implement a particular scenario or task• System tests: applied to the entire system to determine if it meets its requirements• Test driven development• All production code is written to make failing test cases pass• Means: write test case first, have it fail, then write code that makes it pass11Wednesday, October 17, 2007Tests for Unit• Test that you can set a property to a particular value and then retrieve that specific value for that property at a later time• Test that a property
View Full Document
Unlocking...