Course Summary

1. Course Summary Course Summary Spring 2007 CS 101 Aaron Bloomfield

2. Course Reflection

3. Course goals • Objectives: Students who complete the course will: • Understand fundamentals of programming such as variables, conditional and iterative execution, methods, etc. • Understand fundamentals of object-oriented programming in Java, including defining classes, invoking methods, using class libraries, etc. • Be aware of the important topics and principles of software development. • Have the ability to write a computer program to solve specified problems. • Be able to use the Java SDK environment to create, debug and run simple Java programs.

4. Unstated course goals • Everybody needs to have a “base” level of programming to continue on in the CS courses (or as required by other departments) • CS 101 and 201 provide that “base” level

5. What was new this semester • Each of the homeworks and exams are always new each semester • Because of the ‘fraternity file’ effect • The course project • A new one was developed for this semester • Some things that were improved upon from last fall: • Videos of lectures • Clicker response system • Using cs101 e-mail • Different textbook than last semester • Only 1 grad TA, so most tasks that are usually done by grad TAs (such as running labs) were done by undergrad TAs

6. What didn’t work this semester • Clickers! • Although they did work better than last semester • I still think that they can greatly help a large course, if they work • Grading • The big problem was HW 7 – it got delayed a long time, and caused a domino effect • The course project • A good idea, but in hindsight, we didn’t implement it as well as we should have • Want to lower the amount of student frustration • Some humor that seemed not so appropriate after the VT shootings, so I didn’t show them

7. What did work this semester • Videos of lectures • Clickers, sort of • Using cs101 e-mail • The new textbook • Students liked it much better than the one used in the past • The assignments ideas were more creative than in the past • Keeping a class of 360 students moving is not a trivial task • Many things that were “behind the scenes” • TA organization and utilization • Grading system • Me delegating the work better to the TAs • The class size was smaller (!) • “Only” 263, vs. 415 two years ago

8. Did I push too hard this semester? • I pushed the class hard this semester • But did I push too hard? • Consider: • I’ve gotten more “things are going great, but hard” comments than I have “things are too hard” comments (anecdotal) • Homeworks took about 6 hours, on average • The results from the survey questions for each HW • There were 10 HWs over about 15 weeks • That’s about 4 hours (on average) on homeworks per week • From lab 12, This course required 6.7 hours per week outside of lectures • Other courses required 7.0 hours • I’m interested in your feedback on this! • But not today in lecture… • Please send e-mail (anonymous or not) if you have comments…

9. The Big OOP Picture

10. The classes for the game • Control (hw 10) • Depot (hw 8) • Descriptions (lab 10) • Game (all assignments) • Inventory (hw 8) • Location (hw 7) • Map (hw 10) • MapPrinter (lab 11) • Parser (lab 9) • Party (hw 9) • Person (hw 7) • Vehicle (hw 9)

11. How a big OOP program interacts • Note how the classes interacted in the game • A lot of objects were created and manipulated • A Location for each spot in the Map grid • Depots possible in each Location • Etc. • The way this game has objects interacting is how a big OOP program would work

12. Map map = new Map(); map.populate(); Map map • populate() • getLocation() • … • map: • … Location Location Location • app = “cloudy” • depot • … • … • app = “sunny” • depot • … • … • app = “arid” • depot • … • … Location Party • app = “rocky” • depot • … • … • size = 3 • party • … Depot Depot Person • name = “FortX” • location • costFactor = 2.0 • inventory • … • name = “FortX” • location • costFactor = 2.0 • inventory • … • name = “Chris” • health = 10 • isAlive = true • … Inventory Inventory Inventory Person • money = 0.0 • food = 1000 • ammo = 100 • oxen = 100 • … • money = 0.0 • food = 1000 • ammo = 100 • oxen = 100 • … • money = 155.1 • food = 234 • ammo = 17 • oxen = 12 • … • name = “Chris” • health = 10 • isAlive = true • … Vehicle Person • location • party • inventory • … • … • name = “Chris” • health = 10 • isAlive = true • … player Classes w/only static methods: Control, Descriptions Game, MapPrinter, Parser Vehicle player = new Vehicle (const); player.setLocation (map.getLocation (const, const));

13. Problem solving • To solve a problem in CS, you break it down into smaller and smaller pieces… • A big program is broken down into packages • Which we haven’t really seen yet • Consider the game to be one package • The packages are broken down into hierarchies • This uses inheritance • Our game didn’t use a hierarchy, as you did not know of inheritance at that point • The hierarchies are broken down into classes • The game had 12 classes • Each class is broken down into methods and variables • Some (such as MapPrinter) only had a few; others (such as Location) had lots • Each method is broken down into parts, etc.

14. The completed game • This could easily be made by multiple people • Each person does a separate class • Not exactly equal, but it still lowers the workload • Our (fully commented) code for the game was well over 1,000 lines • Granted, we had very long comments • However long yours was, it was a about a 1,000 line program • Even if you had trouble getting parts working, and had to use our code • You still wrote all the parts, and saw how they interacted with the rest of the system

15. Have a great summer break!