| 
    
 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
 
  - 
  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):
 
 
  - 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
 
  - 
  Coding--the 
  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)
 
 
    
      
        | 
         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. 
      - 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 
      of code. 
 
      - 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 
      achieving output.
 
      - 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. 
      Criterion 
      
        - 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.
 
        - 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 
        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 
           
         
      
        - 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.
 
        - 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
 
         
         
    
      - Robustness ( 5 pts ): Is it easy to crash the 
      program?
 
     
          
            Total Possible = 
            100 
              
     
    Mastery Factors 
      
        - 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 
        3 
        classes? Programs with less than 3 classes 
        receive a zero.
 
        - 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.
 
        - Student 
        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
              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).  | 
             
     
     |