From ALESwiki

3. Proposed Software Architecture

3.1 Overview

ALES is a GUI based game interface, written in Java, so it will be portable across many systems. By using Java's "Look and Feel" graphical classes, this system will look like a native application on whichever platform the user is on. If they are on Microsoft Windows, it will have a Windows look and feel. The same will be true for Macintosh. There are custom graphical classes that can be used to make this look like a native Macintosh application.

The system will have a very simple user interface and anyone that has used a recent GUI-based operating system should be able to play this game with no issues. Most of the interface will be point and click, with very little typing required.

Because it is Java-based, the machine must have the necessary Java components to run Java applications. The most recent Java Runtime Environment can be downloaded from http://java.sun.com/downloads.

3.2 System Decomposition

The ALES decomposes into 2 subsystems: the GUI subsystem and the Game subsystem. Each one of those items can be further decomposed to simplify system design.

GUI Subsystem

The GUI subsystem is responsible for the interacting with the Player. This includes the menus, the game board display, displaying critters, and the animator. Each one is responsible for interacting with the user.

Game Subsystem

The Game subsystem is the main engine for playing the game. It controls the game clock, the decisions, the file operations, creature management, help system, and the stats maintained. Each one of these items can, and should be, decomposed into smaller subsystems to facilitate coding.

3.3 Hardware/Software Mapping

ALES is a small Java based program that will run on most modern computer systems. Since it is Java-base, we will be able to use it on computers running Windows, Macintosh, or Linux. We do require JRE 1.5 and some minimum hardware specifications.

To make sure it runs smoothly, we recommend the following minimum configurations:

Window/Linux based Processor: Intel Pentium 4 or Celeron 1.2 Ghz or Higher Memory: 512MB RAM Harddrive: 20GB total, with 5GB freespace Monitor: 17" SVGA Monitor OS: Windows 2000 or higher

Macintosh base Processor: G4 Processor Memory: 512MB RAM Harddrive: 20GB Hard Drive, with 5GB freespace Monitor: 17" SVGA Monitor OS: OS X 10.4 Preferred

The ALES program runs directly on the computer and stores all data files on the hard drive. This will keep the system running at optimal speed, with very little slow down.

3.4 Persistent Data Management

Game board saves and game progress saves will be written to a text file that will be stored on the local system. For this reason, we are recommending that the user has at least 5GB of freespace available on their system to keep this information. If a user plays a lot of very large, complex games and saves their progress in intervals, this can use up a lot of hard drive space.

The Game Board Saves will contain data such as: size/dimensions of the board, information on each critter, where each critter is located, and initial conditions of the water.

The Game Progress Saves will contain more data than this. They will also include information on the state of each critter, every hex tile, and time/progress information.

3.5 Access Control & Security

In the first iteration of our system, there are no plans to manage access control or implement security features. The system runs on a stand alone computer and the user must have read, write, and execute permissions to the directory where ALES is going to be installed. The user must also have read and write permissions to the directory where the saved games will be stored.

3.6 Global Software Control

The ALES system uses a mixture of control flow methods. Some parts are controlled through threads, while other parts use event drive flow control. The creature decisions will be driven using threads and the GUI interface will use event flow control.

Trying to simulate life form behavior can be very difficult, because if we were to use a procedure driven flow to control the creatures, then the creatures would be acting as one large group instead of individual entities. Therefore, we have chosen to emulate creature behavior using threads. This will allow each creature to run on its own thread and we will be able to segregate the decision making activities into these child threads.

Since we are using threads here, there will be some concurrency and synchronization issues that the software will handle by requiring each child to report its state back to the parent. Before moving on with each round of decision making, every child must be accounted for.

The GUI system will use event driven flow control as is standard with most Windows-based systems. There will be listeners for the menu system, the game board, and game controls to let us know what the user is doing. The system will react to each event that is fired and respond with the appropriate action.

3.7 Boundary Conditions

Initialization

The software runs on the local computer system and currently there is no support for usernames or profiles. We are doing this to keep the interface clean, simple, and easy to use. ALES will have its own icon that can be placed on the desktop or in the program menu. When a user starts the ALES program, by default, it will load the last saved game that was played on that computer. From there, they can choose to continue playing that game or create a new game/board.

Termination

The ALES simulation can be terminated by the user by using the exit function. This can be accessed from the menu system or directly from the user interface. Once the exit function is called, the user will be prompted to save their current process if they would like, cancel the exit function, or exit the ALES system.

Failure

Since ALES is a stand alone application, most of the issues that arise will be related to computer problems, data corruption, or external conditions. Computer problems would be things like other applications interfering with the stability of the system or insufficient resources. Data corruption could be anything from a corrupt JRE install to corruption of the game files. External conditions could be things like power issues or general user errors.

ALES will implement functions to easily back up game files and it will encourage the user to do so and often as needed. This program is a very simple model, so this is the only real issue that we will have to deal with. We will not support issues related to the user's computer and we are not liable under the GPL License for any data corruption that might occur.