Introduction

In this milestone you are setting up the high-level design of your project, and starting the implementation of the model and view. The specific tasks are the following:

• derive the model and view components of the design for last quarter's model and prototype, respectively
• refine the model and view designs based on the initial SCOs that have been agreed for your project, and using the packaging guidelines discussed in 308 lecture notes week 5
• refine the view-only form of execution in the 308 prototype to execution where model and view classes communicate with each other

Deliverables

1. The package directory structure defined under your- project/implementation/source/java. See 309/examples/milestone2/implementation/source/java for an example.

2. A draft overview.html, describing the high-level architectural design of your tool in terms of its basic functionality and the separate executable components of the tool. The overview.html file goes in your- project/design/javadoc. See 309/examples/milestone2/design/javadoc/overview.html for an example.

3. Draft package.html files within each package directory, describing the purpose and contents of the package. See all of the package.html files under 309/examples/milestone2/implementation/source/java/caltool/ for examples.

4. The derived and compilable .java files for the model classes. See the Java files in 309/examples/milestone2/implementation/source/java/caltool/ for examples.

5. Operational menubar and/or top-level toolbar(s) for your tool. If your tool has multiple top-level applications, you may choose to implement two or more top-level UIs for this milestone, however a single top-level UI is entirely satisfactory.

6. Integration of at least two pairs of model/view classes for each team member, where the integration entails:

   1. Implementation of stubbed methods in the model classes; there must be at least three such methods per class, per team member, for a total of six model methods per team member.

   2. Design and implementation of one or more companion view classes for the chosen model classes, in which there must be at least three action-producing UI elements that call a model method. The GUIs can be based on last quarter's prototype, with packaging and design documentation added, as well as integration with the model methods.

   3. Display of the GUI via the appropriate top-level menu or toolbar command.

   4. Invocation of the stubbed model methods from the view, to validate that the model/view communication is happening.
   To summarize, this deliverable requires that each team member connect at least six model methods to corresponding view, spread over at least two model/view class pairs.

7. Generated javdoc for all classes, with the content of the javadoc comments following the handout on 309 design and implementation conventions.

8. NOTE WELL: There must be an @author javadoc comment for every class that identifies the author(s) of that class. As described in the design and implementation conventions, if a class has multiple authors, their names and IDs are listed comma-separated in the same @author tag.

9. An administration file named "m2-duties.html" that names the model/view class pairs assigned to each team member for this milestone. Include a brief description of how to run each team members work from the top- level GUI. Note that this m2-duties file is in addition to the general work-breakdown.html. The purpose is to make the work assignments for this milestone completely clear.

10. An updated general work-breakdown.html.

    1. Add any updates since milestone 1, in particular making sure the "Implementation Files" column is up to date, and consistent with the (separate) m2-duties.html.

    2. Put the names of the appropriate .java files in that column, thereby assigning .java files to team members. If a team member is designing all of the Java files in a particular package, the the package directory can be listed instead of individual .java files.

11. A HOW-TO-RUN.html file in the project administration directory. This file explains how to start up the one or more executables for your project.

package ... ;

/****
 *
 * Generic stub file so javadoc will generate package-level documentation,
 * without any real class files yet defined.
 *
 */
public class JavadocStub {}

Note on Projects Not Using Java

The preceding deliverable descriptions are described in terms of Java. If you use a development platform other than Java, substitute the equivalent forms of support in your chosen platform.

In particular, the development language(s) and platform you choose must provide the equivalent of a javadoc documentation generation tool. If it does not, the chosen platform is not usable in 309.

Discussion of Work Assignments

The individual work assignment for executable deliverables can be in one of the following forms:

1. A managerial model class, the corresponding pull-down menu, and the implementation of at least one data-entry dialog with an OK button. The three other model methods can be invoked from other data-entry dialogs or directly from the menu.

2. A model class and its companion editor view, with four buttons that invoke stubbed model methods.

3. A model class and a companion display view, with buttons, sub-menus, or other GUI elements that invoke four stubbed model methods.

One team member needs to be in charge of the top-level model class with the Main method, and the menubar itself. This member can work on a relatively simple model/view pair, e.g., File or Edit.

The point of this milestone is to get started with model/view communication, not to have a completed implementation in any form. If you're working on a model/view pair that requires some non-trivial model data, you can stub out the data in a very simple form. For example, if you have data that will eventually be stored in an SQL database, you can stub out those data initially as a java.util.Vector. If you're working on a view that has some complicated layout, you can stub it out by putting in javax.swing.JLabel place-holders for some of the complicated components of the GUI.

Details of ``Stub'' Files and Methods

The term "stubbed file" will be used in 309 to denote a place holder for part of the design or implementation that is not yet fully defined. We will use a number of different forms of stub files throughout the quarter. For this milestone, class stub files are necessary as described above, so that javadoc will not complain about empty package directories.

This milestone involves package-level but not all of the class-level design for view (i.e., GUI) classes. Therefore, some view packages may have no view classes defined. In such cases, you will need a stub .java file as a place holder in that package. As noted above, this is necessary to avoid complaints from javadoc. You'll also need to put a stub file in any model package that has no derived classes.

Definition of ''Stub'' Methods

The body of a "stubbed method" consists of a single print statement of the form:

System.out.("In class-name.method- name.");

public void scheduleAppointment(Appointment appt) {
    System.out.println("In Schedule.scheduleAppointment.");
}

public AppointmentsList listAppointments() {
    System.out.println("In Lists.listAppointments.");
    return null;
}

For the purposes of this milestone, "non-trivial" model data refers to collections that may be displayed in the GUI. For list displays, javax.swing.DefaultListModel is a good choice. For tables, consider javax.swing.DefaultTableModel.

Notes on Work Breakdown for this Phase of the Design

In your project's administration/work-breakdown.html, add a new, right-most column called "Implementation Files", where you list the .java files assigned to the team member for each row in the table. If one team member is working on all of the files in a package, you can list the files as package/*.java.

Each team member must write and commit at least one package.html file and at least one .java file in a package. This is a trivial amount of work in terms of the initial content of the files. The initial package.html need only be a sentence or two describing the purpose and contents of the package; it will be refined as we go. The initial package classes are just stubs to allow javadoc to be generated. The reason that everyone should do these things is to get a concrete understanding of the physical structure of a multi-package java design. The package.html files will expand in the future, and the .java stub files will obviously expand to real class designs and implementations.

Grading

This milestone is worth 8% of the overall project grade. The scoring out of 100 raw points is as follows:

• Design documentation 50/100:
  • packages: 8
  • classes: 20
  • methods: 12
  • data fields: 10
• GUI Execution: 25/100
• Stubbed Model Method Execution, via call from GUI View class: 25/100

Per the design and implementation conventions, the javadoc comment for each class must have an "@author" javadoc tag indicating the single author for that class. Any team member who is listed as the @author of NO classes will receive a score of zero on Milestone 2, even if that person's name appears in the work-breakdown file.