Index
A
abstract classes, definition of, 111
abstraction
abstraction mechanism, 88
managing the complexity of a large problem, 65
acceleration, definition of, 24
actors, definition of, 91
Adams, Douglas, 179
Adapter pattern
class adapters, 146
code example, 147
description of, 146
object adapters, 146
add(), 150
aggregation, definition of, 130
agile development models
Agile Manifesto web page, 8
aims of, 14
description of, 8
eXtreme Programming (XP), 15
lightweight methodologies, 14
refactoring, 14
Scrum, 23
See also coding; eXtreme Programming (XP); object-oriented analysis and design (OOA&D); software development
Alexander, Christopher, 137
analysis paralysis, avoiding, 105
architectural patterns, 48
assertEquals(), 204
assertions, using for errors that should never happen in production, 173
B
backlogs
product backlog, 23
sprint backlog, 23
backtracking, 75
bank account example
CheckingAcct class, 110
creating the classes for, 110
InvestmentAcct class, 110
SavingsAcct class, 110
BankAccount class, withdraw(), 120
Beck, Kent, 204
begin-end block boundaries, 163
behavioral design patterns
Iterator pattern, 148
Observer pattern, 150
Strategy pattern, 154
See also design patterns
Bentley, Jon, 184
BirdFeeder class, 103
Birds by Burt example
bird identifier, designing and implementing, 105
class diagrams, creating, 92
close(), 104
complete code listing, 93
decomposing the problem and identifying the objects, 92
design and program changes, anticipating, 105
FeedingDoor class, 103
open(), 104
operate(), code listing, 104
pressButton(), 104
problem statement, defining, 90
RemoteControl class, diagram of, 102–103
RemoteControl use case, 106
requirements list, establishing, 91
Sensor class, 103
simplifying the SongIdentifier and Song classes, code listing, 127
song identifier use case and its alternate, table of, 107
Birds by Burt example (cont.)
SongIdentifier class and delegation, 126
use case for a remote control, creating, 102
use case, creating, 91
blocks and statements, style guidelines, 166
bottom-up assessment, definition of, 73
branch coverage, 196
breakpoints, 188
Brooks' law, 16
buffer overflow problems, 184
Bugzilla, 218
built-in block boundaries, emulating, 164, 166
C
C, 164
change, managing, 44
change control board (CCB), 29
CheckingAcct class, 110
class adapters, 146
class diagrams, 101
definition of, 92
sections of, 92
classes
abstract classes, definition of, 111
abstraction mechanism, 88
arranging in a class hierarchy, 87
BankAccount class, 120
breaking complex classes into simpler ones, 108
class design guidelines, list of, 134–135
classes as having only one responsibility, 103
classes as templates for objects, 87
closing the base class from modification, 120
encapsulating variable behavior in subclasses, 120
generalization, 88
getting the behavior of derived classes right, 125
inheritance, 88
making simple classes that work together, 103
method overriding in derived classes, 126
Open-Closed Principle (OCP), 116, 119
polymorphism, 88
protecting classes from unnecessary change, 116
reuse mechanism, 88
sharing the behavior and attributes of other classes, 126
sub-class, 87
super class, 87
using and re-using single-feature classes, 162
using composition to assemble behaviors from other classes, 128
See also objects
client-server architectural pattern
explanation of, 53
print spoolers, 54
X Windows graphical system, 54
close(), 104
code and fix model
advantages and disadvantages of, 8
description of, 8
code coverage
branch coverage, 196
checking return values, 197
definition of, 196
loop coverage, 196
off-by-one error, 196
straight line code, 196
testing every program statement, 196
testing for an end-of-file (EOF) marker, 197
code inspections
description of, 212
Fagan, Michael, 213
Inspection meeting, 215
inspection phases and procedures, 214
Inspection report, 216
list of roles used, 213
minor and major defects, levels of, 216
Overview meeting, 215
Planning phase, 215
Preparation phase, 215
purpose of, 212
recorded metrics, 217
required criteria, list of, 213
scheduling another inspection meeting, 217
See also code reviews; review methodologies; Software Quality Assurance (SQA)
code patterns, 137
code reviews
including an experienced developer as a disinterested third-party, 212
length of, 212
moderator, 212
no managers allowed, 212
objective of, 212
recorded metrics, 212
roles of the attendees at a code review, 211
tester, 212
See also code inspections; review methodologies; Software Quality Assurance (SQA)
coding
Adams, Douglas, 179
adhering to a programming language's naming conventions, 171
assertions, using, 173
bad code example, critique of, 161
begin-end block boundaries, 163
block layouts, types of, 163
blocks and statements, style guidelines, 166
built-in block boundaries, emulating, 164, 166
C, 164
camel case, using, 171
coding standards, 22
common code ownership, 17–18, 30
comparing the plan-driven and agile development processes, 159
declaration before use rule, 167
defensive programming, definition of, 172
errno global variable, 175
error recovery, suggestions for, 174–176
exceptions, throwing and catching, 176–178
fat interfaces, 162
getMessage(), 177
good layout and formatting, objectives of, 163
goto statements, 166
handling errors that occur at runtime, 174
having a header block comment with methods and functions, 169
having your methods do just one thing, 162
header files and source code, 168
Hunt, Andrew, 160
identifier naming conventions, 170
indentation, using, 165
individual statements, wrapping, 166
JavaDoc comments, 169
layout of, 162
magic numbers, 162
NullPointerException, 176
parentheses, using, 166
Pascal, 164
Pike, Rob, 170
printf(), 175
protecting a program from bad data, guidelines for, 172
putting separate conditions on separate lines, 166
scanf(), 175
software construction metaphor, 160
statement separator symbol, 164
statement terminator symbol, 164
style guidelines, using for a developer team, 171
taking advantage of built-in exception handling, 174
Thomas, David, 160
two audiences for your code, 160
variable declarations, style guidelines, 167
visibility modifiers, 161
Visual Basic, 163
white space, suggestions for using, 165
writing good, informative comments, 168
See also eXtreme Programming (XP); object-oriented analysis and design (OOA&D); software development
cohesion, 64
comments, 162
keeping comments up to date, 168
setting off block comments with blank lines, 168
style guidelines, 168
writing good, informative comments, 168
common code ownership, 17–18, 30
common design characteristics, 115
communication conduits, 48
communications protocols, 55
compilers
debugging syntactic errors, 182
eliminating all compiler errors and warnings before reviews or testing, 182
composition
definition of, 128
Space Rangers example, 128–129
computational structures, 48
computeTax(), 156
concurrency issues, 185
Context, 154
continuous integration, 21
continuous unit testing, 15
control coupling, definition of, 80
controller, definition of, 50
creational design patterns
definition of, 139
Factory pattern, 142
Singleton pattern, 141
Curtis, Bill, 66
D
dangling pointer problems, 184
data coverage
boundary conditions, testing, 197
definition of, 196
good data and bad data, examining, 197
illegal data values, testing, 198
no data, testing for, 198
pre-conditions and post-conditions, testing, 198
too little or too much data, testing for, 198
typical data values, testing, 197
uninitialized variables, testing for, 198
Davis, Alan, 64
debugging
Bentley, Jon, 184
breakpoints, 188
buffer overflow problems, 184
checking out a working copy from a VCS repository, 190
compilers and, 182
concurrency issues, 185
dangling pointer problems, 184
DDD debugger, 188
DEBUG blocks, using and removing, 186
debuggers, 188
debugging as rewarding, 222
Eclipse, 188
eliminating all compiler errors and warnings before reviews or testing, 182
finding the root cause of an error and fixing it, 181
finding the source of an error systematically, techniques for, 185
fixing errors, 188
fixing only one error at a time, 189
fixing the underlying problem, not the symptom, 183
GDB debugger, 188
how not to approach a debugging problem, 183
initialization problems, 184
logic errors, definition of, 183
multi-threaded and multi-process programs, debugging, 188
NetBeans IDE, 188
print statements, inserting, 185
refactoring, 189
reproducing an error reliably, 184
reviewing (inspecting), definition of, 181
semantic errors, definition of, 182
source code control, 189
syntactic errors, definition of, 182
testing the fix, 189
testing, definition of, 182
three types of errors, 182
timing errors, 184
using a debugger to get a stack trace, 184
using the debugging features of an integrated development environment (IDE), 185
version control systems (VCS), 189
walking off the end of an array, 184
watchpoints, 188
working backwards to find and fix errors, 184
See also defects; errors; testing
defects
defect levels, list of, 35
defect tracking systems, information tracked, 218
delivering defect-free code, 209
high defect rates, 29
releasing a program with as few defects as possible, 35
See also debugging; errors; testing
defensive programming
assertions, using, 173
C program code example, 172
definition of, 172
errno global variable, 175
error recovery, suggestions for, 174–176
exceptions, throwing and catching, 176–178
getMessage(), 177
handling errors that occur at runtime, 174
NullPointerException, 176
protecting a program from bad data, guidelines for, 172
taking advantage of built-in exception handling, 174
delegation
definition of, 126
simplifying the SongIdentifier and Song classes, code listing, 127
Delphi method, description of, 31
Dependency Inversion Principle (DIP), 116
definition of, 130
example of, 131
design
good design, characteristics of, 20
simple design, characteristics of, 20
design patterns
Adapter pattern, 146
Alexander, Christopher, 137
behavioral design patterns, 139, 148
code patterns, 137
creational design patterns, 139
criteria for classifying design patterns, 139
definition of, 138
elements of, 138
essential features of, 138
Factory pattern, 142
Gang of Four, 138
Gang of Four's classic design patterns, list of, 139
Iterator pattern, 148
Model-View-Controller (MVC) architectural pattern, 138
Observer pattern, 150
purpose, 139
scope, 139
Singleton pattern, 141
Strategy pattern, 154
structural design patterns, 139, 146
using, 65
why design patterns are needed, 138
Wrapper pattern, 146
See also behavioral design patterns
desk checks, 211
Dijkstra, Edsger, 71, 210, 224
domain requirements, 42
Don't Repeat Yourself Principle (DRY), 116, 121
duty cycle, 32
dynamic analysis, 210
E
Eclipse, 188
egoless programming, 224
eight queens problem
backtracking, 75
complete Java code listing, 84
decomposing a problem until a procedure becomes obvious, 78
description of, 73
examining the problem for a top-level decomposition, 73
proposed solution 1, 73
proposed solution 2, 74
proposed solution 3, 75
refinement 1, 75
refinement 2, 76
stepwise construction of trial solutions, 75
using pseudo-code to find a solution, 76
differentiating from information hiding, 80
encapsulating services and data, 79
errno global variable, 175
errors
buffer overflow problems, 184
compilers and, 182
concurrency issues, 185
dangling pointer problems, 184
DEBUG blocks, using and removing, 186
defect levels, list of, 35
delivering defect-free code, 209
eliminating all compiler errors and warnings before reviews or testing, 182
error recovery, suggestions for, 174–176
exceptions, throwing and catching, 176–178
finding the source of an error systematically, techniques for, 185
fixing errors, 188
getMessage(), 177
handling errors that occur at runtime, 174
high defect rates, 29
initialization problems, 184
logic errors, definition of, 183
NullPointerException, 176
refactoring, 189
releasing a program with as few defects as possible, 35
reproducing an error reliably, 184
semantic errors, definition of, 182
syntactic errors, definition of, 182
taking advantage of built-in exception handling, 174
three types of errors, 182
timing errors, 184
walking off the end of an array, 184
working backwards to find and fix errors, 184
See also debugging; defects; testing
estimating project duration, 20
evolutionary prototyping
advantages and disadvantages of, 14
description of, 13
exploration phase, description of, 22
extensibility, 64
eXtreme Programming (XP)
Beck, Kent, 15
Brooks' law, 16
code as the sole deliverable, 19
coding standards, 22
continuous integration, 21
continuous unit testing, 15
Cunningham, Ward, 15
estimation as the responsibility of the developers, 20
exploration phase, 22
four basic activities of, 19
four core values of, 17
four variables of software development, 16
good design, 20
heavy customer involvement, 15
implementation phase, 22
implementation tasks, 199
keeping the cost of change manageable, 17
life cycle, description of, 22
maintenance mode, 23
mothballing the code and starting over, 23
on-site customer representative, 16
overview of, 15
planning game, 22
productizing phase, 23
redesigning code to make it simpler, 17
risk, minimizing and handling, 16
scope of a project, controlling, 16
short iteration cycles and frequent releases, 16
spike, definition of, 18
starting with fewer resources and a tight budget, 18
stories explaining how the whole system works, 20
stories in XP projects, 199
striving for defect-free code, 18
test-driven development (TDD), 15, 19
12 practices of, 20
using unit tests as a regression test suite, 16
See also agile development models; coding; object-oriented analysis and design (OOA&D); software development
F
Factory pattern
description of, 142
features of, 145
IceCream interface, code example, 143
IceCreamFactory class, code example, 144
See also design patterns
Fagan, Michael, 213
Fairley, Richard, 64
FeedingDoor class, 103
Fowler, Martin, 100
functional specification
author's name, 39
chief architect model, 40
definition of, 38
disclaimer, 39
distinguishing between requirements, policies, and implementations, 43
domain requirements, 42
functional requirements, definition of, 37
functional requirements, four types of, 42
getting customers to respond to a requirements list, 40
including an Open Issues section, 41
including detailed screen-by-screen specifications, 40
keeping a Backlog section, 41
keeping technical and marketing notes in a notebook, 41
managing expectations, 40
never hard-code business policies, 43
non-functional requirements, 43
outline of, 39
overview, 39
project manager model, 40
taking a course in writing, 38
telling the project stakeholders what a program will not do, 40
Unified Modeling Language (UML), 40
use cases, 40
user requirements, example of, 42
value of a good set of functional requirements, 37
writing functional specifications in a natural language, 38
See also project management; requirements digging; Unified Modeling Language (UML); use cases
G
Gamma, Eric, 204
Gang of Four
classic design patterns, list of, 139
design patterns, essential features of, 138
GDB debugger, 188
getInstance(), 142
getMessage(), 177
getNextElement(), 148
getting the behavior of derived classes right, 125
Git, 191
global-data coupling, definition of, 80
goals, definition of, 91
goto statements, 166
gray-box testing, 193
H
hasNext(), 148
hasPrevious(), 150
header files
nesting, 168
source code and, 168
Hertzfeld, Andy, 5
heuristics
abstraction, using, 65
adhering to the Principle of One Right Place, 66
changes, anticipating, 65
common design patterns, using, 65
Davis, Alan, 64
drawing diagrams to visualize a program design, 66
encapsulation, 65
Fairley, Richard, 64
finding real-world objects to model, 64
information hiding, 65
loose coupling, using, 65
modularity, 65
software design and, 63
time-tested heuristics, list of, 64
using well-defined interfaces between modules, 65
Hunt, Andrew, 160
I
identifiers
camel case, using, 171
naming conventions, 170
using descriptive identifiers, 170
implementation phase, 22
implementation tasks, 199
indentation, using, 165
information hiding, 65, 79, 87
differentiating from encapsulation, 80
inheritance, 123
abstraction mechanism, 88
inheritance graph, 88
overloading of operators, 88
polymorphism, 88
reuse mechanism, 88
when inheritance isn't the right thing to do, 126
initialization problems, 184
Inspection meeting, 215
Inspection report, 216
integrated development environment (IDE), using its debugging features, 185
integration testing
gray-box testing, 193
See also testing; unit testing
interfaces
dividing a bloated interface into two or more smaller, more cohesive interfaces, 132
Interface Segregation Principle (ISP), 116
making all interactions between modules through an interface, 79
sharing, 64
using well-defined interfaces between modules, 65
InvestmentAcct class, 110
ISO-OSI layered architectural model, 55
iterative process models
DeMarco, Tom, 12
description of, 12
failing to meet an iteration deadline, 13
Iterator pattern
add(), 150
code example, 149
description of, 148
getNextElement(), 148
hasNext(), 148
hasPrevious(), 150
Iterator interface, 149
Java Collections Framework (JCF), 149
ListIterator, 149
next(), 150
previous(), 150
remove(), 150
traversing a collection one element at a time, 148
See also design patterns
J
Java Collections Framework (JCF), 149
JavaDoc comments, 169
Jenkins, Stephen, 222
JUnit
assertEquals(), 204
assertion library methods, list of, 204
Beck, Kent, 204
definition of, 204
executing a test from the command line, 204
Gamma, Eric, 204
JUnitCore class, executing directly, 205
TestCase base class, extending, 204
TestPhoneContact class, code listing, 205
writing a test in, 204
K
Keyword in Context (KWIC) index
creating the index using top-down decompositon, 81
example of, 81
modular decomposition of, 82
L
Law of Demeter, 116
definition of, 133
keeping dependencies to a minimum, 133
layered architectural approach
communications protocols, 55
explanation of, 54
ISO-OSI layered architectural model, 55
operating systems (OSs), 54
life cycle models
agile development models, 8, 14
Agile Manifesto web page, 8
Brooks' law, 16
code and fix model, 8
DeMarco, Tom, 12
evolutionary prototyping, 13
eXtreme Programming (XP), 15
15 principles of eXtreme Programming, 17–19
four basic activities of eXtreme Programming, 19
four core values of eXtreme Programming, 17
four variables of software development, 16
iterative process models, 12
keeping the cost of change manageable, 17
lightweight methodologies, 14
nailing down requirements at the beginning of a project, 10
plan-driven models, 8
refactoring, 14
risk, minimizing and handling, 16
Royce, Winston, 9
scope of a project, controlling, 16
sequence of steps, 7
Software Engineering Institute (SEI), 14
12 practices of eXtreme Programming, 20
types of, 7
using unit tests as a regression test suite, 16
viewing from the perspective of object-oriented analysis and design, 89
waterfall model, 9
waterfall with feedback model, 11
See also coding; eXtreme Programming (XP); object-oriented analysis and design (OOA&D); software development
lightweight methodologies
characteristics of, 14
debunking its myths, 14
linear problem-solving approach, 60
Liskov Substitution Principle (LSP)
getting the behavior of derived classes right, 125
indications that you're violating the Liskov Substitution Principle, 126
Martin, Robert, 124
method overriding in derived classes, 126
Rectangle/Square example, 123
sharing the behavior and attributes of other classes, 126
Square class, 124
when inheritance isn't the right thing to do, 126
ListIterator, 149
logic errors, definition of, 183
loop coverage, 196
loose coupling
control coupling, 80
definition of, 79
four broad categories of, 80
global-data coupling, 80
keeping dependencies to a minimum, 133
loosely coupled modules, 64–65
Principle of Least Knowledge (PLK), 133
Principle of Loose Coupling, 116
simple data coupling, 80
structured data coupling, 80
M
magic numbers, 162
main program – subroutine architectural pattern, 56
maintenance mode, 23
McConnell, Steve, 160–161, 194
methods
doing too many things, 162
fat interfaces, 162
having a header block comment with methods and functions, 169
having your methods do just one thing, 162
magic numbers, 162
naming, 162
protecting from bad data, 162
smaller functions as easier to test, 163
using and re-using small, single-feature methods, 162
using too many input parameters, 162
Meyer, Bertrand, 100
misunderstood requirements, 29
MobilePhone class, 122
Model-View-Controller (MVC) architectural pattern, 138
controller, definition of, 50
describing the flow of an MVC program, 50
explanation of, 49
model, definition of, 50
Nifty Assignment example, 51
view (viewport), definition of, 50
See also design patterns
modular decomposition
aiming for high cohesion in a module, 79
encapsulation, 79
information hiding, 79
interfaces, 79
Keyword in Context (KWIC) index, 81
loose coupling, 79
modularity, three characteristics of, 79
separation of concerns, 79
N
Nestor, John, 67
NetBeans IDE, 188
new keyword, 141
next(), 150
Nifty Assignment example
creating the model, view, and controller objects, 53
description of, 51
organization of the program, UML object diagram, 52
non-functional requirements, 43
O
object adapters, 146
object-oriented analysis and design (OOA&D)
abstract classes, definition of, 111
aggregation, definition of, 130
analysis paralysis, avoiding, 105
bank account example, 110
BankAccount class, 120
BirdFeeder class, 93
Birds by Burt example, complete code listing, 93
Birds by Burt example, defining the program elements, 90
breaking complex classes into simpler ones, 108
candidate objects, identifying and describing, 108
candidate objects, organizing into groups, 109
object-oriented analysis and design (OOA&D) (cont.)
class design guidelines, list of, 134–135
classes as having only one responsibility, 103
closing the base class from modification, 120
coding to an interface rather than an implementation, 117
common design characteristics, 115
composition, definition of, 128
composition, Space Rangers example, 128–129
conceptual model, creating, 100
decomposing the problem and identifying the objects, 92
delegation, example of, 126–128
Dependency Inversion Principle (DIP), 116, 130
describing in terms of the software development life cycle, 89
differentiating analysis from design, 100
Don't Repeat Yourself Principle (DRY), 116, 121
duplicating code as duplicating behavior, 121
duplication of design and code, avoiding, 110
encapsulating variable behavior in subclasses, 120
encapsulation, 122
essential features, definition of, 100
examining your features list and requirements for duplications, 121
Fowler, Martin, 100
getting the behavior of derived classes right, 125
having one requirement in one place, 121
indications that you're violating the Liskov Substitution Principle, 126
inheritance, 123
Interface Segregation Principle (ISP), 116, 132
iterative nature of, 105
Liskov Substitution Principle (LSP), 116, 123
making simple classes that work together, 103
Martin, Robert, 124
method overriding in derived classes, 126
Meyer, Bertrand, 100
object-oriented analysis as anticipating change, 105
object-oriented analysis as creating a conceptual model of a problem domain and its solution, 100
object-oriented analysis, definition of, 88, 100
object-oriented analysis, separating from design, 107
object-oriented design as creating an object model of a solution, 100
object-oriented design as managing change, 105
object-oriented design principles, list of, 116
object-oriented design, definition of, 88
object-oriented design, objectives of, 103
Open-Closed Principle (OCP), 116, 119
Point class, 117
Principle of Least Knowledge (PLK), 116, 133
Principle of Loose Coupling, 116
private methods, extending, 120
problem statement, defining, 90
process steps in analysis and design, 88
producing a work product, 100
protecting classes from unnecessary change, 116
Rectangle/Square example, 123
refactoring, 119
requirements list, establishing, 91
Shape interface, 117
sharing the behavior and attributes of other classes, 126
simplifying the SongIdentifier and Song classes, code listing, 127
Single Responsibility Principle (SRP), 108, 116, 122
song identifier use case and its alternate, table of, 121
SongIdentifier class, 126
Square class, 124
textual analysis, definition of, 101
use case for Birds by Burt, revising, 102
use case, definition of, 91
Violinist class, 116
ViolinStyle class, 117
virtual methods, 126
when inheritance isn't the right thing to do, 126
See also coding; eXtreme Programming (XP); software development
objects
objects as members of classes, 87
passing messages to, 87
possessing identity, state, and operations, 87
using encapsulation and information hiding, 87
See also classes
Observer pattern
description of, 150
Observer interface, code example, 152
pull Observer, 151
push Observer, 151
Subject interface, code example, 151
See also design patterns
off-by-one error, 196
open(), 104
Open-Closed Principle (OCP), 116, 119
operate(), code listing, 104
operating systems (OSs), 54
opportunity-driven problem-solving approach, 61
overloading of operators, 88
Overview meeting, 215
P, Q
pair programming, 30, 191, 224
parentheses, using, 166
Pascal, 164
person-hours, estimating project tasks in, 31
phone contacts example
creating the tests, 200
establishing the tasks, 199
file opening test, code example, 203
PhoneContact class, code listing, 200
PhoneContactList class, code listing, 203
TestDriver class, code example, 202
TestPhoneContact class, default constructor, 200
writing the story, 199
Pike, Rob, 170
pipe-and-filter architectural pattern
anagram example, 48
disadvantages of, 49
explanation of, 48
plan-driven models
description of, 8
Royce, Winston, 9
waterfall model, 9
planning game, description of, 22
Planning phase, 215
play(), 117
Point class, 117
polymorphism, 88
portability, 64
post-mortem, performing after every project, 35
PowerPoint, using effectively, 34
Preparation phase, 215
pressButton(), 104
previous(), 150
Principle of Least Knowledge (PLK), 116
definition of, 133
keeping dependencies to a minimum, 133
Principle of Loose Coupling, 116
Principle of One Right Place, 66
print spoolers, 54
printf(), 175
productizing phase, description of, 23
project management
addressing identifiable risks through avoidance and mitigation, 30
change control board (CCB), 29
common code ownership, 30
communicating bad news about a project, 34
defect levels, list of, 35
Delphi method, description of, 31
DeMarco, Tom, 30
estimating project size and required effort, 31
estimating project tasks in person-hours, 31
figuring out a realistic duty cycle, 32
high defect rates, 29
ignoring a wild-assed guess (WAG), 31
introducing defects (errors) into a program, 35
knowing the dependencies between tasks, 32
making a detailed breakdown of features into tasks, 31
measuring the velocity of each task, 33
misunderstood requirements, 29
pair programming, 30
performing a post-mortem after every project, 35
PowerPoint, using effectively, 34
product backlog, 29
project plan, contents of, 27
project plan, project organization section, 28
project plan, project oversight section, 34
project plan, project schedule section, 31
project plan, resource requirements section, 30
project plan, risk analysis section, 28
project plan, work breakdown and task estimates section, 31
project status report, presenting, 34
project-scheduling software, using, 32
releasing a program with as few defects as possible, 35
requirements churn, 29
schedule slips, 28
Spolsky, Joel, 32
Spolsky's painless schedule, 33
turnovers, reducing, 30
See also functional specification; requirements digging
pull Observer, 151
purpose, 139
push Observer, 151
R
Rectangle/Square example, 123
characteristics of, 21
release backlog, 45
RemoteControl class
diagram of, 102
integrating into the program, 103
remove(), 150
requirements digging
categorizing requirements, 45
definition of, 43
managing change, 44
non-technical problems with requirements, 45
overcoming problems with project scope and requirements creep, 44
prioritizing requirements based on customer input, 45
problems of domain understanding, 44
questions to ask when examining requirements, 45
requirements churn, 29
See also functional specification; project management
return values, checking, 197
reuse mechanism, 88
review methodologies
Bugzilla, 218
code inspections, 212
code reviews, three types of, 211
defect tracking systems, information tracked, 218
defect tracking systems, typical workflow, 218
desk checks, 211
performing code reviews right after unit testing, 211
reviewing (inspecting), definition of, 181
summarizing the characteristics of the three review methodologies, 217
walkthroughs, 211
See also code inspections; code reviews
risk
addressing identifiable risks through avoidance and mitigation, 30
minimizing and handling, 16
Royce, Winston, 9
S
SavingsAcct class, 110
scanf(), 175
schedule slips, 28
scope, 139
controlling the scope of a project, 16
overcoming problems with project scope and requirements creep, 44
Scrum
acceleration, definition of, 24
characteristics of, 23
daily Scrum meetings, 24
development of, 23
product backlog, 23
release backlog, 45
Scrum master, 24
Scrum retrospective, 24
sprint backlog, 23
sprints, definition of, 23
semantic errors, definition of, 182
Sensor class, 103
separation of concerns, 79
setUpMusic(), 117
Shape interface, 117
simple data coupling, 80
Single Responsibility Principle (SRP), 108, 116, 122
Singleton pattern
code example, 141
creating a class that can be instantiated only once, 141
description of, 141
getInstance(), 142
new keyword, 141
synchronized keyword, 142
See also design patterns
software architecture
architectural patterns, 48
client-server architectural pattern, 53
communication conduits, 48
computational structures, 48
detailed design versus style, 47
layered architectural approach, 54
main program – subroutine architectural pattern, 56
Model-View-Controller (MVC) architectural pattern, 49
object-oriented architectural patterns, 49
pipe-and-filter architectural pattern, 48
representing software architectures visually as black box graphs, 48
two levels of software design, 47
Wirth, Niklaus, 56
See also design patterns
software design
Conklin, Jeff, 60
Curtis, Bill, 66
design as iterative, 67
design as messy, 62
designers and creativity, 66
desirable design characteristics, 63
dividing software problems into two layers, 59
ease of maintenance, 63
extensibility, 64
fitness of purpose, 63
great software designers, characteristics of, 67
having knowledge of the problem domain, 67
heuristics, 63
high cohesion within a module, 64
interfaces, 64
linear problem-solving approach, 60
loosely and tightly coupled modules, 64
modularity, 63
Nestor, John, 67
opportunity-driven problem-solving approach, 61
portability, 64
refactoring, 63
simplicity, 63
steps in solving a software-design problem, 66
understanding the design process, 62
software development
admitting when a project is behind, 4
communicating with team members, 2
communicating with the customer, 3
debugging as rewarding, 222
definition of, 1
developing software well, requirements for, 2
Dijkstra, Edsger, 224
distinguishing software development from software engineering, 1
egoless programming, 224
embracing failure when writing software, 222
employing small, well-integrated teams, 2
following a project plan that everyone buys into, 3
Hertzfeld, Andy, 5
holding regular status meetings, 3
Jenkins, Stephen, 222
joining the ACM and the IEEE-CS, 224
key issue that divides plan-driven development and agile development, 222
pair programming, 224
picking the right set of development tools, 4
reading a lot of code, 2
reading about how great programmers think, work and code, 223
reading about problem solving and design, 223
requirements churn, managing, 4
risk, handling flexibly, 3
simple tools, using, 222
small teams build the best software, 222
software development, learning, 2
suggestions on becoming a better software developer, 223
writing software as a creative activity, 222
See also coding; eXtreme Programming (XP); life cycle models; object-oriented analysis and design (OOA&D)
Software Engineering Institute (SEI), 14
Software Quality Assurance (SQA)
Bugzilla, 218
characteristics of software quality from the user's perspective, 209
debugging as rewarding, 222
debugging your code, 210
Software Quality Assurance (SQA) (cont.)
defect tracking systems, information tracked, 218
defect-free code, delivering, 209
Dijkstra, Edsger, 210
dynamic analysis, 210
limitations of testing, 210
reviewing your code, 210
static analysis, 210
testing your code, 210
See also code reviews
source code control, 189
Space Rangers example, using composition to assemble behaviors from other classes, 128–129
spike, definition of, 18
Spolsky, Joel
project-scheduling software, using, 32
Spolsky's painless schedule, 33
sprints
definition of, 23
sprint backlog, 23
Square class, 124
statement separator symbol, 164
statement terminator symbol, 164
static analysis, 210
status reviews and presentations, 34
stepwise refinement
backtracking, 75
bottom-up assessment, definition of, 73
decomposing a problem until a procedure becomes obvious, 78
definition of, 72
eight queens problem, 73
stepwise construction of trial solutions, 75
top-down refinement, definition of, 72
straight line code, 196
Strategy pattern
computeTax(), 156
Context, 154
creating the Context class, code example, 156
creating the TaxStrategy classes, code example, 155
description of, 154
Strategy interface, 154
usage examples, 154
See also design patterns
structural design patterns
Adapter pattern, 146
Wrapper pattern, 146
structured data coupling, 80
structured programming
bottom-up assessment, definition of, 73
definition of, 71
Dijkstra, Edsger, 71
stepwise refinement, 72
top-down refinement, definition of, 72
sub-class, 87
Subject interface, code example, 151
Subversion, 191
super class, 87
synchronized keyword, 142
syntactic errors, definition of, 182
system testing
black-box testing, 194
T
tame problems
characteristics of, 62
definition of, 59
example of, 62
technical specification, definition of, 38
test-driven development (TDD), 19
writing unit tests before coding, 195
testing
adversarial roles of developers and testers, 195
Beck, Kent, 204
characteristics of, 198
code coverage, 196
combinatorial explosion problem, 194, 196
combining static (code reading) and dynamic (testing) techniques, 194
data coverage, 196
definition of, 182
developers as lousy testers, 195
exploration, 199
Gamma, Eric, 204
gray-box testing, 193
how to write a test, 199
implementation tasks, 199
increasing code complexity and increasing the number of possible errors, 194
JUnit, 204
Martin, Robert, 198
McConnell, Steve, 194
off-by-one error, 196
phone contacts example, 199
stories in XP projects, 199
testing only a single concept in your code, 199
three levels of, 193
what to test, 196
when to test, 195
white-box testing, 193
writing unit tests before and after coding, 195
See also debugging; defects; errors; integration testing; testing; unit testing
textual analysis
definition of, 101
picking out the nouns and verbs in a use case, 101
Thomas, David, 160
tightly coupled modules, 64
timing errors, 184
top-down decompositon, 81
top-down refinement, definition of, 72
tuneInstrument(), 117
turnover
best ways to reduce turnover, 30
mitigating the effects of, 30
two levels of software design, 47
U
Unified Modeling Language (UML), 40
generalization, definition of, 112
using open arrows to indicate inheritance, 112
See also functional specification; use cases
unit testing
characteristics of, 198
developer's responsibility for, 195
how to write a test, 199
importance of, 208
phone contacts example, 199
white-box testing, 193
writing unit tests before and after coding, 195
See also integration testing; testing
use cases, 40
actor, definition of, 91
actors, identifying, 109
creating, 101
definition of, 91
describing several scenarios, 109
examining the external behavior of a program, 91
goal, definition of, 91
identifying new objects, 102
illustrating different scenarios in the use of a program, 107
MobilePhone class, 122
RemoteControl use case, 106
revising the use case for Birds by Burt, 102
song identifier use case and its alternate, table of, 107, 121
using textual analysis to pick out the nouns and verbs in a use case, 101
See also functional specification; Unified Modeling Language (UML)
user requirements, example of, 42
V
variables
declaration before use rule, 167
variable declarations, style guidelines, 167
version control systems (VCS)
copy-modify-merge strategy, 190
Git, 191
incomplete merge strategy, 191
lock-modify-unlock strategy, 190
pair programming, 191
serializing changes in the repository, 190
Subversion, 191
view (viewport), definition of, 50
Violinist class
diagram of, 116
play(), 117
setUpMusic(), 117
tuneInstrument(), 117
ViolinStyle class, diagram of, 117
virtual methods, 126
visibility modifiers, 161
Visual Basic, 163
W
walkthroughs
confirming small changes to code after fixing an error, 211
roles of the code author and reviewer, 211
watchpoints, 188
waterfall model
description of, 9
disadvantages of, 10
waterfall with feedback model
advantages and disadvantages of, 11
description of, 11
white space, suggestions for using, 165
white-box testing, 193
wicked problems
characteristics of, 60
definition of, 59
examples of, 60
wild-assed guess (WAG), ignoring, 31
Wirth, Niklaus, 56
withdraw(), 120
working copy, 190
Wrapper pattern, description of, 146
X, Y, Z
X Windows graphical system, 54