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

Therefore, in Figure 6, all views have an Access attribute, which is
used to store, which roles are allowed to access that particular
view. In Figure 10, LibraryView and AdminView make use of the
Access attribute to provide access information. For example,
LibraryView may only be accessed by those who have either the
role Subscriber or the role Admin, because only these roles are
specified as string values in the Access attribute.
The role of a user is stored in the session information. Instances of
the metaelement SessionInfo represent an access point to all
elements containing session data. For this purpose, at the
technical level, a reference to zero or more DataSets is allowed. If
any of these is an SDataSet, the SecurityRoles associated with it
are available to the user whose SessionInfo contains the SDataSet.
In our example model (Figure 10), the only SDataSet associated
with the SessionInfo instance is User. It contains two attributes
that are instance of Role: IsSubscriber and IsAdmin. If the value
of either of these is true, that user belongs to the respective group.
As you can see, a subscriber would be able to access the
LibraryView but not the AdminView.
5. CODE GENERATION PROCESS
So far we have described the basic principles of the OMEGA
approach and the metamodel hierarchies used to illustrate it. In
this section we will provide an overview of the architecture of the
code generator.
The code generator backend is intended to perform a
transformation of a set of static and dynamic OMEGA models into
the resources constituting the modeled system, such as source
code files and deployment descriptors. In comparison with open
source tools for model-to-code transformation, such as
OpenArchitectureWare 4 or AndroMDA 5 , the OMEGA generator
is able to leverage the advantages provided by the hierarchical
nature of the underlying metamodels. For our implementation we
have chosen a template-based model-to-code approach (cf. [13]).
The generator uses source code templates that contain the target
text and code to access the input models, therefore the templates
closely resemble the target source code. Errors in the output of the
generator can easily be traced back and be fixed at the template
level. Additionally, due to the similarity between source code
templates and the output in the target language, templates can be
Figure 9 - The Dynamic Business Metamodel (Excerpt)
derived from a reference implementation, a prototypical example
representing all relevant architectural aspects of a target system
(cf. [13]).
The template engine that has been used in the implementation,
Apache Velocity, provides an untyped, interpreted language that
contains basic control structures and the means to access Java
objects but lacks advanced language features such as exception
handling.
An overview of the steps of the code generation process is shown
in Figure 3. In the OMEGA editor plugin, UML-compatible input
models are designed by the modeler (see upper left corner). These
class and statechart diagrams are passed to the code generation
plugin.
As a first step, these models are transformed into the generator
model, which has a format more suited to a template-based code
generator (as shown in the upper right corner). Problematic
aspects of the source model include the non-existence of optional
4 http://www.openarchitectureware.org
Figure 10 - Actual Static Model
5 http://www.andromda.org
221