Design and Programming Chapter 7 Applied Software Project Management, Stellman & Greene See also:

Options for Programmers  Start building code, creating objects and user interface elements  Build a user interface prototype to demonstrate to users, stakeholders and team  Create pictures, flowcharts, dataflow diagrams, database design diagrams, or other visual tools  Develop object models using code, UML, or class diagrams  Write a design specification using some or all of these tools... The team determines which of these is appropriate

The design must be reviewed  Walkthrough with users  Many users may be confused or uninterested in object models or UML diagrams  Consider reviewing differently for different audiences

Version Control  With several people working together, there must be a current and updated version of the software  Repository contains each of the system’s files  Changes must not get lost  Some call this configuration management

Subversion  Free and open source version control system  Functions are accessed via command line  Uses copy-modify-merge model instead of lock- modify-unlock Programmer retrieves current version from repository, makes updates, and commits Uses version numbers

Making updates  Programmer checks out repository onto a local machine; copy is called working copy Can check out all or part of repository  There can be several working copies out  Each working copy keeps track of who has it and when it was checked out  When it is committed, the repository is updated to look like the local copy Subversion performs an atomic commit (all changes are made, or none)

Making updates  Subversion does not let user modify an out-of-date copy  Subversion notifies user that the working copy is out- of-date, and it is up to the user to ask for Subversion to update the working copy  A conflict occurs when two users make different changes to the same line; the second committer must determine which change will be committed (see tables 7-2 and 7-3)  See pages 140 – 149 and author’s slides for Subversion details

Refactoring: Improving the design of a program without altering its behavior  Choices that impact how easy the code is to and to understand Variable names Breaking code into functions Choosing more efficient statements  As project progresses, programmers may realize/discover better design Team may choose to review changes only Refactoring examples: pages  Extract method: changes made during code review p. 151  Replace Magic Number with symbolic constant p. 152  Decompose conditional p. 153  Introduce explaining variable p. 154

Refactoring pays for itself  Code that may have once been acceptable becomes spaghetti code  It may take as much time to refactor difficult code as it does to trace through  The clearer the code is, the less likely it is to have defects  When to do: When a reasonably large amount of code is added

Unit Testing  Code is made up of objects, functions, modules, or other non-trivial units  The purpose of unit testing is to create a set of tests for each unit to verify that it performs its function correctly  Test-driven development Programmer writes the unit test before writing the unit Ensures that requirements are understood Ensures that testing is not forgotten

Test all of the code, test all of the possibilities  It takes multiple tests to verify a single unit (e.g. object in Java, function in C)  A good test verifies that: The unit correctly performs its intended functions The unit functions properly at its boundary conditions (values at the edge of the range The unit is robust: it gracefully handles unexpected values and error conditions  See JUnit and Example p

Test Cases  A test case is a piece of code that verifies one behavior of the software  Tests run without input from user  Output: pass, fail, or generate error  Use a Framework Piece of software that automatically runs tests and reports results  Test cases are grouped into suites that verify specific units or functions  Run test suites after each refactoring

Who does What?  Programmers do unit testing Verify that the software works as the programmer intended (unit tests)  Software testers (Quality Assurance, QA) Verify that the software meets its requirements specified in SRS (functional tests) Verify that the software meets the needs of the users and stakeholders specified in the Vision and Scope document  Each is looking for different things

Other  Code that passes unit tests does not necessarily mean that the code does what it is supposed to do  QA runs software as if they were users without access to individual units  Some defects may only appear when units are put together... Putting it all together is the job of QA  Up front time cost to write tests ⇨ saves time over finding bugs later and rebuilding object entirely

Using Automation  When projects become complex and require many steps, it is easy to forget something  It often requires much of a senior team member’s time to generate new builds on a regular basis ⇨ causing delays  Automated build tools honor dependencies so that code is built only when supporting libraries are available: Make, Apache Ant, Jam  Other tools allow tasks to be configured to run on a schedule: Cruise Control and TinderBox  However! Tools may be overwhelming and slow down the works

For Next Time  Present project design Using power point Approximately 8-10 slides  Download Subversion: who will try it?