Course Summary - PowerPoint PPT Presentation

About This Presentation
Title:

Course Summary

Description:

Be aware of the important topics and principles of software development. ... Many things that were 'behind the scenes' TA organization and utilization. Grading system ... – PowerPoint PPT presentation

Number of Views:28
Avg rating:3.0/5.0
Slides: 34
Provided by: csVir
Category:
Tags: course | summary

less

Transcript and Presenter's Notes

Title: Course Summary


1
Course Summary
  • Course Summary
  • Fall 2005
  • 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
  • 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

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

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

8
What 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

9
Did 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.

10
The Big OOP Picture
11
The 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)

12
How 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

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

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

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, with 137 of 173 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
  • 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

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

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
30
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
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
Have a great holiday break!
Write a Comment
User Comments (0)
About PowerShow.com