1 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  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  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 (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: - … - populate() - getLocation() - … Vehicle - location - party - inventory - … Location - app = “arid” - depot - … Inventory - money = food = ammo = oxen = … Location - app = “cloudy” - depot - … Location - app = “rocky” - depot - … map Location - app = “sunny” - depot - … player Party - size = 3 - party -… Depot - name = “FortX” - location - costFactor = inventory -… Inventory - money = food = ammo = oxen = … Depot - name = “FortX” - location - costFactor = inventory -… Inventory - money = food = ammo = 17 - oxen = 12 - … Classes w/only static methods: Control, Descriptions Game, MapPrinter, Parser Vehicle player = new Vehicle (const); player.setLocation (map.getLocation (const, const)); Map map = new Map(); map.populate(); Person - name = “Chris” - health = 10 - isAlive = true - … Person - name = “Chris” - health = 10 - isAlive = true - … Person - name = “Chris” - health = 10 - isAlive = true - …

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!