Download Producing Industrial-Quality Software

94.204* Object-Oriented Software
Development
Unit 3
Producing Industrial-Quality Software
•
Copyright © 2002, Systems and Computer Engineering,
Carleton University. 94.204-03-IndustrialSW.ppt
revised January 2002
1
What is Industrial-Quality Software?
• Often characterized as:
– bug-free
– efficient
• execution time
• memory requirements
• Of equal importance, industrial-quality
software is software than can be
understood and maintained by someone
other than the original author
Copyright © 2002, Systems and Computer Engineering,
Carleton University. 94.204-03-IndustrialSW.ppt
2
Defensive Programming
• Separation and information hiding are not
secrecy, they are safety measures
– Be defensive: always worry about
dealing with all situations
– Be paranoid: worry about those
situations that can never happen - they
will
• Principle of Maximal Paranoia
– “No matter how unlikely, or even
impossible, a situation or state is, the
first user, on the first day of release of
the software, will cause the software to
enter that state.”
– This is a failure of the programmer to
anticipate the occurrence of the set of
inputs that put the program in that state
Copyright © 2002, Systems and Computer Engineering,
Carleton University. 94.204-03-IndustrialSW.ppt
3
Defensive Programming
• In other words: any program that ‘crashes’
is a failure
• General protection faults (Windows), bus
errors and segmentation violations never
happen in good programs
• A good program always dies gracefully if
it comes upon a situation and/or state with
which it cannot deal
• Please practice defensive programming
Copyright © 2002, Systems and Computer Engineering,
Carleton University. 94.204-03-IndustrialSW.ppt
4
Defensive Programming
• Practical suggestions for defensive
programming :
– Check all inputs before using.
– Check all arguments before using
within a method
– Always check the validity of your
object references before using
• After creating an object
• Whenever a method returns an
object reference.
• Your code should be littered with
– If ( object == null ) …
– Exceptions are exceptionally useful.
We shall teach them thoroughly later
but you have to use them.
Copyright © 2002, Systems and Computer Engineering,
Carleton University. 94.204-03-IndustrialSW.ppt
5
Software Maintenance
• studies have shown that up to 80% of the
total cost of a piece of software is the cost
of maintenance:
– bug fixes
– improvements to implementation; e.g.
recoding a function to decrease
execution time or memory usage
– adding new features
• object-oriented programming may decrease
maintenance costs (too early to tell)
– in theory, OO programs should have
fewer bugs than traditional structured
programs (decreasing cost)
Copyright © 2002, Systems and Computer Engineering,
Carleton University. 94.204-03-IndustrialSW.ppt
6
Software Maintenance
• however, classes tend to evolve as they are
reused over several projects
– as we reuse classes, we often identify
the need for the objects to provide
additional behaviour
• for the forseeable future, maintenance will
comprise a significant % of a typical
software developer’s work
• it is unlikely that software will be
maintained for its entire life by the original
developer
– we can’t afford to throw away software
just because its author has left the
company
Copyright © 2002, Systems and Computer Engineering,
Carleton University. 94.204-03-IndustrialSW.ppt
7
Coding Conventions
• to reduce maintenance costs, we must
produce code that can be read and
understood by someone other than the
original author
• to ensure this, many companies have inhouse coding conventions that are followed
by all software developers
• typically specify:
– guidelines for picking identifier names
– code layout (indentation, use of blank
lines and spaces)
– commenting conventions
Copyright © 2002, Systems and Computer Engineering,
Carleton University. 94.204-03-IndustrialSW.ppt
8
Coding Conventions
• Sun’s coding conventions for Java are on
the course Web site
– read them, ask questions if you don’t
understand them
• The following conventions must be used
on all of your assignments, and in the tests
and exams.
• Naming convention (by example)
– Classes : ClassName
– Methods : method(arg1, arg2)
• Note spaces !
– Variables : variableName
– Constants : CONSTANT_NAME
Copyright © 2002, Systems and Computer Engineering,
Carleton University. 94.204-03-IndustrialSW.ppt
9
Coding Conventions
• Indentation convention (Version 1)
public ClassName
{
ClassName(int a, int b,
float b)
{
if (condition)
{
statement;
}
else
{
statement;
}
}
}
Copyright © 2002, Systems and Computer Engineering,
Carleton University. 94.204-03-IndustrialSW.ppt
10
Coding Conventions
• Indentation convention (Version 2)
public ClassName
{
ClassName(int a, int b,
float b)
{
if (condition){
statement;
} else {
statement;
}
}
}
Copyright © 2002, Systems and Computer Engineering,
Carleton University. 94.204-03-IndustrialSW.ppt
11
Documenting Code
Soapbox Time
• detailed design information for a software
module belongs in the source code, not in
separate documents
• e.g., for a Java class, we need to provide
– class specification (public methods,
variables, and constants)
• in other words, the information that
someone who wants to use the class
needs to know
– Notes about implementation details
• the information that someone who is
going to modify the class needs to
know
Copyright © 2002, Systems and Computer Engineering,
Carleton University. 94.204-03-IndustrialSW.ppt
12
Documenting Code
• literate programming (Knuth)
– use tools to extract source code and
design documents from a single
document
– Java has been influenced by this
philosophy
Copyright © 2002, Systems and Computer Engineering,
Carleton University. 94.204-03-IndustrialSW.ppt
13
Comments in Java Programs
• Java programs can have two kinds of
comments:
– implementation comments
– documentation comments
• the term “interface comment” would
be more accurate than
“documentation comment”, but
“interface” already has a special
meaning in Java, and the meaning of
“documentation comment” is widely
understood in the Java community,
so we’ll stick with that term
Copyright © 2002, Systems and Computer Engineering,
Carleton University. 94.204-03-IndustrialSW.ppt
14
Implementation Comments
• used to comment out code or explain
implementation details
• identical syntax to C++ comments
(delimited by /*...*/ and //)
Copyright © 2002, Systems and Computer Engineering,
Carleton University. 94.204-03-IndustrialSW.ppt
15
Documentation Comments
• “documentation comments are meant to
describe the specification of the code, from
an implementation-free perspective, to be
read by developers who might not
necessarily have the source code at hand”
– Sun’s Java coding conventions
Copyright © 2002, Systems and Computer Engineering,
Carleton University. 94.204-03-IndustrialSW.ppt
16
Documentation Comments
• documentation comments delimited by
/** and */
• documentation comments can be placed
immediately before
– class definitions
– interface definitions
– member variable and constant
definitions
– method and constructor definitions
Copyright © 2002, Systems and Computer Engineering,
Carleton University. 94.204-03-IndustrialSW.ppt
17
Documentation Comments
• documentation comments can contain tags
that denote comment information that is to
be processed in specific ways
• documentation comments can contain
HTML tags
• Java SDK provides javadoc to build
Web pages from documentation comments
extracted from .java files
– look at Complex.java and
Complex.html
Copyright © 2002, Systems and Computer Engineering,
Carleton University. 94.204-03-IndustrialSW.ppt
18
General Format of a Documentation
Comment
/**
* One sentence summary,
* spanning as
* many lines as required.
*
* Additional sentences
* provide other
* useful information.
*
* @tag ...
* @tag ...
* ...
*/
Copyright © 2002, Systems and Computer Engineering,
Carleton University. 94.204-03-IndustrialSW.ppt
19
Some Tags
@author
– lists author(s), affiliations
– e.g.,
@author D.L. Bailey
Carleton University
@version
– used to list version #, release date
– e.g.,
@version 1.3 January 21,
1999
Copyright © 2002, Systems and Computer Engineering,
Carleton University. 94.204-03-IndustrialSW.ppt
20
Some Tags
@param
– provides name and description of one
method parameter
– e.g.,
@param rp the new value
for the real part of this
Complex number.
– can only appear in method/constructor
documentation comments
– convention: one @param tag per
parameter, listed in same order as they
appear in the parameter list
Copyright © 2002, Systems and Computer Engineering,
Carleton University. 94.204-03-IndustrialSW.ppt
21
Some Tags
@return
– describes what is returned by non-void
methods
– e.g.,
@return a new Complex
number equal to the sum of
this Complex number and c.
Copyright © 2002, Systems and Computer Engineering,
Carleton University. 94.204-03-IndustrialSW.ppt
22
Some Tags
@see
– provides a cross-reference (hypertext
link) to another class, interface, method,
or variable, or to another Web page.
– e.g.,
@see
Complex#Complex(double)
Copyright © 2002, Systems and Computer Engineering,
Carleton University. 94.204-03-IndustrialSW.ppt
23
Example - A Class Documentation
Comment
/**
* This class is a partial
implementation of
* a complex number ADT.
*
* @author D.L. Bailey,
* Department of Systems and Computer
Engineering,
* Carleton University
* @version 1.3 January 21, 1999
*/
public class Complex implements
Cloneable
{
…
}
Copyright © 2002, Systems and Computer Engineering,
Carleton University. 94.204-03-IndustrialSW.ppt
24
Example - A Variable Documentation
Comment
/** Real part. */
private double real;
Copyright © 2002, Systems and Computer Engineering,
Carleton University. 94.204-03-IndustrialSW.ppt
25
Example - A Method Documentation
Comment
/**
* Return the sum of this Complex
number and its
* argument.
*
* @param c the Complex number that
* is to be added to this number.
* @return a new Complex number equal
* to the sum of this Complex number
* and c.
*/
public Complex plus(Complex c)
{
…
}
Copyright © 2002, Systems and Computer Engineering,
Carleton University. 94.204-03-IndustrialSW.ppt
26
Using javadoc
• to build a Web page for Complex.java,
type:
javadoc -version -author private Complex.java
– command-line options:
-version: include @version
paragraphs in the Web page
-author: include @author
paragraphs in the Web page
-private: list all classes,
methods, and variables defined in
Complex.java
Copyright © 2002, Systems and Computer Engineering,
Carleton University. 94.204-03-IndustrialSW.ppt
27
Using javadoc
• javadoc creates:
– Complex.html
– AllNames.html (index of all fields
and methods)
– misc. other HTML files
Copyright © 2002, Systems and Computer Engineering,
Carleton University. 94.204-03-IndustrialSW.ppt
28
Testing
• experienced software developers realize
that the "big bang" approach to software
development (code all modules, glue them
together, throw them on the bare machine)
doesn't work
• testing (usually split into verification and
validation phases) must take place
throughout the life cycle, beginning with
early requirements gathering and
continuing through to acceptance testing of
the final product
• in this course, we’ll focus on testing code
Copyright © 2002, Systems and Computer Engineering,
Carleton University. 94.204-03-IndustrialSW.ppt
29
Testing
• a widely accepted approach for testing
code comprises:
– unit testing of modules (test each
module in isolation)
– integration testing (link modules into a
subsystem, test subsystem, repeat)
– beta-testing (common with commercial
"shrink-wrap" software)
– acceptance testing (install software at
customer's site and test with customersupplied data)
Copyright © 2002, Systems and Computer Engineering,
Carleton University. 94.204-03-IndustrialSW.ppt
30
Software Maintenance & Testing
• when we change a software module, we
must verify that
– the new code works
– we haven’t introduced bugs into
previously correct code
• we need to develop and run tests on the
new code
• we need to retest old code, using the same
tests that it previously passed
– called “regression testing”
Copyright © 2002, Systems and Computer Engineering,
Carleton University. 94.204-03-IndustrialSW.ppt
31
Test Harnesses
• traditionally, to unit test a module, we
develop a test harness (a program to
exercise the module)
• harness sends inputs to the module,
verifies outputs with known correct results
• how do we ensure that an evolving module
and its test harness stay in synch?
Copyright © 2002, Systems and Computer Engineering,
Carleton University. 94.204-03-IndustrialSW.ppt
32
The OO Paradigm and Testing
• object-oriented languages allow the
software developer to enforce
encapsulation, information hiding
• in theory, OO programs should be easier to
test than traditional structured programs
– objects have well defined interfaces, no
global data structures, etc.
Copyright © 2002, Systems and Computer Engineering,
Carleton University. 94.204-03-IndustrialSW.ppt
33
Testing Java Classes
• when developing Java objects:
– instance variables should normally be
private
– methods that provide operations that
can be requested by clients of the object
are public; methods that are only
invoked internally should be private
• this means that clients of the object can
only alter its state indirectly, by sending
messages to the object
– (for now, we are ignoring Java's
protected variables and methods)
Copyright © 2002, Systems and Computer Engineering,
Carleton University. 94.204-03-IndustrialSW.ppt
34
Testing Java Classes
• an important consequence of this:
– if an object ends up in an incorrect
state, we can narrow the search for the
problem to the object's class
• a Java class can serve as its own test
harness
– every class can have a main() method
– we put unit tests for the class in this
method
• create instances of the class
• send messages to the instances
• verify that the requested operations
were performed correctly
Copyright © 2002, Systems and Computer Engineering,
Carleton University. 94.204-03-IndustrialSW.ppt
35
Testing Java Classes
• we test the class by compiling it and
running it under the java interpreter
(which calls the class's main() method)
• when this class is combined with other
classes to form a complete program, only
the main() method of the top-level
application class is executed
Copyright © 2002, Systems and Computer Engineering,
Carleton University. 94.204-03-IndustrialSW.ppt
36
Testing Class Complex
• look at main() for class Complex,
which tests the class in a bottom-up
manner
• it begins by verifying that the constructors
are correct
– any errors must be in the constructors
and/or the toString() method, since
no other methods are used
• it then tests the accessor methods
• it then tests the mutator methods, followed
by the plus() method (tests use
accessors)
• finally, it tests equals() and clone()
(clone() test invokes equals())
Copyright © 2002, Systems and Computer Engineering,
Carleton University. 94.204-03-IndustrialSW.ppt
37
Testing Class Complex
• to test class Complex, we compile it and
run it
• if you are using the Java SDK, type the
following commands at the O/S prompt:
javac Complex.java
java Complex
Copyright © 2002, Systems and Computer Engineering,
Carleton University. 94.204-03-IndustrialSW.ppt
38
Testing Apps that Use Class Complex
• suppose we use the tested complex number
class in a program that models RLC
circuits
– its top-level class is called
CircuitSimulator
– this class creates instances of class
Complex
– class CircuitSimulator has a
main() method - the program's entry
point
Copyright © 2002, Systems and Computer Engineering,
Carleton University. 94.204-03-IndustrialSW.ppt
39
Testing Apps that Use Class Complex
• to run the program:
javac
CircuitSimulator.java
java CircuitSimulator
• program begins execution in main() in
CircuitSimulator
• class Complex is linked into the program;
however, its main() method is not
invoked
Copyright © 2002, Systems and Computer Engineering,
Carleton University. 94.204-03-IndustrialSW.ppt
40