COMP 325 Lecture 14: Selected Implementation Issues
major resources: Object-Oriented and Classical Software Engineering 6ed, Schach 2005, Object-Oriented Software Engineering, Schach 2008.

[ previous | schedule ]

Implementation Workflow

• Ah, finally we get to program... :)
• we will focus on only a few implementation issues
• review of OO concepts
• translating UML to Java
• accessor methods
• documentation of methods
• single point control
• coding standards and conventions
• testing during the implementation workflow

Review of OO Concepts

• Object has identity, behavior, and state. What Java concepts embody them?
• What is a static variable? A static method?
• Does a subclass inherit the private members of its superclass?
• What are the rules for assigning an object of one class to a variable of a different class?
• What is the difference in Java between an abstract class and an interface?
• What is the difference between overriding a method and overloading it?
• What is polymorphism?

Translating UML to Java code

• Start with UML diagrams representing design
• CASE tool may generate code automatically
• Generated code (manual or auto) will be incomplete "skeleton"
• Different types of diagrams map to different aspects of the code
• Translating class diagrams
• Translating sequence diagrams
• Translating state diagrams

Accessor Methods

• source: The Object Primer, 3rd Edition, Scott Ambler, Cambridge University Press, 2004. See www.agilemodeling.com
• Attributes should be accessed using getters (obtain value) and setters (modify value)
• Tradeoff is a slightly slower performance in exchange for reduced coupling and improved robustness, flexibility and maintainability
• Getter named "getAttribute" ("isAttribute" for boolean attributes), where "attribute" is its name
• Setter named "setAttribute", where "attribute" is its name
• visibility should be as restricted as possible
  • easy to think of accessors as public, but it shouldn't always be so
  • advocates using accessors to access attributes even within the same class, better flexibility to change implementation
  • advocates using accessors in subclasses to access inherited attributes, reduces inheritance coupling
  • accessors used only within class should be private; if needed by subclass make protected
• Encapsulates changes to attributes - can modify implementation w/o affecting others
• Not necessarily one-to-one correspondence between accessors and attributes; for instance read-only getPercentage() accessor may actually be calculated (e.g. return count/total * 100.0)
• Recall that C# properties automatically generate and enforce public accessors as wrappers around attributes

Documentation of Methods

