1. Software Engineering 3156 22-Oct-01 #14: Implementation Phil Gross

2. 2 Administrivia Webboard – C’mon folks Homework 1 is here Homework 2 due tomorrow – Note minor update Our server is dead

3. 3 Today’s class We’re ahead, so let’s keep on going Implementation basics

4. 4 Choosing a programming language Note that this is occurring at the implementation phase; in reality may sometimes occur earlier, but you want the design to be mostly language-independent Consider cost of retraining – What if we asked you all to do this in C++? – Mutiny, right?

5. 5 Historically… Most software was written in COBOL Currently, more COBOL code exists than anything else Approved by DoD in 1960: insisted any applications they would buy had to be in COBOL

6. 6 Why COBOL? COBOL well-suited for data processing – Supports large numbers, for example – Report formatting capabilities Object-oriented COBOL? – Yup

7. 7 Levels of languages Lowest: machine code – 000010100111110101110100000111001010 Next: assembly – mov $17, next Next: non-interpreted procedural languages – C, C++, Objective C, COBOL, FORTRAN Interpreted procedural languages – Java, Smalltalk, Perl, Python, Tcl, Ruby, LISP

8. 8 Going on up 4 th -generation languages – Javascript, SQL – Loose typing (a = 5; a = “foo”;) – Less strict error-checking – Not necessarily procedural – Objective often end-user programming – Unsurprisingly, controversial – Success stories abound, however

9. 9 Choosing a language What’s an appropriate language? – Most programs and designs today are object- oriented and procedural – Therefore, C++, Smalltalk, Java, Python, maybe Perl – Of these, C++ best if you have serious time constraints: the rest are interpreted to an extent or another

10. 10 Languages (II) C++ also like C: large number of existing programmers – Not a superset, but close to it: most modern C++ compilers can compile and link against C code – We’ll be looking at C/C++ at the end of this class: useful for OS and DB courses at Columbia

11. 11 Java So if C++ exists, why Java? – Java enables portable bytecode: not completely interpreted, yet not compiled to one machine platform – compromise between completely interpreted and completely compiled – Large, standardized API – Network/Internet oriented language – Yet, at the same time, still C-like

12. 12 Good programming practice Variable naming Parameters Documentation Code layout Nested if’s Others? http://www.joot.com/articles/practices.html: first link on Google, many others abound http://www.joot.com/articles/practices.html Java is your friend here

13. 13 Variable naming “Consistent and meaningful” variable names – Bad: int f, g, h, i, j; – Bad: int freq, frequency, fr, frqncy; – Hungarian Naming Conventions: encode type info in variable names http://www.harper.cc.il.us/~jkiener/nameconv.htm Used by Microsoft heavily Also applies to class naming

14. 14 Parameters Handle constants properly – Don’t hardcode the numeric values in – public static final int port = 5378;

15. 15 Comments (I) Self-documenting code – Yeah, right* – Given time, all code will become unreadable xCoordinateOfPositionOfRobotArm – too long So use xCoord Not good

16. 16 Comments (II) Prologue comments: at the top of every module – Module name, brief description, programmer’s name, date, arguments, variable names, files accessed, names of files changed, module IO, error handling, test data filename, modifications made, dates – “Minimum information must be provided” – Aargh! This is overwhelming – More practical?

17. 17 Comments (III) Janak’s personal tips™ – Use javadoc commenting – Put TODO’s at the top – Use “XXX” in problem areas – Trick: cvs can help comment your code Put $Log$ in a comment block – Profuse comments are not a bad thing – Use emacs or some editor that colors your code

18. 18 Javadoc commenting http://java.sun.com/j2se/javadoc/writingdoccomments/i ndex.html http://java.sun.com/j2se/javadoc/writingdoccomments/i ndex.html Basically, /** * Comment * * @tag Comment for tag */ Done at class, variable, method levels

19. 19 Javadoc tags @author @version @param @return @exception

20. 20 Code layout: bad public class HelloWorld{public static void main(String[] args) {System.out.println(“Hello world!”);System.exit(0);}} Take a look at the IOCCC – http://www.ioccc.org/ http://www.ioccc.org/ – My favorite: Othello

21. 21 Code layout: good Proper indentation – Use an editor that will do most of the work for you: emacs is the best – pico, quite frankly, sucks for this Space is good! Use common bracing (open or closed)

22. 22 Nested if, for vs. while if(a) { if(b) { … } } is much easier to read if phrased if(a&&b) {…} Although more if clauses this way, “shallower” code is generally better Use ? notation for small if statements for(int i=0; i < 10; i++) is much more compact than – int i=0; – while(i < 10) { … i++; }

23. 23 Coding standards ex: Each module between 35 and 50 statements Good: makes code more uniform Bad: coding standards from above often ignored, hard to verify Goal: ease maintenance

24. 24 Testing So you wrote all this stuff… Informal vs. methodical testing – Nonexecution-based testing (module review) vs. execution-based testing (test cases) – Testing to specifications (black-box) vs. testing to code (glass-box) Worst way to test: haphazard data

25. 25 Testing to specifications? Can’t do exhaustive If a product has 20 different “factors”, with 4 values each, there can be a total of 4 20 or 1.1x10 12 different test cases Anyone got spare time on their hands? – If each case were tested once every 30 seconds, would take more than a million years

26. 26 Testing to code? Execute each path in your module at least once? This flowchart has over 10 12 possible paths! Also: how to test every path? Does it detect all of the faults?

27. 27 Paths to completeness? Answer: no Just because you go through all the paths doesn’t mean your test cases cover everything Mini-example to the right: trivial, but representing more important

28. 28 More path testing problems Can only test path if it’s present Conclusion: path testing is not reliable, but is valid

29. 29 So, where do we go? Conclusion: we need a compromise – highlight faults, while accepting that not all faults will be detected Black-box test cases first (specifications) Then, develop additional glass-box techniques (code) To be continued…

30. 30 What does this mean for you? Develop test plan: combination of black-box cases and glass-box cases Code using good principles! – We’ll release criteria as to what we’re expecting in the submitted implementation