Course Summary
Course Summary
Spring 2007
CS 101
Aaron Bloomfield
1
Course Reflection
2
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.
3
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
4
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
5
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
6
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 (!)
7
 “Only” 263, vs. 415 two years ago
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…
8
 Please send e-mail (anonymous or not) if you have comments…
The Big OOP Picture
9
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)
10
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
11
Map
map
- populate()
- getLocation()
-…
- map:
-…
Location
- app = “arid”
- depot
-…
-…
Location
- app = “sunny”
- depot
-…
-…
Depot
Depot
- name = “FortX”
- location
- costFactor = 2.0
- inventory
-…
- name = “FortX”
- location
- costFactor = 2.0
- inventory
-…
Inventory
Inventory
- money = 0.0
- food = 1000
- ammo = 100
- oxen = 100
-…
- money = 0.0
- food = 1000
- ammo = 100
- oxen = 100
-…
player
Location
- app = “cloudy”
- depot
-…
-…
Map map = new Map();
map.populate();
Classes w/only static methods:
Control, Descriptions
Game, MapPrinter, Parser
Location
- app = “rocky”
- depot
-…
-…
Party
- size = 3
- party
-…
Person
Vehicle player =
new Vehicle (const);
player.setLocation
(map.getLocation
(const, const));
Vehicle
- location
- party
- inventory
-…
-…
Inventory
- money = 155.1
- food = 234
- ammo = 17
- oxen = 12
-…
- name = “Chris”
- health = 10
- isAlive = true
-…
Person
- name = “Chris”
- health = 10
- isAlive = true
-…
Person
- name = “Chris”
- health = 10
- isAlive = true
12
-…
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.
13
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
14
Have a great summer
break!
15