1. Object-Oriented Analysis and Design Lecture 10 Implementation (from Schach, “O-O and Classical Software Engineering”)

2. Which Programming Language Often, there is no choice The client says “You must use ___” The product must interoperate with existing software written in ___ Even if there is a choice (“implement in the most suitable language”) If you are a COBOL shop, but the project cries out “Java”…

3. Which Language? If there is a choice, cost-benefit analysis can be used. Do it for each possible language. Risk analysis: for each language List risks and possible resolutions (may be different for different languages) Choose the language with smallest overall risk

4. Which Language “It shall be O-O.” But which? Smalltalk (20 years ago, the only choice) C++ Compilers are cheap, but Managers in C shops think anyone can learn C++ in 21 days (books with this title?) Java This will be an abrupt transition

5. 4GL? Focus, Oracle, spreadsheets Designed to pack 30-50 lines of procedural code into one statement Many success stories, but these are often due to associated Case tools Maybe not good for a level 1 organization

6. “End-User Programming” The old way: Investment manager asks for product to display her portfolio; then waits a year The new way: The manager does it herself, using 4GL Dangerous? Computer pros taught to mistrust computer output; users taught to accept it Amateurs doing DB updates? Training for managers?

7. Good Programming Practice Consistent, meaningful variable names Meaningful to maintainers! minimumFrequency, frequencyMaximum? Incorporate type information: Hungarian naming conventions like Microsoft’s m_hIcon, for “my handle to an Icon”

8. Self-Documenting Code I write the code today, but I am a different programmer one week from today Include a prologue, giving File name Purpose Programmer’s name Date coded Date modified Alphabetical list of variables Location of test data

9. Other Considerations Constant parameters Really very few of these Use const in C++, static final in Java Or, read in from a parameter file Code layout for readability Nested blocks Coding standards

10. Class Testing Informal, by the programmer Formal, by a testing group Non-execution tests Execution-based tests (test cases) There is limited time for testing, so make test cases count Test to spec (black-box) Test to code (glass-box)

11. Testing to Specification Suppose the spec says that 5 types of commission and 7 types of discount have to be incorporated Obviously, 35 different tests, and the black box principle says you have to do them all 20 factors, each with 4 possible values?

12. Testing to Code Flow chart with > 4  10 12 possible paths Loop  18 times

13. Testing to Code Examining every path is no guarantee: Paths may not be present: should have a test for the value of d Testing all paths is not reliable if ((x + y + z)/3 == x) print “x, y, and z are equal” else print “x, y, and z are unequal” x = n/d

14. Black-Box Testing Strategies Equivalence classes Spec says database must handle any number of records from 1 to 16,383 Equivalence class 1: less than 1 record Equivalence class 2: between 1 and 16,383 records Equivalence class 3: more than 16,383 records Use one test case for each equivalence class “A successful test case detects a previously undetected fault.” The flip side?

15. Black-Box Testing Strategies An extension: boundary analysis Test case 1: 0 records Test case 2: 1 record Test case 3: 2 records Test case 4: 723 records Test case 5: 16,382 records Test case 6: 16,383 records Test case 7: 16,384 records

16. Black-Box Testing Strategies Boundary analysis on output specs Suppose outputs must be in the range [$0, $4,984.90] Test inputs that surround these output boundaries

17. Glass-Box Techniques Statement coverage: every line executed at least once (problems) Branch coverage: all branches executed at least once (problems) Path coverage: all paths executed at least once (problems) All definition-use paths: paths between variable definition and use executed (dead code problems)

18. Other Ideas Complexity metrics: “put your good where it will do the most” We saw O-O metrics earlier, and they work Code walkthroughs and inspections: very effective “Cleanroom”: Code inspections before compiling. In the spirit of PSP (from the SEI folks)

19. Debug or Just Rewrite? If the metrics say it’s a complex class or design, insist it be re-written If you test for “a while” and keep finding bugs, insist it be re-written Classes C1 and C2 Test C1 for 4 hours, find 2 bugs Test C2 for 4 hours, find 40 bugs C2 is much more likely to still have bugs

20. Debug or Just Rewrite? Empirical support Number of faults already found Probability of existence of additional faults 1.0 0.0

21. Conclusions Lots of issues in implementation Which language? Documentation and coding standards Testing is hard Tools help, but there is no “silver bullet” Management won’t know all this stuff, so you have to help…