Elaborationist versus Translationist Approach

There are two interpretations of the MDA vision termed elaborationist and translationist approaches [McNeile03]. Following the elaborationist approach, the specification of the application is built up step by step by alternating automatic generation and manual elabora-tion steps on the way from PIM to PSM to code [Kleppe03]. For instance, a tool automati-cally transforms the PIM to a skeleton PSM, which then has to be elaborated by the devel-oper by customizing the generated models and by adding missing details. The apparent problem of this approach is that the lower level models can get out of step with the higher level models by the elaboration activity. Some tools support the regeneration of the higher level models from the lower level models, also called reengineering. The process of full synchronization of the higher level models with the lower level models in both directions is called round-trip engineering. Today, most approaches based on MDA are elaborationist approaches, which have to deal with the problem of model and/or code synchronization.

The elaborationist approach could also be seen as a semi-automatization of the familiar object-oriented development approach following analysis, design and implementation steps.

In the translationist approach, the transformations from PIM to PSM and then further to code are fully automatic, i.e. PSMs and code do not have to and must not be elaborated by

the developer. This avoids synchronization problems between higher level models and lower level models. When the PIMs are modified then the PSMs are just regenerated from the PIMs and the code is regenerated from the PSMs. On the other hand, usually the infor-mation captured by the PIMs is not sufficient for executing the transforinfor-mations to the lower level models fully automatically. Thus, additional information, i.e. additional mod-els, is needed as input for the transformations. The translationist approach originates from works on real-time and embedded systems with special emphasis on modeling executable behavior by UML state machines and activities. For more information see [Mellor02].

On the one hand, the approach presented in this work follows the elaborationist approach for the stepwise construction of the platform independent design models of a Web applica-tion (see Chapter 4). On the other hand, it follows “primarily” (see next paragraph) the translationist approach because the platform independent design models are automatically transformed to platform specific models, which are then automatically serialized to code (see Chapter 5). These platform specific models and the generated code must not be modi-fied by the developer because roundtrip-engineering is neither necessary nor allowed.

Thus, this approach is in line with the objective of the MDA to decouple the technology that an application runs on from the definition of the application.

For traditional non-Web applications a translationist approach would comprise computa-tionally complete models of behavior and the transformation of these models to executable code. Web applications on the other hand are not monolithic applications and they mostly build on software components, for instance a software component providing services for a banking application. Some of these components may already exist and they just have to be integrated in the Web application, thus they do not have to be implemented by the devel-oper. The appropriate term for behavior in this context is service with Web Services being a technology for the implementation of services [W3C02]. This approach focuses on the modeling and transformation of “coarse grained” behavior with so-called process models, see 4.5. Such a process model comprises the composition of “fine grained” behavior by means of UML activities. Fine grained behavior is represented by UML operations which correspond to services. Thus, an operation call corresponds to a service call, for instance the invocation of a Web Service. Process models are transformed to fully executable code, which comprises the invocation and composition of services. Services themselves are not generated by this approach, but implementation skeletons can be generated. Therefore, this approach may be considered as being only “primarily” translationist. This concept for be-havior of Web applications fits in the Service Oriented Architecture (SOA) approach [Dos-tal05] because the basic idea of the SOA approach is to see the realization of a business process as a composition of services. Hence, the application logic of a system is distributed over several independent and loosely coupled services. These services are provided by

ser-Model Driven Software Engineering for Web Applications

vice providers and used by service consumers and to find a service some kind of directory service is necessary. An extension of this approach to additionally include the modeling and transformation of fine grained behavior is an interesting future research topic, see also the conclusions chapter.

On the other hand the automatic transformation to the platform specific implementation models is preceded by the construction of the platform independent design models. The iterative, systematic and stepwise construction of the design models is a key feature of the UWE methodology. The core modeling activities are the requirements analysis, content, navigation, process and presentation design. One contribution of this work to the UWE ap-proach is the automatization of these construction steps with transformations as presented in Chapter 4. These transformations are executed only on the platform independent level and after each transformation follows a manual refinement (i.e. elaboration) step by the developer. As a result of each transformation step a default model is generated, for instance from the content model a default navigation model is generated. These default models are already complete in the sense that the next transformation step could be applied. The only exception is the transition from the analysis model to the design models. All features of classes in the content model and the process model have to be completed manually as the analysis model lacks the necessary details.

Theoretically, it would be possible, following the MDA pattern, to replace a transformation step within the platform independent models followed by a manual refinement step, with a single transformation step that injects the additional information from the manual refine-ment step from an additional model. Practically, the complexity to define the correspond-ing metamodels for such additional models that reflect changes to extended UML models and for enabling the developer to maintain these models would be too high. Instead, the approach of this work faces the maintenance and change management challenges imposed by the semi-automatic construction of the design models by two measures. First, incre-mental updates are taken into consideration in the transformation design allowing the reap-plication of transformations without loss of manually added information by the developer, see 4.1.2. Explicit trace models are used to capture the transformation history. Second, OCL constraints for each design model ensure the consistency of modifications carried out manually by the developer.

57