1. Chapter 6 Object-Oriented Design Part 3

2. © 2004 Pearson Addison-Wesley. All rights reserved 2/35 Outline Software Development Activities Identifying Classes and Objects Static Variables and Methods Class Relationships Interfaces Method Design Testing

3. © 2004 Pearson Addison-Wesley. All rights reserved 3/35 Method Design As we've discussed, high-level design issues include:  identifying primary classes and objects  assigning primary responsibilities After establishing high-level design issues, its important to address low-level issues such as the design of key methods For some methods, careful planning is needed to make sure they contribute to an efficient and elegant system design

4. © 2004 Pearson Addison-Wesley. All rights reserved 4/35 Method Design  An algorithm is a step-by-step process for solving a problem Examples: a recipe, travel directions Every method implements an algorithm that determines how the method accomplishes its goals This is detail design (program logic) and must follow higher level architectural design (component) An algorithm may be expressed (designed) in pseudocode, a mixture of code statements and English that communicate the steps to take to solve a problem.  Other detail design options: HIPO, program flowcharts, and a host of other mainly older technologies… Pesudocode seems to be the technology of choice for a number of years now.

5. © 2004 Pearson Addison-Wesley. All rights reserved 5/35 Pseudocode - Selected Routines Done by a student in class. Printed with his permission. Annotated in several places by me. But this is a good example. While there are some deficiencies, I like this, with the exceptions noted. Note my comments on these students’ work… You will note that these pseudocode examples are ‘reasonably’ language independent. Main thing here is to see the ‘approach’ to solving the problem. ====================================================================================== 1. Good looking main routine. Mostly control. Good indentation. Good abstraction. Main Set state counter to 0 Open input file (could name file here) Do initial read into temp area // called ‘priming the pump’ If valid read occurs While not EOF do Call Build_Array(arguments: pointer to temp area pointer to array) Increment record / object counter Call Read_Record(arguments: pointer to array, pointer to input file) End While End If Close input file end Do Call Compute(arguments: pointer to array, pointer to stat structure, state counter) // Call to a method / function. Call Sort_Array(arguments: pointer to temp structure, pointer to array, state counter) // can see parameters Call Output(arguments: pointer to array, pointer to structure, state counter) end Main (Can see how Main was really a driver… Got input and then directed the execution…)

6. © 2004 Pearson Addison-Wesley. All rights reserved 6/35 2. Example of pseudocode that is too vague. No processing details are included; No algorithm is really shown. Not enough to support follow-on programming. Another example: Read_Record(parameters: pointer to temp struct, pointer to input file) If valid read occurs<====EXAMPLE OF PSEUDOCODE THAT IS TOO VAGUE! Return(void)< What is being read? Variable names? End If end Read_Record ======================================================================================== 3. Another real good function; Indentation good. Level of detail good. Note also the "generalization of the CASE statements." This is how to do such a thing... A few additional examples of pseudocode that are too vague are also shown. Compute(parameters: pointer to array, pointer to state structure, state counter) Initialize counter to 0. Loop while counter <= state counter -1 // we knew the number of states processed / read in. Switch to compute element based on its region number Case New England Region Increment total counter Add state population to total population Increment New England counter Add state population to New England Total Population End Case Case Mid Atlantic Region............< Infer details from New England Case statements. End Case Case South Region............ End Case Case Midwest Region............ End Case End Switch End Loop

7. © 2004 Pearson Addison-Wesley. All rights reserved 7/35 4. Another pseudocode example: Calculate average state population<== TOO VAGUE AGAIN. If New England counter is > 0 Compute New England average population <== TOO VAGUE. End If (need to show formula!!) If Mid Atlantic counter is > 0 Compute Mid Atlantic average populationDITTO... End If If South counter is > 0 Compute South average population // Don’t repeat identical logic! End If If Midwest counter is > 0 Compute Midwest average population End If If Southwest counter is > 0 Compute Southwest average population End If If West counter is > 0 Compute West average population End If // Could say, “for each region compute the average population.” end Compute// Then show the formula to compute the average population. // There is no reason to repeat the same logic for each region…

