The WASA project


WASA Cookstour

  • Packages overview
  • Core classes
  • Buisness Objects and side effect
  • Monitoring
  • Design Patterns


    The most obvious approach to Constraint Satisfaction Problems (CSP) is to express the problem by constraints (set of operators) applied on variables. The application fills those variable with corrects values, and just lets the solver do its job. This approach has the following drawbacks :

    • buisness object values must explicitely be exported to / imported from the solver,
    • the programmer has to express the constraints in a way the solver understands.

    In other words, the solver is disconnected from buisness object's world, and the Programmer has to connect it manually. Some constraint-solving algorithms (like Branch-and-Bound) rely on knowledge of relationships between variables and constraints for performing ptimizations. But the Adaptative Search Algorithm avoids this, it simply requires to express at which level a given Variable violates a Constraint, for a given Configuration. So we decided to take advantage of this property for filling the gap between buisness objects and problem definition.

    So we thought the best place to store Variables is Buisness Objects themselves. This allows reuse of properties and methods to make Constraints and Explorers expression straightforward.

    Let's have a quick look on how the Adaptative Search Algorithm works. For a given Configuration (the state of Buisness Objects), a problem-dependant Explorer finds the neighbourhood, which is a set of other Configurations, with only one modified variable. For each Configuration defined by the neighbourhood, the Constraints are evaluated, and the Configuration with the lowest error is chosen for the next iteration. This implies that :

    • both Explorers and WASA Engine have a side-effect on Buisness Object states,
    • the WASA Engine should be able to backup / retrieve Buisness Objects states,
    • Constraints should be able to set an error score to some Variable.

    This is achieved by the use of a Var class, which acts like an "intelligent" pointer, knowing how to access data inside Buisness Objects. For each Variable which is a part of the Problem evaluation, a Var object is declared by the user. Constraints will evaluate themselves upon Buisness Object properties, and will set appropriate Var instances to the required values. Explorers can either modify the Var's value, or set Buisness Objects state directly.

    Var instances manipulate values as Objects, allowing to express a Problem with any kind of data (not only scalar types). A Var is able to backup and retrieve a Buisness Object value, most of time when it is asked by the other parts of the WASA Framework to do so.

    The WASA Framework lets the user define a Var instance by reflexion (using a Property name), or define his / her own Var-derived classes, for improving execution time, or getting a finer control over value cloning.