Complete Guide > Overview

This chapter gives an overview of the structure of the framework's API. Greater detail can be obtained from the JavaDoc. The structure of EpochX is not complex, and it is easily summarised by the diagram below. All classes in the framework fit into one of four modules that could be called XGP, XGR, XGE and Common. The XGP, XGR and XGE modules contain all the classes specific to one of the representations - STGP, CFG-GP and GE respectively. Any classes common to two or more representations will be found as part of the Common module.


The Common module contains alot of the most important functionality of the EpochX framework. It provides the general structure that each of the representation specific modules work on top of. The central pillar of the framework is the 'core' package, which contains the evolutionary algorithm itself. The class diagram below illustrates how the classes of this package piece together, with execution beginning at the Model. For more information about the specifics of what takes place during execution of the algorithm and the order of events, see the Algorithm chapter.

The InitialisationManager, PoolSelectionManager, CrossoverManager and MutationManager have a slight difference to the other classes in the core package. While the other classes provide their stated functionality, these ones have a void into which an operator must be plugged in order to operate. Note that these classes do not define a crossover, mutation etc. operator. They are just the socket into which one of these operators can be plugged. They 'manage' the operation, but they do not perform it. A set of operator interfaces are defined in the org.epochx.op package of the Common module. Each one of these can be implemented to perform the operation in any number of ways. With the operator to be used set as a parameter on the model. Of course EpochX comes with many of the standard implementations for each operator, although with the exception of selection, these are representation specific.

A current limitation in the framework is that the operator types are fixed, and it is not possible to define entirely new operator types without modifying the framework's source. This limitation will be removed in a future release.

Some of the other features found in the Common module are the life cycle handler code, the statistics handling, grammar parsing, interpreters and random number generators. These will all be covered in more detail in other chapters.


Each of the representation modules contain all the classes necessary to support the program representation. For XGP this includes all the different function and terminal node types that can be combined to create GP program trees. XGE and XGR on the other hand both use parse trees to represent programs and so the necessary classes to support this are found in the Common module. Each candidate solution program is expressed in one of these formats, which is stored internally to an instance of one GPCandidateProgram, GRCandidateProgram or GECandidateProgram. The CandidateProgram types store some meta-data about their program, as well as providing some ancillary methods to operate on the program.

XGP, XGR and XGE each contain implementations of those operators that are representation specific - crossover, mutation, and initialisation. Many of the most common operators are provided such as SubtreeMutation for XGP and RampedHalfAndHalfInitialiser. Each of these implement the appropriate interface, for example, GPInitialiser, GRCrossover or GEMutation.

Another part of the framework that is representation specific is the set of built-in benchmark models that define many of the common problems genetic programming is tested upon. More information about the included models and how models in general work is given in the following chapter Models.


The design intention is that each of the representation modules are independent from each other. This means it is possible to completely remove the XGR and XGE modules and still have a fully working STGP representation in XGP, and the same for each of the other two. The Common module is of course required for all the representations.

Next: Models
Previous: Installation