8. © 2004 Pearson Addison-Wesley. All rights reserved 8/35 Still more: 5 See comments.... Excellent indentation. Good levels of abstraction. Only a couple of problems...a couple of vague statements... Good scope terminators Sort_Array(parameters: pointer to temp structure, pointer to array, state counter) Loop while A counter is <= state counter -1 // example of nested loops in logic. Loop while B counter is <= A counter Compare state abbreviation strings <== Too vague...how?? If element 2 string has a greater value than element 1 string Copy element 1 into temp structure; // swap! Copy element 2 into element 1's position in array Copy temp structure into element 2's position in array End If End Loop Loop while A counter is <= state counter -1 Loop while B counter is <= A counter Compare region number<== to what? If element 2 has a greater region value than element 1 Copy element 1 into temp structure; Copy element 2 into element 1's position in array Copy temp structure into element 2's position in array End If End Loop end Sort_Array

9. © 2004 Pearson Addison-Wesley. All rights reserved 9/35 6 Another well done routine.... See one comment herein. Output (parameters: pointer to array, pointer to state structure, state counter) Set Number region = 1 Set region counter equal to first element in array's region number Loop while variable <= state counter -1 If array element region number does not equal region counter Increment Number region Set region counter equal to current elements region number End If End Loop Compute average regional population Loop while header counter <= Number region Switch to decide which header is to be printed Case region number = 1 Print New England Header End Case Case region number = 2 Print Mid Atlantic Header End Case Case region number = 3 Print South Header End Case Case region number = 4 Print Midwest Header //Again, no need to repeat identical logic. End Case // Merely add a comment to infer logic… Case region number = 5 Print Southwest Header End Case Case region number = 6 Print West Header End Case End Switch While region number is = element region number Print detail lines End While

