Iteration 1: Design

As you work on your project in this iteration, you must update the project board that you submitted as a Roadmap in Iteration 0 to keep track of your progress.

Project Proposal Revision

Submit the revision of your project proposal as a Markdown document at docs/project-proposal.md in the master branch of your group’s repository at https://github.com/jhu-oose/2019-group-<identifier>.

If you submitted multiple proposals in Iteration 0, then you must decide on one now.

Discuss your proposal with your advisor. You may need to revise some parts, or scale your project up or down.

Design

Submit the design of your application as a Markdown document at docs/design.md in the master branch of your group’s repository at https://github.com/jhu-oose/2019-group-<identifier>.

Architecture

This is a more detailed version of the Architecture Overview you introduced as part of the Solution in your Project Proposal.

If you’re using only the tools in the Toolbox, then this section may be the same as the Architecture Overview: “We’re using the tools in Toolbox.”

If you’re deviating from the Toolbox, then you must specify the components of your application, for example, a web application for system administrators, a mobile application for customers, an API for plugin developers, and so forth.

You must also specify which tools outside the Toolbox you’re using, including services, APIs, libraries, frameworks, and so forth. For example, if you need an email server, then you must specify which email server you’re using (either Exim, or Postfix, and so forth). You must discuss what these tools are, why you chose them, and how to configure them, similar to what we did when introducing the Toolbox.

Finally, you must specify how these tools connect to one another if that connection isn’t obvious. For example, if you’re using an email server, how does it deliver incoming messages to the application server? Via a pipe? Via the filesystem?

The presentation of the architecture must tell a story, not simply list tools.

Class Diagram

The class diagram must communicate high-level ideas about the structure of an implementation of the distinguishing features of your application. These are the classes that are models, not classes that are controllers, repositories, server, and so forth. Your class diagram must include enough information for an implementor to know what to do, but avoid clutter. A typical class diagram includes the following:

At least 10 classes.
At least 10 attributes.
At least 5 methods.
At least 5 associations between classes.
Multiplicities in associations (for example, 2, 0..3,, *, and so forth).
Appropriate use of whole-part (diamond) annotations.
Appropriate use of inheritance arrows.
At least 2 design principles (annotate the diagram to point them out).
At least 1 design pattern (annotate the diagram to point it out).

Start Code Base

Submit the code base for of your application in the root directory of the master branch of your group’s repository at https://github.com/jhu-oose/2019-group-<identifier>.

Install all the tools listed in the Architecture and make them work together. You may need to run project generators (for example, those included in IntelliJ IDEA), add dependencies in a build system, configure databases and email servers, and so forth. If you’re using only the tools in the Toolbox, you may accomplish this by starting with TODOOSE, removing everything specific to that application, and leaving behind only the skeleton (for example, removing the ItemsController, but leaving the package for controllers).