• source: The Object Primer, 3rd Edition, Scott Ambler, Cambridge University Press, 2004. See www.agilemodeling.com
• comments appear at the top of the method and embedded
• use Javadoc comments (/** */) for "public" explanation of specification and relevant implementation details (e.g. use of specific sorting algorithm)
• use regular comments (/* */ or //) for "private" explanation needed for maintenance (it may be you!)
• Public explanations for clients include
  • what the method does
  • explanation of parameters - Javadoc has @param tag for this
  • what the method returns if not void - Javadoc has @returns tag for this
  • known bugs
  • error conditions or exceptions - Javadoc has a @throws tag for this
  • example of using the method, if not obvious
  • preconditions and postconditions
• Private explanations intended for maintenance include
  • purpose of local variables
  • explanation of difficult code
  • design decisions

Single Point Control

• principle of define once, use many times
• i.e., anything that needs to be done multiple times, should be done in one place then referenced in the other places where it is needed
• term comes from Robert Glass essay "Single-Point Control" in the book Software Conflict: Essays on the Art and Science of Software Engineering, Prentice-Hall, 1991. Glass is best known for his witty "from the trenches" essays on software engineering.
• There are many forms of single point control. Here are a few types illustrated through examples:
• EXAMPLE: constant identifiers to hold system parameters
  BAD:
  int data[] = new int[100];
  ...
  for (int i=0; i<100; i++)
     data[i] = whatever;
  
  BETTER:
  final int DATA_ARRAY_CAPACITY = 100;
  int data[] = new int[DATA_ARRAY_CAPACITY];
  ...
  for (int i=0; i<data.length; i++)
     data[i] = whatever;
  The array capacity 100 is defined in only one place. If it needs to be changed later, it need be changed in only one place.
  
  
• EXAMPLE: use of modules to define operations used repeatedly
  BAD:
  area1 = Math.PI * radius1 * radius1;
  area2 = Math.PI * radius2 * radius2;
  area3 = Math.PI * radius3 * radius3;
  
  BETTER:
  double circleArea(double radius) { return Math.PI * radius * radius; }
  ...
  area1 = circleArea(radius1);
  area2 = circleArea(radius2);
  area3 = circleArea(radius3);
  
  
• EXAMPLE: abstract data types and object-oriented programming
  An abstraction is defined completely (attributes and behaviors) by, and its definition encapsulated in, a class. The class is then used over and over to instantiate and use objects. If the class enforces information hiding, then the class implementation can be modified without affecting its usage.
  
  
• EXAMPLE: Table-driven control.
  BAD:
  if (price < 100.00)
     discount = 0.10;
  else if (price < 200.00)
     discount = 0.15;
  else if (price < 500.00)
     discount = 0.20;
  else if (price < 1000.00)
     discount = 0.25;
  else
     discount = 0.30;
  
  BETTER:
  double priceBoundaries[] = { 100.00, 200.00, 500.00, 1000.00 };
  double discounts[] = { 0.10, 0.15, 0.20, 0.25, 0.30 };
  ...
  discount = discounts[discounts.length-1];
  for (int i=0; i<priceBoundaries.length; i++) {
     if (price < priceBoundaries[i]) {
        discount = discounts[i];
        break;
     }
  }
  
  
• EXAMPLE: File-driven control.
  Improve table-driven control example by storing the price boundaries and discounts in a data file, then reading them into the arrays at runtime.
  Improve constant identifier for system parameters example by storing the capacity in a data file, then reading it and runtime before creating the array.
  
  
• EXAMPLE: Glossary in documentation.
  Define terms once in a glossary, then refer to them in other parts of the documentation.

Coding Standards and Conventions

• coding standards and conventions are important for maintenance
• results in code that's easier to understand
• maintenance done by different person than implementation
• many developers have internal standards and conventions
• some languages have conventions.
• See java.sun.com/docs/codeconv for Sun Microsystems' Java code conventions, which cover
• file names
• identifier names
• indentation
• commenting
• declarations
• statement structure
• and more...
• semi-related topic: matching language to design paradigm
• OO design does not require OO language for implementation!
• through discipline and coding conventions, an OO design can be implemented in a non-OO language like C
• e.g. you can fake inheritance pretty well using composition (an "inherited" method can written as a one liner that calls a component's corresponding function)
• some "classical" languages have been augmented with OO features, e.g. OO COBOL, OO FORTRAN

Testing during the Implementation Workflow

• prior to implementation, testing is non-execution based practices like walkthroughs and inspection
• implementation testing should incorporate both execution based (aka dynamic) and non-execution based (aka static).
• we will focus first on execution based unit testing
• unit, for OO, is class or method
• test case consists of
• test data
• predicted test result based on that data
• actual test result obtained by running the test
• report of any difference between predicted and actual results
• test case development very important, two approaches are
• black box testing aka functional testing, based on specifications (pre- and post-conditions)
• glass box testing aka structural testing, based on code structure
• in either case, exhaustive testing is not feasible (e.g. testing every possible combination of values)
• get maximal black box results from minimal number of test cases by
• determining equivalence classes (ranges of values in which very value is treated equivalently)
• testing only at equivalence class boundaries plus one intermediate value per equivalence class
• example: method that returns number of digits that its integer parameter has. One equivalence class is range of values -9 through 9 (one digit), another class is 10 through 99 and -10 through -99 (2 digits), etc. Test at: -100, -99, -50, -10, -9, 0, 9, 10, 50, 99, 100, etc.
• example:array search. good test cases include:
• single valued array, target contained in array
• single valued array, target not contained in array
• multiple valued array, target contained in first element
• multiple valued array, target contained in last element
• multiple valued array, target contained in middle element
• multiple valued array, target not contained in array
• get maximal glass box results from minimal number of test cases by
• statement coverage, the minimal set of test cases that assure that every source statement is executed at least once.
• compare and contrast this with path coverage which assures that every possible execution path through the method is executed at least once.
• example (pseudo-code) to illustrate the difference:
  

  if (x > 0) then B1;    else B2; if (y > 0) then B3;    else B4;

  2 test cases, (x=0, y=0) and (x=1, y=1), provide statement coverage of B1, B2, B3 and B4. 4 test cases, (x=0, y=0), (x=0, y=1), (x=1, y=0), (x=1, y=1), are required for path coverage (corresponding paths are B2-B4, B2-B3, B1-B4, B1-B3)

• number of branches in code corresponds to its cyclomatic complexity (aka McCabe's complexity), a code complexity metric more meaningful than lines of code. Cyclomatic complexity measure also estimates number of test cases required for glass box testing.