Package com.rubecula.darwin.startup

Startup (overall description of Darwin 2 framework)

See:
Description

Class Summary

Darwin	Class to start up a Darwin application (not an applet).
Darwin.DarwinClassLoader	Darwin's own class loader.

Package com.rubecula.darwin.startup Description

Startup (overall description of Darwin 2 framework)

Contents:

• Copyright Notice
• Overview
• Darwin Philosophy
• Programming Conventions
• Class Structure
• Links

Copyright Notice

Darwin Framework Project.
Copyright (C) 2003, 2007, 2009 Rubecula Software.
This library is free software; you can redistribute it and/or modify it under the terms of the GNU General Public License as published by the Free Software Foundation; either version 3 of the License, or (at your option) any later version. This library is distributed in the hope that it will be useful, but WITHOUT ANY WARRANTY; without even the implied warranty of MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU Lesser General Public License for more details. You should have received a copy of the GNU General Public License along with this library; if not, write to the Free Software Foundation, Inc., 59 Temple Place, Suite 330, Boston, MA 02111-1307 USA

CVS Version: $Revision: 1.3 $

Back to Top

Here's an update of the (original) registration text for this project:

This project provides a set of framework classes for the development of Evolutionary Computation applications in Java. Such applications, which might be classed as genetic algorithms, genetic programming, etc., enable problems, typically complex and non-analytical, to be solved by successively evaluating a population of possible solutions and breeding from the better-fitting solutions to generate a new population. The code is platform-independent. It is our intention to make this project a resource which can be used and or contributed to by anyone working in the field. As such it is designed to be extremely general in its class structure, with a well-defined separation between method (framework) code and application code.

Back to Top

Darwin 2 Features

The Darwin famework has undergone a major overhaul during 2009 and is now referred to as Darwin 2. The major changes include:

