1 / 15

Course Summary

Course Summary. Course Summary Spring 2007 CS 101 Aaron Bloomfield. Course Reflection. Course goals. Objectives: Students who complete the course will: Understand fundamentals of programming such as variables, conditional and iterative execution, methods, etc.

jaafar
Download Presentation

Course Summary

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript


  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 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…

  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(); Map map • populate() • getLocation() • … • map: • … Location Location Location • app = “cloudy” • depot • … • … • app = “sunny” • depot • … • … • app = “arid” • depot • … • … Location Party • app = “rocky” • depot • … • … • size = 3 • party • … Depot Depot Person • name = “FortX” • location • costFactor = 2.0 • inventory • … • name = “FortX” • location • costFactor = 2.0 • inventory • … • name = “Chris” • health = 10 • isAlive = true • … Inventory Inventory Inventory Person • money = 0.0 • food = 1000 • ammo = 100 • oxen = 100 • … • money = 0.0 • food = 1000 • ammo = 100 • oxen = 100 • … • money = 155.1 • food = 234 • ammo = 17 • oxen = 12 • … • name = “Chris” • health = 10 • isAlive = true • … Vehicle Person • location • party • inventory • … • … • name = “Chris” • health = 10 • isAlive = true • … player 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 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!

More Related