Introduction

The characteristics and requirements of GAs and PGAs outlined in Chapter 2, and the various common features of existing programming environments presented in the previous chapter, provided the grounds for the creation of the GA programming environment described in this chapter. The Genetic Algorithms Manipulation Environment (GAME) is also the result o f a jo in t European research project, w hich brought together university and industry for the development of complex PGA apphcations.

This chapter presents an overview of the whole programming environment and briefly describes its main modules. Being a complex and sophisticated programming environment, the design and implementation of the various modules of GAME was carried out by a team o f three researchers at UCL. This thesis focus on the parts of the system which were the responsibility of the author of this dissertation and comprised:

• the definition of the modular architecture of the system;

• the definitio n and im plem entation o f G A M E’S genetic-oriented and problem independent data structures;

• the design and implementation of GAME’S genetic manipulation engine: the Virtual Machine;

• the specification of a programming model that enables GAME applications to be dynamically configured;

• the design and implementation of the communication and parallel control module that allows the development of portable sequential and parallel apphcations;

• and the specification of a hierarchically organised set of libraries to maintain parameterised versions of genetic algorithms and operators.

The next section starts with an overview of GAME’S object-oriented architecture. It is followed by the introduction of its representation abstractions and programming model. Then, a summary description of each main module is presented. The chapter ends with a brief overview of the PAPAGENA project, stressing the importance of GAME for the development of real-world apphcations.

4.2. GAME Architecture

The Genetic Algorithms Manipulation Environment provides a unified framework that makes the development of complex and sophisticated sequential and paraUel genetic algorithms apphcations extremely easy. The design of GAME was mainly driven by the requirements and characteristics observed in a large num ber of GAs and PGAs. It is also the resu lt o f a combination o f common features encountered in the majority of general-purpose programming environm ents. In addition, G A M E’S innovative object-oriented approach and platform - independent paraUel programming model makes the system unique in its class.

GAME addresses all the basic requirements involved in the design cycle o f a GA application. It offers problem-independent genetic-oriented data structures, comprehensive programming interfaces and a set of hbraries with parameterised versions of a broad range of GAs and PGAs. Its underlying infrastructure provides mechanisms for the manipulation of genetic data structures, simulation monitoring and application execution on a virtual computing environment supporting multiple parallel computation models. GAME is highly customisable and its hbraries can be easily expanded with the inclusion of new parameterised modules.

Users can interact with GAME at three distinct levels: application prototyping, module configuration/creation and system customisation. At the prototyping level, novice and non-expert users can rapidly configure and execute an apphcation by simply setting up a few parameters in a configuration file. At the module configuration/creation level, programmers can combine pre­ defined modules from the algorithm and genetic operator hbraries to create new apphcations. M oreover, entirely new m odules w ritten from scratch or by m odification of source code examples, can be easily integrated into the environment. FinaUy, the system customisation level aUows programmers to modify internal modules of the environment, such as the Virtual Machine or the graphic user interface. The interaction at this level is particularly important for porting GAME to hardware or operating system platforms not supported in its original distribution. It is

Chapter 4 The GAME System 65

also at the system customisation level that GAME’S functionality can be adapted or expanded to suit diverse application requirements. GAME’S standard modules, such as the Virtual Machine, can be replaced easily by customised versions thereby providing extra functionality.

4.2.1. Genetic Representation

One of the key features of a GA general-purpose programming environment is the ability to support the representation of a variety of problems. The traditional GA requires a problem to be represented as a single string (normally using the binary alphabet). Although effective and easy to manipulate, this representation model restricts the construction of genetic algorithms and operators in many ways, and generally results in problem-dependent implementations.

GAME provides problem-independent representation through a set of abstractions that help with the description o f a broad range of genetic data structures. It is possible to represent genetic data structures as simple as ordinary binary strings, or as complex as parse trees of any depth or w idth (depicted in Figure 4.1), as required in genetic programm ing applications. GAME’S principal genetic-oriented abstraction, the DVA, is a tree node, which has the ability to store information. It is the result of the combination of two primary objects defined by the system;

• DataUnits and • DnaNodes

