copyright © 2002, systems and computer engineering, carleton university. 94.204-03-industrialsw.ppt...

Copyright © 2002, Systems and Computer Engineering, Carleton University. 94.204-03-IndustrialSW.ppt

1

94.204* Object-Oriented Software Development

Unit 3

Producing Industrial-Quality Software

• revised January 2002


2

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


3

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


4


• 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


5


• 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.


6

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)


7

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


8

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 in-house 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


9

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


10

Coding Conventions

• Indentation convention (Version 1)

public ClassName

{

ClassName(int a, int b,

float b)

{

if (condition)

{

statement;

}

else

{

statement;

}

}

}


11

Coding Conventions

• Indentation convention (Version 2)

public ClassName

{

ClassName(int a, int b,

float b)

{

if (condition){

statement;

} else {

statement;

}

}

}


12

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


13

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


14

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


15

Implementation Comments

• used to comment out code or explain implementation details

• identical syntax to C++ comments (delimited by /*...*/ and //)


16

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


17


• 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


18


• 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


19

General Format of a Documentation Comment

/** * One sentence summary, * spanning as * many lines as required. * * Additional sentences * provide other * useful information. * * @tag ... * @tag ... * ... */


20

Some Tags

@author

– lists author(s), affiliations

– e.g., @author D.L. BaileyCarleton University

@version

– used to list version #, release date

– e.g., @version 1.3 January 21, 1999


21

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


22

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.


23

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)


24

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

{

…

}


25

Example - A Variable Documentation Comment

/** Real part. */

private double real;


26

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)

{

…

}


27

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


28

Using javadoc

• javadoc creates: – Complex.html – AllNames.html (index of all fields

and methods) – misc. other HTML files


29

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


30

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 customer-supplied data)


31

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”


32

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?


33

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.


34

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)


35


• 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


36


• 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


37

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())


38

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


39

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


40

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...

Documents