Reference no: EM131220331

Project: Add Time and Object Interaction to the Simulation

Addendums

Addendums to the project will be posted at: https://www.cs.uoregon.edu/Classes/16S/cis211/Projects/P4/P4.html
This specification is very detailed, and will very likely require corrections and clarifications. The sooner that you notify the teaching staff of potential issues with the specification, the sooner any issues can be addressed. Please check for new addendums frequently, such as whenever you resume work on your project.

Purpose
- Bring the simulation to life with simulated time and object interaction.
- Illustrates the alternative flow of control for errors provided by try/catch in place of returned error codes.
- Demonstrates the benefits of well-designed data abstraction and modularity in that most methods and functions need no modification or consideration at all, but continue to do their jobs flawlessly and abstractly.
- Demonstrates, through a final installment, how to iteratively develop a solid 500 loc (lines of code)

Overview of New System Behavior

The simulation now includes the passing of time.

Simulated time advances in jumps, with time "frozen" while the user enters commands, and then jumping ahead one minute every time the user issues a "go" command, which simulates the passing of one minute of time.

Each of the two command interpreter prompts are now preceded by "Time x " in which x is an integer representing the elapsed time, in minutes. For example: "Time 0 FILE>" or "Time 5 >" Time starts at 0 minutes for every run of the simulation

Humans and Robots move one grid unit per minute.

Travelers can now receive a series of destinations. Each destination must be a Waypoint or an x,y location on the grid. Each traveler that is currently moving moves one grid unit towards the next destination every minute. Consecutive destinations must be in the same row, or the same column, but not both, and is discussed in more detail later in the project description.
Robots fight Fires.

Robots can be moved to fire locations, and can extinguish the fires. All fires start with a strength of "5". The strength of a fire decreases at a rate of one unit per minute for every robot that is currently extinguishing it.

State Machines of Behavior

The status and behavior of Humans, Robots, and Fires can be characterized by state machines, as in Figure 1.

Humans are either moving or stopped. Robots are extinguishing; moving; or standing-by (stopped and not extinguishing). Fires are either burning or extinguished. Each object's state is indicated by its member variables. When a Traveler (Human or Robot) is moving, _moving is True and _destination_list has at least one location in it. When a Traveler is not moving, _moving is False and _destination_list is empty. When a Robot is extinguishing, _extinguishing_fire points to the Fire object that is being extinguished. When a Robot is not extinguishing, _extinguishing_fire points to None. A Fire's state is determined by its

_strength. If a Fire's _strength is greater than 0, it is burning. If it is 0, it is extinguished, and deleted from the simulation.

Transitions between states result from user commands, or operations finishing after time has passed. A "move" command will start a Traveler moving. A Traveler will stop when it reaches its destination or the user issues a "stop" command. A Human will stop just before entering a location with a Fire. A Robot will stop if a user issues a valid "attack" command. Every Fire is initially burning, and becomes extinguished after attacked by one or more robots.

Every time a user enters a command, the system should attempt to execute that command and, if it can be executed, should leave the simulation in whatever state would be appropriate if it had been executed.

Software Design Specification
Expand the modules as follows.

P4_Model.py
Model class

Member variables

Add a pseudo-private member variable that maintains an integer representation of the current simulated time. Initialize to 0.
Member functions
get_time( ) - A "getter" for the time variable. Returns an int.

update( ) - Update all simulation objects in the order in which they were created. Advance time by a minute. get_fire( name ) - Same as get_human( ) and get_robot( ) but for Fire objects.

fire_at_location( location ) - Returns a Fire object at that location if one exists. Otherwise returns None. delete_fire( name ) - Delete from the Model and the View a fire with the passed-in name.

Traveler class
Member variables
_destination_list - a list of locations discussed below in move_to( ).
_moving - Boolean. Indicates whether the traveler is currently moving. The traveler's "moving status".
Member functions
journey_to(destination_list) - This method should do the following:

1. Take a "destination_list" list as input. Go through each item in the destination_list from left to right. For each item, first make sure that it is a valid location in the world, and then make sure that this traveler can move from its current location (for the first location in destination_list) or from the previous location in destination_list (for all subsequent locations in destination_list) directly to this new location with a horizontal or vertical movement.

2. Set the pseudo-private member variable _destination_list to the contents of the input destination_list. Set the traveler's _moving to True. Call the traveler's update( ) method.

Implement error checking on the destination_list argument as follows: For the first item in destination_list that is either an invalid location or would require a diagonal movement to move directly to, throw a user-defined exception that outputs the following message: "Error: ‘<location>' is not an valid location for this ‘move'.", in which <location> is the first problem location in destination_list exactly as the user typed it, or the empty string if there is no destination_list.

get_next_moving_location( ) - If the traveler is currently moving, this function returns the location (as a tuple of two integers) that the traveler would move to if it were to move one grid unit closer to the next location in its destination list.

move_to(location) - This method should work as in Project 3 but with the following modifications: If moving to the specified location puts the traveler at the next location in _destination_list, remove that location from the list. If the list is then empty, change the traveler's moving status to False and output to the console "Human Ming arrived at location (5, 6)" (replacing "Human", "Ming", and the location with appropriate values). Do not output to the console any information other than when the traveler arrives at the final destination in the list.

