Modification History

Team Name: Informal Science Education 2

Team Members:

• Jeffrey Miller j_miller68@hotmail.com
  Jeff's Web Page
• Michael Wales Mag7Rule@aol.com
  Mike's Web Page

Contents of this Document

The Current System

The Proposed System

• Needs
• Users and Modes of Operation
• Operational Scenarios
• Operational Features
• Expected Impacts
• Analysis

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

• Biologist: A biologist can set up the initial conditions, and modify the simple transition conditions to create a variety of simulations to meet their needs. This user isn't expected to know how to change the 3 algorithms in the Java source code because they probably won't have any experience with Java progamming.
• Computer Programmer: A computer programer is an expected user because the source code will be documented so that a programmer can code a complex algorithm for transitions into the program. This user is expected to have a good knowledge of Java programming and data structures.
• Teachers: A teahcer could use the Cellular Automata tool to teach Cellular Automata theory and it's uses. A teacher can show examples and students can see how the actual transitions occur.

The Proposed System: Operational Scenarios

• Biological research: A biologist can use the tool to try to design a set of transition rules that will model a real-life system. A biologist may also have a set of rules ( or an algorithm ) that he just needs to implement in a simulation to view it's effects. The ease at which the tool can be reconfigured will help the biologist accomplish these goals.
• Algorithm design: The tool will have the source code and documentation provided with it so that a user with a good background in Java programming can redesign the algorithms for the transitions. Their will be simple transition states provided in the code, but an algorithm may be needed to design a more complex set of rules.
• Teaching: Our CA tool can be used to show students the basics of how a CA simulation works. A teacher can show how the transition rules can effect the outcome of the simulation. Some of the more interesting simulation's can be quickly shown as examples to students also.

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.

• A simulation interface with a variety of ways to simulate. The simulation should be able to be saved and loaded after any cycle completes. There should also be a simulation mode that will allow the user to simulate set amount of cycles, but saving after x amount of cycles for a playback later on.
• Powerful initial state editing tools. The ability to set a rectangular area of simulation space to a given state.

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.

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

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.

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.

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.

• Programming Language: There are many different programming languages to choose from. The other main choice for the project would be C++. If we did the program in C++, we would have to use Visual C++ or Borland C++ Builder. Both of these compilers are incompatible with each other and all other operating systems. We chose Java because all the GUI classes are built into the language and because of it's compatability. By choosing Java we have lost the speed that C++ would have provided.
• Number of Rules: By not limiting the number of available states in the Cellular Automata to a fixed value, we are increasing the usefulness of our program on a research standpoint, but we are limiting the extent we can use graphics for the states.

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.