Getting in touch

Things to do now

• Bookmark: https://course.ccs.neu.edu/cs3500/

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

• Register on https://handins.ccs.neu.edu. Choose your section correctly! (If you choose wrong, contact Kayla immediately.)

Resources for the entire semester

• Design Principles Master List

• How to write tests

• Using Examplar

Grading

Grade breakdown:

• 60% homework

• 5% labs / in-class exercises (style + attendance + non-trivial submission)

• 15% first exam

• 20% second exam

Both exams count towards your final grade

N.B. exact percentages may change slightly

Homework

• Nine homeworks: four shorter ones, then four longer ones, and one extra credit

• Usually due at 8:59 PM

• Self-eval: another separate assignment from the "main" assignment. Do not open self-eval until you are done with main assignment.

• Late policy

  • Four No-Questions-Asked Late Days (2 for individual, 2 for group)

  • Use at most one per assignment (including labs and self-evals!)

  • No other late work accepted without extension.

  • If you need an extension, email me. See the syllabus for details.

Examplar

• Practice in lab on Friday

• Used for HW1 to learn testing for this class

• Your goal: write examples to separate the working implementations (wheat) from the buggy ones (chaff)

• Our goal 1: Give you intuition on writing meaningful tests from a specification.

• Our goal 2: Give you a way to test your assumptions.

• Grading criteria

  • Correctness: How many tests do not cause the wheat to fail?

  • Thoroughness: How many chaffs cause at least one of the tests to fail?

  • Precision: For each chaff, is there a unique subset of examples that fail on that chaff?

  • Uniqueness: For each test method, did that test method catch a unique subset of chaffs?

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

  • If you use ChatGPT or anything similiar to write code for you, you fail the class

• You are responsible for protecting your work

  • If someone uses your work, you fail the class

• If you are using github, make and keep repo private

What to expect

• Time commitment
  • Read lecture notes, attend lectures regularly
  • Start early, work often
  • If you are working on same thing for hours, take a step back. You may need some assistance.
• Lecture -> Assignment correspondence
• Testing matters, how/when to test
• The idea of self-evaluations

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