This webpage is dedicated to the OCL-based constraint checker embedded within the Hulotte framework.


Hulotte framework provides a general approach to designing domain-specific component frameworks. Hulotte is implemented as an extension of the Fractal Component Model, a generic-purpose and hierarchical component model, and on its support in Java. Using Hulotte, the application developer specifies its applicative architecture as a set of components interconnected via bindings.
The basic building blocks are the primitive components implemented in Java using Fraclet, an annotation framework that reduces the complexity of the implementation of component-based applications. Java annotations in Fraclet are used to mark classes, fields or methods that implement Fractal concepts.

Since Hulotte allows the reuse of components' architectures within various domain-specific contexts, our framework provides a constraints checker which operates at two levels: First, at architectural level, to insure the consistency between the domain-specific concerns (named DomainSpecificAnnotations) specified by the application developer. Second, between the architectural level and the implementation level (further referred as implementation level constraints), to insure the consistency between domain-specific concerns and the code.

For instance, we consider the use of Hulotte to design component-based applications specific to the multitasking and the distributed domains. Following the Hulotte metamodel, we provide to the application developer the domain-specific concerns illustrated in the following figure.

Domain-Specific Hulotte Annotations
  • periodic and sporadic annotations mark components as active. An active component will be attached to its own thread of control managed by a generated Hulotte runtime. The component activation is either periodic -- i.e., dependent on a periodicity given by the developer--, or sporadic -- i.e., triggered by incoming events.
  • The protected annotation for a component specifies that the Hulotte runtime must guarantee mutual exclusion over the execution of its services.
  • asynchronous allows the expression of asynchronous bindings between components.
  • Finally, the distributed annotation defines the component's allocation within distributed nodes.

An application example based on these annotations is illustrated in the figure below. In this application, components are distributed in two nodes (in gray) that communicate via an asynchronous binding. In the first component (ActionComponent), a periodic Writer sends data to a shared protected component. This data is then read by a second Reader periodic component that, though the asynchronous binding, sends the data to the second Reaction Component (download the example serialized in XML).
Hulotte's Application Example
Considering this example, we can highlight the following architecture level constraints:
  • Each component must be either distributed or nested within a unique distributed parent composite.
  • An asynchronous binding must not be defined if its destination interface is not exported by sporadic component.
  • A cyclic composition chain between the same active or protected component instances must be forbidden to avoid deadlocks.

Examples of implementation level constraints are specified as follows:
  • The methods specified within interfaces involved in a distributed binding (i.e. between distributed components) must have parameters and return values of primitive types to ease marshaling, and must not declare checked exceptions.
  • Since the protected component services are executed as a critical section within the Hulotte runtime, the implementations of these services must not be based on internal synchronization mechanisms (such as the synchronize Java keyword) to avoid potential deadlocks.
  • The periodic components must implement a unique task entry point which will be periodically called by the runtime (such as the Java Runnable interface).
Hulotte Metamodels

Hulotte is implemented using EMF metamodels. These metamodels capture three level of abstraction: the architectural level, the implementation level and the Fraclet level which acts as a pivot representation between them. As an implementation metamodel, we use SpoonEMF, based on the Spoon programm transformation framework.

Since these metamodels are linked together, we are able to check the aforementionned constraints using OCL rules in a homogeneus way. Their implementation in EMF are downlodables from the following links:

Download Hulotte's constraints checker

Download the Hulotte's framework prototype.