Module: Disaster Recovery Modeling
Parent Component: Object-oriented Java
Use Java to simulate a disaster recovery simulation complete with a mission commander, DisasterSite object, and RescueTeam objects. In this module, we'll scour this code to understand how it works, find a few bugs, and then build our own objects to improve the simulation.arrow_downward
Jump to a section
local_diningModule "hamburger" guide
bookResources and reference documents
schoolModule Preparation Exercises
motorcycleExercise 1: Diagramming Classes
motorcycleExercise 2: Object oriented highlighting
motorcycleExercise 3: Enforce RescueTeam Size restriction
motorcycleExercise 4: Build out "Mission Status" action
buildMini Project: Mission Time Tracking
Module Hamburger Guide
Print off the hamburger guide for this module, review it carefully, and complete its sections as a culminating activity for this module.
Module Learning Objectives
Read (i.e. digest) Java code written using an object-oriented approach thoroughly enough to properly constrct a diagram of each class, including member variables and methods
Analyze program output to determine the likely nature of a bug. Locate this system bug, correct it, and test to ensure that the issue is fixed
Write an additional class for the missionControl package which calls methods and integrates with the other classes to simulate a disaster recovery situation
Module Core Concepts
We want to understand our missionControl package by studying this output:
Go to our component 3, module 3 code on github. Populate a project called missioncontrol and place in it a package called missioncontrol and then put our three class files in there.
Exercise 1: Diagram the Package's Classes
Exercise type: Digesting Code
Examine the classes in the package missioncontrol carefully. Create a class diagram using the following skeleton as a starting point. We want to know the names, member variables, and method contracts for each of the three classes in the missionControl package.
Exercise 2: Object-Oriented Code Highlighting
Exercise type: Code Parsing
Use this highlighting scheme to show the class-based relationships in our MissionControl and DisasterSite classes.
Object-oriented highlighting scheme (different from non-object scheme
Value assigned to a member variable
Method Declaration and body in a bracket [
Object creation with 'new' AND all pointer variables to these objects
Method calls and arguments [skip calls to println()]
Print off the code for MissionControl and DisasterSite for highlighting
If you have trouble viewing these PDF documents, try downloading them and opening them in the adobe reader directly. Otherwise, print off the code from netbeans or github
Clicking too early will turn your brain to...mush! Check with a neighbor and together check your work against the key, discussing any differences.
Exercise 3: Enforce RescueTeam size restriction
Exercise type: Adding code to existing classes
Our missioncontrol simulation is currently a skeleton. It shows the basic functions that we can carry out using three classes that interact through calling methods on one another.
Currently, when the commander assembles a RescueTeam by deciding what team size to dispatch. Note that the MissionControl class has a member constant called totalStaff. It is initialized to 10.
- Run the program as it was downloaded from GitHub. Note that we can create and send a RescueTeam that is larger than the total MissionControl staff of 10.
- Study the code and create a method for enforcing the rule that the Commander cannot send a RescueTeam of more than 10 people. If the commander attempts to do so, a note should be written to the log (not just println() noting that this "Request cannot be completed: not enough staff."
- This rule should be enforced in an appropriate place in MissionControl. For this exercise, if the commander tries to send a RescueTeam that is too big, the error should be printed and the Commander should be returned to the main menu and can try again.
- Now add a function that allows the mission commander to check the total number of staff in MissionControl. This could become an option number 4 in the menu, or it could be logged automatically when the command is prompted to choose a RescueTeam size. No key here, sorry.
Exercise 4: Build out Mission Status
Exercise type: Adding code to existing classes
The Commander Action menu current offers the commander an option #3: Check Mission Status. Note that it doesn't do anything. We want to fix this.
- Plan and create functionality such that when the Commander requests action #3, a true or false value is displayed based on the number of remaining victims. If 0 victims remain, the Commander should see that mission status complete is TRUE.
- Note that we can implement this functionality either in MissionControl with calls to getCurrentVictimCount() or in DisasterSite by creating a new method in which the DiasterSite itself checks the total number of remaining victims and returns true or false to the calling method.
- Now that you have a working method which can determine if the mission is complete, use it to prevent the commander from sending a RescueTeam on a mission that is already complete. If you completed the exercise about limiting RescueTeam size to the available staff, note that we can build this checking system into the flow-of-control statement you've already written so that we are checking both the team size and the mission status before dispatching another RescueTeam.
- You can use a chained or nested if-controlled block. You can also use the logical AND operator '&&', which will allow you to control the execution of an if-controlled by checking two separate true/false expressions.
Module mini-project: Mission Time Tracking
Exercise type: Mini-project
In rescue missions, time is of the essence. This mini-project guides you through creating a system for tracking how long the mission has been underway and provides statistics related to how much time is required to rescue each victim.
- Look up how to get the current system time in Java. You'll get a result in milliseconds which you'll need to convert to a value that makes sense for the program.
- When the mission starts, create a "time stamp" that is the beginning of the mission
- Each time the commander request action #3: check mission status, the current time the mission started is displayed, along with the total mission time, calculated when the Commander enters choice #3.
- Add a final element to the Check Mission Status option: print out the total time needed to rescue EACH victim. In other words, calculate a rescue statistic by dividing total time of the mission by the number of rescued victims. This will need to be a double value.