Domain-specific multimodeling[1] is promising when compared to more traditional development paradigms such as single-language programming and general-purpose modeling.
Finally, the method offers concrete proposals on how to (3) apply this knowledge in actual development in the form of consistency, navigation, and guidance.
To illustrate development with multiple languages, we will draw an example from a case study: The Apache Open For Business (OFBiz) system.
Briefly stated, OFBiz is an enterprise resource planning system that includes standard components such as inventory, accounting, e-commerce etc.
As an example, let us focus on the content management component, particularly a use case in which the administrative user creates an online web survey as shown in the screenshot below.
The figure shows a screenshot of the administrative interface of the content management application in a running OFBiz instance.
The purpose of the entity engine is to manage transactional properties of all business objects and interact with various persistence mechanisms such as Java Database Connectivity, Enterprise JavaBeans or even some legacy system.
This produces a similar effect of importing definitions from another model as in the case of the auto-attributes elements in the previous listing.
Another typical application is to use Java code snippets to invoke external webservices and import results in a suitable format.
These difficulties stem from the observation that the more kinds of artifacts we introduce into our process, the more coordination between developer efforts is needed.
Learning the different languages and understanding their interaction is necessary to make sense of the complex composition of artifacts.
There is currently no established method of characterizing different languages such that developers quickly can reach an operational understanding.
This argument can be stated in the following way: “The different languages are hard to understand and only add to the confusion because their XML-based syntax is particularly verbose and unintelligible.
This editor presents the domain in a simple and visually appealing manner but may very well use the XML representation (and perhaps a layout configuration) underneath.
Ease of navigation between different software artifacts is an important criterion for tools in traditional development environments.
This claim is supported by the observation that all major development environments today offer quite sophisticated navigation facilities such as type hierarchy browser or the ability to quickly locate and jump to references to a method definition.
The development environments can provide these navigation facilities because they maintain a continuously updated model of the sourcefiles in the form of an abstract syntax tree.
Furthermore without this internal representation, existing environments cannot resolve neither intra- nor inter-language references for such languages and hence cannot provide useful navigation.
In terms of the create survey example such tools should display the relations between the three languages by using the soft references as navigation points.
In the previous example, an ideal editor should for instance be able to suggest the createSurvey service as a valid value when the developer edits the target attribute in the Form definition.
An environment which could reason about artifacts from different languages would also be able to help the developer identify program states where there was local but not global consistency.
Guidance or intelligent assistance in the form of proposals on how to complete a model would be useful for setups with multiple languages and complex consistency constraints.
This schema is the metamodel of the Entity DSL and it specifies how elements can be composed and what are, to some extent, the valid domains of attributes.
This partly a matter of making sure that soft references between models and code are not broken, similar to referential integrity in model-to-model consistency.
More generally, we can state that multi-level customization imposes very fine-grained constraints on the involved models and code snippets.
Such overlaps are frequent when the expressiveness of general-purpose languages is needed to implement specialized requirements that are beyond the scope of the model.
Second, the consistency relations are used to navigate, visualize and map the web of different languages in a development setup.
Several papers introduce the different steps of the coordination method, report on this evaluation, and elaborates on the technical aspects of each individual experiment.
Overall, the results have been promising: a significant number of errors have been found in production systems and given rise to a constructive dialog with developers on future tool requirements.
A development process based on these guidelines and supported by tools constitutes a serious attempt to solve the coordination problem and make domain-specific multimodeling a practical proposition.