GAs in SWOP

TODO : explain the big picture, zoom on the GA module, explain the basic concepts...

Solution Repository

The GA Module provides optimisation for solutions that are described in another module of the platform. At the moment, the information concerning the solution to be otimized is contained in the Product Model Ontology (PMO). Basically, the PMO provides all necessary information about the products and their components, as well as the description of user requirements to be provided at execution time.

[RV] This sucks ! We have different names for identical things... We have chosen to name this solution since the GA module can optimize e.g. processes, which are not really products. We can refactor this in our side, choose a common name, anything... but the same for all !

The GA Module uses the SolutionRepository to introspect solutions dynamically and create executable GA Applications for them. This component is described by a Java interface, and injected in the GA module using IoC (using the Spring Framework). This way, it can be completely replaced by another implementation.

At the moment we have a testing implementation of the SolutionRepository with the Cap Sealing System (CSS) solution hard-coded into it. Of course, it will be later on fully replaced by a PMO-enabled implementation.

[RV] TODO : link to interfaces ?

GA Applications

In the SWOP GA module, an application consist of a parameterizable evolutionary run, based on the description of a solution and an end-user provided fitness function. Basically, an application is generated for each solution, and is executed later on, in order to find the best individuals, based on supplied requirements (user-provided values used for evaluation).

At the moment, applications are executed using a web-based interface. A WebService offering the same features (configuration of requirements and execution of runs) will be developed later on.

The ECJ library is used for handling the dark internals of the GA plumbing (mutation, crossover, breeding etc.), which supports multi-objective evaluation.

The Application Generator

This component is the cornerstone of the GA Module. It actually generates the skeleton of a GA application (==configurator ? not sure, TO BE CHECKED !), where most of the "plumbing" is already available, so that the end-user only has to care about what's really important : the fitness function. That's basically the only thing the user has to implement to have a fully functional GA application.

The generation process is hanlded programmatically by invoking the Generator component, passing it the ID of the target solution. Of course, this is fully transparent to the end user.

Fitness Function Implementation

The FF consist in evaluating an individual based on the combination of components (and their properties) that constitutes its genome. A note is given (per objective), allowing the system to perform evolution and selection of populations amongst generations.

As said earlier, the fitness function has to be implemented by the end user in order to evaluate individuals and find the best ones (optimized configurations). This is done via a simple scripting language (Groovy). Basically, the FF implementer uses early-binding style objects to evaluate the individual. All the GA internal stuff is completely hidden, and the FF uses a high-level of semantic, by manipulating typed instances for the solution's components and their properties.

Summary of the process

Here is the global process for creatind and using a GA application :

1. Generate the application for a given solution (has to be done every time the solution description has changed - update in the PMO structure)
2. Obtain an instance of SWOPEvolve (top-level class for an evolutionary run) for the generated application
   
3. Get hold of the requirements (kind of a map of properties), and set values in there
4. Launch the run and handle the results (produced as XML compliant to this schema)