Draft Release: 11:59 Monday 20 April, to be discussed during week 4 lab meetings
Finished Release: 11:59PM Monday 27 April, to be formally evaluated

Continued work on Design and Implementation:

1. Make any necessary refinements to the package design of Milestone 2.

2. Provide design documentation for all packages, classes, methods, and data fields.

   1. Note Well: Permanent point deductions will be made for any missing documentation.

   2. The handout for the 309 Design and Implementation Conventions has details for what the documentation entails.

   3. In particular, model class documentation must consist of

      1. a description of the purpose of the class

      2. a summary of the methods that the class provides

      3. for classes that define a significant data structures, a description of what the data structures are, including pictures if necessary

      4. for classes that implement a significant piece of processing, a description of the processing algorithms employed

   4. At the end of the conventions handout is the following point breakdown for the design documentation:
      • packages: 5%
      • classes: 15%
      • methods: 12%
      • data fields: 8%
      which means you will lose up to 40% of the points for your portion of the milestone if any or all design documentation is missing.

3. Complete the .java files for all derived model classes.

   1. The files should have public methods that trace to operations in the requirements specification, some of which are implemented (see below).

   2. If a method is unimplemented, make it a "stub", as described in the Milestone 2 writeup.

4. Define model class data representations.

   1. I.e., provide the class data fields that define how class data are represented.

   2. Begin implementation of model methods, to produce real data, or canned testing data.

   3. As necessary, write test data-generation methods, to support model classes where underlying process classes are not yet completed.

   4. Each team member must have some key aspect of the model data design implemented, where the precise definition of "key" will be determined in our lab meetings, and the precise definition of "implemented" means that the execution of the program can be validated as described under HOW-TO- RUN below.

5. Refine view classes.

   1. Continue to refine view class design and implementation.

   2. As necessary, provide hand-built model testing data, when underlying process classes are not completed.

6. Bottom Line -- some things must actually run for Milestone 3.

   1. There must be implemented model classes that hold real data. (Real data can include canned testing values; "real" means that data are held in the model, not just views.)

   2. GUIs on the screen must communicate with the models to change and view the data.

   3. We will discuss in Week 4 labs precisely what each team member is responsible for.

Testing:

1. Define the testing package design. As described in Lecture Notes 3, the testing package structure mirrors exactly the model package structure. Hence, the packaging hierarchy for testing is a clone of tool's packaging design. I.e., the package directories under your- project/testing/implementation are the same as those under your-project/implementation.

   If you use an IDE such as Eclipse, you can use its test support features to create the testing packages and template testing classes. If you do not use such an IDE, then you build the package directories and classes by hand, which is not a particularly time consuming task.

   A testing package structure generated by an IDE may be in a different location than your-project/testing/implementation. If this is the case, please include a simple one-line file in the project administration directory named TESTING-DIRECTORY-PATH.html. The one line in this file has the path to the testing directory.

2. Write a draft integration test plan for the entire team. Put the plan here:

   testing/implementation/integration-test-plan.html

3. Per team member, write class test plans for the model you were assigned in Milestone 2, or alternate classes if appropriate. (We will define exactly what "if appropriate" means in your week 4 lab meetings.)

   1. To be specific, each team member must define the testing class for two of their model classes. These are the classes containing the methods for which the preconditions and postconditions are defined in the next deliverable.

   2. As described in 309 Lecture Notes Week 3, Week 4, and the Milestone 3 example, the class test plans appear as javadoc comments in the testing classes.

4. Per team member, refine/write Spest ¹ pre- and postconditions for the six model methods you were assigned in Milestone 2 (and additional methods if necessary).

   1. At least three of these methods must involve some form of data validation and error communication with the GUI.

   2. For the three methods (at least) that perform data validation, you must:

      1. Define/refine Spest preconditions and postconditions, suitable for unit test generation

      2. Design and implement the error communication between the model and view. It is highly recommended that you use the exception-based error handling design discussed in Lecture Notes Week 3, but if your team may choose to use an alternate design, as long as it achieves the same level of model/view separation as that of the design described in the notes.

Administration:

1. Provide a HOW-TO-RUN.html file in the project administration directory.

   1. This file explains how to start up the one or more executables for your project.

   2. Where necessary, be very precise about what commands the end-user performs, what files need to be present, and any other necessary support structures that need to be in place for execution to be successful.

2. Provide a m3-duties.html file.

   1. It itemizes for each team member the parts of the project that produce validatable execution results.

   2. It also itemizes precisely for each team member what aspects of the implementation the member is responsible for, and how the implementation is validated.

   3. Validation must include at least some display in a GUI window, with communication to appropriate model class(es), including data validation error handling.

   4. In addition, validation may also be presented by:

      1. the creation of data files

      2. the creation of database entries

      3. output to stdout
      where all such forms of validation must be described clearly and completely for each team member.

   5. So in summary, make the contents of the m3-duties file a table of the following form, with commands and validation details appropriate for your project:

      Team Member	Description of Operation	User Commands	Validation
      Member1	Add an item to the Stuff database	select Stuff->Add menu item, fill in dialog and press 'OK'	select View->Stuff menu item, confirm that item was added
      	Deleting from Stuff	select Stuff->Delete menu item, enter ID of item to delete	confirm in view that item is gone
      	Sorting Stuff	add three items in reverse order of ID; select Stuff->Sort menu item	confirm in stdout dump that items have been sorted
      ...
      Member6	...	...	...

3. Update work-breakdown.html as necessary. (The work-breakdown file defines overall project responsibilities. The m3-duties file defines the specific work for Milestone 3. For example, work- breakdown can say that team member X is working on all of the classes in a particular package. The m3-duties file will say which particular classes and methods are the focus of work for Milestone 3.)

4. As noted earlier, if the path to your testing directory is other than your- project/testing/implementation, provide the path name in the one- line file administration/TESTING-DIRECTORY-PATH.html.

Footnotes:

¹ If your team is using a language other than Java (i.e., Node JS or Python), then pre- and postconditions are written as function (aka, method) comments in the syntax of your language