JCLEC Intro

Three layers comprise the JCLEC architecture:

In the lower layer it is the system core. It has the definition of the abstract types, its base implementations and some software modules that provide all the functionality to the system. Over the core layer it is the experiments runner system in which a job is a sequence of evolutionary algorithms executions defined by means of a configuration file. It receives as input this file and it returns as result one or several reports about the algorithms executions. In the upper layer there is a Graphical User Interface (GUI) for EC called GenLab. It allows solving a problem more easily using the available EAs from a specific interface. It configures the algorithm, executes it in an interactive way and it also generates the on-line information about the evolutionary process. The system can be also used to define execution sequences that will be executed by the batch-jobs runner module. And the user can include his/her own code whenever the developed code fulfills the hierarchy defined in the system core.

Below figure shows the interfaces that define the functionality of the JCLEC system. As it can be seen, three types of interfaces exist: The related with the evolutionary system (IIndividual, IFitness, ISpecies, IEvaluator and ISystem), the ones that represents actions accomplished during evolution (IProvider, ISelector, IRecombinator and IMutator) and the evolutionary algorithm itself (IAlgorithm).

The IIndividual interface represents one of the individuals that live in a system in evolution. This interface does not declare methods related to the individual's genotype neither with its phenotype, granted that this functionality is defined in the lower classes of the hierarchy. In fact, JCLEC's core contains several implementations of the IIndividual interface that are distinguished in the genotype that they present (bit string, int or double arrays, expression trees, etc). Such classes can be used directly in the implementation of evolutionary algorithms or they can be extended by the user (defining the phenotype that maps to a given genotype). Obviously, user can also define new types of individuals associated to new encoding schemes. As a matter of fact, if the class implements the IIndividual interface, then the integration with the other system components is taken for granted.

All the IIndividual instances are linked to an object that implements the interface IFitness, which denotes the individual's fitness. There are several implementations for this interface that represent fitness in mono-objective and multi-objective problems.

As we have mentioned previously, in all the EAs there is a system that represents the evolutionary process. The ISystem class is in charge of representing this system in an abstract way. This class has a reference to an ISpecies object that represents the structural characteristics of the individuals and to an IEvaluator object that has to evaluate individuals. The ISpecies class has a different implementation for each type of individual in JCLEC, because it represents the structural features of a set of individuals (for instance, for binary individuals it stores the size of the chromosome and the schema that represents them, and for GP it stores the maximum size of the tree, the terminal and function nodes). This information is used by genetic operators in order to handle individuals correctly. The ISpecies class also works as a factory of IIndividual objects and it provides methods to create instances of the class they represent. On the other hand, IEvaluator performs the evaluation of the individuals, that is, it computes and assigns theirs fitness. In order to resolve a problem with JCLEC is necessary that the user implements a class that extends to this interface, providing the system with a way to obtain the individuals' fitness.

The abstract representation of EAs is responsibility of the IAlgorithm interface. This class has a reference to the system in order to evolve it as well as some references to ITool objects. Such objects represent the actions performed in the course of an evolutionary algorithm. There are several interfaces that extend ITool. The IProvider is responsible of providing new individuals to the system (it is used in the algorithm initialization phase). The ISelector represents a selection procedure. The IRecombinator and IMutator interfaces represent the crossover and mutator genetic operators. Many of these components can be used in any EC paradigm, while others are designed to deal only with a certain type of individual. The user is responsible for choosing correctly these components during the design of a specific application. Also, the IAlgorithm interface has three methods related to the EA execution: doInit():void takes charge of initializing the algorithm, doIterate():void takes charge of doing an iteration, and isFinished():boolean takes charge of notifying about the finalization of the execution.

Finally, in order to obtain information about the execution of an evolutionary process we have defined a listeners system similar to the one used in the management of events in Java. This system consists of the IAlgorithmListener interface and the AlgorithmEvent class. The IAlgorithmListener objects take charge of picking up all the events related to the algorithm execution (algorithm started, iteration completed and algorithm finished) and react depending on the event. The AlgorithmEvent represents events that happen during the algorithm execution. This class has a reference to the algorithm in order to access the current state and to react according to the object it has been created to.