• Configuration: the components which make up evolutionary computation applications are now assembled by configuring a set of beans, each of which implements one of the many interfaces defined by the framework. The configuration is typically based on an XML file and is interpreted by a configuration manager with dependency injection. For this purpose, Darwin 2 uses a custom-made, but generic bean container called BeanPot (http://beanpot.sourceforge.net/) which has a minimal footprint and provides just the required functionality (including implicit registering of MBeans with a JMX agent). Of course, Spring could equally well be used.
• Domain (core): many more types of genetic artifacts are available out of the box, for example sex-based chromosomes to enable sexual selection. A more flexible and powerful subsystem is provided for driving the generations and environmental changes.
• The license used is now GPL.

As described below, the framework is infinitely flexible but you are probably interested to know what's implemented "out of the box":

• Diploid and haploid genomes;
• Simple Mendelian genetics;
• sex-linked and non-sex-linked loci and chromosomes;
• Polygeny and pleiotropy
• Meiosis based on chromosomes (with variable probability of crossover) or loci;
• Mutation;
• Fitness for the environment;
• Sexual selection, i.e. attractiveness to the opposite sex (assuming diploid genome with some sex-linked chromosomes);
• All numerical calculations, for example for fitness or mate selection, are typically implemented using an expression evaluator where the expression can be varied at runtime (except that when the expression is unchanged, the evaluation is performed directly [for performance reasons];

Darwin Philosophy

Here are some of the tenets of the philosophy behind the design and development of Darwin and Darwin 2:

• It is object-oriented and implemented in Java.
• At a high level, it models the mechanisms found in nature, without having to be exact in every detail.
• Framework (core) classes, visualization classes, example classes, etc. are appropriately in separate packages.
• The code conforms to a set of programming conventions, including the fact that most public methods (in particular those which are not bean methods like getXxx/setXxx) in the domain package are defined by an interface.
• Documentation is an integral part of the package.
• Elegance is generally more important than performance, although some caching methods have been added in Darwin 2.
• It is highly extensible. This extensibility is achieved through:
  • the use of interface types to model all concepts;
  • the use of factory classes which allow developers to define their own constructors for concrete objects.
• It is open-source: comments and constructive criticism are welcomed. However, if you are thinking of using it in your own application, please note that Darwin 2 is licensed under the GPL (not the LGPL).
• The architecture is defined such that the domain package is divided into vertical "slices": for example, world can reference anything; genetics can reference helper. The packages also conform to a layer-based architecture.

Back to Top

Programming Conventions

• In general, each concept is modeled by the following:
  • an interface with a plain name, such as Genome;
  • an abstract class which provides a basic, typically partial, implementation of the interface and whose name is concept_, for example, Genome_;
  • (usually) a default implementation class, marked final, which extends the abstract class and whose name is something like concept_Standard, for example, Genome_Standard or some other name, often in honor of some great mind in the field;
  • (optionally) a set of policy-specific implementation classes which extend the abstract class and whose names are of form: concept_policy, for example, Genome_Diploid;
  Interfaces which simply exhibit the visitor interface (i.e. a simple callback mechanism) typically do not have an abstract class (which would do nothing) and may not have a default class either. All references to the concept, for example types referenced in method signatures, are in terms of the concept (i.e. the interface). The abstract class is referenced only in certain restricted circumstances. The names of the concrete (implementation) classes are used only for constructors (and those are generally found only in the factory classes or in XML configuration files).
• The order of source files is generally: public class fields, public class methods, public instance methods, non-public instance fields, non-public instance methods. Some variations occur because of requirements of static initialization (some private class fields may appear first).
• Naming: [this needs revision for Darwin 2] class fields and methods generally begin with capital letters (exceptions when name is a Java convention such as valueOf); instance fields are of the form _Class or similar; constants (final static fields) have names beginning with "$".

Tips on writing good code. [FROM HERE ON DOWN, THIS NEEDS REVISION FOR DARWIN 2]

Setter Methods

Take care when putting a setter method (that sets a bean property) into an interface. The bean setters (reflection, dependency injection, etc.) do not need the interface and the interface may encourage other beans to set that property indirectly. This can cause hard-to-diagnose problems when a property is set by dependency injection and then at some later time set by the action of another bean.

Back to Top

Class Structure

The following is an introduction to the major classes and interfaces of the Darwin package. Use it as a starting point and/or as an adjunct to the javadoc. [NOTE: This section is far from complete - see the javadoc!] However, if there are discrepancies, then the javadoc must of course be considered definitive. Most of the classes described are found in the com.rubecula.darwin package. Some utilities, of a more general nature, are found in com.rubecula.util.

Following are descriptions of the Darwin framework interfaces each having a simple concept name: Concept.

• Expression: this application interface defines how genetic information (Genes, Genomes) is "expressed" as physical information (Traits, Phenotypes).
• Gene: This application-independent class represents a particular gene at a locus of a genome. :
• Auditable which is useful for identifying items for testing purposes.

• etc.
  

Following are descriptions of the Darwin classes.

• etc.
  

Back to Top

Important Notes:

The package is bundled with the Jakarta Commons Logging facility, without which it will not compile. You don't need your own logger to work with JCL but a log4j configuration file is provided and, if log4j is in your classpath, it will run as expected.
However, by default, all logging is turned off (logging is directed to the NoOpLog implementation). In order to turn it on, open up LogFactory_Darwin.java (currently in the util package but needs to be moved) and comment out the return new NoOpLog(); line and uncomment the LogFactory.getLog... line.

TODO THIS IS OUTDATED. You will find a working example applet: the PepperedMoth example, in the examples package. This applet has an optional feature provided which allows you to vary the formula expressions (in the options window of the applet). Normally, you will leave this feature off (and filter out the compilation of the Evaluator_JEP class which you won't need). In order to turn this feature "on" you must do the following:

1. Procure an (open-source) license to JEP;
2. Re-enable compilation of Evaluator_JEP;
3. In the config/pepperedMoth.properties file, set the expressionsEnabled property value to true.

A note on the use of constructors

In general, we do not invoke constructors directly in the application code. Any object which is a singleton is normally constructed as a bean and defined thus in the configuration XML file. Furthermore, classes of which there is a small finite number of instances known at configuration time will also be constructed as beans. Such classes must have public constructors in order that the bean container can instantiate them. An object of which there may be an unlimited number of instances, dynamically constructed at runtime, will normally be constructed by a factory class. Such classes will normally have a package-scope constructor and if the objects implement an interface called Concept or extend a superclass called Concept, there will be a factory class in the same package whose name is ConceptFactory.

Links:

• Darwin Home Page
• Source Forge Project Page: Darwin
• About Darwin

Back to Top

Last Updated: 2009-10-05 By: Robin Hillyard