10. © 2004 Pearson Addison-Wesley. All rights reserved 10/35 7. Switch to decide which summary to print Case region number = 1 Print New England Summary WHAT IS INCLUDED IN THE End CaseSUMMARY??? (TELL ONE TIME IN PSEUDOCODE. Case region number = 2 Print Mid Atlantic Summary End Case Case region number = 3 Print South Summary End Case Case region number = 4 Print Midwest Summary End Case Case region number = 5 Print Southwest Summary End Case Case region number = 6 Print West Summary End Case End Switch Advance screen with user input End Loop Print grand totals end Output

11. © 2004 Pearson Addison-Wesley. All rights reserved 11/35 The problem with pseudocode comes in implementation. Pseudocode represents your algorithm, your logic, your approach to solving the problem - module by module. Since pseudocode is algorithmic, it should be language independent - and should strive to meet this tenet. However, some languages are somewhat language independent. So consider the following guidelines: For looping and selection, The keywords that are to be used include Do. While...EndDo; Do Until...Enddo; Case...EndCase; If...Endif; Loop … EndLoop When calling subprograms or methods use: Call (or invoke)... with (parameters); Call; Return....; Return; Always use scope terminators for loops and iteration. Try to eliminate the use of the word Perform as this is clearly language-dependent. Do not include the words Begin, End; Return is okay. Never include any data declarations in your pseudocode.  Pseudocode is logical procedure; algorithms. It does not include data definitions. As verbs, use the words Generate, Compute, Process, etc. Words such as set, reset, increment, compute, calculate, add, sum, multiply,... print, display, input, output, edit, test, etc. with careful indentation tend to foster desirable pseudocode. Note: "increment" implies adding 1 to some data item. If you need to show incrementing by more than one, say "increment field-a by 5. Similar for decrement, which means subtract 1 from a data item. Or, decrement field-a by 5. One way to make your pseudocode more language independent is to use words such as Do. Thus, a Do... Until (condition) or a Do While (condition) each with an Enddo at the end of their scope is encouraged. Thus a Do While (not end of file) followed by several statements - indented followed by an Enddo lined up with the Do While is acceptable (in fact, GOOD) form. Use Do…Endo or Loop and EndLoop. More

12. © 2004 Pearson Addison-Wesley. All rights reserved 12/35 DO WHILE (COUNTER < 100).... ENDDO OR DO.... UNTIL (NO MORE RECORDS) These are good. Note that the Do...Until has the test AFTER the code is executed the first time, and once thereafter... Make every attempt to rid your pseudocode of any hyphens! Hyphens says Cobol, and it is this dependency that we are trying to reduce; semicolons say C or Java. Try to eliminate these!  Writing Cobol or Java or C as your pseudocode is not acceptable. Write your  pseudocode (that is, your logic before you code. Easy to fix this way…) Sort the input old master file on keys xxxx and xxxx both descending creating a new sorted master file. If page counter indicates nearing end of page, generate trailers, print headers, reset line counter, increment page counter. endif

13. © 2004 Pearson Addison-Wesley. All rights reserved 13/35 A few last words: Remember, pseudocode is your step by step solution to solving the problem. Thus, there must be a level of detail in your algorithm to support program development. An entry like: Calculate Total Pay without showing the formula is not any real help; phrases like: Build Table are too abstract to be of much good. You need to show HOW to build the table, and WHAT is the formula for computing the total pay. Remember: detail design is one step above the actual code! Code is the implementation / realization of this level of design! It may be appropriate to abstract these into a separate module and "DO" a module where the table is built or DO a module where the total pay is calculated, if complicated. But regardless, your pseudocode must include this level of detail. While all this is not meant to provide a comprehensive treatment of pseudocode, it is meant to provide some Examples and show acceptable standards with which you are asked to comply. If you have suggestions: revisions, additions, omissions, etc. from these guidelines, please email me with your suggestions. Lastly,

14. © 2004 Pearson Addison-Wesley. All rights reserved 14/35 Objects as Parameters Another important issue related to method design involves parameter passing Parameters in a Java method are passed by value A copy of the actual parameter (the value passed in) is stored into the formal parameter (in the method header) Therefore passing parameters is similar to an assignment statement When an object is passed to a method, the actual parameter and the formal parameter become aliases of each other

15. © 2004 Pearson Addison-Wesley. All rights reserved 15/35 Passing Objects to Methods What a method ‘does’ with a parameter may or may not have a permanent effect (outside the method) The method may/ may not change the value! See ParameterTester.javaParameterTester.java See ParameterModifier.javaParameterModifier.java See Num.javaNum.java Note the difference between changing the internal state of an object versus changing which object a reference points to

16. © 2004 Pearson Addison-Wesley. All rights reserved 16/35 //******************************************************************** // ParameterPassing.java Author: Lewis/Loftus // // Demonstrates the effects of passing various types of parameters. //******************************************************************** public class ParameterPassing { //----------------------------------------------------------------- // Sets up three variables (one primitive and two objects) to // serve as actual parameters to the changeValues method. Prints // their values before and after calling the method. //----------------------------------------------------------------- public static void main (String[] args) { ParameterTester tester = new ParameterTester(); // creates an object of type ParameterTester int a1 = 111; Num a2 = new Num (222); // creates objects a2 and a3 of type Num (see ahead) Num a3 = new Num (333); System.out.println ("Before calling changeValues:"); System.out.println ("a1\ta2\ta3"); System.out.println (a1 + "\t" + a2 + "\t" + a3 + "\n"); tester.changeValues (a1, a2, a3); System.out.println ("After calling changeValues:"); System.out.println ("a1\ta2\ta3"); System.out.println (a1 + "\t" + a2 + "\t" + a3 + "\n"); } // end main() } // end class

17. © 2004 Pearson Addison-Wesley. All rights reserved 17/35 // ParameterTester.java public class ParameterTester { // Modifies the parameters, printing their values before and after making changes public void changeValues (int f1, Num f2, Num f3) { System.out.println (“Before changing the values:”); System.out.println (“f1\tf2\tf3); System.out.println (f1 + “\t” + f2 + “\t” + f3 + “\n”); // a1 was 111, a2 (an object) was 222; a3 (an object) was 333 f1 = 999// f1 has local value of 111 but is changed locally. // Not changed in calling method!! f2.setValue (888);// This method ignores value passed in f2 which was 222; // changes value in object a2 to 888. f3 = new Num (777); // Here f3 is set equal to a totally new Num object and initialized to 777 // Can no longer access a3 that was sent to it. System.out.println (“After changing the values:”); System.out.println (“f1\tf2\tf3); System.out.println (f1 + “\t” + f2 + “\t” + f3 + “\n”);

18. © 2004 Pearson Addison-Wesley. All rights reserved 18/35 //******************************************************************** // Num.java Author: Lewis/Loftus // // Represents a single integer as an object. //******************************************************************** public class Num { private int value; //----------------------------------------------------------------- // Sets up the new Num object, storing an initial value. //----------------------------------------------------------------- public Num (int update) { value = update; } //----------------------------------------------------------------- // Sets the stored value to the newly specified value. //----------------------------------------------------------------- public void setValue (int update) { value = update; } //----------------------------------------------------------------- // Returns the stored integer value as a string. //----------------------------------------------------------------- public String toString () { return value + ""; }

19. © 2004 Pearson Addison-Wesley. All rights reserved 19/35 Method Overloading Method overloading is the process of giving a single method name multiple definitions If a method is overloaded, the method name is not sufficient to determine which method is being called  The signature of each overloaded method must be unique The signature includes the number, type, and order of the parameters  Does NOT include return type!

20. © 2004 Pearson Addison-Wesley. All rights reserved 20/35 Method Overloading The compiler determines which method is being invoked by analyzing the parameters float tryMe(int x) { return x +.375; } float tryMe(int x, float y) { return x*y; } result = tryMe(25, 4.32) Invocation

21. © 2004 Pearson Addison-Wesley. All rights reserved 21/35 Method Overloading The println method is overloaded: println (String s)// note formal param println (int i) println (double d) and so on... The following lines invoke different versions of the println method: System.out.println ("The total is:"); System.out.println (total);

22. © 2004 Pearson Addison-Wesley. All rights reserved 22/35 Overloading Methods  The return type of the method is not part of the signature That is, overloaded methods cannot differ only by their return type  Constructors can be overloaded  Overloaded constructors provide multiple ways to initialize a new object

23. © 2004 Pearson Addison-Wesley. All rights reserved 23/35 Outline Software Development Activities Identifying Classes and Objects Static Variables and Methods Class Relationships Interfaces Enumerated Types Revisited Method Design Testing

24. © 2004 Pearson Addison-Wesley. All rights reserved 24/35 Testing Testing can mean many different things It certainly includes running a completed program with various inputs It also includes any evaluation performed by human or computer to assess quality  The earlier we find an problem, the easier and cheaper it is to fix

25. © 2004 Pearson Addison-Wesley. All rights reserved 25/35 Testing The goal of testing is to find errors As we find and fix errors, we raise our confidence that a program will perform as intended We can never really be sure that all errors have been eliminated So when do we stop testing?  Conceptual answer: Never  Snide answer: When we run out of time  Better answer: When we are willing to risk that an undiscovered error still exists

26. © 2004 Pearson Addison-Wesley. All rights reserved 26/35 Reviews A review is a meeting in which several people examine a design document or section of code It is a common and effective form of human-based testing Presenting a design or code to others:  makes us think more carefully about it  provides an outside perspective Reviews are sometimes called inspections or walkthroughs

27. © 2004 Pearson Addison-Wesley. All rights reserved 27/35 Test Cases A test case is a set of input and user actions, coupled with the expected results Often test cases are organized formally into test suites which are stored and reused as needed For medium and large systems, testing must be a carefully managed process Many organizations have a separate Quality Assurance (QA) department to lead testing efforts

28. © 2004 Pearson Addison-Wesley. All rights reserved 28/35 Defect and Regression Testing Defect testing is the execution of test cases to uncover errors The act of fixing an error may introduce new errors After fixing a set of errors we should perform regression testing – running previous test suites to ensure new errors haven't been introduced It is not possible to create test cases for all possible input and user actions Therefore we should design tests to maximize their ability to find problems

29. © 2004 Pearson Addison-Wesley. All rights reserved 29/35 Black-Box Testing In black-box testing, test cases are developed without considering the internal logic They are based on the input and expected output  Input can be organized into equivalence categories  Two input values in the same equivalence category would produce similar results  Therefore a good test suite will cover all equivalence categories and focus on the boundaries between categories

30. © 2004 Pearson Addison-Wesley. All rights reserved 30/35 White-Box Testing White-box testing focuses on the internal structure of the code The goal is to ensure that every path through the code is tested Paths through the code are governed by any conditional or looping statements in a program A good testing effort will include both black-box and white-box tests