Post on 19-Jan-2018
description
1
Course Summary
Course SummarySpring 2007CS 101Aaron Bloomfield
22
Course ReflectionCourse 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…
99
The Big OOP PictureThe 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 = 0.0
- food = 1000- ammo = 100- oxen = 100- …
Location- app = “cloudy”- depot- …- …
Location- app = “rocky”- depot- …- …
map
Location- app = “sunny”- depot- …- …
player
Party- size = 3- party-…
Depot- name = “FortX”- location- costFactor = 2.0- inventory-…
Inventory- money = 0.0- food = 1000- ammo = 100- oxen = 100- …
Depot- name = “FortX”- location- costFactor = 2.0- inventory-…
Inventory- money =
155.1- food = 234- 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
1515
Have a great summer Have a great summer break!break!