Download presentation
Presentation is loading. Please wait.
Published byCalvin McKenzie Modified over 9 years ago
1
Design and Programming Chapter 7 Applied Software Project Management, Stellman & Greene See also: http://www.oreilly.com/catalog/appliedprojectmgmthttp://www.oreilly.com/catalog/appliedprojectmgmt
2
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
3
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
4
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
5
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
6
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)
7
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
8
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 150-154 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
9
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
10
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
11
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. 158-161
12
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
13
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
14
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
15
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
16
For Next Time Present project design Using power point Approximately 8-10 slides Download Subversion: who will try it?
Similar presentations
© 2025 SlidePlayer.com. Inc.
All rights reserved.