Human class

Member functions

update( ) - If the object's moving status is True, use superclass and Model methods to determine if the human is about to step into a location with a fire. If not, move the human to that location using a superclass method. If yes, change the human's status to stopped and output the following message to the console: "<human> stopping short of fire <fire>." in which <human> is the name of the human and
<fire> is the name of the fire.

Robot class
Member variables
_extinguishing_fire - Points either to None or to a fire object that the robot is currently extinguishing.
Member functions
fight_fire( fire_object) - Set up the robot to extinguish the fire_object.
update( ) - If the robot is moving, move the robot one grid unit. If it is extinguishing a fire, reduce that fire object's "fire strength" by one unit.
journey_to( destination_list ) - Same as Traveler. journey_to( ).

Fire class
Member variables
_strength - an integer from 0 to 5 indicating the current strength of the fire. Always initialize to 5. When it reaches 0, the fire is extinguished and the Fire object needs to be deleted from the simulation.

Member functions

del ( ) - Outputs to the console "Fire <name> has disappeared from the simulation." <name> is the fire name.
get_strength( ) - Returns the value of _strength.

reduce_strength( ) - Decrement _strength by 1. If _strength reaches 0, remove fire from the simulation, both from the model and the view.
update( ) - Does nothing.

P4_View.py
View class
Member functions
update_object(name, location) - Update the method so that the object is removed from the view if location is None.

P4_Controller.py
Controller class
Member functions
run( ) - Will need updated for new commands. do_human_robot_command( ) - Will need updated for new commands.

P4_Utility.py

P4_Utility.py defines the following two user-defined exceptions as was shown in lecture. All three other modules should import these two classes such that the classes can be accessed without the "dot" notation (as BadLineError rather than as P4_Utility.BadLineError )
BadLineError class - This exception is thrown any time that an error occurs such that the entire command line needs to be output along with the error statement, such as in the following exchange: Time 0 > garbage in Unrecognized command: garbage in BadMsgError class - This exception is thrown any time that a message needs to get passed to the exception- handling code, which is done as was shown in lecture.

End-User Functionality
Add and Modify End-User Commands and Functionality
Implement and modfiy these commands as described.

go
Update all the simulation objects. Advance time by one minute.

<traveler> move <series of locations>
Move the traveler (human or robot) named <traveler> to each location in the series. Each location in the series is either a single letter indicating a Waypoint, or an integer-comma-integer sequence with no intervening spaces. For example: "t2 move a 5,6 b" would attempt to move a traveler named T2 to waypoint A, and then location (5, 6), and then waypoint B. Before moving the traveler, verify that (a) each location is valid, and (b) the traveler can move directly to each location, in order, with only horizontal or vertical movements. For example "t2 move 1,1 5,5" would be illegal, but "t2 move 1,1 1,5 5,5" would be permitted.

Implement error checking as follows: First, if there is no human or robot named <name>, output "Unrecognized command: " followed by the line that was input. Second, if (a) and (b) above are not satisfied, process the error as specified in the P4_Model.journey_to( ) description elsewhere in this document.

<traveler> stop
Stop the traveler (human or robot) named <traveler> at its current location and issue a command such as "Human Ming stopped at location (5, 6)" (replacing "Human", "Ming", and the location with appropriate values).

<robot> attack <fire>
If a robot of name <robot> is in the same location as a fire of name <fire>, then the robot should change its status from moving to extinguishing the fire.

Coding Specifications

All user input error messages should now be handled with try/except.

Your solution should have two sets of try/except statements, one in P4_Model.run(), and one in P4_Model.open_input_file(). The first set should have two except statements, one for each of the two user-defined exceptions. All error messages should be printed to the console in the code within the except statements associated with these two sets of try/except. Error messages should not be printed anywhere else in your submission. No method should use a return value specifically for error-checking. For example, P4_model.create_sim_object( ) should no longer return anything, and the calling of this function should no longer check for a return value. The only print statements left in P4_Model.py should be to report the results of correctly-working commands. Your project should have exactly two try / except blocks, one in P4_Model.run() and one in P4_Model.open_input_file(). Handle all file-related error processing within P4_Controller.open_input_file( ). Do not send the error up to the try/except block in the command loop.

You may create private "helper" methods.

Feel free, if you like, to create additional private methods that are used by the required public functions if you think these helper functions would help you to organize your code better. Each must have a docstring that explain the arguments (including the types) that are expected, what member variables will be manipulated, and what gets returned. All must be private, preceded by the two underscores.

Additional specifications

- Feel free to use global constants but not global variables.

- Store member variables that are strings in lowercase; capitalize the first letter of each name when displayed.

- The interpreter ignores whether commands, names, and arguments are in uppercase versus lowercase except to output the line exactly as it was entered if the initial word in the line could not be processed.

- Do not add any import statements or public member functions beyond those specified. You may create additional private member variables and methods.

- Do not use the "@property" decorator (and don't worry if you don't know what it is).