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!