Exception-handling strategy

The AppModel and EventResponder are gateways to the user interface and user. Therefore, any user-entered data passed down from EventResponder or AppModel will be checked for exceptions. Each aspect in the AppModel or EventResponder dialogs will have certain parameters that are checked by ExceptionManager such as not being able to have a character for a number. Only then, are they passed to Domain or Application-level objects.

Any aspect that fails will re-prompt the user for a more appropriate value and the process for checking the exception and either allowing entering the domain or prompting the user for a more correct value will cycle.

Inside our security boundary which is our domain or application level, the strategy will be that if an exception occurs, it is likely an unknown error and will be logged and the game will shut down while notifying the user of such.

M5 33k! TA: David

New Scenarios

Scenario 1:

The user calls for a new game through the User Interface. She sees a screen asking if she wants to load, save or play a new map. She selects new map. She then sees another screen that prompts her for her profession and the names of 5 members of her party. Then she sees another screen prompting her to buy some items such as oxen, food, clothes, parts, etc, and is presented with quantity options and monetary values. At the top of the screen she sees that she has $1600 and that she’s a banker. She selects her quantities of items and hits accept.

Scenario 2:

The user is looking at the main game screen with some status, information, terrain, and the wagon on the terrain and there are four buttons: hunt, rest, move, and trade. The user sees that the rations have been depleted and the day has passed on the status information. The status also shows that the wagon has traversed 10 more miles.

passengerEat	Obligations	Benefits
Client: Wagon	(precondition) Food is available. (postcondition) Food value goes down.	Party is fed.
Service provider: Person	(precondition) Person is not dead. (postcondition) Health is adjusted.	Lifespan is determined by whether or not Person eats i.e. health is improved.

addPerson	Obligations	Benefits
Client: Wagon	(precondition) There must be room for a Person. Person must exist. (postcondition) Collection of people in Wagon is increased by 1.	Wagon has the Person.
Service provider: Person	(precondition) (postcondition) Person is now in the Wagon i.e. Wagon now has a Person.	Wagon has the Person.

processMile	Obligations	Benefits
Client: EventManager	(precondition) An initialized Wagon must be passed in. An initialized Map must be passed in. (postcondition) Wagon’s properties may or may not be changed.	Allows Map and Random Events to interact with the Wagon.
Service provider: Game	(precondition) EventManager has static methods. (postcondition) EventManager returns the changed Wagon.	Game processes the Wagon movements through the EventManager.

moveAMile	Obligations	Benefits
Client: Wagon	(precondition) Wagon is on a valid spot for moving on the Map. (postcondition) Wagon’s current mile has changed.	Allows Wagon to move across the Map.
Service provider: Game	(precondition) Wagon must exist. (postcondition)	Allows the user to move the Wagon.

addItem	Obligation	Benefits
Wagon	Precondition: The item has to exist in the	The wagon now has a new item.
	game world. The item can’t exceed the weight-holding capacity of the wagon.
	Postcondition:
	The collection of items in
	wagon is increased by the number of items purchased.
item	Precondition: None.	The wagon has the item.
	Postcondition:
	The wagon has the item.