The D ataU nit is defined as a class o f objects th at is capable o f storing “genetic information’’ - the problem’s data. Currently, GAME provides DataUnit objects to store most of the native C ++ data types (char, int, long and double) and a special type that stores binary encoded strings. DataUnit types are fully integrated with native data types (internal conversion operators and assignment operator overloading provide transparent conversions between types).

Figure 4.1 - A genetic-oriented representation Individual

DnaNode

DataUnit DataUnit

DnaNode

DnaNode

1

I

The DnaNode object has the ability to “connect” several DnaNode objects. It can also o p e ra te as a container for one or m ore D ataU nit o bjects, transform ing this p articu la r

configuration into a DNA object. A DnaNode may connect only to one “parent” node, which in turn, may contain an arbitrary num ber o f other DnaNode objects, configuring a tree data structure. A special class derived from the DnaNode, the Individual, sits on the root of the tree structure and represents a single candidate solution to a given problem. Therefore, any genetic representation in GAME must be formed by an Individual object connected to one or more DnaNode objects (depending on the number of variables, or chromosomes, defined by the problem); the latter containing at least one DataUnit object (a gene). The DnaNode class provides a set of member functions related to node-level operations such as attachNode, detachNod&, copyNode and deleteNode. It also provides operations over the DataUnit objects it stores such as

readData, writeData, modifyData, copyData a n d deleteData. The c o m b in a tio n o f the functionality provided by the DnaNode and DataUnit objects gives an enormous flexibility for describing complex genetic structures containing mixed data types at any level o f the tree structure.

4.2.2. Programming Model

A GAME apphcation is a computer program that co-ordinates the operation of execution units, or active objects, defined as GAME Components. Any GAME Component object must be derived from the G am eCom ponent class. This class provides the basic functionality for concurrent execution and inter-process communication. It allows GAME Component objects to execute as independent processes, or active objects, similar to the ACTOR [1] model. GAME’S programming model presents the following features:

• GAME applications consist of a collection of GAME Components - typically the application front-end (with the graphic user interface), one or more algorithms (with its operators) and the Virtual Machine - executing sequentially, concurrently or in parallel.

• Components may share the same memory space, the same processor or execute on a different processor or m achine. These three options can coexist in the same application (see Figure 4.2), and the actual distribution is dynamically controlled by the components themselves.

• GAME Components communicate asynchronously or synchronously via message passing. Components have the abihty to buffer messages in their mailboxes. Messages are queued and collected from a mailbox sequentially, in a first-in-first-out order. • Messages are objects derived from the MessagePackage class and contain specific

commands and parameters for GAME Components. Messages may also be replied with status and other information resulting from the command, on its completion.

Chapter 4 The GAME System 67

• M essa g e P a c k a g e o b je cts can only carry G A M E o b je cts d e riv e d fro m the G am eStream O bject class. Objects derived from this class have the ability to be represented as a data stream that contains the relevant information to produce exact copies, or clones, of the original object.

• A GAME application must have, at least, an ApplicationComponent object, which generally implements the user interface. Application components create one or more

AlgorithmComponent objects that, in turn, create OperatorComponent objects. Figure 4.2 - Sequential and parallel GAME applications

Graphical User Interface Genetic Algoritm Genetic Operator Genetic Operator Virtual Machine Fitness Evaluator Population Manager Graphical User Interface

P.E.M. (Communication System)

Genetic Algorithm Operators Vi Ma rtual chine Pop Man F itness Evaluatoi

J

Application components may also create a MonitorComponent object, whereas algorithm components typically create a VirtualMachine object (also a GAME component) to execute genetic manipulation commands generated by the algorithm itself and its operators.

4.3. GAME Modules

The GAME system is a collection of libraries organised in two major groups: the Service Libraries and the Genetic Libraries. The Service Libraries contain the modules that form the core of the environment: the Virtual Machine, the Parallel Execution Module, the Monitoring Control Module and the Graphic User Interface. They also contain a collection of classes that implement the genetic-oriented data structures, exception handling, etc. Figure 4.3 presents an overview of GAME’S architecture with its main modules.

Figure 4.3 - G AM E’s modular architecture M onitoring Control M odule Parallel Execution Module

Parallel Support Module

Fitness Evaluator Population

M anager

