Survey
* Your assessment is very important for improving the workof artificial intelligence, which forms the content of this project
* Your assessment is very important for improving the workof artificial intelligence, which forms the content of this project
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