4th International Conference on Principles and Practices ... - MADOC

associations, which may result in references containing a null
value, and the fact that not all information is aggregated and
organized in a way suitable for the generation process.
After the initial processing of the models has been performed,
domain-specific transformations of the static and dynamic models
are carried out, leading to a modified generator model M’. In the
case of the static models this means that additional domainspecific
attributes are woven into the model. The transformation is
controlled via an XML definition of the attributes that are
supposed to be added to classes of a particular metaclass. For
example, all classes of type Article receive a new attribute called
Approved, which is used for the review process.
Additionally, in this processing step patterns are resolved, i.e., the
state-substate pattern in the dynamic model (see section 3.3). The
transformations required for this step are also defined in XML,
and offer options such as the introduction of new states to a
dynamic model and the rerouting of transitions to incorporate
these new states.
The final step in the generation process is the actual model-tocode
transformation performed by the Velocity template engine
(represented by the last arrow in Figure 3). For each node in the
static models a set of templates is invoked according to an XML
mapping associating metaclass names with output templates. A
reference to this node is then passed to each of the invoked
templates, which query the node object for its relevant properties
such as name, attributes and associations with other nodes. For
example, information about attributes provides the basis for
attributes and/or getter and setter methods in a Java source file.
It is important to note that each input node from M’ can result in
any number of output resources, e.g., a node with the metaclass
DataSet can be transformed into an EJB bean class and the
various interfaces required. Conversely, a single output resource
can also be generated from the extent of all classes instantiating
the same metaclass, i.e., the XML deployment descriptor in an
EJB environment.
Static nodes that are associated with dynamic models are subject
to further processing. The generator applies the state pattern (cf.
[14], [15]) to create the implementation of a state machine for
every dynamic model.
All these artifacts are written to a prepared skeleton eclipse
project that contains required libraries and a build script that
creates a deployable, ready-to-run binary file of the modeled
system.
While the process described above uses established code
generation techniques, it allows for accessing the metainformation
provided by the hierarchy. For example, domain-specific
attributes and methods can be woven into classes based on their
metaclasses. The separation of templates for the different layers
(i.e., technical and business) has been implemented using basic
model-to-model transformations and facilitates the rapid creation
of additional business domain templates.
6. JAVA-SPECIFIC CODE GENERATION
PROBLEMS
In the previous section we have provided an overview of the code
generation process. In this section we will discuss some selected
issues we have experienced during the implementation and
evaluation of the code generation plugin.
For the purpose of evaluation we have created several examples
targeted at J2EE/EJB2.x compliant application servers. This
choice was made due to the multitude of services provided by a
J2EE environment, such as persistence, transaction management,
declarative, role-based security, etc. that were needed for the
realization of the examples.
J2EE as a target platform has generally proven beneficial;
however, some inherent characteristics of the platform
complicated the development of the source code templates. The
amount of classes and interfaces required to implement an EJB
entity bean for example has been somewhat hindering during the
initial creation of the source code templates, due to the fact that
even simple changes required adapting various templates. We
expect this situation to improve by adopting the Java Persistence
API that simplifies the development of persistence-capable,
transaction-safe classes.
Initial proof-of-concept implementations of our examples were
closely tied to the EJB technology, because they were focused on
demonstrating the applicability of our own Web framework
COBANA rather than on efficient implementation. The basis for
using alternative technologies, such as Hibernate, was created by
refactoring our reference implementation, separating EJB-specific
from other system aspects by introducing patterns such as
Business Delegate or Data Transfer Object (cf. [16]).
In section 3.3 the notion of the explicit metastate was introduced
as a state containing entry code supplied by the modeler for
situations where none of the implicit metastates contained in the
hierarchy is applicable. As the modeler is relatively free as to what
kind of code to insert, the problem of gracefully handling
potential exceptions arises. Due to the lack of a Java metamodel in
the Velocity template engine, it is not possible to wrap critical
parts of the code with the required specific exception handling
code. The only way to ensure the correctness of the generated
code is to wrap all modeler-defined entry code passages with
generic exception handling. This situation was improved by the
definition of technology-independent but meaningful exception
types, i.e. for exceptions occurring during data access.
For the access control example described in section 4.3 the use of
declarative servlet security mechanisms was planned. In order to
be able to specify access restrictions for URL patterns, the passing
of View names (cf. section 4.1) via query strings was replaced by
a mechanism based on URL rewriting, a mechanism that enables a
Web server to programmatically manipulate the URLs of
incoming requests. In our case it allows for the representation of
query strings in an URL-like fashion, e.g.,
http://localhost/ControllerView=Library can be expressed as
http://localhost/Controller/Library. As URL patterns in the
servlet specification are not supposed to be specified via regular
expressions, all possible combinations of Views and ChildViews
have to be declared in the security configuration.
On a more general level, the lack of an equivalent for UML-style
bidirectional associations in the Java programming language
requires representation as two unidirectional references causing
some overhead and loss of semantics.
222