Milestone 5 consists of the team Design Review: in lab week 7, per schedule below

Milestone 6 release: 11:59PM Monday 9 November

Overview

Your work for Milestones 5 and 6 involves the following activities:

• Completion of the requirements scenarios.
• Refinement of the Java model, including Spest pre/postconditions
• High-Level model/view design
• Initial model/view implementation
• Presentation of your model/view design to the class

NOTE: All model design and implementation must be done in Java. If your team wants to do view design and implementation in some toolkit other than Java Swing, you must make this decision by Wednesday 28 October.

Deliverables

1. Completed Section 2 of the requirements specification document, per comments in the Milestone 4 evaluation and team meetings during 6th and 7th weeks.

2. The package directory structure defined under your- project/implementation/source/java. Create this package structure by copying the current structure in your project specification directory into the project implementation/source/java/model directory. See 307/examples/milestone6/implementation/source/java for an example.

3. 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 307/examples/milestone6/design/overview.html for an example.

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

5. The derived and compilable .java files for the model classes. See the Java files in 307/examples/milestone6/implementation/source/java/caltool/ for examples.

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

7. Integration of at least one pair of model/view classes for each team member, where the integration entails:

   1. Implementation of stubbed methods in the model class; there must be at least three such methods for each team member.

   2. Design and implementation of one or more companion view classes for the chosen model class, in which there must be at least three action-producing UI elements that call a model method. The GUIs are chosen from the most important aspects of the requirements, as discussed in your team's milestone 4 evaluation.

   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 three model methods to the view, defined in at least one model/view class pair.

8. Spest preconditions and post conditions for at least three model methods per team member; the methods should not be overly complicated in their specification, and they do not need to be the same stubbed methods that are connected to the view, though they can be.

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

10. An updated work-breakdown.html:

    1. For each team member column, fill in the information the the "Milestone 6" row of the work-breakdown table.

    2. List all requirements files for each team member.

    3. List all model and view packages (or .java files) for each team member. If a team member is responsible for all the files is a package, then only that package name needs to be listed in the work-breakdown.

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.

12. An executable .jar file, located by default in the implementation/executables project directory. If the location is elsewhere, say so in the HOW-TO-RUN file. Note that if you have multiple applications for different users, then you will have multiple .jar files.

package ... ;

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

Overview of Model/View Design

For this milestone we are going to transition from the purely abstract model specification of the previous milestone to a more concrete model and view design. In terms of project directories, this involves copying the abstract model files from the project specification directory into a model sub-directory of the project implementation. Here's a picture of this transition:

The exact placement of of your model and view sub-directories is up to you. The important thing is that the model/view design of your program must be clearly evident in directory structure. Lecture Notes Week 6 discuss details of model/view design, including alternatives for exactly how to lay it out.

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. 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 307 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 _ui 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

As noted above, 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.

Discussion of Design Reviews

The schedule for the design reviews during week 7 labs is posted at 307/handouts/design-review-presentation-schedule.html You may use any media you choose, including powerpoint slides, whiteboard, and operational demonstrations. Organize your presentations along the following lines:

1. focus the discussion on the major interesting model and view classes

2. use UML and function diagrams to present the design

3. you can also show Java code excerpts, in large font

4. if you have an operational demo of an interesting piece of GUI functionality, present it

Scoring on the requirements component of the milestone is as follows:

• Complete and consistent with evaluation comments and customer meeting discussions; if you have any questions about this, please come to office hours for further clarification: 55/100
• Follows proper requirements presentation style, as described in the requirements document outline and lecture notes week 3 : 35/100
• Traceable to the Java model: 10/100

Scoring for the design and implementation component of the milestone is as follows:

• Design documentation 24/100:
  • packages: 4
  • classes: 12
  • methods: 8
• GUI Execution: 28/100
• Stubbed Model Method Execution, via call from GUI View class: 28/100
• Spest pre/post logic: 20/100