Software Engineering Oct-01 #14: Implementation Phil Gross

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

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

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 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 Why COBOL? COBOL well-suited for data processing – Supports large numbers, for example – Report formatting capabilities Object-oriented COBOL? – Yup

7 Levels of languages Lowest: machine code – 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 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 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 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 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 Good programming practice Variable naming Parameters Documentation Code layout Nested if’s Others? first link on Google, many others abound Java is your friend here

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 Used by Microsoft heavily Also applies to class naming

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

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

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 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 Javadoc commenting ndex.html ndex.html Basically, /** * Comment * Comment for tag */ Done at class, variable, method levels

19 @exception

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 – – My favorite: Othello

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 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 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 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 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 Testing to code? Execute each path in your module at least once? This flowchart has over possible paths! Also: how to test every path? Does it detect all of the faults?

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 More path testing problems Can only test path if it’s present Conclusion: path testing is not reliable, but is valid

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 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