• Overview
• Elements
  • Project description: 3 points
  • Intended users and user stories: 4 points
  • Wireframe diagram: 6 points
  • UML class diagram: 8 points
  • Cloud- or device-based services or data: 4 points

Overview

This is the end of the first sprint of the personal Android project, with a set of deliverables due. In general, the deliverables include project summary elements, as well as high-level design documentation: user stories, a wireframe diagram, and a UML class diagram for the domain model classes of your project.

Most of the tasks in this deliverable are assigned as homework, and are evaluated that way; however, there is also a project value of 25 points (out of 200 total for the project); in addition, up to 5 points of extra credit can be earned for exemplary execution of any or all of the required elements.

All of the items listed below are expected to be accessible/linked to from the project’s GitHub Pages site.

Elements

Project description: 3 points

This should appear on your overview page, and will generally need to be more detailed than in your proposal.

• There must be at least one paragraph summarizing the project topic in general terms.

• There must be at least one additional paragraph (or a bullet list) containing an overview of intended functionality.

Please use complete sentences and proper grammar.

Intended users and user stories: 4 points

This must be presented as a list (numbered or bulleted), either in the project overview page or in a page reachable by a link from the overview page.

• Each item in the list should have a single type of intended user. Be as specific as possible—for example, something along the lines of “Anyone who likes games” is not sufficient.

• Below each type of intended user, you must have at least one user story for that intended user. Make these specific, but not excessively detailed; 1 or 2 sentences per user story is generally appropriate. Remember that each user story should follow (at least roughly) the form:

  As a <type of intended user (who)> I want to <goal (what)> so that <benefit (why)>.

Note: Extreme verbosity, dramatic expression, or poetic form may be amusing to the instructors (and presumably, to you), but it generally won’t earn any extra credit. In fact, if it detracts from the instructors’ ability to understand the who, what, and why of the user story, it may actually work against you.

Wireframe diagram: 6 points

• The wireframe must be displayed as a single SVG, in a page dedicated to this purpose, accessible via a link from the main (overview) page of your GitHub pages site. This PNG image must be a clickable link that opens a PDF form of the same image.

• In most cases, the wireframe should show at least 3 screens. If you don’t think your app will have that many screens, don’t forget about settings screens, high score screens for games, user profile screens, etc.

• On the other hand, if you find yourself including more than 5 screens, try to focus on the 5 most important screens—at least for now.

• Flow between the screens should be indicated by arrows, leading from some control (button, menu item, etc.) in one screen to another screen. To help the reader understand the flow, add short text annotations to these arrows.

UML class diagram: 8 points

Classes and general requirements

• Only classes specific to your application should be included; do not (for example) include classes from the Java standard library—though types defined in that library (and others) should be included as attribute, operation, or parameter types, as appropriate.

• Each class in the diagram must be named using UpperCamelCase (like all Java classes we write).

• Each class must include all attributes and operations that have non-private access. While private attributes and operations are often included in class diagrams (especially implementation class diagrams), do not include them here.

  On each included attribute or operation, indicate its access level with these prefixes:

  • ”+” for public;
  • ”#” for protected;
  • ”~” for package-private.

• All attributes and non-constructor operations must be named using lowerCamelCase (like all methods and non-constant fields in a Java class or interface).

• All attributes, operations (other than operations corresponding to constructors), and operation parameters included in the diagram must be written so that the type is shown after the name, with a colon character (“:”) separating them.

  • For an attribute, the type is the type returned by the corresponding property’s accessor (getter), or the parameter type of the mutator (setter); see below for more on this.

  • For operations corresponding to methods, use the method return type.

  • For methods with the void return type, include “void” as the return type in the diagram.

  • For constructors included as operations in the diagram, do not include a return type (obviously, you don’t need to follow the operation name with a colon in this case, either).

