Informal Science Education 2

Concept of Operations

EEL5881 - Software Engineering, Fall 2000

Modification History

VersionDateWhoComment
Version 0.0 August 15, 2000 G. H. Walton Template
Version 1.0October 5, 2000 Michael WalesInitial complete document
Version 2.0December 10, 2000Michael Wales Final version of document to reflect changes in program

Team Name: Informal Science Education 2

Team Members:


Contents of this Document

The Current System

The Proposed System


The Current System

Currently there is no existing system that UCF has developed. There are some online tools that are available for use. Most systems are not user friendly and don't have some of the key features we are looking to develop. Changing the transition rules typically is a matter of changing the source code of the simulator. Most tools typically don't have the ability to save the state of the simulation and fast playback modes either.

The Proposed System: Needs

Dr. Moshell requires a tool to run Cellular Automata simulations on. The tools that are available don't have currently have the ability to run many types of different simulations. The new tool would be reconfigurable in many different ways to aid researchers. The new tool would be a user friendly interface that could be used by biologists. The user should be able to change the environment and physics setting for the simulation.

The system that we design will have a Grahical User Interface (GUI) that will allow the user to easily set up the initial conditions for the simulation. The user can simply can change the initial states of the cells by moving the mouse cursor over the cell and clicking. The interface will also allow the user to drag out a large rectangle to change the states for multiple cells at one time. The user will then be able to save this initial state for future reuse in other simulations.

Our system will also have a menu system that allows the user to change the transition conditions for the system. The state will be selected from a menu, and then a check list (and corresponding parameters for each transition condition) will be shown for modification. For example, to create a simple life game, the user could do the following. 1. The user can create a cell condition called 'living'. 2. The user can modify the 'living' cell's transition properties to state that the cell will transition to 'living' if 3 neighboring cells are living. 3. The user can then create a 'dead' cell condition with it's corresponding properties. These properties will be stored in a file so the user doesn't have to constantly set up new transition properties when a different type of simulation is needed.

The transitions types possible will include transitioning for: how many neighbors a cell has, symmetrical conditions, distance from other cells, and a choice of three algorithms that can be coded directly into the Java source code. There will be documentation to aid future users who wish to change one of those algorithms.

The Proposed System: Users and Modes of Operation

The Proposed System: Operational Scenarios

The Proposed System: Operational Features

Must Have:

  1. Built-in transitions with paramaters can be modified.
  2. Code that can be modified to import complex algorithms into the simulation. These programmable algorithms will have paramaters that can be easily modified thru the regular user interface.
  3. An editing tool that will allow the user to easily set up the initial conditions of the simulation. The initial conditions should be able to be saved and loaded from files for future use.

Would Like to Have:

The Proposed System: Expected Impacts

We expect the system will aid UCF reasearchers in finding new ways to model biological simulations. The new tool has will have the ability to let a user with some Java programming knowledge edit the code to create very advanced algorithms. This tool will aid researchers by being a friendly interface with some powerful inner workings.

We also expect the system could have an impact at the way Cellular Automata theories can be taught. Students can be shown working examples in motion. Instead of instructors relying on their own code or drawings on a blackboard. The simulation can be controlled to let the user change the environment easily and quickly.

The Proposed System: Analysis

The proposed system will be a Java application capable on running a many different platforms. The editor tool will allow the user to set up many different sets of initial conditions of the environment (and allow the user to save them for later use). The simulator will allow the user to change the transition requirements for different simulations. The simulator will also have modes that will allow it to run a simulation and save some of the intermediate states for later viewing after the simulation has run through.

Expected Improvements:

  1. User friendly editor and simulator.
  2. Editor tool that has great functionality and is easy to use.
  3. Simulator that can have the transitions properties changed.
  4. Simulator that can have programmable transitions.
  5. Simulator can be run in Windows, MacOS, UNIX, Linux, Solaris, and any other environment that the Java Runtime Environment (JRE) exists on.
  6. States and transitions can be saved to disk to avoid trying to copy down or remember a set of transition rules

Disadvantages:

  1. Tool cannot be run on a PC that doesn't have Windows 95 or later with a JRE. A system typically has to be a Intel 486 of better to support Windows 95.
  2. Using an interpreted language like Java will cause some slightly lower performance than code compiled into native machine code. We hope that this disadvantage does not turn out to be significant.

Limitations:

  1. We are going to limit the number of possible transition types to 5. With the ability to create custom algorithms this shouldn't be a very significant problem.
  2. There could be unforseen limitations in the way the transitions take place if we don't forsee including the proper parameters into the simulation.

Risks:

  1. Time: As undergraduate students in our final year, our course load is significant enough to demand excellent use of our time on the project. We will need to keep very strict timelines to avoid getting behind on our project.
  2. Dr. Moshell might have more needs that will have to be accounted for before the project is finished. We will have to address any concerns, and hopefully we can find solutions to all of them.
  3. We have alot of risks associated with the GUI and graphics. We are not extremely experienced Java programers and we will be learning alot of new things as we design the program. We have to make sure that the GUI works 100% and don't let it take up all of our time.

Alternatives and Tradeoffs:


Template created by G. Walton (GWalton@mail.ucf.edu) on August 30, 1999 and last modified on August 15, 2000.

This page last modified by Michael Wales (Mag7Rule@aol.com) on December 10, 2000.