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 didnt 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 didnt
  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 didnt 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
• Ive 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
• Thats 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
• Im 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()
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 havent really seen yet
• Consider the game to be one package
• The packages are broken down into hierarchies
• This uses inheritance
• Our game didnt 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!