Title: Course Summary
1Course Summary
- Course Summary
- Fall 2005
- CS 101
- Aaron Bloomfield
2Course Reflection
3Course 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.
4Unstated 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
5What was new this semester
- Test code required
- In hindsight, this should have been explained
better - More TA office hours
- This was well received by everybody
- Faculty mini-talks
- Had trouble scheduling this in a coherent way, so
only one happened this semester. Should I do
more? - Labs
- Many were improved upon, and a few were added
- Increased number of HWs by 2
- Final few assignments were for a common big
program - In hindsight, we see a better way to implement
this next semester - Changing of the order the chapters were gone over
6Changes 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
- There were not enough people to make this work
this semester - Probably will ditch CodeLab - it didnt work as
well as I had hoped - Its 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 - Better web site design (its in development now
thoughts?) - Will most likely lower the number of midterms to
two (and require the final) - Want to put more diagrams in the slides (make
them more visual) - Will have the TAs give review sessions before the
tests - Might have forums/newsgroups on the website
7What didnt work this semester
- I botched a lecture back in September (in chapter
3) - With this fixed, Ill have freed up one more
lecture session - Plus one for the removed midterm
- A number of things worked, but need improvement
(mentioned before) - Implementation of the game
- Faculty mini-talks
- Required test code
- The semester schedule (i.e. Thanksgiving break)
made it difficult to properly teach arrays - There wasnt a HW on 1-D arrays as a result
- This wont be a problem in the spring, but will
be next fall - Had a bit of trouble keeping the lectures
interesting towards the end of the semester - Want to lower the amount of student frustration
8What did work this semester
- This class learned much more than last semesters
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 - Changing of the order the chapters were gone over
- Improved TA office hours
- Improvements to the labs
- Grading system worked very well this semester
- All the code on the website
- Many things that were behind the scenes
- TA organization and utilization
- Grading system
- Me delegating the work better to the TAs
9Did I push too hard this semester?
- I pushed the class much harder this semester than
last semester - But did I push too hard?
- Consider
- Ive gotten as many things are going great
comments as I have things are too hard comments
(anecdotal) - Homeworks took under 5 hours on average
- The results from the survey questions for each HW
- There were 8 HWs over about 16 weeks
- Thats 2.5 hours (on average) on homeworks per
week - Ultimately, I think that with a bit better
organization, I can lower the amount of time
spent on the HWs while still having people learn
the same amount - Im interested in your feedback on this!
- But not today in lecture.
10The Big OOP Picture
11The classes for the game
- Creature (HW J6)
- Weapon (HW J6)
- Room (HW J7)
- Map (HW J8)
- Game (HW J8)
- Parser (lab 9)
- Descriptions (lab 10)
- MapPrinter (lab 11)
12How a big OOP program interacts
- Note how the classes interacted in the game
- A lot of objects were created and manipulated
- A Room for each spot in the grid
- Creatures and Weapons for some of the Rooms
- A Map object
- Etc.
- The way this game has objects interacting is how
a big OOP program would work - Encapsulation
- The Room class didnt need to know how the
Creature class kept track of whether the monster
was angry or not - It just called getAngry() and setAngry()
- It could have been stored as a boolean or an int
13Problem 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 havent seen yet
- Consider the game to be one package
- The packages are broken down into hierarchies
- This uses inheritance
- Our game didnt use a hierarchy, as you did know
of inheritance at that point - The hierarchies are broken down into classes
- The game had 8 classes
- Each class is broken down into methods and
variables - Some (such as MapPrinter) only had 1 others
(such as Map) had dozens - Each method is broken down into parts, etc.
14The 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 over
1,300 lines - 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 part, and saw how it interacted
with the rest of the system
15Review of Chapter 1
16Demotivator winners!
- Methodology
- 1st place vote counted for 3 points
- 2nd place vote counted for 2 points
- 3rd place vote counted for 1 point
- Will buy two demotivators and hang them in my
office - The results, with 137 of 173 precincts reporting
17Engineering software
- Complexity of software grows as attempts are made
to make it easier to use
18Software engineering
- Goal
- Production of software that is effective and
reliable, understandable, cost effective,
adaptable, and reusable
- 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
19Principles 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
20Object-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
21Programming
- 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
22Problem Solving Process
- What is it?
- Analysis
- Design
- Implementation
- Testing
23Problem 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
24Problem 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
25Problem 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
26Problem Solving Process
- What is it?
- Analysis
- Design
- Implementation
- Testing
Test the components individually and collectively
27Problem Solving Process
28Tips
- Find out as much as you can
- Reuse what has been done before
- Expect future reuse
- Break complex problems into subproblems
29Tips
- 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
30Tips
- 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
31Tips
- 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
32Tips
- 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
33Have a great holiday break!