Goals:
-In a nutshell, we basically want to start defining and implementing our game
from an application design standpoint. Thus, we created various diagrams and
charts to convey the specific nature of the relationships amongst our Oregon
Trail's classes, etc.
How We Accomplished Those Goals:
-The 2 most important aspects of this milestone was the creation of our UML and
sequence diagrams. The UML class diagram is shown below. It demonstrates the
fields of our classes and what methods they have. If a class has a triangle
arrow pointing to it, that means it is a superclass of that class. If a class
has a diamond arrow pointing to it, that means it "contains" or "has"
the class that is connected to it. Note the design pattern and structure of our
game. Everything is ultimately centered around the GameManager, which controls
everything. The Wagon and Date class are ultimately used as Singletons, and the
EventManager class serves as a factory for Random or Location events.
-Here is a link to our Sequence Diagram. It demonstrates the flow of our game's classes by testing it with a hypothetical scenario. It helps to refer to the UML diagram when trying to understand the sequence diagram, because the sequence diagram cannot call a method that is not already defined in the UML charts.
-Another important goal that we accomplished was the creation of our
"Architecture/Trust Boundaries" chart. As the note states, "Collaborations between the Game Manager
and the Event Manager, Date, and Wagon are designed [to be] trusted. Collaborations between
the Event Manager and different Event types were designed to be trusted." Also,
regarding untrusted collaborations, remember that "If a collaborator can’t be trusted, it doesn’t mean it is inherently more unreliable.
It may require extra precautions:
–Pass along a copy of data instead of sharing it
–Check on conditions after the request completes
–Employ alternate strategies when a request fails
–Check for timeliness, relevance and correctly formed data.
–Make objects read-only to prevent modification"
(Responsibility.ppt, slide 45)
Our chart is below. It was designed by Michael Slaughter, the powerful yet
humble President of team Menfinity:
-In regards to Exception and Error Handling, we stated that "In general, the only user created errors that can occur are at shops and the beginning of the game. Most exceptions will originate from the respective information holder, and that exception will peculate up the design hierarchy to the Game Manager where a specialized error message will be presented to the user. In the case of a user caused error. The message will float back to the top where the error will be nicely presented to the user, and they will be asked to re-input the erroneous field."
-Here is a screen mock-up prototype made by Terris a.k.a. Yaku, a member of Team Menfinity:
Advice:
-Do the UML diagram before you do the sequence diagram. If you need to update
your CRC cards, you can probably do so while constructing the UML class diagram.
-Consider Downloading Visual Paradigm in order to help with the construction of
your UML and sequence diagrams. That's what we used for ours.
-If you have access to it, use the Responsibility.ppt slides. They will help
you! Menfinity-- We. Are. Forever. Men.
