Group Two Architectural Design Review Package

Group Members: Jesse Watts-Russell, Phil Davis, Nick Carter, and Andrew Michaud

Table Of Contents

• Introduction to our groups project.
• Planned agenda for project review.
• Suggestions for how our reviewers should split up the work.
• Roadmap to the various architectural design documents.
• Our own critiques of our own architecture.
• How to get more information from us.

Introduction

We are the Group Two FSM team and for our project we are creating a Treasure Island Game, where the Islands are the states, and getting to the final island represents winning, while anything otherwise respresents losing. If you havn't already seen, here is our final proposal.

Adjenda for the Review

• Again go over the high-level concepts of our FSM game.
• Discuss the different design decisions we have made.
• Delve into the architecture we have designed.
• Introduce our detailed, albeit messy and confusing, sequence diagram.
• Initially discuss the different high-level views, models, and controllers in our MVC.
• Start to discuss the key methods implemented by our views, models, and controllers.

Reviewing Split of our Initial Architecture

• One reviewer should review our user stories and our domain diagram.
• One reviewer should review our domain and class diagrams.
• One reviewer should review our algorithms description and sequence diagram.
• One reviewer should review our team critique and our rationale for our choices.

We feel this is an even division of work among the reviewing team, and that it gives each member of the reviewing team insight into a different aspect of our architecture. We hope this will lead to a better understanding and a more informed review of our architecture.

Roadmap to Architectural Design Documents

• Alpha User Stories and Use Cases

  The use cases and user stories we plan to have for our Alpha phase are as follows:

  1. On open,the user will see a screen with states and no transitions. The user may then draw transitions.
  2. The initial view has a start state and at least 1 accepting state.
  3. The user can view an input language or string for which they are designing this machine.
  4. The user can check whether their solution is correct or not.
  5. The user should be able to easily differentiate initial and final states from other states.
  6. The user and game should easily be able to identify states and transitions.
  7. Transitions should be able to go to any islands, including looping back to the same island.
• Domain Diagram
• Class Diagrams
• Description of important models/algorithms/data structures for our game
• Sequence Diagram

Self Critique of our Architecture

• Team critique of design
• Rationale For Choices

Where/how to access additional information

1. First off, come to us, we probably know our project better than anyone or anything else (including our documentation, which is probably a bad thing).
2. Our GitHub wiki is pretty darn detailed with notes from every meeting, and all our diagrams and stuff... the only bad thing is we havn't figured out how to give other people access to it.
3. We'll be aiming to make our wiki more hyper-linked instead of solely on the github page.