1 / 34

CS 101 Spring 2006 Course Summary and Reflection

This course summary provides an overview of the goals, objectives, and changes of the CS 101 course during the Spring 2006 semester. It also discusses what worked and what didn't work, as well as future changes and improvements.

emanseau
Download Presentation

CS 101 Spring 2006 Course Summary and Reflection

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 2006 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 • It’s hard to change things for the spring semester, because of the size of the class • 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 • And it was handled much better than it was last semester • The visual diagrams to show what was going on • Many more TA office hours

  6. Changes on deck for next semester • Will keep (and improve upon) all the stuff from the last slide • Study groups • The idea is a way for people to study and/or work together • This does NOT mean group assignments, however • This is a bit difficult to implement • Am considering if I want to use CodeLab - it didn’t work as well as I had hoped • It’s a good idea, but a real pain to manage properly • I want to talk about debugging more • We are considering a site license for the debugging version of JCreator • Want to put more diagrams in the slides (make them more visual) • Will have the TAs give more review sessions before the tests • Might have forums/newsgroups on the website

  7. What didn’t work this semester • Requiring test code • The intent was to make students think about how to test their program • A number of things worked, but need improvement (mentioned before): • Implementation of the game • Required test code • Want to lower the amount of student frustration • The computer systems always dying. ARGH!!! • A lack of sleep on my part

  8. What did work this semester • This class learned more than last semester’s class did • Even if you feel confused now, take my word for it • And as my goal is to teach (and not to be popular), this is a good thing • Improved TA office hours • Grading system worked very well this semester • All the code on the website • And the fancy website design! • Many things that were “behind the scenes” • TA organization and utilization • Grading system • Me delegating the work better to the TAs

  9. Did I push too hard this semester? • I pushed the class harder this semester than last semester • But did I push too hard? • Consider: • I’ve gotten more “things are going great” comments than I have “things are too hard” comments (anecdotal) • Okay, without HW J7, which we said was our bad • Homeworks took under 5 hours on average • The results from the survey questions for each HW • There were 8 HWs over about 16 weeks • That’s 2.5 hours (on average) on homeworks per week • This course required 4.1 hours per week outside of lectures • Other courses required 7.2 hours • I’m interested in your feedback on this! • But not today in lecture…

  10. The Big OOP Picture

  11. The classes for the game • Location (HW J5) • Vehicle (HW J6) • Market (HW J7) • Inventory (HW J7) • Cargo (HW J7) • Universe (HW J8) • Parser (Lab 9) • Descriptions (Lab 10) • Map (Lab 11) • Game (provided)

  12. How a big OOP program interacts • Note how the classes interacted in the game • A lot of objects were created and manipulated • A Location (or not) for each spot in the Universe grid • Markets and Inventories for each Location • A Vehicle object • Etc. • The way this game has objects interacting is how a big OOP program would work

  13. universe vehicle Location Location Location Location Location Universe • name = “Gem” • market • … • … • name = “Gem” • market • … • … • name = “Gem” • market • … • … • name = “Gem” • market • … • … • name = “Gem” • market • … • … • density = 0.1 • universe: • populate() • … Market Market Market Market Market • costFactor = 1.0 • inventory • … • costFactor = 1.0 • inventory • … • costFactor = 1.0 • inventory • … • costFactor = 1.0 • inventory • … • costFactor = 1.0 • inventory • … Universe Inventory Inventory Inventory Inventory Inventory Inventory • cargo: • … • cargo: • … • cargo: • … • cargo: • … • cargo: • … • cargo: • … Cargo Cargo Cargo Cargo Cargo Cargo Cargo Cargo Cargo Cargo Cargo Cargo • “cloth” • … • “cloth” • … • “gems” • … • “gold” • … • “silver” • … • “water” • … • “fuel” • … • “gold” • … • “oil” • … • “toys” • … • “wood” • … • “texts” • … Vehicle • location • inventory • …

  14. 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 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 10 classes • Each class is broken down into methods and variables • Some (such as Map) only had a few; others (such as Location) had dozens • Each method is broken down into parts, etc.

  15. 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 1,500 lines • Granted, we had very long comments • However long yours was, it was a program greater than 1,000 lines • 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

  16. Review of Chapter 1

  17. Demotivator winners! • Methodology • 1st place vote counted for 3 points • 2nd place vote counted for 2 points • 3rd place vote counted for 1 point • Ties were resolved by the number of 1st place votes • Will buy two demotivators and hang them in my office… • The results, with 410 of 447 precincts reporting…

  18. Engineering software • Complexity of software grows as attempts are made to make it easier to use

  19. Software engineering • Goal • Production of software that is effective and reliable, understandable, cost effective, adaptable, and reusable • Work correctly and not fail • Goal • Production of software that is effective and reliable, understandable, cost effective, adaptable, and reusable • Because of the long lifetime many people will be involved • Creation • Debugging • Maintenance • Enhancement • Two-thirds of the cost is typically beyond creation • Goal • Production of software that is effective and reliable, understandable, cost effective, adaptable, and reusable • Cost to develop and maintain should not exceed expected benefit • Goal • Production of software that is effective and reliable, understandable, cost effective, adaptable, and reusable • Design software so that new features and capabilities can be added • Goal • Production of software that is effective and reliable, understandable, cost effective, adaptable, and reusable • Makes sense due to the great costs involved to have flexible components that can be used in other software • Goal • Production of software that is effective and reliable, understandable, cost effective, adaptable, and reusable

  20. Principles of software engineering • Abstraction • Encapsulation • Modularity • Hierarchy • Abstraction • Encapsulation • Modularity • Hierarchy • Abstraction • Encapsulation • Modularity • Hierarchy • Abstraction • Encapsulation • Modularity • Hierarchy • Abstraction • Encapsulation • Modularity • Hierarchy Determine the relevant properties and features while ignoring nonessential details Ranking or ordering of objects Separate components into external and internal aspects Construct a system from components and packages

  21. Object-oriented design • Purpose • Promote thinking about software in a way that models the way we think and interact with the physical word • Including specialization • Object • Properties or attributes • Behaviors

  22. Programming • Problem solving through the use of a computer system • Maxim • You cannot make a computer do something if you do not know how to do it yourself

  23. Problem Solving Process • What is it? • Analysis • Design • Implementation • Testing

  24. Problem Solving Process • What is it? • Analysis • Design • Implementation • Testing • Determine the inputs, outputs, and other components of the problem • Description should be sufficiently specific to allow you to solve the problem

  25. Problem Solving Process • What is it? • Analysis • Design • Implementation • Testing • Describe the components and associated processes for solving the problem • Straightforward and flexible • Method – process • Object – component and associated methods

  26. Problem Solving Process • What is it? • Analysis • Design • Implementation • Testing • Develop solutions for the components and use those components to produce an overall solution • Straightforward and flexible

  27. Problem Solving Process • What is it? • Analysis • Design • Implementation • Testing Test the components individually and collectively

  28. Problem Solving Process

  29. Tips • Find out as much as you can • Reuse what has been done before • Expect future reuse • Break complex problems into subproblems

  30. Tips • Find out as much as you can • Reuse what has been done before • Expect future reuse • Break complex problems into subproblems • Research can require significant time and generate questions • The effort is worthwhile because the result is a better understanding • True understanding of the problem makes it easier to solve Consider Sketching a solution and then repeatedly refine its components until the entire process is specified • Find out what is known about the problem • Talk to the presenter • Determine what attempts have succeeded and what attempts have failed

  31. Tips • Find out as much as you can • Reuse what has been done before • Expect future reuse • Break complex problems into subproblems Your time is valuable Correctness is probably even more valuable Use existing infrastructure that is known to work Be open to indirect use of existing materials

  32. Tips • Find out as much as you can • Reuse what has been done before • Expect future reuse • Break complex problems into subproblems • Make as few assumptions as necessary • Maximizes the likelihood that your effort can be used in future situations

  33. Tips • Find out as much as you can • Reuse what has been done before • Expect future reuse • Break complex problems into subproblems • Divide-and-conquer • Solve subproblems and combine into an overall solution

  34. Have a great holiday break!

More Related