Mr. Rogers AP Computer Science -- Personal Software Project Specifications

Amer. College Board

Comp Sci Syllabus Mr. Rogers Class Info Southside High


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.

Project Milestones

Milestone 1. Due on or before April 7, 2010
Value: 25 points
Analysis--the 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 starting point.

Milestone 2.  On or before April 12, 2010
Value: 50 points Design--the 2nd step in the software design cycle: This will include the following (2 to 10 pages):
  1. 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.
  2. Block drawing from BlueJ showing the relationship of the classes.
  3. 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
Coding--the 3rd step in the software design cycle: This should include the following elements:
  1. GUI interface - chap. 16, 17
  2. 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. 3 classes minimum
  4. a graph or graphical output - chap. 15
  5. 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.
  6. complete comments - use Javadoc comments on all classes, methods, and fields (see the criterion section under the grading heading for more detail)

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

  1. 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.
  2. Compile often. It's easy to find compiling errors if they are few in number and are confined to a few lines of code.
  3. 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.
  4. Set up your GUI first. A GUI is easy to trouble shoot and will move you in the right direction of achieving output.
  5. 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.
  6. 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.
  7. 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.
  8. 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.


Grading Procedure

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.


  1. 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 impressive GUI.
  2. 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.
  3. 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?
  4. Efficiency of Code ( 15 pts ): The program must use loops and methods rather than needlessly repeating lines of code.
  5. Style ( 5 pts ): Does the program follow conventional style and indenting forms?
  6. 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 deduction.

    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

  7. 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.
  8. Programming elements ( 35 pts ): The code must contain the following elements:
  • methods
  • loops - both simple and nested
  • fields
  • parameter passing
  • arrays
  • instances
  • if-else statements
  1. Robustness ( 5 pts ): Is it easy to crash the program?

Total Possible = 100


Mastery Factors

  1. 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.
  2. Functionality ( 0-1 ): Will the project compile and do all the features of the GUI work? Programs that won't compile receive a zero.
  3. Credits ( 0-1 ): Is all borrowed code from open source programs clearly marked as such? Plagiarism will result in a grade of zero.
  4. Number of Classes ( 0-1.01 ): Are there at least 3 classes? Programs with less than 3 classes receive a zero.
  5. Size ( 0-1.01 ): Are there at least 300 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.
  6. Student Understanding ( 0-1 ): Can the student explain the code?
  7. Coolness ( .9-1.03 ): Is the program cool in some way or hum drum? Does it in some way exceed expectations?
  8. 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 software 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).

Ideas for Project

A good place to start:

While not Java, NetLogo is a relatively easy-to-learn computer language. It runs on the Java virtual machine, so will work on any computer that runs java, but that's not what makes it such a good starting point. Download the NetLogo IDE and you'll have access to several hundred simulation programs (in the IDE under files>models library). What make this such a great resource is not just the fact that you can run the models and see the possibilities, but you can also see the code and a full explanation of the science behind the model complete with  references. Anyone who knows Java should be able to look at the NetLogo code and have a pretty good idea of how to write something similar in Java, even without learning to program in NetLogo.

Other useful links and ideas:

  1. Artificial Intelligence: This attempt to simulate the human brain functions. This includes neural networks which are computer programs which learn.
  2. Artificial Life: Uses computer simulations to derive general theories about life. the Scientific American article "ARTIFICIAL LIFE: Boids of a Feather Flock Together" is a great place to start.
  3. Cellular automata: Cellular automata are computer programs that try to simulate life at the cellular level. They attempt to explain how undifferentiated cells can divide and become complex structures such as appendages.
  4. Chaos Theory: This deals with non linear systems which can become chaotic. It includes various forms of turbulence, animal populations, climate and the stock market.
  5. Fractals: These use relatively simple iterated equations to produce elaborate graphics.
  6. Number Series: There are many different type. Computers are commonly used to discover new members of various series. This includes the search for perfect numbers, mersenne primes, etc.
  7. Spam Filters: These devices are used for blocking e-mail spam. They can range from very sophisticated to very simple filters and can be fairly simple to write.
  8. Markov Chains:
  9. Physics Simulations Accounting for Air Resistance: The reason air resistance is ignored in most calculations has to do with the fact that it generally requires a computer to do account for it.
  10. Random Number Generators: There's no such thing as a perfect random number generator. Usually they have to strike a balance between performance and speed and are still a topic of research among computer scientists.
  11. Monte Carlo Simulations: These are programs which use random number generators to simulate complex problems. They can be extremely complex or very simple. Simple simulations of this type can be done with relatively little programming experience.
  12. Flocking/herding Behavior: Programs of this type attempt to simulate the behavior of predators and prey using simple sets of rules.
  13. Snow Flake/Crystal Growth: Look at thousands of pictures of snow flakes and they all tend to be slightly different yet they are recognizable as snow flakes. This implies that there are simple rules which can govern how the crystals are formed.






SAM Team--Southside High School's STEM and Computer Science extra-curricular club (Mr. Rogers Sponsor)

Mr. Rogers' Twitter Site

Mr. Rogers Teacher's Blog

Mr. Rogers T-shirts

Mr. Rogers Information for Teachers

Mr. Rogers Science Fair Information

Check out other web sites created by Mr. R:

Check out Articles by Mr. Rogers:

Insultingly Stupid Movie Physics is one of the most humorous, entertaining, and readable physics books available, yet is filled with all kinds of useful content and clear explanations for high school, 1st semester college physics students, and film buffs.

It explains all 3 of Newton's laws, the 1st and 2nd laws of thermodynamics, momentum, energy, gravity, circular motion and a host of other topics all through the lens of Hollywood movies using Star Trek and numerous other films.

If you want to learn how to think physics and have a lot of fun in the process, this is the book for you!


First the web site,

now the book!

Mr. Rogers Home | Common Sylabus | AP Comp Sci I | AP Comp Sci II | AP Physics Mech | AP Physics E&M | AP Statistics | Honors Physics|IB Design Tech | Southside

[ Intuitor Home | Physics | Movie Physics | Chess | Forchess | Hex | Intuitor Store |

Copyright © 1996-2011 T. K. Rogers, all rights reserved. Forchess ® is a registered trademark of T. K. Rogers.
No part of this website may be reproduced in any form, electronic or otherwise, without express written approval.