CS383 HW#3

Due: Friday 2/19/16 10:00pm

You are to work in the following teams:

1 Knight Writers 3 4

song6803 purk2552 helb4651 sass8427 alsh5301 fran6139 harr5275 camp7325

slip5295 gwade guan ocke8865 juts3869 denn2725 benz5834 ferg2065

jank6275 mora5651 boss2849 bolt1003 gall7417 brec9824 snev7821 mars2681

cart1189 wel2150 carl7595 dani2918 wern0096 ratc8795 doum6708 gent7104

As a team, choose a name and let the instructor know.

Requirements Doc

Starting from Dr. J's Requirements Doc, and any useful work from prior teams' assignments the past weeks, BY TUESDAY 2/9 10PM, build a document that lists your proposed requirements:

it should be a LaTeX doc that will be a section in our overall semester project doc.
it should have two sections, functional and non-functional
team vote on each Dr. J requirement, and if the majority wants to reject/replace that requirement, write me a brief explanation.
add any functional or nonfunctional requirements that you think should be agreed on up front

Turnin via Blackboard. Plan to discuss in class Wednesday 2/10.

Backlog Starting Point

Starting from Monday's Backlog, develop your team's backlog for this sprint, prioritize which are the items that need attention first, and break those into pieces that can be assigned to individuals or small groups.

Github Group

Now, finally, each team needs a Github group. You should add Dr. J as a team member, although I will basically not commit anything since I will not want to mess you up. If you have an existing one that you can use for the new team, fine; otherwise, elect a Github boss, who should create one and work with team members to get them all into it.

Coalescing our Use Cases

The newly formed teams need to agree on a common set of use cases. You can start from the use cases from the former teams' past assignments, select whichever you think is the best starting point, and then add revise whatever best ideas from the other two teams. Review your functional and non-functional requirements to see if any of them suggest additional use cases that are needed.

Class Diagrams

For this sprint, as one of your team's sprint commitments, the team should develop a set of class diagrams for your project. Focus on the application domain, not auxiliary classes that are likely to be used in the implementation (e.g. GUI class libraries). Teams should divide the labor up so that each person on the team is given one or more UML class diagrams that describe details about a portion of the project.

A "detail" subteam (1-3 persons) should be assigned to each major subsystem. The number of subteams is up to your team, but remember to include:

code editing
translation/execution/debugging
chat/codeshare/common view
awareness/invitation/finding others online

The "detail" subteams should show as much detail about their assigned classes' associations, attributes, and methods as is known at this time. Edits of all kinds can be made later on.

Every UML diagram should have 1+ author name(s) in a small font, and be accompanied by a supporting "diagram dictionary": a section of prose text that defines the classes and user-defined associations, and clarifies any ambiguities or tricky sections of the diagram. All UML diagrams should be reviewed for completeness and accuracy by at least one other team member; add "reviewed by XXX" in a small font after the author name(s) in the diagram. Be "egoless" and take criticism seriously, fixing or adding things can help your grade. Within your team, check to make the diagrams mutually consistent and stylistically consonant. Adopt standards for fonts and such within your team.

Each team should assign one additional "overview" subteam to draw one or more higher-level overview class diagrams showing the aggregated big picture, with more classes and associations showing but class class detail. This could be one giant diagram, or separate diagrams for inheritance, aggregation, and user-defined associations, or provide an overview along some other structured lines.

Use PlantUML as your diagram "editor". Use "hide circle" to avoid its irritating circles, e.g.

@startuml
hide circle
class foo
@enduml

Diagram Assembly Document

Add your plantUML files and generated .png's to a doc/ directory in your team's repository, then put them all together in an assembly document (in LaTeX) for group turnin. Note that for this homework we are talking about turning in class diagrams assembled together, but do not lose or otherwise misplace your use cases and use case diagrams, we will be turning in a big combined document in future.

The finished turnin, via Blackboard, should consist of an assembly document (PDF), and a .zip containing LaTeX, image files, and plantUML files for each diagram.

Backlog Items

Everyone should:

Get a Java compiler installed and learn Java, enough to do a main menu with at least: a background graphic, a "New Game", "Load Game", "Save Game", "Options", "About", and "Exit". There is no turnin item for this assignment item.

Sprint Report

Per class lecture notes, each team should plan to spend 5 minutes reporting orally in class each Sprint on their team's progress as part of the turnin in two weeks.