Course Summary
Course Summary
Fall 2006
CS 101
Aaron Bloomfield
1
Course Reflection
2
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.
3
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
4
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
 And it was handled better than it was last semester
 The visual diagrams to show what was going on
 Videos of lectures
 Clicker response system
 Using cs101 e-mail for faster response
5
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 (not
group assignments)
 This is a bit difficult to implement unless you have very large
lectures
Textbook is changing!
 This will also mean the slides will change as well
Different clickers (the ones you use for CHEM 151)
Won’t be using CodeLab
 Might use a similar system
I want to talk about debugging more
 We are considering a site license for the debugging version of
JCreator
Will (hopefully) have more TAs, and thus more TA office hours
Might have forums/newsgroups on the website
6
What didn’t work this semester
 Textbook issues during the first month of the semester
 One of the big reasons I’m changing books
 Clickers!
 Clickers!
 Clickers!
 Want to lower the amount of student frustration
7
What did work this semester
Videos of lectures
Clickers, sort of
Using cs101 e-mail for faster response
Many things that were “behind the scenes”
 TA organization and utilization
 Grading system
 Me delegating the work better to the TAs
 The marshmallow gun!




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” 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 9 HWs over about 16 weeks
 That’s about 3.5 hours (on average) on homeworks per week
From lab 12, This course required 5.2 hours per week outside of
lectures
 Other courses required 6.2 hours
I’m interested in your feedback on this!
 But not today in lecture…
9
 Please send e-mail (anonymous or not) if you have comments…
The Big OOP Picture
10
The classes for the game










Ship (HW J6)
Cell (HW J6)
Descriptions (lab 9)
ShipList (HW J7)
Parser (Lab 10)
AI (HW J8)
Human (provided in HW J8)
MapPrinter (lab 11)
Board (HW J9)
Game (provided)
11
How a big OOP program interacts
 Note how the classes interacted in the game
 A lot of objects were created and manipulated
 A Cell for each spot in the Board grid
 Ships possible in each Cell
 Etc.
 The way this game has objects interacting is how a big OOP
program would work
12
“rowboat"
Cell
- ship
- isHit = false
+…
ShipList
- int shipCount = 0
- Ship[] list
b
Cell
+…
Board
- ship
- isHit = true
+…
(0,0)
- int NOT_SHOT_AT = 0
- int MISSED = 1
-…
- int sizex = 8
- int sizey = 8
- ShipList ships
- Cell [][] cells
Ship
- length = 2
- name
- int xPosition = 0
- int yPosition = 0
- int hits = 1
- boolean isH = false
+…
Ship
Cell
- ship
- isHit = false
+…
+…
(7,7)
Cell
Cell
Cell
Cell
Cell
- ship
- isHit = true
+…
- ship
- isHit = false
+…
- ship
- isHit = true
+…
- ship
- isHit = false
+…
- ship
- isHit = false
+…
- length = 3
- name
- int xPosition = 4
- int yPosition = 7
- int hits = 1
- boolean isH = true
+…
“canoe"
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 10 classes
 Each class is broken down into methods and variables
 Some (such as MapPrinter) only had a few; others (such
as Ship) 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
Review of Chapter 1
16
Demotivator 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 were as of 11:00 today
 The results, with 186 of 198 precincts
reporting…

17
Engineering software
 Complexity of software grows as attempts are made to make
it easier to use
18
Software engineering
 Goal
 Production of software that is effective and reliable,
understandable, cost effective, adaptable, and reusable
 Design
Makescorrectly
Work
Because
Cost
tosense
software
of
develop
the
due
and
so
long
to
and
not
that
the
fail
lifetime
maintain
new
greatfeatures
costs
many
should
involved
and
people
not
capabilities
to
will
exceed
have
be
involved
expected
can
flexible
be added
components
benefit
that can be used in other software
 Creation
 Debugging
 Maintenance
 Enhancement
 Two-thirds of the cost is typically beyond creation
19
Principles of software engineering
 Abstraction
 Encapsulation
 Modularity
Determine
relevant
Ranking orthe
ordering
of
properties
and
Separate
Construct
components
a
system
from
into
objects
features
while
ignoring
external
and internal
components
and
nonessential
aspectsdetails
packages
 Hierarchy
20
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
21
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
22
Problem Solving Process
 What is it?
 Analysis
 Design
 Implementation
 Testing
23
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
24
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
25
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
26
Problem Solving Process
 What is it?
 Analysis
 Design
 Implementation
 Testing
Test the components individually and collectively
27
Problem Solving Process
Determine
problem features
Describe objects
and methods
Produce the
classes and code
Examine for
correctness
Analysis
Rethink as
appropriate
Design
Implementation
Testing
28
Tips
 Find out as much as you can
 Reuse what has been done before
 Expect future reuse
 Break complex problems into subproblems
29
Tips
 Find out as much as you can
 Reuse what has been done before
 Expect future reuse
 Break complex problems into subproblems
Consider
Research
can is
require
and generate questions
Find out what
knownsignificant
about thetime
problem
Sketching
apresenter
solution
andbecause
then repeatedly
its components
The
worthwhile
the resultrefine
is a better
Talk effort
to theis
until
the entire process is specified
understanding
Determine what attempts have succeeded and what attempts
True
of the problem makes it easier to solve
have understanding
failed
30
Tips
 Find out as much as you can
 Reuse what has been done before
 Expect future reuse
 Break complex problems into subproblems
Your
Be
open
timetoisindirect
valuable
use of existing materials
Correctness is probably even more valuable
Use existing infrastructure that is known to work
31
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
32
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
33
And the winner, with 37 votes, is…
34
Have a great holiday
break!
35