CS 3500, Summer I 2020
Getting in touch
|Amit Shesh||NI 132C|
|Clark Freifeld||NI 132G|
|Jason Hemann||326 WVH|
|Vidoje Mihajlovikj||132E Nightingale|
Things to do now
Sign up for Piazza (instructions on main web page)
Register on handins.ccs.neu.edu. Choose your section correctly!
Make sure you can access this course on Teams (one for entire course, one for your section)
Resources for the entire semester
1-2% in-class exercises
15% first exam
24% second exam
N.B. exact percentages may change slightly
Seven homeworks: four shorter ones, then three longer ones
Usually due at 8:59 PM
Self-eval: separate assignment from the "main" assignment. Do not open self-eval until you are done with main assignment.
Four No-Questions-Asked Late Days (2 for individual, 2 for group)
Use at most one per assignment
No other late work accepted
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
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
How to use lecture notes
Read the recommendations on course web page
Fill out ungraded survey for each lecture on handins (you won't be able to submit an assignment if you don't!)
Why Object-oriented Design?
Writing software is hard
Writing good software
is very hard
(define (f->c f) (* 5/9 (- f 32))) (f->c 212)
(* 5/9 (- 212 32))
(* 5/9 180)
But programs get big
|1993||Windows NT 3.1||4|
|1994||Windows NT 3.5||7|
|1996||Windows NT 4.0||11|
|2003||Windows Server 2003||50|
We compose complex systems from simple parts
We can write programs that we cannot completely understand
Another challenge: change
Customers don't know what they want
What they want changes
Software development life cycle
Software development life cycle in theory
Software development life cycle in practice
Completely wrong implementation
Slightly less cursory analysis
Some implementation and testing
More analysis and re-design
More implementation and testing
Iterate, iterate, iterate
Bug reports (Yay!)
Temptation to rewrite from scratch
We need help!
How can we deal with complexity?
How can we design for flexibility?
One possible answer:
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
Sis a subtype of a type
T, then objects of type
Scan be used anywhere objects of type
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”?
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.
What are objects all about?
Data abstraction and encapsulation
Client perspective versus implementor perspective
Testing and specification