The modules in white (Monitoring Control Module, Parallel Execution Module, VM Parallel Support, Population Manager and Fitness Evaluator) represent the parts of the environment runtime libraries that are common to all applications. These modules are not “seem” by the user, being embedded into all applications through various GAME Component classes. Conversely, the Genetic Libraries and the Graphical User Interface (in gray) are modules that contain components which the user may modify, via the application configuration file. These modules are then said to be customisable. The other module represented in gray is the Virtual Machine, which besides being a customisable module (the user can configure the number of PMs and FEs, for instance) also represents an abstraction comprising hidden and more specialised GAME Components, such as the Population Manager and the Fitness Evaluator.

The connections demonstrate the dependence relationship between modules. It can be seen that the two most important modules are the MCM and the PEM, the latter being also used by the former. Being the core of the system, PEM is used for the most basic activity in the application which is communication between its components.

The modular structure adopted for GAME is based on the design of other programming environm ents, such as the Pygmalion and the Galatea Neural Networks programming environments, also developed at UCL. However, various new concepts and ideas have been introduced and modified to adapt their original design to an object-oriented approach.

4.3.1. Virtual Machine

The Virtual Machine (VM) is the module responsible for maintaining the genetic data structures and providing facilities for their manipulation and evaluation. It isolates the genetic

Chapter 4________________________The GAME System________________________________ ^

operators and algorithm s from dealing directly w ith the data structures through a set of commands, implemented as a collection of functions, the VM Application Program Interface (VM-API). The Virtual Machine is also capable of providing a certain degree of parallelism, in which several commands can be executed simultaneously, providing parallelism is supported by the host platform. The VM comprises three sub-modules: the Population Manager, the Fitness Evaluator and the Parallel Support Module. The Population M anager maintains the genetic- oriented data structures organised in population pools, and executes genetic m anipulation commands over them. The Fitness Evaluator performs the actual evaluation of the genetic data structures and related calculations such as totaU average, highest and lowest fitness. Finally, the parallel support module distributes commands received by the Virtual Machine among (possibly) several copies of the Population Manager and Fitness Evaluator modules.

The VM-API includes commands for creation, elimination, duphcation, partial swapping, inversion and modification o f genetic data structures. Fitness-related commands permit the computation of each individual’s fitness as well as the determination of populations’ total and average fitness. The highest and lowest fitness values of a population can also be requested via the API.

4.3.2. Parallel Execution Module

The P arallel Execution M odule (PEM ) im plem ents a hardw are/operating system independent interface that supports multiple parallel computation models. It also provides an API with functions for process initiation, termination, synchronisation and communication. It is responsible for integrating all the GAME Component objects that form an application, with even sequential com ponents relying upon PEM to transp ort th eir m essages to o th er GAM E components. PEM comprises two layers: (i) th e upper-layer defines the standard interface functions used by all GAME components of an application; (ii) the lower-layer implements the functions that map upper-layer requests into specific platform-dependent support for process control and communication. The design of PEM facilitates its porting to a variety of platforms (with scalar or parallel architectures), by simply replacing its lower layer. Applications created with GAME are then automatically portable across all platforms containing an implementation of PEM.

4.3.3. Genetic Libraries

The Genetic Libraries comprise a collection o f modules containing pre-defined and param eterised applications, genetic algorithm s and genetic operators. These libraries are hierarchically organised, that is, modules of the Apphcation Library are constructed with modules of the Genetic Algorithm Library that, in turn, are built from modules of the Genetic Operators

Library. New applications and algorithms can be created by simply listing the required modules and their parameters in a configuration file.

4.3.4. Monitoring Control Module

The Monitoring Control Module (MCM) collects and displays - through a graphic user interface - events that happen during a simulation session. GAME Components may be requested to notify the MCM about received or transm itted messages, as well as any m odification of DataUnit objects they possess [30]. The level of monitoring can be selected by the user for each GAME Component object in an application. The MCM also has the ability to inform other components of the occurrence of particular events, by keeping internal “lists of interests”.

4.3.5. Graphical User Interface

The Graphical User Interface module contains simple graphic widgets that can be used to compose an application front-end. It enables applications to input and output data in a variety of formats. This module includes standard widgets for displaying texts, graphics, dialogue boxes, buttons and charts. It allows different widgets to be associated with various events reported by the monitoring module. The modular design of the graphical user interface permits the integration of the system’s basic library with commercial cross-platform or “home-grown” graphic hbraries.