COMS W3156: Software Engineering, Fall 2001

COMS W3156:Software Engineering, Fall 2001 Lecture #13: Implementation I Janak J Parekh janak@cs.columbia.edu

Administrativia • JDOM should now be installed on CUNIX • Look in ~cs3156/jdom and the webboard • HW2 due next Tuesday

Next class • Continue implementation: Testing • Concurrent architectures and event models • Input on concurrent architectures

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

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?

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

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

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

Going on up • 4th-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

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

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

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

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 • Java is your friend here

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

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

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

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?

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

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

Javadoc tags • @author • @version • @param • @return • @exception

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

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)

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++; }

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

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

Testing to specifications? • Can’t do exhaustive • If a product has 20 different “factors”, with 4 values each, there can be a total of 420 or 1.1x1012 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

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

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

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

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…

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

COMS W3156: Software Engineering, Fall 2001