• For an enumeration (i.e., an enum class), the “«enumeration»” prefix is used before the class name, and enumerated values are listed in a similar fashion to attributes, but written in UPPER_SNAKE_CASE, without an access-level prefix, and without a type suffix.

  For example, if in our puzzle application, each piece is of one of three types, enumerated as CORNER, EDGE, INTERIOR; and if we intend to implement that as an enum class named PieceType, we would include that class in the diagram shown on the right.

  (If we have declared non-private methods in enum class—beyond those inherited from Enum or generated automatically by the compiler—they must be included as described in “Method operations”, below.

Attributes

For this diagram, the attributes of a class will be taken from the properties of the class, not directly from the fields (which should all be private anyway). That is, if some aspect of the object state is exposed outside the class using an accessor (getter) or mutator (setter) that follows the JavaBeans naming conventions (i.e., getProperty() for a non-boolean-valued accessor, isProperty() for a boolean-valued accessor, setProperty(value) for a mutator), that defines a property, which must be included as an attribute in the diagram.

If there is a getter for a given property, but not a corresponding setter, it is a read-only property, indicated by “{readOnly}” (or “{read-only}”) in the diagram; conversely, if there is a setter but no getter, it is a write-only property, indicated by “{writeOnly}” (or “{write-only}”).

For example, if you have (or plan to have) a class name “Puzzle”, with a method declared (or planned) as public int getMissingPieces(), but without a corresponding setter, then we conclude the following:

• The attribute (property) name is “missingPieces”.

• missingPieces has a getter without a corresponding setter, so it is read-only.

• missingPieces has public visibility, so it must be included in the diagram.

(Note that the above conclusions hold even if there is no actual field named missingPieces.)

Given the above, we would include this as an attribute of Puzzle in the class diagram:

+ missingPieces: int {readOnly}

Method operations

Any operation that you have implemented (or plan to implement) as a non-private method—not including accessors and mutators that follow the JavaBeans naming convention—must be included as an operation in the diagram. The operation must be written with these elements, in the order shown:

1. An access-level/visibility prefix;

2. The operation (method) name;

3. An opening (left) parenthesis;

4. Any parameters, listed in order and separated by commas (each parameter should be written as the parameter name, followed by a colon, then the parameter type);

5. A closing (right) parenthesis;

6. A colon character (omit for a constructor operation);

7. The return type (omit the type for a constructor operation).

For example, if the Puzzle class will have a method declared as protected void scramble(boolean extreme), it would be included in the diagram as

# scramble(extreme: boolean): void

Constructor operations

Any non-private constructor (not including the default constructor generated by the compiler when no other constructor is declared) must be included as an operation in the diagram, and must be written with these elements, in the order shown:

1. An access-level/visibility prefix;

2. The constructor name (which is also the class name);

3. An opening (left) parenthesis;

4. Any parameters, listed in order and separated by commas (each parameter should be written as the parameter name, followed by a colon, then the parameter type);

5. A closing (right) parenthesis.

For example, if the Puzzle class has (or will have) a constructor declared as public Puzzle(int numPieces, int difficulty), it would be included in the diagram as

+ Puzzle(numPieces: int, difficulty: int)

Relationships

Please use “What are the six types of relationships in UML class diagrams?” as a guide for completing the requirements below.

• The diagram must include all composition, aggregation, inheritance, association, and dependency relationships that exist between the classes in your domain model.

• Relationships to classes or interfaces in the Java standard library, Android framework, etc. need not be included.

• All relationship lines must include text annotations, providing additional information about the nature of the relationship; these annotations should be used to “tell the story” about how the classes are related to each other. When this text is very abbreviated, using directional arrows or other indicators can make the story more clear.

• Multiplicity/cardinality indicators are optional, but recommended.

Example

Expanding on the shorter examples from the previous sections, consider a jigsaw puzzle application, in which the domain model classes are Puzzle, Piece, and PieceType.

• Every Piece has a PieceType; that type is in inherent attribute of a piece (i.e. a part of the whole), but those PieceType instances exist outside of their relationship to Piece. Thus, this is probably best described as an aggregation relationship.

• Every Puzzle has multiple Piece instances, and the latter have no meaning outside of the context of the Puzzle; this is a composition relationship.

Our UML class diagram could look like this:

Cloud- or device-based services or data: 4 points

Your overview page should include a bullet list of device- or cloud-based services, or data sources, that your application will use. This is expected to be significantly more detailed than in your proposal.

For each one, include the following information:

• Service/source name;
• URL of service overview or API reference page (if cloud-based);
• URL of Android documentation for the device service (if device-based);
• How the service/data source will be used by your app;
• Will your app be able to function without full-time access to this service/data source?