How's things?

• Quizzes 01A&B should be done by now. (1B answers? Can revisit?)
• Tamarin status
• A01, part 1: Tamarin account + anon ID to Anthony
• A02 due Wednesday night
• Today: Last day to drop without W.

Today: How to write code

• Best practices developed over 60 years of software development
• (We'll revisit the history and some of the other lessons later)
• (slides are a bit wordy)

Software Development Steps

• Requirements
  • What's the problem to solve?
• Design
  • How to solve the problem? Break the problem down.
• Implementation (construction, +integration)
  • Actually write the code.
• Testing (2 levels)
  • Verification: Does the code match the design?
    • ("Did we build it right?"; vs Design; usual sense of "debugging")
  • Validation: Does the code actually solve the original problem?
    • ("Did we build the right thing?"; vs Requirements)
• (deployment / installation / release)
• Maintenance

Waterfall model (1/2)

• Do the steps in order (no backtracking)
• A bit of a straw-man model

Waterfall model (2/2)

• Advantages:
  • Big Design Up Front / "measure twice, cut one"
  • Very efficient with stable requirements
  • Tends to be well-documented and understood; works well for large teams
  • Basically: Think-before-you-write makes for better code.
• Disadvantages:
  • Requirements are often not stable, sometimes not even clear
  • Design problems sometimes not discovered until implementation (requiring redesign)
  • Basically: Not flexible.

Spiral Model

• Modified waterfall
• Good for large projects (takes months)
• Start with requirements and design
• Then iterate with small prototype
• Test the prototype
• Revisit design
• (Maybe repeat)
• Then move on to actual implementation

Iterative + Incremental Development (class of models)

• vs waterfall-like models
• Anything more than a few lines is too big to do it right in one big push!
• (but don't want to prototype either)
• General design first
• Then fill in details incrementally for each part:
  • specific design for that part, write code, test and verify part
  • revisit general design and pick next part
• May need to refactor code if initial design was bad

Agile Programming

• Taking iterative + incremental to the extreme
• Many Agile flavors: Extreme Programming (XP), Scrum, etc.
• Focus on people (programmers and customers, less on management and process)
• Get something working fast and then expand it
• Basically: iterate really fast (days or weeks, not months or years)
• Common features
  • Pair programming, small teams, (F2F stand-up meetings)
  • Write unit tests first
  • customer representative always on-hand
  • code always works, adding a single feature at a time (incremental)

Which model is best?

• Depends on:
  • project (cost, size, risk, fault tolerance)
  • team size
  • programmers (experience, design and testing skills)
  • team culture (coherence vs individuality)
  • etc.
• But all follow the same steps in some way!
  • varies on how you iterate/increment
  • varies on how you execute each step (eq, implementing alone or in a pair, coders do their own testing vs a separate testing team, write tests before code or after, finalize design before you start or revisit design throughout project)

Software Development Steps (again)

• Requirements
• Design
• Implementation
• Testing
• (release)
• Maintenance

Focus is usually on the first 4, but code spends most of its lifetime in Maintenance phase

Exercise: Design for A02

• Problem: Draw a large X of a user-specified size.

In this class (1/2)

• Don't just start coding!
• Requirements: what do you need to do?
  • Not much of an issue here: read the assignment.
• Design:
  • Break problem down into smaller and smaller pieces until you know how to implement each one.
  • Hardest (and most creative) part of programming
  • Do this before you start (even if it only takes 1 minute on an envelope, don't skip it!)

In this class (2/2)

• Implement + Test (verification):
  • Write one piece at a time (a few lines of code each)
  • Compile, run, and test after each iteration.
  • Your code should always be working. (If it stops working, 90% chance you broke it in the last 5 minutes.)
  • Don't flail away at it.
• When done: Validation. (Did you meet the requirements?)
• "Ship it!" (Release / submit)
• (Note: no Maintenance step for us...)

What is a class?

• Program (if it contains a main method)
• Collection of (static) methods
• Template for creating instances (objects)

Method definition format

• Examples:

  public class Planet {
    public static void main(String[] args) { /* body */ }
    public int getAge() { /* body */ }
    private static double getDensity(double mass, double vol) { /* body */ }
  }

• Parts:
  • Access modifier: public or private (or protected or none)
  • Static (or none): Associated with class (or instance)
  • Return type: data type of return value (or void: nothing returned)
  • Method name
  • Parameter list: 0 or more variable declarations
  • Body: code in curly braces

Important terms

• Method definition
• Signature: name + parameter list
• Overloading: more than one method in class with same name (but different param lists)
• Method call

Method calls

• Depends on definition. Method call parts:

    class-or-object.method-name(parameters, ...)
  

• Example method calls:

    Planet mars = new Planet(???);
    System.out.println(mars.getAge());
    double result = Planet.getDensity(1000.5, 200);
    Planet.main(new String[0]);
  

Examples from API

• Math class: random, pow, min, rint.
• String class: charAt, substring, valueOf

Shortcuts and Gotchas

• can leave off class-or-object part if calling another method in the same class
• can call static method on instance (though bad form)

In and out of a method

• Input: parameters. Pass by value.
• Output: return value
• Possible side-effects (such as on object's state)
• (Style: Avoid printing to the screen when possible.)
• This is info you should put in a /** javadoc */ comment before method def.

Example: pass-by-value

public class Example {
  public static void main(String[] args) {
    int a = 3;
    int b = 5;
    swap(a, b);
    System.out.println("a = " + a + ", b = " + b);
  }
  
  public static void swap(int left, int right) {
    int temp = left;
    left = right;
    right = temp;
  }
}    

• parameters: args (in main); left, right (in swap)
• local variables: a, b (in main); temp (in swap)

Example: Still pass-by-value

public class Example {
  public static void main(String[] args) {
    int a = 3;
    int b = 5;
    swap(a, b);
    System.out.println("a = " + a + ", b = " + b);
  }
  
  public static void swap(int a, int b) {
    int temp = a;
    a = b;
    b = temp;
  }
}    

Parameters and local variables?

Example: Return values

public class Example {
  public static void main(String[] args) {
    String hello = "hello";
    hello = toTitleCase(hello);  //what if no assignment here?
    System.out.println(hello);
  }

  public static String toTitleCase(String str) {
    if (str.length() > 0) {  //XXX: doesn't support nulls
      return Character.toUpperCase(str.charAt(0)) + str.substring(1);
    }else {
      return ""; 
    }
  }
}

BTW: Strings are immutable: any method you call on a String that would change the String returns a changed copy instead.

Example: Nested method calls

System.out.println(mars.getAge());
String hello = "Hello";
System.out.println(hello.substring(hello.lastIndexOf('l')));

Don't do this too much though (hard to read/understand). Alternative:

String hello = "Hello";
int cutFrom = hello.lastIndexOf('l');
String end = hello.substring(cutFrom);
System.out.println(end);

For next time...

• A02
• Only one 5-point quiz this week given Wed.