.:The Babylon's Project:.

.:The Framework Customization Model (1/3):.

The overall goal of the FCM is to provide framework users with active and passive assistance while creating framework customization. To make this assistance possible, the framework developer has to provide the framework with its structural dependencies also called consistency model.

The structural dependencies

Structural dependencies capture framework usage constraints that must be respected when a customization is done by the framework user. On a pragmatic point of view, structural dependencies are relations binding two or more heterogeneous elements of a framework (class, method, file, etc.) in the way that if an action is done on one element (creation/deletion/modification) an action should be done on the others. In order to show an example of what structural dependencies are, we use the EJB framework (which allows to build distributed Java components) to create an EJB component called Account.

The resulting customization will be correct if the following constraints are respected:

• Account, the component interface, must implement the framework interface EJBObject. AccountImpl, the implementation of the account component, must extend EntityBean. AccountHome, the factory for the account component, must implement EJBHome -- Here the constraints are on the inheritance relationship.
• AccountImpl must implement all methods from Account because AccountImpl does not implement Account -- Here there is a constraint on the addition of methods.
• AccountImpl must contain one ejbCreate method per creation method on AccountHome, the factory. The framework will manage the correspondence between the specification in the interface and the implementation in the class following naming constraints.
• Last but not least, a file named deploy.xml must be filled with the name of all the classes created -- This shows that dependencies can be among heterogeneous elements.