Cmpt 225

General Requirements

• You are expected to do your entire assignment on your own, otherwise, you will be penalized.

• You must follow the phases of the software development process described in our first lectures as part of all your CMPT 225 assignments. This signifies that you must create:
• Object-Oriented and Modular Design. This includes (but is not limited to) the decomposition of large methods into smaller ones where each resulting method has 1 purpose or responsibility, and the use of decomposition and encapsulation to create classes, where each class has 1 purpose or responsibility and has a well defined interface (public aspect of the class.
• Object-Oriented Program. This includes (but is not limited to) good programming style as well as good internal documentation.

• You must use exception handling mechanism to handle any erroneous and exceptional situations (i.e., unexpected situations) that may occur.

• You must build a command-line interface (CLI) to your application as opposed to a graphical-user interface (GUI). A command-line interface application does not make use of dialogue boxes to communicate with the user. Instead, it displays its output in the same window in which you have issued the "execute" or "run" command to run your application and it takes its input from the keyboard. In most of our assignments, your application will need to be "menu-driven", i.e., the execution of your application is driven by the menu selection the user has made (from menus displayed on the monitor console).

• You cannot use an I/O library provided by a Java introductory textbook (or any other Java textbooks) you may have used in your previous courses. Actually, you cannot use any libraries aside from the libraries that comes with Java 2 Standard Ed. 5.0 and you cannot use Java Collection classes such as the ones (but not limited to) contained in the java.util package.

• In our assignments this semester, you may be required to use specific names for your classes, documents, filenames, and directories (folders). When these names are bolded (bolded and underlined), this signifies that you must use this exact name (same spelling, extension, etc.) given in the assignment. One of the reasons for this requirement is that it will make the marker's task a lot easier when he is, for example, looking for a particular file in your submitted assignment, or attempting to compile your assignment. And believe me, you want a happy marker marking your assignment, not an annoyed one :-)

• All your classes must be stored in their own file, unless you are creating "inner" classes.

• Do not "hardcode" filename and/or file path into your code. Instead, ask the user to enter this information. This makes your application more flexible.

• For Java software software developers: Assume that the markers will be compiling and running your application from one of the CSIL Linux workstations or from one of the CSIL Windows workstations using JDK 1.5 (Java 5). If you have developed your assignment on another platform, using another version of Java, I strongly suggest that you compile and run your assignment on one of the CSIL workstations (Linux or Windows) before submitting it. This will prevent situations in which your assignment cannot compile hence cannot be marked.

• For the C++ software developers: Assume that the markers will be compiling and running your application from one of the CSIL Linux workstations or from one of the CSIL Windows workstations. If you have developed your assignment on another platform, I strongly suggest that you compile and run your assignment on one of the CSIL workstations (Linux or Windows) before submitting it and that your submit your makefile or .dsw files (if you used Visual C++ to implement your assignment) along with your assignment. This will prevent situations in which your assignment cannot compile hence cannot be marked.

• You must not create Java packages. You must not create Jar files. You must have all your java files in one directory. This eases the task of compiling your files.

About Documents

Marking Scheme

Phase 1 - Design and Phase 2 - Verification

• We will look at the completeness, quality and correctness (use of abstraction, decomposition and encapsulation) of your
• UML Design Diagram
• Identification of your real-world objects (classes) and their characteristics
• Interaction (relationship) between your real-world objects
• Assignment of operations to appropriate classes
• Correct class invariant, precondition(s) and postcondition(s)
• Algorithms
• Interfaces (public aspect of classes)
• Test plans
• Completeness of your unit test plans

• We will look at
• completeness (this includes internal comments) of your code
• quality (efficient design, proper decomposition of large methods such as the main( )) of your code
• correctness (your classes do satisfy their invariant, your methods do satisfy their precondition(s) and postcondition(s)) of your code

• We will compile all the classes you provided and run your application.
• Completeness and Correctness: We will look at how well your application satisfies the requirements of the assignment, which includes the problem statement and its requirements as well as the submission requirements, and the general requirements listed above.
• We will run your test drivers and look at the completeness of your unit testing.