From MWCSWiki

---

Welcome to Team FacePalm

Heard a bad joke? Know Adam Peck? Then you have probably have placed the palm of your hand to your forehead with force enough to make a slapping noise.

Members

Renee Carignan

Diane Ditko

Jesse Hatfield

Dylan Yaga

Group Meeting Time

Mondays and Wednesdays @ 3pm in Trinkel basement

Staffing Decisions

<center> <table border=1> <tr><th></th><th>Domain</th><th>Persistence</th><th>Delivery</th><th>Presentation</th></tr> <tr> <td><s>Phase 1 - Requirements</s></td>

   <td>Renee</td>
   <td>Jesse</td>
   <td>Dylan</td>
   <td>Diane</td>

</tr> <tr> <td><s>Phase 2 - Design</s></td>

   <td>Diane</td>
   <td>Renee</td>
   <td>Jesse</td>
   <td>Dylan</td></tr>

<tr> <td>Phase 3 - Implementation</td>

   <td>Dylan</td>
   <td>Diane</td>
   <td>Renee</td>
   <td>Jesse</td>

</tr> <tr> <td>Phase 4 - Testing</td>

   <td>Jesse</td>
   <td>Dylan</td>
   <td>Diane</td>
   <td>Renee</td>

</tr>

</table> </center>

Current Work

BOLD = DONE

Candidate classes for each subsystem should be posted on the Wiki by Friday, September 28, at 5 PM.

Stage 1: Sanity check. Your entire team should schedule a time to come meet with Stephen for 45-60 minutes. Just send me an e-mail to suggest this time. You should come to this meeting armed with:

1. The names of all the probable classes you've identified for each of the subsystems.
2. A 1-2 sentence description of what each one represents.

Stage 2: Design deliverables. You should prepare the following design artifacts during the course of your work:

1. A package diagram showing the full names of all the packages you have defined, and the dependencies between them. You should also indicate which subsystems contain which packages, using <<subsystem>> package stereotypes and aggregation arrows.
2. <s>A deployment diagram showing the architecture of the system and which components reside on which system nodes.</s>
3. A set of class diagrams that depict your design classes and the static relationships between them. You should specify all attributes and methods, including their method signatures, and the visibility of each. There is no hard-and-fast rule about how many diagrams you must provide, or how many classes must appear on each diagram. The only rule is that each class in your design must appear on at least one diagram. Some common approaches include: (a) one class diagram per package, (b) one class diagram per subsystem, (c) one class diagram for each coherent chunk of functionality, which may involve classes that cross package and subsystem boundaries. The bottom line is: anything important you decide about classes and their relationships during phase 2 should not go left unsaid, but should be present on some diagram so that it properly communicates the information to the next (implementation) phase.
4. A set of sequence diagrams showing important message exchanges (execution paths) through the design. Each one should represent some scenario that demonstrates how the classes will collaborate to achieve that scenario's functionality. There's no hard-and-fast rule about how many sequence diagrams you should have, but it is common to include one per use case.
5. HTML documentation, produced using the standard javadoc tool from the JSDK, for the entire public API of each subsystem. This will require you to create stubbed-out .java files for each of the public classes in your subsystems so you can run javadoc on them. You should also create a simple package.html file for each package containing a brief description of its purpose, so that it will be picked up by javadoc and included in the output. The result of doing all this will be a set of web pages (.html) that you can deploy in your Tomcat directory so that your entire team (and I) can browse it online.

Completed Work

To complete milestone #1, you should turn in the following deliverables via hardcopy:

1. A system-wide use case diagram, depicting all system actors, the use cases that each one can execute, and the system boundary.
2. A brief (half page) document listing all of the actors and giving a one or two sentence description of each.
3. Use case descriptions for each use case that appears in the diagram, including sunny day and any relevant rainy day scenarios. Use case descriptions should be separated from each other by a heavy black horizontal line. (Or, you can start each description on a new page.)
4. For each of the four subsystems:
   1. A subsystem use case diagram, depicting the actors that make use of it, the use cases that each one can execute, and the subsystem boundary. Note that some of the actors in these diagrams will invariably be other subsystems. You may draw these as "blockheads" if you wish.
   2. Use case descriptions for each use case that appears in the subsystem diagram, including sunny day and any relevant rainy day scenarios. Use case descriptions should be separated from each other by a heavy black horizontal line. (Or, you can start each description on a new page.)
5. A brief (probably not more than a page) document delineating any non-functional requirements that complement these use cases. You may wish to indicate goals for performance, disk space, portability, security, reliability ("up time"), extensibility, etc.
6. A declaration of your staffing decisions for the remainder of the project. This simply entails assigning one team member to each subsystem for each phase of the project. You may do this as you wish, with the following constraint: no team member can be on the same subsystem twice. For this part, just turn in a chart that looks something like this: