Download
1 / 12
120 likes | 217 Views
Software Design Model. Jurassic Park Simulation System (JPSS). Submitted by Arlan Sands – Team Lead Corey Cowart Nick Salaka Brandon Gilzean Daniela Zicavo COP 4331 and EEL4884. May 4, 2010 Spring 2010. JPSS Virtual World.
E N D
SoftwareDesign Model Jurassic Park Simulation System(JPSS) Submitted byArlan Sands – Team LeadCorey CowartNick SalakaBrandon GilzeanDaniela ZicavoCOP 4331 and EEL4884 May 4, 2010Spring 2010
JPSS Virtual World A typical Jurassic Park scenario begins when a dinosaur begins to wander until it becomes hungry. The dinosaur, depending on what species it is, will either wonder for another dinosaur for food or plant for food. The dinosaur will lay an egg when both its hunger and health level are satisfied. This cycle will continue until either all the dinosaurs die due to starvation or until a state of stability has been reached, thus causing a meteor to hit. The numbered boxes on the diagram indicate the relative sequence in which actions and events occur. Of course, the activities of the dinosaur, egg and plant become concurrent in a steady-state operation of the Jurassic Park system.
Motivations In 1994 Ingen Corporation developed a process to clone and recreate living dinosaurs. The primary intention of doing so (besides scientific research) was to create a theme park in which tourists could view, interact, and study creatures that had never before been viewed by man. However, since humans have never been able to study the way that dinosaurs interact with each other due to their extinction, they ran into a few problems in creating a correct distribution of dinosaur types and holding areas. They found that certain combinations of species would create an imbalance in a particular holding area; for example: If too few carnivores are introduced into a holding area with too many herbivores, two problems are created. First, if there are enough herbivores close together when a carnivore attacks, they will help each other fight the attacker, in which case the carnivores will eventually die of starvation since they cannot effectively kill a single herbivore to eat out of a large group. After which, with no predators, the herbivores will begin to overpopulate and eventually eat all of the vegetation, eventually causing them to also die of starvation.
Simulator Description (Design Model) • AppError and IOMgmt. These packages are independent of the virtual world being reproduced. Both packages are implemented as C++ namespaces and are represented in the code by a C++ header (.h) file and implementation (.cpp) file bearing the name of the namespace.
Simulator Description cont’d • IOMgmt: This package provides several classes for managing file streams. The two primary classes used by the simulator are InMgr and OutMgr. In addition, two exception classes are provided. Class IOError is used exclusively by classes in IOMgmt for throwing exceptions when errors occur while attempting to perform stream operations. Class TokenError is provided to application clients of InMgr when trying to parse data from some input stream. TokenError is thrown by all Extract() and Get() methods of classes in GroundTruth that must read instances from the input file stream when the virtual world is being constructed.
Simulator Description cont’d • Agent Layer: This layer consists of all active object classes or agents. Active objects must be instances of some subclass of abstract class Agent. The simulation progresses as a result of events created and serviced by agents. All simulation time must be accounted for in the time delays associated with sending messages from one agent to another. In other words, agents control the progress of the simulation and can only communicate with each other by sending messages through events. There is one exception to this statement – a direct call must be made from a sending agent to a public message constructor provided by the receiving agent. These calls are necessary as part of message passing mechanism and have no meaning in the virtual world.
Simulator Description cont’d • Passive Layer: The passive layer contains all classes that model problem data and inanimate objects of the simulated world. Agents make direct calls on passive objects, but must account for the simulation time consumed when doing so. Passive objects may make direct calls to each other, if necessary. Passive objects may be passed from one agent to another as part of a instance of some message.
Lessons Learned • We learned to efficiently manage our time and make the most of it. We learned to work as a group. Each member was able to work on the required assignments so we could get the desired results for the final project. We will apply on future tasks what we have learned regarding project documentation and design. We hope to use the information gained on this project to maximize future successes and reduce future failures.
