Getting in touch

• http://www.ccs.neu.edu/course/cs3500/

• Sign up for Piazza (instructions on main web page)

Academic integrity

• No illicit collaboration

  • Guideline: words okay, code not okay

  • If unsure, ask!

• You must submit only your own work

  • If you steal someone else's work, you fail the class

• You are responsible for protecting your work

  • If someone uses your work, you fail the class

Grading

Grade breakdown:

• 60% homework

• 15% first exam

• 25% second exam

N.B. exact percentages may change slightly

Homework

• Eight homeworks: four shorter ones, then four longer ones

• Usually due at 8:59 PM

• Late policy

  • Four No-Questions-Asked Late Days™

  • Use at most one per assignment

  • No other late work accepted

Simple semantics

(define (f->c f) (* 5/9 (- f 32)))

(f->c 212)

(* 5/9 (- 212 32))

(* 5/9 180)

100

But programs get big

Another challenge: change

• Customers don't know what they want

• What they want changes

Software development life cycle

1. Analysis

2. Design

3. Implementation

4. Testing

5. Deployment

6. Evaluation

7. GOTO 1

Software development life cycle in theory

1. Analysis

2. Design

3. Implementation

4. Testing

5. Deployment

6. Evaluation

7. GOTO 1

Software development life cycle in practice

1. Cursory analysis

2. Completely wrong implementation

3. Slightly less cursory analysis

4. Wrong-headed design

5. Some implementation and testing

6. More analysis and re-design

7. More implementation and testing

8. Iterate, iterate, iterate

9. Deployment

10. Bug reports (Yay!)

11. Head scratching

12. Coffee

13. Temptation to rewrite from scratch

We need help!

• How can we deal with complexity?

• How can we design for flexibility?

Object-oriented design

Central concepts:

• Information hiding

• Interfaces

• Polymorphism

Loose coupling

• Replacement

• Reuse

SOLID Principles

• Single responsibility: every object should be responsible for just one focused purpose

• Open/closed: everything can be open to extension, but closed to modification

• Liskov substitution: if a type S is a subtype of a type T, then objects of type S can be used anywhere objects of type T can.

• Interface segregation: no client should be forced to depend on methods it doesn't use

• Dependency inversion: abstractions should not depend on details; rather the reverse

What makes software “good”?

• Correctness

• Efficiency

• Security, maintainability, robustness, portability, reliability, testability, usability, scalability, ...

“No silver bullet”

There is no single development, in either technology or management technique, which by itself promises even one order-of-magnitude improvement within a decade in productivity, in reliability, in simplicity.

—Fred Brooks

Topics

• What are objects all about?

• Interface polymorphism

• Data abstraction and encapsulation

• Client perspective versus implementor perspective

• Object-oriented terminology

• Generic polymorphism

More topics

• Testing and specification

• Algorithmic efficiency

• Software archaeology

• Class diagrams

• Design patterns