The programming assignment for chapters 13, 14, 15,
and 16 will be a GUI and graphical program which answers a research question and
uses the elements we've studied in cool but useful program. It will be judged
partly on appearance, creativity, and overall "coolness". See grading
rubrics at right for further grading specifications.
The project must be a simulation that answers a research question
and draws a time plot of an important variable. The best projects are ones that
could be expanded into a science fair project.
- Milestone 1. Due on or before
April 7, 2010
- Value: 25 points
1st step in the software design cycle: Submit an analysis of the
project goals and criterion for success. Must contain at least 3 paragraphs ( 1 to 2
typed pages) as follows:
- Paragraph 1) State and discuss your project's research question, statement of purpose,
and/or goals. After reading this paragraph, an evaluator should have a clear
idea of why you are doing your project.
- Paragraph 2) State your hypothesis. Note, a
hypothesis is not an "educated guess". Guessing at an answer before the
research is done or project completed can create bias. A hypothesis is a proposal for answering the
research question, statement of purpose, or goals. For a software project, the hypothesis should state what
the program will do and how it will go about answering the research
question/proposal/goals. (See hypothesis.)
- Paragraph 3) Discuss the required input,
possible algorithms, and graphical output in at least in general terms. Keep
this simple but complete. A person reading your proposal should be convinced
that you are capable of programming it. Remember the program should have both
a scientific/technical and artistic side.
Choose your project
wisely. If you take Computer Science II you can use your program as a
- Milestone 2. On or before April 12, 2010
- Value: 50 points
2nd step in the software design cycle:
This will include the
following (2 to 10 pages):
- Drawing of the GUI interface. The
operation and purpose of the program should be reasonably evident just by
looking at the drawing of the GUI. The drawing can be done using PowerPoint or
other types of object oriented drawing tools. Drawings done by hand must be done neatly with a straight edge.
A drawing of the GUI should be the staring point of a design.
- Block drawing from BlueJ showing the
relationship of the classes.
- Printouts from BlueJ outlining each class with
Javadoc descriptors at the top (title, purpose, author, date), important
fields, and major methods with their Javadoc descriptors (purpose,
preconditions, post conditions). This is a design. Do NOT include code.
- Milestone 3. On or before May 4th earns
a 10 pt bonus, May 5th to 17th earns no bonus, May 18th to 21st earns a 10 pt
penalty, May 22nd+ earns a 20 point penalty.
- Value: 100 points
3rd step in the software design cycle:
This should include
the following elements:
- GUI interface - chap. 16, 17
- a pull down menu that opens a simple help file. The help file is a
separate text file in the same folder with the code. - chap. 14
- 3 classes minimum
- a graph or graphical output - chap. 15
- 200 lines of code minimum
- Spaces, include lines, lines with only a curly bracket, lines not written by
the student, and comments do not count.
- complete comments - use Javadoc
comments on all classes, methods, and fields (see the criterion section under
the grading heading for more detail)
for Managing a Large Software Project
Creating a large software project is like
ridding a horse: As long as you stay on top and the horse is going in the
right direction, you're ok. But, if you lose control you're likely to find
yourself spending a lot of time (and maybe pain) just getting back to where
you started. The following tips are offered to help keep you in the saddle.
- Do a quality job on Mile Stone 2. A
good starting design will make a big difference in controlling your
Project. Having a logical design will make it much easier to find bad
lines of code.
- Compile often. It's easy to find
compiling errors if they are few in number and are confined to a few lines
- Do not delete. If a line of code is
not working comment it out. Do not delete it until you have your code
working. This will prevent you from going in circles. When finished be
sure to delete commented out code. It's bad form to leave sections of
commented out code in your final program. Doing so will reduce your grade.
- Set up your GUI first. A GUI is
easy to trouble shoot and will move you in the right direction of
- Achieve Output ASAP. You cannot
spot run time errors until your program is actually running. Run time
errors are problems such as over running an array and will result in error
messages. You also cannot evaluate your program's logic and troubleshoot
logic errors until you have output. You will frequently need to add
temporary output for troubleshooting purposes.
- Take baby steps. Troubleshooting
difficulty increases exponentially with the number of errors. You need to
eliminate compiling, run time, and logic errors as you write the program.
Do not wait to the end before starting the debugging process.
- Do not let others write your code.
It's ok to seek help but if you let others—who may or may not understand
your design—actually alter your code you are almost guarantied to lose
control of your project, especially if you code is not already working.
- Comment as you code. Adding
comments as you code facilitates the troubleshooting process. It helps you
find parts of your code which are not working.
Your project folder is
to be placed inside a folder with your name on it. This folder will be
placed in the “Turn in Folder for Comp Sci Project” on the R or G-drive. The
project must already be compiled or a deduction will be made.
Note: Criterion and Mastery factors are
subject to change.
- Research Question
or Purpose Answered ( 15 pts ): Does the project answer the
research question and do major
algorithms work in a meaningful manner?
Answering the research question or purpose is more important than having an
- Abstract ( 5 pts ): Does the applet
or main class
have a short paragraph in comments at the beginning that explains the
purpose of the project and how the program proposes to accomplish it does?
Without an abstract criterion 1 cannot be properly evaluated.
- User Friendliness (
5 pts ):
Is the purpose and operation of the program reasonably evident just by
looking at the GUI? Can a new user
understand and use the project in just a few minutes by muddling?
- Efficiency of Code
( 15 pts ):
The program must use loops and methods rather than needlessly repeating
lines of code.
- Style ( 5 pts ): Does the program
follow conventional style and indenting forms?
- Javadocs and Comments ( 5 pts ): Are the Javadoc’s
adequate? For example:
each class and method should have a purpose. Each fields or variable
should have either an obvious name or comment. Each method should have a
title, purpose, preconditions, and post conditions. Algorithms and significant
code segments inside methods On the other hand, overdoing comments can
also result in a
Classes: at a minimum a brief description.
Fields: a brief description.
Constructors: a brief description.
Methods: a briefdescription, @param with a description of any arguments, @ return with a description of any value returned
- Help file ( 10 pts
): Has a pull down menu in the GUI which reads a text file
containing help instructions and displays it in a separate text box.
Note, the text file is generally created in an application such as
Notepad and is not part of the Java source code.
elements ( 35 pts ): The code must contain the following elements:
- loops - both simple and nested
- parameter passing
- if-else statements
- Robustness ( 5 pts ): Is it easy to crash the
Total Possible =
- GUI and Graphics (
0-1 ): Must have a GUI interface containing controls like buttons
and pull down menus and must have some form of graphics.
- Functionality ( 0-1
): Will the project
compile and do all the features of the GUI work?
Programs that won't compile receive a zero.
- Credits ( 0-1 ): Is all
borrowed code from open source programs clearly marked as such?
Plagiarism will result in a grade of zero.
- Number of Classes (
0-1.01 ): Are there at least
classes? Programs with less than 3 classes
receive a zero.
- Size ( 0-1.01 ): Are there at least
line of code written by the student? Repeated lines of code will not be
counted as part of the 300 line if a loop or method could do the job
more efficiently. Spaces, borrowed code, and comments do not count.
Understanding ( 0-1 ): Can the student
explain the code?
- Coolness ( .9-1.03
): Is the program cool in
some way or hum drum? Does it in some way exceed expectations?
- Cleanness of the
project (0.8-1.0): All unused or extraneous code, classes, or
interfaces are to be deleted, in other words, cleaned up.
Highest Possible =
1.05 ( Note a grade this high
would be extremely rare)
The final grade is calculated by multiplying
all the Mastery Factors (MF) times the sum of all the Criterion (C).
Grade = (MF1*MF2*...*MF8)*(C1+C2+...+C9)
Note: having a zero in any mastery
factor will cause a grade of zero.
The maximum grade is 105%
Forms of Software Design
Design is the 2nd step of the
life cycle and can make or break the coding step. The 2
dominate style of design are as follows:
Top-down design: starts with an overview of the software
that defines relevant subsections based on a well-developed
understanding of the system to be created. The overview identifies
the purpose and interface requirements of the subsections.
Top-down design is similar to creating an outline for a writing
project such as a book.
In Mr. Rogers opinion, some level of top-down design is almost
always needed in order to efficiently code a program, especially
if the project is divided among multiple programmers.
Bottom-up design: starts by fully specifying individual
subsystems in detail. The subsystems are then eventually linked
together into a complex project. These projects tend to grow in
size and complexity over time as a greater understanding of the
project evolves. Bottom-up designs have been compared to growing a
plant from a seed.
Realistically, some amount of bottom up design is almost always
done in creating a piece of software. However, over-reliance on
bottom-up designing can result in spaghetti code (a tangled mess).