Project 1 — UMBC 4.0 Parking Garages

Assigned Wednesday, February 15th
Program Due Wednesday, February 29th by 9:00am
Weight 6%
Updates

Objectives

To gain experience:

  1. Implementing and using classes
  2. Separating an OO program’s user interface code from its application code
  3. Performing console input/output in Java
  4. Documenting classes
  5. Documenting methods

Project Policy

This project is considered an OPEN project. Please review the Project Policies on the Projects page before beginning your project.

Project Analysis

Once this project is turned in, the code will be reviewed in class as noted on the schedule as “Project 1 Analysis.” If you would like to volunteer your code to be reviewed in class as part of the analysis, please contact your instructor. Your name will be held in strict confidence. This practice has worked extremely well in the past. It is a wonderful way to compare and contrast the different designs that people have used. And think about it -- you get personel (yet anonymous) feedback on your project by your instructor!

Project Overview and Design

UMBC has decided to build three single-car parking garages next to the ITE building. The garages will be available for use by computer science majors who maintain a 4.0 GPA. Of course, there are certainly more than three CS majors with 4.0 GPAs at any given time. But times are tough. So, the garages are first-come, first-served every day.

The design of your first project will contain exactly two classes. One class will be a Garage class, which will contain the attributes and operations (e.g. open the door) for a single-car garage. The other class will be a user interface (UI) class called Project1 that contains the main() method from which the program begins execution. The Project1 class will also be used to perform user input/output and to invoke the appropriate methods of the Garage class. The program will be driven by a simple text-based menu with one-character menu options.

Project Specification

A parking garage will be able to be in one of six states at any given time. Those states are:

Note that when either a garage's door is broken or there has been an accident in the garage, the garage is rendered non-functional. That is, it cannot be used (i.e. the user should be informed if they attempt to perform an action, such as open the door, on a non-functioning garage). Also, these are the only two types of malfunctions that can occur.

When your program starts, it will assume that all three garage doors are operating properly, but closed, and that all garages are empty.

Next, the following menu must be displayed. 

  O - Open door
  C - Close door
  P - Pull car in
  B - Back car out
  F - Find an empty space
  D - Display space state
  E - Exit the program

Further explanation of these options is as follows.

Note that, where relevant, the garage on which to perform an action (1, 2, or 3) must be specified before any other needed inputs. In general, be sure to perform the tasks listed for each command in the exact order specified above and prompt for the input needed in the exact order specified above. Not doing so may result in the grading script not being able to handle your program, resulting in a lowered grade.

Project Hints, Notes, Requirements, Restrictions

  1. The package name for this project must be proj1.
  2. The user interface class (that contains main()) must be called Project1. The garage class must be called Garage.
  3. You may use an array object to hold the garages, but it is not required. However, you may not use any of the API container classes, such as ArrayList. That will be allowed later in the semester.
  4. In keeping with the principle of separation of user interface and applications code, the Garage class should not perform any user input or output. All user input/output should be performed by Project1's main() or one of main’s helper methods.
  5. Be sure that you follow the OOP principle of encapsulation. Don’t use accessors and mutators to write procedural code in main(); call appropriate Garage methods instead. Remember, we want to provide the “minimal public interface.”
  6. You must comment using Javadoc formatting for both method and class headers.
  7. All methods of the Project1 and Garage classes must have appropriate method header comments, including pre- and post-conditions, as shown in the course coding standards and discussed in class. Make sure that your Project 1 code does not violate any Garage method preconditions. If it does, the Garage method should throw a RuntimeException exception with an appropriate message (we will discuss this in class).
  8. Both the Project1 and Garage classes should have file header comments, but you may omit the Class Invariant portion (for now).
  9. Use the Scanner class for user input as discussed in lab. Be sure to create only one Scanner object, which should be an instance variable in the Project1 class. If you do not follow this procedure, it is possible that the automated grading script will not work with your program (and that’s not good!).
  10. Since main() is by definition a static method, any constants, instance variables, and helper methods that are also defined within the Project1 class and used by main() should be defined as private static. (We'll talk about how to get around this later in the semester.)
  11. Generally speaking, each main menu selection corresponds to a method of the Garage class.
  12. Input Guarantees and Error Handling:
    1. All user input is guaranteed to be of the correct type, but not necessarily a valid value.
    2. Menu selections are guaranteed to be entered as a single character, but may be either upper- or lower-case. In the case of an invalid menu selection, display an informative error message to the user and redisplay the menu.
    3. In the case of the selection of a garage (1, 2, or 3), if the user enters other than these values, display an appropriate error message and reprompt the user for the garage number.
    4. For all other errors (e.g. attempting to open a broken garage door), display an appropriate error message and return the user to the main menu.
    5. Be informative. When your program performs an action, it should tell the user whether or not the action (say what it is) is successful or not. Also, tell the user on which garage the operation has been attempted (e.g. "Garage 1 has a broken door and cannot be opened."). Remember, the user should never be puzzled as to what is currently happening with the program.

Grading

See the course website for a description of how your project will be graded.

Project Compilation and Submission

Before submitting your project, be sure to compile and test your code on the GL system. See the compiling and executing on the GL system link on the course Projects page for details on how to compile and execute your project on GL.

See the Submitting your project for grading link on the Projects page for detailed instructions on how to submit your project.

You may resubmit your files as often as you like, but only the last submittal will be graded and will be used to determine if your project is late. For more information, see the Projects page on the course web site.

Remember — if you make any change to your program, no matter how insignificant it may seem, you should recompile and retest your program before submitting it. Even the smallest typo can cause errors and a reduction in your grade.