Writing BtrPlace extensions

BtrPlace is already bundled with several Views and constraints to accomodate with common concerns. In some circumstances, the library may however lack of solutions. We discuss here how to create extensions.

Generalities

BtrPlace is designed around the bridge pattern to dissociate the user API which expresses a constraint or a view and the solver API which expresses the enforcement algorithm using the choco API. Furthermore, it is pretty sweet to be able to serialise an instance into JSON to be able to replay it for debugging purpose.

As a result, when you develop a view or a constraint, you will have to develop 3 components:

1. the user-side code. For a view, this exhibits a part of a cluster state. For a constraint, this will exhibit the desired state.
2. The serialisation code to produce a JSON version of your component.
3. the solver-side code. This consists in customizing the default Choco CSP to express your requirements

Writing a View

User-level API

Every view derives from ModelView.

• It must provide an identifier
• It must be Copyable
• It must implements equals() and hashcode()

It is also convenient to implement a static get() method to access the view inside a model once attached (example)

Remember that a view reports the initial cluster state. Accordingly, there is no notion of interpretation about the current situation.

Choco-level API

The Choco version of a constraint implements ChocoView.

The mapping process

The mapping between a user-level view and the choco-level view is done using the ChocoMapper.mapView that is accessible from any ChocoScheduler Parameters. Internally, the Reflection API is used to instante the Choco view and the mapper expects a constructor for the ChocoView that takes the user-level view as a unique parameter.

Injection workflow

Inside the view, the developer must implement at minima the inject() method

TODO***