Ph.D. Dissertation A Template-Based Model Transformation...
Transcript of Ph.D. Dissertation A Template-Based Model Transformation...
Ph.D. Dissertation
A Template-Based Model Transformation Approach
Using A Simplified Hierarchical Metamodel
by
Hongming Liu
College of Computing and Digital Media
DePaul University
Advisor: Xiaoping Jia
Committee members:
Jane Huang
Jami Montgomery
Adam Steele
Konstantin Laufer
ACKNOWLEDGEMENTS
Undertaking this research has been a great learning experience. First and foremost, I’d like
to thank my advisor, Xiaoping Jia, for his continuous support and guidance, for providing
a very flexible working environment, and of course for his insight and dedication in this
research project.
I am also greatly indebted to my committee members. I thank each of them for their
extensive reviews and comments, and for making the time to be part of the committee in
the first place: Jane Huang , Jami Montgomery, Adam Steele and Konstantin Laufer.
I appreciate the help of Lizhang Qin, Christopher Jones and Howard Dittmer. And thank
them for their collaboration in the project and their support.
Last but not least, I want to thank my wife Pinqi Tan for her unconditional support
and encouragement. I also thank my parents in China who lost the opportunity of higher
education but have always instilled the loss as inspiration in me.
Contents
1 Introduction 3
1.1 Problem Statement . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3
1.2 Approach . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5
1.3 Summary of Contributions . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5
1.4 Outline of the Dissertation . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6
2 Background 8
2.1 Software Engineering and Software Development Process . . . . . . . . . . . 8
2.2 Model Driven Engineering . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9
2.2.1 Model . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10
2.2.2 Metamodeling . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12
2.2.3 Model Transformation . . . . . . . . . . . . . . . . . . . . . . . . . . 13
2.3 Model Driven Architecture . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15
2.3.1 UML . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15
2.3.2 XMI . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17
2.3.3 MOF . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19
3 ZOOM Architecture and Notation 22
3.1 ZOOM Architecture . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22
3.2 Modeling with ZOOM Notation . . . . . . . . . . . . . . . . . . . . . . . . . 25
3.2.1 Structural Models . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25
3.2.2 Behavioral Models . . . . . . . . . . . . . . . . . . . . . . . . . . . . 26
i
3.2.3 User-Interface Models . . . . . . . . . . . . . . . . . . . . . . . . . . 27
4 HRMT Model Transformation Approach 28
4.1 Source Model Representation . . . . . . . . . . . . . . . . . . . . . . . . . . 30
4.1.1 Hierachical Relational Metamodel . . . . . . . . . . . . . . . . . . . . 31
4.1.2 HRM Definition . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 32
4.1.3 Path Expression Language in HRM . . . . . . . . . . . . . . . . . . . 34
4.2 Transformation Template . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 34
4.3 Transformation Algorithm . . . . . . . . . . . . . . . . . . . . . . . . . . . . 37
4.4 Model Transformation Process . . . . . . . . . . . . . . . . . . . . . . . . . . 39
4.4.1 Parsing the source model . . . . . . . . . . . . . . . . . . . . . . . . . 40
4.4.2 Traversing the object tree . . . . . . . . . . . . . . . . . . . . . . . . 41
4.4.3 Matching node in object tree with rule . . . . . . . . . . . . . . . . . 43
4.4.4 Generating target text . . . . . . . . . . . . . . . . . . . . . . . . . . 44
4.4.5 Post processing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 47
5 The HRMT Tool Suite 49
5.1 HRMT Architecture . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 49
5.2 HRMT Main Components . . . . . . . . . . . . . . . . . . . . . . . . . . . . 52
5.3 Use of HRMT Tool Suite . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 54
6 Development of Transformation 55
6.1 Basic Classes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 55
6.2 Classes with Associations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 57
ii
6.3 EJB Entities . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 59
6.4 Comprehensive EJB Applications . . . . . . . . . . . . . . . . . . . . . . . . 60
7 Case Study: A Hospital Information Management System 64
7.1 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 64
7.2 Requirement of HIMS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 64
7.2.1 Scope of HIMS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 64
7.2.2 Functionality Requirements . . . . . . . . . . . . . . . . . . . . . . . 65
7.2.3 Non-Functional Requirements . . . . . . . . . . . . . . . . . . . . . . 66
7.2.4 External Interface Requirements . . . . . . . . . . . . . . . . . . . . . 67
7.3 Modeling and Transformation of HIMS . . . . . . . . . . . . . . . . . . . . . 67
7.4 Features Illustrated by Case Study . . . . . . . . . . . . . . . . . . . . . . . 68
7.4.1 Multi-platform support . . . . . . . . . . . . . . . . . . . . . . . . . . 68
7.4.2 Security requirement support . . . . . . . . . . . . . . . . . . . . . . 69
7.4.3 Scalability requirement support . . . . . . . . . . . . . . . . . . . . . 70
7.4.4 Performance requirement support . . . . . . . . . . . . . . . . . . . . 72
8 Related Work 74
8.1 Direct-Manipulation Approach . . . . . . . . . . . . . . . . . . . . . . . . . . 74
8.2 Transformation using XSLT . . . . . . . . . . . . . . . . . . . . . . . . . . . 75
8.3 Template-Based Approaches . . . . . . . . . . . . . . . . . . . . . . . . . . . 77
8.4 QVT(Queries/Views/Transformations) . . . . . . . . . . . . . . . . . . . . . 78
9 Evaluation of Transformation Tools 81
iii
9.1 Transformation Tools Being Evaluated . . . . . . . . . . . . . . . . . . . . . 89
9.1.1 Direct-Manipulation Approaches: Jamda . . . . . . . . . . . . . . . . 89
9.1.2 Transformation using XSLT: Stylus Studio . . . . . . . . . . . . . . . 91
9.1.3 Template-Based Approaches: AndroMDA . . . . . . . . . . . . . . . 93
9.1.4 QVT(Queries/Views/Transformations): ATL . . . . . . . . . . . . . . 97
9.2 Evaluation Result . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 100
9.2.1 Evaluation Result Reflecting Metamodel Complicity . . . . . . . . . . 101
9.2.2 Evaluation Result Reflecting Transformation Complicity . . . . . . . 103
10 Conclusion 109
10.1 Contributions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 109
10.2 Future Work . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 111
A Development of Transformation 130
A.1 Generation of Basic Classes . . . . . . . . . . . . . . . . . . . . . . . . . . . 130
A.2 Generation of Classes with Associations . . . . . . . . . . . . . . . . . . . . . 140
A.3 Generation of EJB Entities . . . . . . . . . . . . . . . . . . . . . . . . . . . . 150
A.4 Generation of Comprehensive EJB Applications . . . . . . . . . . . . . . . . 158
B ZOOM Model for Hospital Information Management System 177
C Screenshots of Hospital Information Management System 180
iv
List of Figures
1 An Example of MDE Transformation . . . . . . . . . . . . . . . . . . . . . . 13
2 ZOOM Architecture . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 24
3 HRMT Model Transformation Overview . . . . . . . . . . . . . . . . . . . . 29
4 HRMT Model Transformation Process Overview. . . . . . . . . . . . . . . . 30
5 HRM Example of a Class Diagram . . . . . . . . . . . . . . . . . . . . . . . 33
6 Graphic representation of HRM-Based Transformation Algorithm . . . . . . 38
7 Graphical Representation of PIM . . . . . . . . . . . . . . . . . . . . . . . . 41
8 Abstract Syntax of PIM . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 42
9 Model Transformation in details. . . . . . . . . . . . . . . . . . . . . . . . . 43
10 Matching metamodel node and generating target text with rule . . . . . . . 44
11 Expression Mapping in details. . . . . . . . . . . . . . . . . . . . . . . . . . . 45
12 HRMT Architecture . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 50
13 ZOOM Graphical Representation of Hospital Information Management System 68
14 Model Transformation Process Comparison . . . . . . . . . . . . . . . . . . . 95
15 ATL Approach . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 99
16 Evaluation Result of Source Model . . . . . . . . . . . . . . . . . . . . . . . 102
17 Evaluation Result of Template . . . . . . . . . . . . . . . . . . . . . . . . . . 105
18 HIMS Main Page ASP.NET version . . . . . . . . . . . . . . . . . . . . . . . 180
19 HIMS Main Page JSP version . . . . . . . . . . . . . . . . . . . . . . . . . . 181
20 HIMS View Medical Data ASP.NET version . . . . . . . . . . . . . . . . . . 182
21 HIMS View Medical Data JSP version . . . . . . . . . . . . . . . . . . . . . 183
v
List of Tables
1 XMI Compatibility Test Result . . . . . . . . . . . . . . . . . . . . . . . . . 19
2 HRM Components . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 33
3 Examples of PEL Expressions . . . . . . . . . . . . . . . . . . . . . . . . . . 34
4 Explanation of code fragment names . . . . . . . . . . . . . . . . . . . . . . 36
5 Example of Expression Mapping . . . . . . . . . . . . . . . . . . . . . . . . . 46
6 Explanation of code fragment names . . . . . . . . . . . . . . . . . . . . . . 56
7 Explanation of code fragment names . . . . . . . . . . . . . . . . . . . . . . 56
8 Explanation of code fragment names . . . . . . . . . . . . . . . . . . . . . . 59
9 Explanation of code fragment names . . . . . . . . . . . . . . . . . . . . . . 60
10 Explanation of code fragment names . . . . . . . . . . . . . . . . . . . . . . 61
11 Explanation of code fragment names . . . . . . . . . . . . . . . . . . . . . . 62
12 Example of ZOOM Annotation . . . . . . . . . . . . . . . . . . . . . . . . . 70
13 Explanation of Metric Factor . . . . . . . . . . . . . . . . . . . . . . . . . . 82
14 Evaluation Result of Source Model . . . . . . . . . . . . . . . . . . . . . . . 101
15 Evaluation Result of Template . . . . . . . . . . . . . . . . . . . . . . . . . . 104
16 Evaluatin Result of Transformation Tools . . . . . . . . . . . . . . . . . . . . 107
vi
ABSTRACT
Model-Driven Engineering(MDE) is a model-centric software engineering approach which
aims at improving the quality of and facilitating the development of software artifacts by
focusing on the design models instead of code. Its vision is to build an abstract model of
a system that we can then transform into more refined models and eventually transform
into the system implementation. Although some variants of MDE, especially Model-Driven
Architecture(MDA), are already quite advanced and serve as the conceptual foundation for
commercial software products, there are many challenges to achieving true Model-Driven
Engineering.
Two major challenges that researchers face when attempting to realize the MDE vision
are 1)providing precise, analyzable, transformable, and executable models and 2) provid-
ing well-defined transformations that support rigorous model evolution, refinement, and
code generation. Both of these challenges point to a mutual research topic: metamodeling.
Metamodeling is the key technology that ensures precise, analyzable models, which is the
basis for the transformation definition. Considering these challenges and their connection
to metamodeling, we provide a solution that uses a simplified metamodel as the foundation
for building a template-based model transformation framework. This simplified metamodel
is called the Hierarchical Relational Metamodel(HRM). The Hierarchical Relational Meta-
model is built upon Z-based Object-Oriented Modeling notation (ZOOM). HRM maintains
both a tree structure and the relationships among model elements. The model elements and
the tree structure are constructs of the ZOOM modeling language comparable to constructs
of a programming language. To capture more complicated modeling language constructs like
association, we adopt a mathematical collection to depict the relationships among different
1
constructs.
The design of the Hierarchical Relational Metamodel (HRM) provides us a simplified way
to understand and make use of the abstract syntax and semantics of the source models. On
top of the HRM, we design a template-based model transformation framework. The trans-
formation framework provides a simplified way of getting information from the metamodel,
makes the template definition more readable, and allows different sets of templates to be
provided for model transformation between different target technical platforms.
A transformation tool, the Hierarchical Relational Metamodel Transformation tool(HRMT)
that implements this design is developed. Its major components are discussed in this thesis.
To demonstrate the ability of this tool, a case study is presented to show how HRMT can
transform ZOOM model specifications to applications running on multi-platforms and to
show HRMs support of non-functional requirements.
This thesis also provides a detailed study of some of the related work. A group of essential
metrics is identified to evaluate different transformation tools. The result of the evaluation
supports our argument that HRMT provides a simple, effective way to define model trans-
formations and the benefits of this model transformation framework include readability of
metamodel definitions and transformation definition.
In summary, we provide a model transformation approach that supports MDE using a sim-
plified hierarchical metamodel. The benefits of this model transformation approach include
1) readability and rigorousness of metamodel definitions; 2) simplicity of transformation
definitions; and 3) support of non-functional requirements.
2
1 Introduction
Model-Driven Engineering (MDE) tackles the problem of system development by promot-
ing the use of models as the primary artifact to be constructed and maintained [1,2]. MDE
shifts software development from a code-centric activity to a model-centric activity. Ac-
complishing this shift entails developing support for modeling concepts at different levels of
abstraction and then transforming abstract models to more concrete descriptions of software.
In other words, MDE reduces complexity in software development through modularity and
abstraction [3].
Because of MDE’s potential to dramatically change the way we develop applications,
companies are already working to deliver supporting technologies [4, 5]. Although some
variants of MDE, especially Model-Driven Architecture(MDA), are already quite advanced
and serve as the conceptual foundation for commercial software products, there are many
challenges to achieving true Model-Driven Engineering.
1.1 Problem Statement
The major challenges that researchers face when attempting to realize the MDE vision
were discussed in [6]. According to many research projects that point out the inadequacy in
MDE development [7–9], there are two main challenges that MDE infrastructure faces:
• Providing precise, analyzable, transformable and executable models [6].
• Providing well-defined transformations that support rigorous model evolution, refine-
ment, and code generation [7].
3
The first challenge is currently addressed specifically yet inadequately by the Object Man-
agement Group’s(OMG) UML [10] standard specification. UML-2, with its current version
UML 2.2, is the de facto standard object modeling notation for software engineering. It
allows modelers to capture a wealth of information about software system components, their
behaviors, and their interactions. However, currently UML-2 is insufficient for MDE ow-
ing to its deficiencies in several critical areas including incompleteness, semi-formalness and
inconsistency [11,12].
The second challenge, model transformation that support rigorous model evolution, refine-
ment, and code generation is also an active research area [13, 14]. There are many research
projects that provide fundamentals for model transformation. Model transformation is the
process of converting one model into another model. Performing a model transformation
requires a clear understanding of the syntax and semantics of both the source and target
models. To take modeling to a higher level of abstraction, it is necessary to have a standard
mechanism to define metamodels of modeling languages [15]. OMG addresses this issue in
its MDE initiative Model Driven Architecture(MDA) [16, 17] by creating Model Object Fa-
cility(MOF) [18]. In response to the need for a standard approach to defining the functions
that map between metamodels, the OMG issued the MOF 2.0 Query/View/Transformation
(QVT) [19–21] Request for Proposals. Several replies were provided by a number of compa-
nies and research institutions that evolved over three years to produce a common proposal
that was submitted and approved [21–23].
4
1.2 Approach
Both of the challenges mentioned above point to a mutual research topic: metamodeling.
Metamodeling is the key technology that ensures precise, analyzable models, and it is the very
element of metamodeling that is the basis for transformation definition. Considering these
challenges and their connection to metamodeling, we provide a solution that uses a simplified
metamodel as the foundation for building a template-based model transformation framework.
This simplified metamodel is called the Hierarchical Relational Metamodel(HRM). The Hi-
erarchical Relational Metamodel is built upon Z-based Object-Oriented Modeling notation
(ZOOM). HRM maintains both a tree structure and the relationships among model elements.
The model elements and the tree structure are constructs of the ZOOM modeling language
comparable to constructs of a programming language. To capture more complicated mod-
eling language constructs like association, we adopt a mathematical collection to depict the
relationships among different constructs.
In summary, our objective is to apply such an overall research approach in realization
of MDE focusing on model transformation. The notation and metamodel design lays the
foundation of our tool development. And the development of the Hierarchical Relational
Metamodel Transformation tool(HRMT) in turn demonstrates the validity and advantage
of the design.
1.3 Summary of Contributions
This dissertation provides a solution that uses a simplified metamodel as the foundation
to build a template based model transformation framework. This simplified metamodel is
5
called Hierarchical Relational Metamodel(HRM). The Hierarchical Relational Metamodel is
built upon Z-based Object-Oriented Modeling notation (ZOOM). A template based model
transformation framework using the Hierarchical Relational Metamodel (HRM) is intro-
duced. This framework aims to provide a simple, effective, and practical way to define
model transformations. The benefits of this transformation framework include 1) readability
and rigorousness of metamodel definitions; 2) simplicity of transformation definition; and
3) support of non-functional requirements. A case study is provided to demonstrate the
feasibility of the approach, and comparisons with related research work are provided to show
the benefits of this framework.
The main contribution of our research project is the design and realization of such a model
transformation framework. It fulfills the goal of transforming PIM to PSMs for different
platforms. However, many research projects and commercial tools can claim the same thing.
Our approach is distinguished from others by its simplicity of source modeling language,
readability of transformation definition and simplicity of metamodel definitions. It also
provides support of non-functional requirements.
1.4 Outline of the Dissertation
This dissertation is organized as follows: Chapter 2 provides detailed background infor-
mation about model-driven engineering and model transformation. Chapter 3 presents the
ZOOM architecture and notation. Then Chapter 4 covers the characteristics of our model
transformation approach and elaborates on the model transformation process. Chapter 5
introduces the HRMT tool and its main components. In Chapter 6, several scenarios of
transformation development are presented. Chapter 7 discusses a case study that demon-
6
strates our approach. Chapter 8 categorizes some of the related work to our research. Chap-
ter 9 reviews the evaluation result of comparing our tool with others. Finally, Chapter 10
concludes the dissertation and summarizes the main contribution of our research work.
7
2 Background
2.1 Software Engineering and Software Development Process
Software Engineering, as defined in IEEE Standard 610.12, is “The application of a sys-
tematic, disciplined, quantifiable approach to the development, operation, and maintenance
of software; that is, the application of engineering to software”. Software engineering is an
engineering discipline which is concerned with all aspects of software production from the
early stages of system specification through to maintaining the system after it has gone into
use [24,25]. It is the branch of systems engineering concerned with the development of large
and complex software intensive systems. It focuses on: the real-world goals for, services
provided by, and constraints on such systems; the precise specification of system structure
and behavior, and the implementation of these specifications; the activities required in or-
der to develop an assurance that the specifications and real-world goals have been met; the
evolution of such systems over time and across system families. It is also concerned with
the processes, methods and tools for the development of software intensive systems in an
economic and timely manner [26,27].
A traditional theme in software engineering discourse has been “why can’t we develop
software like other engineers build bridges”. Software development is often compared with
hardware development in terms of maturity and the progress in software development seems
to be minimal [28]. However, the fact that it is feasible to build much more complex and
larger systems today should have undermined this false sense of inferiority. As a result of
academic and industrial research and experience in object-oriented design methods [29–31],
formal methods etc, there have been significant improvements in the ways in which software
8
are built over the last fifty years [32–34].
Still software development is an area in which we are struggling with a number of problems.
Writing software is labor intensive. With each new technology, much work needs to be done
again and again. Systems are never built using only one technology and systems always
need to communicate with other system. There is also the problem of continuously changing
requirements. The most important problems with software development include productivity,
portability, interoperability and maintenance problem [35–37].
2.2 Model Driven Engineering
The term Model Driven Engineering(MDE) was first proposed by Kent in [1]. MDE tackles
the elusive problem of system development by promoting the usage of models as the primary
artifact to be constructed and maintained. It aims for integration of software engineering
phases such that the development of a system from the first abstract design to the finished
product is a continuum with no gaps in between. Model driven engineering automates
transformations between different models by using formal models of the software system and
well-defined mappings (both horizontal and vertical) between different models [13, 38].
Within the context of MDE, a model of the system is not just a drawing in some design
document anymore but a set of formal concepts and elements [39]. A system may possess
many different models which conceptualize different aspects of the system at different levels
of abstraction. For example one model of the system may describe behavior of distinct com-
ponents as finite-state automata whereas another model may describe collaboration between
those components using a coordination model, such as shared tuple-spaces. In a traditional
software engineering process, mapping between design and implementation is done by ex-
9
ploiting the expert knowledge of a programmer. In model driven engineering this expert
knowledge is not lost in millions of lines of code but instead it is explicitly visible in trans-
formation functions. Refinement steps from the first high-level design models all the way to
the implementation are given as formal mappings between models [6, 40].
Model driven engineering can be exploited in all phases of the software design process [2,3].
Even very rough models can be used as an interface between customers and designers during
requirements analysis. During initial design and refinement phases, formal models can be
used to simulate, analyze or even automatically verify software designs. The ultimate goal of
MDE is the rapid development of robust software using reusable designs, or in other words,
the automatic generation of lower level models and complete implementation. Model driven
engineering tries also to achieve platform independent software solutions by using different
levels and views of models and modeling languages [41,42].
2.2.1 Model
Model driven engineering is a model-centric software engineering approach. In a MDE
system, a model is a consistent and complete set of formal elements describing a system that
is amenable to analysis [39]. For example, we could build a bank model, ignoring security
and user interface aspects, or we could model a combination of these domains. We choose
which subject matters to include and which to ignore, although we might then need to weave
several models together. When a model’s subject matter has a high degree of abstraction,
the model is closer to the eventual user’s language that is, a smaller gap exists between a
non computer expert and the model. A model is expressed in a language that exists at some
(language) abstraction level. A model written in the C modeling language will ignore (or
10
abstract away) the realization of function calls and expressions, leaving CPU-oriented issues
such as register allocation to the compiler or to a virtual machine interpreter that adds such
realizations at runtime. Similarly, a model expressed in the Unified Modeling Language will
ignore the realization of associations, leaving those decisions to the model compiler or human
designer [39].
Model driven engineering offers the potential for automatic transformation of high-level,
abstract application subject matter models into running systems. Researchers have pointed
that modeling technology has matured to the point where it can offer significant leverage in
all aspects of software development [43, 44]. In an increasing number of application areas,
you can generate much of the application code directly from models. Automation doesn’t
remove the requirement for creativity. Rather, it formalizes existing solutions and raises the
level at which we can apply creativity, thus giving the developer more leverage. To make
automation a reality, models must have a defined meaning, or in other words, be written in
a well defined language [45, 46]. A language consists of syntax and semantics. The syntax
can be human or machine centric. Semantics define what the syntax means by linking the
syntax to a semantic domain [47]. Model driven engineering automates the transformation of
models from one form to another. We express each model, both source and target, in some
language. The target models language, for example, might define a meaning for remote
access of objects, even though the source models language does not. We must clearly define
the two languages. Because modeling is an appropriate formalism to formalize knowledge, we
can define a modeling language’s syntax and semantics by building a model of the modeling
language - a so-called metamodel. We will cover more about metamodel in the following
section.
11
2.2.2 Metamodeling
As we stated above, a model in the context of MDE needs to be written in a well-defined
language. A well-defined language was defined as a language which is suitable for automated
interpretation by a computer. Metamodeling can help define a well-defined languag [48,49].
Languages are often defined using a grammar in Backus Naur Form(BNF), which describes
what series of tokens is a correct expression in a language [50]. This method is suitable and
heavily used for text-based languages, like programming languages. A BNF grammar could
be used to define modeling language. It does fulfill the requirement that it is suitable
for automated interpretation. Because modeling languages do not have to be text based,
and often aren’t (they can, for example, have a graphical syntax, like UML). A different
mechanism for defining languages in the MDE context will be needed. This mechanism is
called metamodeling.
Metamodel is defined in [39] as “ a specification model for a class of systems under study
where each system under study in the class is itself a valid model expressed in a certain mod-
eling language”. In other words, a metamodel describes the abstract syntax of a modeling
language as a class model. Each class in a metamodel describes a model element, i.e. a con-
cept or abstraction in our modeling language. Every kind of element that a modeler can use
in his or her model is defined by the metamodel of the language the modeler uses. Because
a metamodel is also a model, a metamodel itself must be written in a well-defined language.
This language is called a metalanguage. For example, BNF is a metalanguage. A metalan-
guage plays a different role than a modeling language in the MDE framework, because it
is a specialized language for describing modeling languages. Because a metalanguage is a
language itself, it can be defined by a metamodel written in another metalanguage. In theory
12
Relational PSM
EJB Component PSM
SQL Source Code
Java Source Code
Platform Independent Model (PIM)
.NET PSM
C# Source Code
Transformation: PIM -> Relational
Transformation: PIM -> EJB Component
Transformation: PIM -> .NET PSM
Transformation: Code Generation
Transformation: Code Generation
Transformation: Code Generation
Figure 1: An Example of MDE Transformation
there could be an infinite number of layers of model-language-metalanguage relationship [51].
2.2.3 Model Transformation
Model driven engineering moves development focus from third generation programming
language code to models [13,52]. The objective is to increase productivity and reduce time-
to-market by enabling development and using concepts closer to the problem domain at hand,
rather than those offered by programming languages. The key challenge here is to transform
these higher-level models to platform-specific models that tools can use to generate code.
Figure 1 shows the overall picture of MDE using an example. On the top is a Plat-
form Independent Model(PIM), which is transformed into three different Platform Specific
Model(PSM) in three different platforms: Relational Database, EJB and .NET [53–55]. In
MDE the focus of a developer shifts to the development of a PIM. The PSMs that are needed
are generated by transformation from PIM into multiple PSMs for different platforms. Ev-
erything specified at the PIM level is therefore completely portable. And the fact that PSM
can be transformed to code automatically greatly improves productivity.
13
For the model driven engineering vision to become a reality, tools must support model
transformation [55–57]. Development tools should let users not only apply predefined model
transformations but also define their own. Beyond automating transformation execution,
tools could suggest which model transformations a user might appropriately apply in a
given context [58]. Performing a model transformation requires a clear understanding of
the abstract syntax and semantics of both the source and target. As introduced in the last
section, metamodeling is a common technique for defining the abstract syntax of models and
the interrelationships between model elements. For visual modeling languages, there are a
number of advantages in basing a tool’s implementation on the languages metamodel [59].
Such tools offer users three different architectural approaches for defining transformations:
• Direct model manipulation: tools access an internal model representation and have the
ability to manipulate the representation using a set of procedural APIs. Jamda is an
examples of this approach [60].
• Intermediate representation: this approach exports the model in a standard form,
typically XML, so an external tool such as XSLT can transform it [61,62].
• Transformation language support: many tools use this approach and provide a template-
based or rule-based transformation language that provides a set of constructs for ex-
plicitly expressing, composing, and applying transformations [63–65]. This approach
is also what our transformation framework adopts.
14
2.3 Model Driven Architecture
Model Driven Architecture is an initiative by the Object Management Group to address
the issue of model driven engineering [66]. MDA is a new way of writing specifications and
developing applications, based on a platform independent model (PIM). A complete MDA
specification consists of a definitive platform independent base UML model, plus one or more
platform specific models (PSM) and interface definition sets, each describing how the base
model is implemented on a different middleware platform [67].
MDA development focuses first on the functionality and behavior of a distributed appli-
cation or system, undistorted by idiosyncrasies of the technology or technologies in which it
will be implemented. MDA separates implementation details from business functions. Thus,
it is not necessary to repeat the process of modeling an application or systems functionality
and behavior each time a new technology comes along. While other architectures are gener-
ally tied to a particular technology, MDA is trying to model functionality and behavior once
and only once. Mapping from a PIM through a PSM to the supported MDA platforms will
be implemented by tools, easing the task of supporting new or different technologies [68,69].
The approach I am proposing is parallel with MDA in many ways. However, the essential
difference is the underlying notation and metamodel design. In the following two sub sections,
we will look at MDA’s underlying notation UML and it’s metamodel MOF.
2.3.1 UML
In the last few years OMG’s Unified Modeling Language (UML) has emerged as the stan-
dard modeling notation of the software industry [29, 70]. UML is used in the development
process of various object-oriented and especially component-based systems. It provides the
15
software developer with the facility to specify, visualize and document large system models,
including the static application structure as well as dynamic behavior of the system. Addi-
tionally it allows describing the instantiation of objects and their distribution. Right now the
prominence of UML is still augmented by the OMG’s MDA standardization process, where
UML is utilized as a general purpose language for various domains on different abstraction
levels [71].
UML is a graphical notation that provides the software developer with twelve diagram
types, basically classified into three categories:
• Structural Diagrams represent static application structure (Class Diagram, Object
Diagram, Component Diagram, and Deployment Diagram)
• Behavior Diagrams describe aspects of dynamic behavior (Use Case Diagram, Sequence
Diagram, Activity Diagram, Collaboration Diagram, and State-chart Diagram)
• Model Managing Diagrams illustrate how to organize and manage your application
modules (Packages, Subsystems, and Models)
UML as a core standard of MDA enables the development of platform independent models
(PIM) as well as platform specific models (PSM). Naturally a software developer starts to
describe the business semantics of his application by building a PIM, which captures the
structure and behavior of the application but no technical aspects. Later on the PIM is
transformed by OMG-standardized mappings into a PSM for the desired platform. Normally
this transformation is accomplished by an MDA-enabled development tool. In a final step
the tool generates the source code from the information covered by the PSM.
16
In his keynote speech in Codegen conference 2008 [72], Bran Selic points out that the do-
mains are getting increasingly more specialized requiring increasing language specialization.
While UML 2 is designed as a family of modeling languages, it uses semantic variation points
to address this issue.
Fundamentally the flexibility and compensability of MDA is based on the generic usability
and methodology- independence of UML. Thereby programmers are able to exchange and
combine PIMs and PSMs developed with different tools on variable platforms. One can even
interchange UML models and above all their graphical information between different tools
by using XMI (XML Metadata Interchange, another OMG standard in progress) [73–75].
2.3.2 XMI
The Object Management Group (OMG), the same standard organization that maintains
the UML standards, proposes the use of XMI and XMI-DI [74] to enable model interchange.
One of the strong points of XMI is that it is based on XML [73]. XML has been suc-
cessfully used to support many document and model representation standards. XML is
well-documented, machine-independent and there exist plenty of tools supporting it. Thus,
XMI documents should be portable and easy to parse.
It is also important to remark what XMI is not. XMI cannot be used to define the structure
of a modeling language. This is the role of the Meta Object Facility (MOF) [76] standard,
which will be covered in the following subsection. Actually, XMI can be used to serialize any
MOF-based modeling language including, but not restricted to UML and MOF itself. The
fact that XMI is independent of a modeling language is at the same time one of its strong
points and major weaknesses. First, two tools that use two different versions of the UML
17
standard, for example UML 1.4 and UML 2.0 will not be able to exchange models even if
they use XMI. Also, a UML model serialized as a XMI document will not contain any extra
information that is not present in the UML model as such.
A study in [77] pointed out that one of the main impediments to use XMI in practice is
the large number of different versions of the XMI standards and UML metamodels. At the
moment of writing this text, there are five versions of XMI (1.0, 1.1, 1.2, 2.0 and 2.1) and
eight versions of UML (1.0 to 1.5 and 2.2). This means that a document containing a UML
model can actually be serialized in 40 different combinations of XMI and UML versions.
The diversity of different XMI implementations has already been studied in [78]. There,
Jiang devised a method to explore differences between XMI formats using DTDs. The fast
evolution of XMI and UML gives little room for implementors to try it out in practice.
In an article from the MODELS conference, Lundell et al. [79] tested XMI with 14 UML
tools. Obviously, the older tools cannot load from the newer tools, but can the newer tools
read models from the older tools? That’s the important question after all, if you want to
use XMI as insurance against your tool being discontinued: will this year’s tools load last
year’s models? The result is shown in Table 1, see the article for full details.
In this study, eight older tools are used for testing: ArgUML, Fujaba, Artisan, Poseidon,
Rhapsody, Rose 1.0, Rose 1.1 and Visio. They are listed in the first column of Table 1. XMI
files are exported from these tools. Five UML modelling tools were identified which support
XMI version 2.0 (or later): Borland Together Architect 2006 for Eclipse, EclipseUML Free
Edition, IBM Rational Software Architect 6.0, IBM Rational Software Architect 6.0 and
Altova UModel 2006. They are listed in the first row of Table 1. They will import XMI
files and the failed or successful results are recorded in the table. For example, the XMI
18
Table 1: XMI Compatibility Test Result
Import → Borland Eclipse Rational Magic Draw UModelExport ↓ArgoUML Failed Failed Failed Failed FailedFujaba Successful Failed Failed Failed FailedArtisan Failed Failed Failed Failed FailedPoseidon Failed Failed Failed Successful FailedRhapsody Failed Failed Failed Failed FailedRose 1.0 Failed Failed Failed Failed FailedRose 1.1 Failed Failed Failed Failed FailedVisio Failed Failed Failed Failed Failed
file exported by ArgoUML failed to be imported by Borland while the XMI file exported by
Fujaba was successfully imported by Borland.
The results show unsuccessful interchange for the majority of tool combinations. There
are only two successful cases out of all 40 combinations. This result very clearly exposes the
problem of XMI compatibility.
2.3.3 MOF
UML defines models, which have their own information, and they have meta-information
pertaining to them. Although UML defines its own metamodel for expressing its meta-
information, the OMG also has the Meta-Object Facility (MOF) as a meta-information
management standard, which evolved from needs of expressing metadata for CORBA in
platform independent ways [80]. Nowadays the MOF defines a generic framework for de-
scribing and representing meta-information [81].
The OMG MOF is designed for use in a wide variety of scenarios that have a significant
metadata component; e.g. type management, software development, information manage-
ment and data warehousing. MOF has contributed considerably to some of the core principles
19
of the MDA. Building on the modeling foundation established by UML, MOF introduced
the concept of formal metamodels and Platform Independent Models (PIM) of metadata
(examples include several standard such UML, CWM, EDOC, EAI etc.) as well as map-
pings from PIMs to Platform Specific Models (PSM) such MOF-to-IDL mapping in the MOF
specification or MOF-to-XML DTD mapping in the XMI specification [82–84].
The core of the MOF approach to meta-data management is openness. The goal is to
provide a framework that supports any kind of meta-data, and that allows new kinds to
be added as required. In order to achieve this, the MOF specification adopts a four-layer
metamodeling architecture:
• M0 What is to be modeled
• M1 Models (for example, a UML model)
• M2 Metamodels (for example, an abstract syntax model in the UML specification)
• M3 The meta-metamodel (MOF)
Layer M3 is a specification of the modeling language used to express metamodels in M2.
In OMG, this is always the MOF metamodeling language. This metamodeling language is
reflexively specified, so no higher layers are needed. When a modeling language’s metamodel
uses that same modeling language, the statements in the metamodel are expressed in the
same language the metamodel is describing. We call this a reflexive metamodel. This meta-
model circularity has raised some concern by researchers [85, 86]. To break the circularity,
definition ultimately must be provided in terms of more basic concepts, for example via a
formal mathematics semantics or an explicit set of axioms and deduction rules.
20
OMG also provides a generic concrete syntax called Human-Usable Textual Notation(HUTN)
[87] for MOF-based metamodels. HUNT defines a generic concrete syntax, which aims to
conform to human-usability criteria. However, as [75] pointed out that there were no current
reference implementation of HUTN: the Distributed Systems Technology Centres TokTok
project (an implementation of the HUTN specification) seems to be inactive (the source
code can no longer be found), whilst work on implementing the HUTN specification by
Muller and Hassenforder [88] has been abandoned in favor of Sintaks [89], which operates
upon domain-specific concrete syntax. Instead, metamodel developers use generation tools
to derive specific syntax parsers and editors. Among these approaches, Eclipse technologies
such as EMF [90] (and GMF [63]) can be used to generate tree-based (and graphical) model
editors. Baar [91] introduces a formalization of visual concrete syntax, and highlights its use-
fulness in analysis of correctness1. Text-to-model transformation tools such as TCS [92] and
TEF [93] can be used to define a custom concrete syntax for a metamodel and to generate
a corresponding parser.
21
3 ZOOM Architecture and Notation
Since our Hierarchical Relational Metamodel is built upon Z-based Object-Oriented Mod-
eling notation (ZOOM), it is necessary to introduce this notation and overall ZOOM archi-
tecture. The following sections present the architecture and main components of ZOOM. It
is also important for us to point out that although our HRMT approach is developed based
upon ZOOM, the idea of creating a simplified metamodel to facilitate model transformation
is independent of ZOOM. In other words, our HRMT can be implemented upon another no-
tation as long as we can build a hierarchical relational metamodel on top it. However, since
ZOOM is in fact the foundation of HRMT tool, we will limit the discussion of underlying
notation to ZOOM only.
3.1 ZOOM Architecture
While UML-2 is widely used as a visual modeling language to support MDE, it has sev-
eral weaknesses. UML-2 is not specifically designed for MDE, so its models are generally
informative without providing definitive views. Also, while UML-2 provides multiple visual
views to present similar aspects of a software design, it lacks an inherent mechanism to
enforce consistency between these views. Additionally, UML-2 lacks user and system inter-
face design notations. To overcome these obstacles, and to enhance the UML-2 models and
metamodel to include support for formal syntax and semantics and to provide a new UI
model, a new formal notation called ZOOM is developed in an earlier research project [94].
ZOOM stands for Z-based Object-Oriented Modeling. It is based on the formal specification
notation Z [95–99], which is in turn based upon set theory and mathematical logic. ZOOM
22
provides a human-readable syntax to specify the mathematical model in Z. A complete de-
scription of how ZOOM supports Z notation can be found in [94]. Although widely used
to specify software systems, one deficiency of Z is that its specification is limited to math-
ematical logic and does not provide useful mechanisms to support OO modeling such as
classes or inheritance. ZOOM extends Z to support these object-oriented concepts. Another
deficiency of Z (and the other Z-Based OO extensions) is the lack of visual notations for its
constructs and an absence of notations for specifying user interfaces. ZOOM provides visual
representations of models that are consistent with UML-2, and extends those notations to
support UI and formal action design.
Figure 2 shows the overall architecture of the ZOOM models for a software system. The
functional requirements derive the structural, behavioral and UI models. ZOOM provides
a pre-defined event model, which is processed by an event-driven framework, to bind the
structural, behavioral, and UI models together [100]. The integrated ZOOM model will be
processed by the Knowledge-based Model Compilation Tools resulting in different implemen-
tations of the software system based on the specific platform and knowledge base.
We partition the software design into three components: structural models, behavioral
models and UI models. The separation of a system into these three parts is an application of
the well-known paradigm in software engineering - Separation of Concerns, which formally
separates the system based on special purpose concerns [101]. This separation allows each
aspect of the system to be specified separately, making each aspect easier to write, under-
stand, and change with less impact on the other aspects. For example, under this separation,
modelers can modify the user interface based on device profiles and user preferences without
changing the structural or behavioral models. The other advantage of this separation is
23
Functional Requirements
Structural Model
Behavioral Model Derive
Derive
Derive
UI Model Device Profile
User Preference
Web Phone
Event - Driven Framework Knowledge - based Model Compilation
Tools Rules
Templates Model
Transformation And
Code Generation
UI Generation PDA
PC
Figure 2: ZOOM Architecture
that we can use different formal specification languages to describe different aspects of the
system. Using a specific language, which is developed and aimed at a specific need, makes
the modeling process more accurate and formal.
Each ZOOM model has dual representations including a textual specification and a visual
view. The visual representations are consistent with common UML-2 diagrams, such as class,
use case and state machine diagrams, but also include semantics and extensions. This enables
the use of popular tools to design and maintain ZOOM models. Modelers will appreciate
the ability to use available tools to construct their models and to add formal specifications
to those models. Unlike the models in UML-2, the ZOOM models are executable with its
execution semantics. All three components in ZOOM can be independently animated, and
the whole software system can be visually animated with the event-driven framework.
24
3.2 Modeling with ZOOM Notation
ZOOM modeling notations consist of three components: structural models, behavioral
models and UI models, each of which is discussed in detail in the following sections.
3.2.1 Structural Models
The structural model defines the functional part of the system using object-oriented con-
cepts. These models provide not only the class relations and hierarchies, but also a pre-
cise specification of the functionality of each entity. Structural models are specified by
using ZOOM-M language. Graphically, the visual modeling notations are consistent with
the UML-2 class diagram. Textually, the ZOOM-M syntax is consistent with many Java
language constructs. The main characteristics of ZOOM-M include formalism, the use of
object-oriented constructs, and side-effect free operations. ZOOM-M is strongly typed with
a semantically rich type system that supports inheritance and generic types [94]. ZOOM-M
includes a library that contains a collection of pre-defined structural models, including Set,
List, OrderedSet, Bag, Relation, Map, Pair, Tuple, etc. Through this library and the quanti-
fied iterator expression grammar, ZOOM-M is able to specify everything that Z can specify.
Syntactically, ZOOM-M provides many language constructs like attributes and operations,
which are similar to Java and C++ expressions. This makes the models easily understand-
able by industry developers. Additionally, ZOOM-M provides a concrete and precise syntax,
which extends OCL. ZOOM-M is as expressive as Z and OCL but with a friendlier syntax
and a much richer set of libraries [102,103].
Each ZOOM structural model is called a struct. Structs are the basic building blocks
in ZOOM-M. They are class-like entities, providing attributes and operations. Structs are
25
defined with formal specifications including class invariants and operation pre- and post-
conditions. These constraints are a key element of Betrand Meyers principle of design by
contract [104], which provides elements of the ZOOM foundation. The use of such constraints
can improve the quality of software documentation as well as its precision [105].
3.2.2 Behavioral Models
The behavioral model is the central communication mechanism that links the structural
models with the UI models. It uses an extended and formalized state machine diagram to
specify the dynamic aspects of a system.
In UML-2, there are five kinds of diagrams used to specify the different behavioral char-
acteristics of systems. Among these, State Machine diagrams and Activity diagrams are
widely used. Although these two views can be used to illustrate behaviors, they have their
own weakness when considering a fully automatic MDE approach. A state machine diagram
represents the lifecycle of an object, therefore it is good for specifying the control object,
but it lacks the ability to show the collaboration of multiple objects. An activity diagram
defines the behavioral logic of one activity based on data flow, but more closely resembles
low-level programming constructs rather than a high-level abstraction of the design.
Compare to UML-2 state diagram, ZOOM behavioral model has several improvements.
It introduces the variable declaration in state machine; an optional “extends” semantics
is introduced for state machine declaration; actions are defined using formal pre / post-
conditions, ZOOM-SM or activity diagram; It also provides a ”post” action, which is used
to fire new event to behavioral models; the parameter passing and naming mechanisms are
introduced in activity diagram; a formal event description language is defined. Formalized
26
state machine plus those improvements defines a formal and powerful behavioral modeling
notation.
3.2.3 User-Interface Models
Unlike UML-2 and OMGs MDA notations, ZOOM separates UI models from other aspects
[106]. This comes from the intrinsic characteristics of the UI aspect being separated from the
structural and behavioral aspects. This separation is useful even when we consider external
systems. In ZOOM, we consider all external systems as a special type of user. Those external
systems, for example, a database system, communicate with the designed software through
the same mechanism as the human users do. The UI typically has a tight coupling to a
specific platform while other aspects are typically platform-independent [107]. ZOOM uses
a specific visual UI modeling notation to achieve this separation of concerns rather than
mixing the UI design as part of programming. One advantage of this separation is that it
is easy to change a UI view by only changing the UI models, thus leaving other aspects
unchanged. This is especially important while developing multi-platform software systems.
Another advantage is that it is convenient for a modeler to model the software system from
the bottom-up. While a UI model is typically composed of several nested sub-UI models,
each of them can find the structural and behavior counterparts as a subset of the whole
structural and behavioral models. A second advantage of this separation of concerns is that
we overcome the difficulties of specifying the UI together with the structural model. In
its present form UML-2 fails to enforce this separation of concerns, trusting instead in the
capabilities of the modelers or the modeling tools.
27
4 HRMT Model Transformation Approach
The primary objective of our approach is to assist software development, from platform
independent models to platform dependent models and code, with a framework that pro-
vides a simple way to define transformations, mappings, and refinements. We accomplish
this by using ZOOM as a UML extension to define a platform independent model and a
transformation mechanism supporting model-to-model transformation.
The use of metamodeling techniques provides a way for transformation to understand and
make use of the abstract syntax and semantics of both the source and target models. This
allows the transformation to happen at the metamodel level. Figure 3 shows the overview
of our model transformation approach. It shows that the Transformation Template is de-
fined in M2, the metamodel level, while the Transformation Execution is implemented in
M1, the model level. Also shown in the diagram, the ZOOM Metamodel is defined by a
Hierarchical Relational Metamodel(HRM). Metamodeling is the key in this structure. First,
it provides a mechanism to define modeling languages such that they are unambiguously un-
derstood. A transformation tool can then read, write and understand the models. Second,
the transformation rules that constitute a transformation definition describe how a model in
a source language can be transformed into a model in a target language. With metamod-
eling, these rules use the metamodels of both the source and target languages to define the
transformation.
Our approach to model transformation is different from most of the existing MDE ap-
proaches that are based on MOF. We propose a simpler hierarchical meta modeling archi-
tecture than MOF. The key element in our model transformation is how transformations
28
Figure 3: HRMT Model Transformation Overview
can be specified at the metamodel level. The approach to specifying model transformations
involves specializing the Hierarchical Relational Metamodel(HRM) we proposed to charac-
terize source or target models. We will discuss the use of the metamodel in transformation
in the following sections.
Figure 4 shows the basic structure of our model transformation framework. A transforma-
tion engine takes the HRM defined source model as input, and uses a template comprised of
a set of transformation rules to produce an output model in a format specified by the tem-
plates. In other words, the output from the transformation engine is a transformation of the
input model. We regard a model as a set of model elements that are in correspondence with
a metamodel element via the instantiation relationship. Metamodel based transformations
use only the elements of the metamodels, thus the transformation description is expressed
in terms of the two metamodels. The rule set in the Figure 4 is the transformation tem-
plate which is an extensible component. Different set of templates can be used in different
transformation tasks for various target platforms. It’s in this sense that we also call the
29
HRM MetaModel
Transformation Engine
Rule Set
<<stereotype>>
ZOOM Model (Source Model)
Result Model/Code
rule
rule
Target Model
Post process Model Level Transformation
Expression Level Transformation
Figure 4: HRMT Model Transformation Process Overview.
template “cartridge” to reflect the exchangeability of templates. It’s the core component of
the transformation framework. We will discuss the characteristics of our approach in the
following subsections.
4.1 Source Model Representation
We use ZOOM notation to represent the Platform Independent Model(PIM). ZOOM no-
tation has a textual syntax defined by BNF, which gives us a simplified way to define and
use the ZOOM metamodel. Since ZOOM provides the textual syntax in a form that most
programming languages have, we are able to build an internal representation of ZOOM mod-
els in a structure similar to an Abstract Syntax Tree(AST), except that the nodes in the
tree will be constructs of the modeling language instead of constructs of the programming
language. However, to capture more complicated modeling language constructs like associ-
ation, we adopt mathematical collections to depict the relationships of different constructs.
Considering its tree structure and such relationships, we name our metamodel Hierarchical
Relational Metamodel(HRM).
30
The use of HRM provides a way for transformation to understand and make use of the
abstract syntax and semantics of both the source and target models. Based on HRM, we
design our template based model transformation to get the information necessary to generate
the target model or code from HRM-compliant models inside a model repository. A set of
interchangeable templates can be provided for model transformation between different target
technical platforms.
Metamodeling is a critical part of our transformation approach. It provides a mechanism
to unambiguously define modeling languages - ZOOM in our case. It is the prerequisite for
a model transformation tool to access and make use of the models. We will now look into
the design of our Hierarchical Relational Metamodel(HRM).
4.1.1 Hierachical Relational Metamodel
The fact that ZOOM notation has a textual syntax defined by BNF gives us a simplified
way to define and use the ZOOM model’s metamodel. From an implementation point of
view, metamodel defines the internal representation of models. In programming languages,
this internal representation often takes the form of Abstract Syntax Tree(AST) that can
be processed by an interpreter or compiler [108, 109]. Since ZOOM provides the textual
syntax in a form that most programming languages have, we are able to build an internal
representation of ZOOM models in a structure similar to an Abstract Syntax Tree. The
only difference is the nodes in the tree are constructs of the modeling language instead
of constructs of programming language. To capture more complicated modeling language
constructs like association, we also adapt mathematics collection to depict the relationships
of different constructs. It is considering its tree structure and such relationships that we
31
name this metamodel Hierarchical Relational Metamodel(HRM).
This tree structure of the metamodel is the fundamental difference between HRM and
MOF. MOF uses a graphic structure that makes it harder to represent relationships be-
tween elements of the metamodel. Since model transformation uses the representation of
metamodel elements to gather information about the source model, a more complicated
representation will make the model transformation task more complicated as well.
4.1.2 HRM Definition
We provide the following definition of HRM:
Definition 4.1. Hierarchical Relational Metamodel is a 3-tuple: HRM = (N, C, R), where
• N is a set of nodes: N = {n1 , n2, ... nj}
• C is a relation on N × N, which forms a tree structure that has one root and no
unconnected nodes. Each node may have zero or more children. In other words, a node
is either a leaf (i.e. with no children) or can be decomposed as one or more children
and each child forms a subtree. Essentially HRM use composition relationships as the
central relationship to capture the hierarchical structure of the metamodel.
• R = {r1, r1 ... rk} is a set of relations between nodes, where ri is a relation on N × N.
Figure 5 shows a simple class diagram that has four classes: Student, Graduate, Under-
graduate and Course. The corresponding HRM diagram is also show in Figure 5 in the
middle. This metamodel can be represented as (N, C, R) according to Definition 4.1. More
specifically, we can elaborate the contents of its three components in Table 2. The compo-
nents r1, r2, r3 and r4 are relations between classes n1, n2, n3, n4 and relationship enroll,
32
Figure 5: HRM Example of a Class Diagram
Table 2: HRM ComponentsHRM Node contentN { ClassDiagrm, n1, n3, enroll, x, y, n1.name, n3.advisor, ...}C { (n1, n1.name),(n3, n3.advisor), (n3, n3.thesis), ...}R { r1, r2, r3, r4 }r1 {(x, n1), (y, n1)}r2 {(x, n3), (y, n4)}r3 {(enroll, n1)}r4 {(enroll, n2)}
x, y.
The tree structure of HRM is the fundamental difference between HRM and MOF. MOF
uses a graphic structure that makes it harder to represent relationship between elements of
the metamodel. Reflected in XMI, the textual representation of MOF based model, there are
no composition relationships separately maintained within a model element. This lack of a
simple structure requires MOF based model transformation tools to use their own mechanism
33
Table 3: Examples of PEL ExpressionsPEL Expression Meaning
n.this node n3: Graduaten.parent ClassDiagramn.children nodes n3.advisor and n3.thesisn.elementName value of the attribute elementName of n3: Graduaten.children[0].elementName value of the attribute elementName of n3.advisor: advisorn.children[1].elementName value of the attribute elementName of n3.thesis: thesis
to build simplified metamodel representation.
4.1.3 Path Expression Language in HRM
The tree structure in the metamodel makes it convenient to navigate inside a specific
model. We use a sub-set of the ZOOM notation, Path Expression Language(PEL) to accom-
plish the navigation. There are two key features of PEL. One feature is to address parts of
HRM. It is in a format similar to XPath [110,111], which is a syntax for defining parts of an
XML document. Each expression is under a particular context node. The other feature of
PEL is to support ZOOM syntax variable and expression evaluation. Since we have devel-
oped a fully functioning ZOOM Evaluator, the transformation process can call the ZOOM
Evaluator to get the results of PEL.
For example, using the HRM diagram shown in Figure 5, if n = n3 is the current context
node in a HRM tree. PEL supports the expressions shown in Table 3.
4.2 Transformation Template
The rule set shown in Figure 4 is a collection of transformation rules. This rule set is
functioning as a container of transformation templates. Here we provide the definition of
34
transformation rule as followings:
Definition 4.2: A transformation rule set R = {r1, r2, ... rn} is a set of model transformation
rules.
Definition 4.3: A transformation rule r = P → (Tpre, Tpost) where P defines the pattern
to select the element of the source model and the template pair (Tpre, Tpost) defines the
mapping to target model. Respectively Tpre defines the mapping to target model before
traversing children of the selected element, and Tpost defines the mapping to target model
after traversing children of the selected element. The rationale of this design is closely related
to the transformation algorithm that we will talk about in the next sub section.
In our framework, the development of transformation is in a large part the process of
constructing transformation rules. The rule set in the Figure 4 is an extensible component.
Different sets of templates can be used in different transformation tasks for various target
platforms. That’s why we also call the template a “cartridge” to reflect the exchangeability
of templates. The template is the core component of the transformation framework. We will
show how template or rules are developed in Section 7.
Model transformation is the notion that we can transform a source model of a system into
a real system in one or more target platforms. The source model contains information about
the system entities you want to generate but it doesn’t have the knowledge of syntax require-
ment of model or code in a target platform. Model transformation template is designed to
fill in this missing knowledge and the template represents the syntax of the target modeling
or programming language. So the development of transformation is actually the process of
constructing the transformation template.
Definitions 4.2 and 4.3 give the definition of transformation template and transformation
35
Table 4: Explanation of code fragment names
Name Code FragmentFile java file creationImport import listCONα placeholder for class constructorsFIELDα placeholder for class member of fieldsGetSetα placeholder for get and set methods
rules. To further understand the structure of a rule, let’s look at a simple example of a rule
for transforming a “struct” in ZOOM model to a “class” in Java.
r = (P → (Tpre, Tpost))
P = struct
Tpre = (File, Import, CONα, FIELDα, GetSetα)
Tpost = ()
In the above specification, P = struct specifies the element of the source model the rule
will be applied to. Tpre is described using a group of code fragment names which function
as code fragment placeholders. A code fragment placeholder is an anchor to reserve a place
for more detailed code fragments. The using of such concise and friendly names to depict
fragments of code avoids the details of concrete syntax and facilitates the understanding
of the construction of rules. The same mechanism will be used in section 7 when more
transformation development is discussed. Table 4 shows the meaning of each of these names.
Using a template is one of the advantages of our transformation framework. The flexibility
of using different templates for different target systems makes ours an extensible architecture.
The interchangeability of different templates is parallel with cartridges in a printer system.
In our transformation framework, there are three ways to obtain a template or cartridge:
you can write it from scratch; you can use a pre-defined template “as is”; or you can extend
a predefined template in a limited way.
36
4.3 Transformation Algorithm
Metamodel based transformation uses the elements of metamodel. Our adopting of Hier-
archical Relational Metamodel(HRM) allows us to build an internal representation of ZOOM
models in a structure similar to an Abstract Syntax Tree(AST). Once metamodel is generated
as an AST like structure, it is accessible by the transformation process through traversing
the tree.
We use an algorithm of “pre-order” to traverse the tree which means each node is visited
before its children are visited and the root is visited first. The algorithm is exemplified by
the pseudo code shown in Listing 1. This algorithm shows that for each node, transformation
involves the following in order:
• finding the matching rule for this node(line 2)
• getting the output text by applying pre part of the rule(line 3, 4)
• traversing all the children nodes of this node and performing a transformation on each
of them(line 5-7)
• getting the output text by applying post part of the rule(line 8, 9)
As we can see in Definition 4.3, a transformation rule has two mapping parts, Tpre and
Tpost. They are represented as rule.pre and rule.post in the pseudo code. Shown in Listing 1:
rule.pre is the mapping before traversing children of the selected element, while rule.post is
the mapping after traversing children of the selected element. As shown in line 5-7 in
Listing 1, each node in the metamode will be visited once and all its children node will get
37
1 transformnode ( node , RuleSet , Output Model )2 r u l e <− f indMatch ingru le ( node , RuleSet )3 t a r g e t t e x t <− i n s t a n t i a t e ( r u l e . pre , node )4 OutPut Model . append ( t a r g e t t e x t )5 foreach c i s a ch i l d o f node6 transformnode ( c , RuleSet , Output Model )7 endforeach8 t a r g e t t e x t <− i n s t a n t i a t e ( r u l e . post , node )9 OutPut Model . append ( t a r g e t t e x t )
Listing 1: HRM-Based Transformation Algorithm
Figure 6: Graphic representation of HRM-Based Transformation Algorithm
visited. To trigger the transformation algorithm, the root node of the source metamodel
needs to be passed, in the form of transformnode(root, RuleSet, Output_Model).
Figure 6 shows a graphic representation of this algorithm. 6 nodes are shown in the graph.
The number in the circle shows the visiting order. Each node is visited twice. In each visit,
an instantiation process will use information provided by both the node and rule to generate
target text.
38
4.4 Model Transformation Process
To illustrate how our approach works, we will discuss the model transformation process in
more detail by using a real example. Although the example is not completely detailed out
for all parts of the system, complete code and rules are giving in appendix. The goal here is
to show how the transformation process is carried out step by step, so we will not elaborate
most of the process specific implementation details.
Community Sports League(CSL) is an organization that facilitates sport games between
regional communities. There are 10 teams in CSL right now. Each team has 12-15 regular
players. While CSL is gaining recognition and popularity, they are thinking of creating a
system to manage team and player information and put some of the information online as
well. Basically, they want to centralize the management of team and player information and
they want people to be able to browse through the teams and look up a certain player. With
a couple of mouse clicks, people can see their favorite local sport star’s weight, height and
recent game stats.
To start the MDE process we need to build a platform-independent model that comprises
the essence of CSL system. This is the only model that the developer will create completely
“by hand.” The other models are mostly generated. The PIM for Community Sports League
is depicted in Listing 2. It will be used as input in the following code generation example as
Roster.zoom.
The PIM is also demonstrated in Figure 7 with its graphical representation. Figure 8 shows
the internal representation of abstract syntax of the PIM. As you can see, the components,
properties and relations existing in the model Roster are defined in the metamodel in a tree
39
1 namespace roster;
2 @Entity
3 struct Player {
4 String id;
5 String name;
6 String position;
7 double salary;
8 }
9 @Entity
10 struct Team {
11 String id;
12 String name;
13 String city;
14 }
15 @Entity
16 struct League {
17 String id;
18 String name;
19 String sport;
20 }
21 @Association(multiplicityLeft=Multiplicity.Many ,
22 multiplicityRight=Multiplicity.Many ,
23 roleLeft = players , roleRight = teams)
24 Relation <Player , Team > playerteam;
25 @Association(multiplicityLeft=Multiplicity.Many ,
26 multiplicityRight=Multiplicity.One ,
27 roleLeft = teams , roleRight = league)
28 Relation <Team , League > teamleague;
Listing 2: Roster.zoom
structure. The texture representation can be given in XML as the right side of Figure 8.
The complete transformation process is depicted in Figure 9. It is divided into 5 individual
steps. Now let’s walk through the transformation process step by step.
4.4.1 Parsing the source model
A source model is provided, in our case, Roster.zoom in Listing 2. Parsing involves reading
actual source code of the model, or the textual representation of model roster and splitting
it into understandable language symbols. This is made possible by ZOOM’s formally defined
40
Team
teamId : String name : String city : String
addPlayer(player : Player) dropPlayer(player : Player)
playerTeam
Player
playerId : String name : String postion : String salary : Double
1..* 1
teamLeague
1..*
1
League
leagueId : String name : String
addTeam(team : Team) dropTeamr(team : Team)
team
league
roster
Figure 7: Graphical Representation of PIM
syntax. A parser will parse the textual representation of the roster model and generate an
internal abstract syntax tree (AST) representation of roster, which is an object tree. The
resulting AST representation is shown in Figure 8.
4.4.2 Traversing the object tree
Once the metamodel is generated as AST, which is accessible by the transformation process
through traversing the tree. We use an algorithm of “pre-order” traversal of the tree which
was introduced in section 4.3. It means each node is visited before its children are visited and
the root is visited first. The traversing is exemplified by pseudo code shown in Listing 1. since
the matching metamodel node with rule(step 3) and generating target text(step 4) happens
during the process of traversing. The pseudo code in Listing 1 actually shows all of these 3
41
[ s1 ]Struct Player
[ s1f1 ]Field playerId
[ s1f2 ]Field name
[m 1 ] Model roster
<Model id='m1' name='roster''> <Struct id=’s1' name='Player'> <Field id=’s1f1' type=’String’ name=’playerId’ /> <Field id=’s1f2' type=’String’ name=’name’ /> <Field id=’s1f3' type=’String’ name=’position’ /> <Field id=’s1f4' type=’Double’ name=’salary’ /> </Struct> <Struct id=’s2' name='Team'> <Field id=’s2f1' type=’String’ name=’teamId’ /> <Field id=’s2f2' type=’String’ name=’name’ /> <Field id=’s2f3' type=’String’ name=’city’ /> <Operation id=’s2o1' name=’addPlayer’ returnType=’void’/> <Operation id=’s2o2' name=’dropPlayer’ returnType=’void’/> </Struct> <Struct id=’s3' name='League'> <Field id=’s3f1' type=’String’ name=’leagueId’ /> <Field id=’s3f2' type=’String’ name=’name’ /> <Operation id=’s3o1' name=’addTeam’ returnType=’void’/> <Operation id=’s3o2' name=’dropTeam’ returnType=’void’/> </Struct> <Association id='a1' name='PlayerTeam' LeftModel = ‘Player’ RightModel = ‘Team’ MultiLeft=One MultiRight=Many /> <Association id='a2' name='TeamLeague' LeftModel = ‘Team’ RightModel = ‘League’ MultiLeft=One MultiRight=Many /> </Model>
[a 1 ]Association PlayerTeam
LeftModel Play
RightModel Team
[ s1f4 ]Field salary
[ s1f3 ]Field position
[ s2 ]Struct Team
[ s2f1 ]Field teamId
[ s2f2 ]Field name
[ s2o1 ]Operation addPlayer
[ s2f3 ]Field city
[ s2o1 ]Operation dropPlayer
[ s3 ]Struct League
[ s3f1 ]Field leagueId
[ s3f2 ]Field name [ s3o1 ]Operation addTeam [ s3o1 ]Operation dropTeam
MultiLeft=One
MultiRight=Many
[ a2 ]Association TeamLeague
LeftModel Team
RightModel League
MultiLeft=One
MultiRight=Many
Figure 8: Abstract Syntax of PIM
steps. To trigger this transformation algorithm, the root node of the source metamodel needs
to be passed. In our case, it is passing as transformnode(m1, RuleSet, Output_Model),
since m1 is the root node.
As we can see in Definition 4.2, a transformation rule has two mapping parts, Tpre and
Tpost. They are represented as rule.pre and rule.post in pseudo code of Listing 1. Shown
in Listing 1: rule.pre is the mapping before traversing children of selected element, while
rule.post is the mapping after traversing children of selected element. And as shown in line
42
Model M metamodel <RuleSet … target=”Java” …> … <Rule match=”Struct”> <pre>
</pre> <post>
</post> </Rule> <Rule match=”Struct/Field”> <pre>
</pre> <post>
</post> </Rule> ... </RuleSet>
...
...
…
...
Literate Target Code
Import java.util.*; class A { protected Type attr1; … }
step5: post processing
Block 1
Block 4
Block 3
Block 2
Instantiated Block 1
Instantiated Block 3
Instantiated Block 4
Instantiated Block 2 step1: parsing
step2: traversing
step3: matching
step4: generating
Final Target Source
(see Figure 5)
(see Figure 6)
Figure 9: Model Transformation in details.
5-7 in Listing 1, each node in the metamode will be visited once and all its children nodes
will get visited.
4.4.3 Matching node in object tree with rule
The key step in this transformation process is applying rules to source models represented
by their metamodels. At this point, the transformation engine enters into the picture. As
implied in the transformation rule definition, r = (P → (Tpre, Tpost)), to apply a rule on a
certain model includes both matching the pattern P and implement mapping Tpre and Tpost.
The pattern P is specified to make sure that the correct node is being located and used. In
the pseudo code in Listing 1, rule.pre(line 3) and rule.post(line 8) function as a template
for the transformation. When implementing a template, we allow both static and dynamic
specification. Static specification is a verbatim mapping and dynamic specification can be
in one of these two forms: macros or JSP alike syntax.
43
Source Rule
Target
A: Struct Block 1
Block 2
M Struct
A
Source
Literate Target
Block 1
Block 2
Other Blocks
match
match generate
generate
Figure 10: Matching metamodel node and generating target text with rule
4.4.4 Generating target text
The generation of target text can be as simple as outputing the text included in the rule
pre or post elements as shown in Listing 1 line 3 and line 8. However, a more complicated
scenario can be involved in this step. Figure 10 shows Step 3 and Step 4 in more details.
The result of these steps is Literate Target Code. It will be used as input in the final step,
post processing. In most of the cases, expressions are in different forms in source and target
model. For example, a set addition expression in ZOOM specification: a += b, will need to
be mapped as a.add(b) in Java syntax. We provide an extensible mechanism to assist the
transformation, or mapping.
The construct in ZOOM that is similar to classes and interfaces in Java and C++ is
struct. Structs are modeling constructs that define the structures, design requirements, and
behaviors at a higher level of abstraction than classes and interfaces, which are primarily
44
a += b : BinaryExpression
metamodel
<RuleSet … target=”Java” …> … <Rule match=”…/ExpressionStatement” … expressionmapping=”yes” ...> <pre>
</pre> <post>
</post> </Rule> ... </RuleSet>
a.add(b) a: LeftOperand b: RightOperand “+=”: operator
Operator LHS RHS += $v1 += $v2 $v1.add($v2) -= $v1 -= $v2 $v1.remove($v2) ...
Rule
Expression mapping table
matching
look up
target
a += b
source
Figure 11: Expression Mapping in details.
implementation constructs. Structs can be considered as prototypes of classes and interfaces.
The construct in ZOOM that is similar to a method in Java is an operation. The syntax of
operation in ZOOM also has close resemblance to methods in Java and C++ so that trans-
formations between them involve mostly keywords mapping and structure rearrangement.
Most Java expressions are also legal in ZOOM. There are additional expressions supported
by ZOOM such as integer expressions, logical expressions, set and list expressions [94].
For these additional expressions, we provide an automatic mechanism to transform them
to expressions of target language. This mechanism is invoked whenever expressions are
in different forms in the source and target model. Just like making the transformation
template extensible, we design this external expression mapping mechanism so that extension
is feasible and straightforward.
Figure 11 shows an example of mapping an expression a += b into a target expression:
a.add(b). An expression mapping table is used for model transform engine to look up a
corresponding expression in a target platform. This table is extensible in the sense that any
specific mapping to a new target platform can be easily added and maintained.
45
Table 5: Example of Expression Mapping
operator source expression target expression+= $v1 += $v2 $v1.add($v2)
-= $v1 += $v2 $v1.remove($v2)
... ... ...
Our external expression mapping is an extension of this template. It is a customized
template for expression transformation. We define the expression mapping as:
Definition 4.4: An external expression mapping is defined as a 3-tuple: M = (o, λ, ρ)
o is the operator of expression
λ is the source expression template
ρ is the target expression template
The example shown in Figure 11 maps an expression a += b into target expression
a.add(b). Using definition 6.1, it can be specified as:
M = (o, λ, ρ)
o = +=
λ = $v1 += $v2
ρ = $v1.add($v2)
A more visual way to represent the mapping definition is using a table such as Table 5.
The advantage of such an expression mapping schema lies in its extensibility. Expression
mapping rules can be adequately represented by enumerating all possible target expressions.
Also, different sets of rules can be compiled in such structural way for different target plat-
forms.
46
4.4.5 Post processing
The Literate Target Code generated in Step 4 as shown in Figure 9 may or may not result
in a desirable order that fits the target technical platform. For example, when the target
platform is Java environment, an attribute node in a struct is always visited after the struct
node, but the final code will require the target attribute code(declaration, initialization etc)
to be present within the target class code. This kind of rearrangement of code is done by
post processing. Post processing is responsible for rearranging the Literate Target Code in a
desirable style that fits to the target technical platform. Here we treated the Literate Target
Code as pieces of segment that can be flexibly rearranged. A post process goes through all
these pieces and place each of them in the right places in the final models or code. This frees
the model transformation engine from the details of contextual requirements of the target
platform.
The post process rearranges the specification in a desirable style that fits to the target tech-
nical platform. This approach has a similar style as proposed in Knuth’s Literate Program-
ming [112]. Literate programming is a methodology that combines a programming language
with a documentation language, thereby making programs more robust, more portable, more
easily maintained, and arguably more fun to write than programs that are written only in a
high-level language. The main idea is to treat a program as a piece of literature, addressed
to human beings rather than to a computer. The program is also viewed as a hypertext doc-
ument, rather like the World Wide Web. Here we treated the generated model specification
or code as segments that can be flexiblly rearranged so that they confirm to the requirements
of the target technical platform.
In our approach, adopting such a post processing mechanism frees the model transforma-
47
tion engine from the details of contextual requirements of the target platform. It makes the
development of transformation templates more straightforward.
After all the above transformation steps, the results are models or source code of the target
platform. In our example, the results are Java source code.
48
5 The HRMT Tool Suite
Chapter 4 introduces our model transformation approach and discusses the characteristics
of this approach. We have successfully applied this approach in the implementation of the
HRMT Tool. In this chapter, we will discuss the architecture of the HRMT tool and its
main components.
5.1 HRMT Architecture
Figure 4 shows the basic structure of our model transformation framework. A transfor-
mation engine takes the HRM-defined source model as input and uses a template comprised
of a set of transformation rules to produce an output model in a format specified by the
templates. In Figure 12, the architecture of HRMT depicts the transformation engine in the
shaded area. The main components such as ASTBuilder and ModelProcessor are shown in
the rectangular box and the line between them represents interaction.
In Section 4.4, we show the complete transformation process in Figure 9. We also present
a walk-through of the transformation process step by step. Here we will briefly show the
steps using the main components shown in Figure 12.
• Parsing the source model
This step is performed by component ASTBuilder. Parsing involves reading the actual
source code of the model, or the textual representation of the model roster, and splitting
it into understandable language symbols. This is made possible by ZOOM’s formally
defined syntax. ASTBuilder will parse the textual representation of a source model and
will then generate an internal abstract syntax tree (AST) representation of it, which
49
Figure 12: HRMT Architecture
is an object tree depicting metamodel.
• Traversing the object tree
Once a metamodel is generated as an AST, which is accessible by the ModelProcessor
through traversing the tree, we use an algorithm of “pre-order” traversal of the tree
which is introduced in section 4.3. This means each node is visited before its children
nodes are visited and the root is visited first.
• Matching node in object tree with rule
The key step in this transformation process is applying rules to source models repre-
sented by their metamodels. TemplateProcessor is responsible for reading the template
file and making available the rules to ModelProcessor. When ModelProcessor encoun-
ters a node in the object tree, it will use the path of the node to locate a corresponding
rule in the template.
50
• Generating target text
The generation of target text can be as simple as outputing the text included in the
rule pre or emphpost elements as shown in Listing 1 line 3 and line 8. However, a more
complicated scenario can be involved in this step. First of all, for variables in a template
whose value depends on a metamodel, they will need to be evaluated by Evaluator. In
most of cases, expressions are in different forms in the source and the target model.
For example, a set addition expression in ZOOM specification: a += b, will need to be
mapped as a.add(b) in Java syntax. This is the job of ExpressionMapper. We discuss
the details of expression transformation in Chapter 6.
• Post processing
The text generated by ModelProcessor is called the Literate Target Code. It may
or may not be in a desirable order that fits to the target technical platform. For
example, when target platform is in a Java environment, an attribute node in a struct
is always visited after the struct node, but the final code will require the target attribute
code(declaration, initialization etc) to be present within the target class code. This
kind of rearrangement of code is done by PostProcessor. PostProcessor is responsible
for rearranging the Literate Target Code in a desirable style that fits to the target
technical platform. Here we treated the Literate Target Code as pieces of a segment
that can be flexibly rearranged. PostProcessor goes through all these pieces and place
each of them in the right places in final models or code. This frees the ModelProcessor
from the details of contextual requirements of the target platform.
51
5.2 HRMT Main Components
Figure 12 shows the main components of HRMT tool. In this section, we will provide
further information about each of the components. Also since HRMT is an integral part of
the ZOOM research project, some of the components, such as ASTBuilder and Evaluator are
common components shared by other ZOOM tools as well. We will point out such shared
components in the following discussion.
• ASTBuilder
ASTBuilder parses the textual representation of source model and generates an in-
ternal abstract syntax tree (AST) representation, which is an object tree depicting
the metamodel. The object tree will be directly accessed by ModelProcessor. AST-
Builder is a common component used by other ZOOM tools such as ZOOM Animator
and Event Based Framework. There are other smaller components that are shared by
HRMT and other ZOOM Tools like TypeChecker. Here we only list those major ones
that are critical to model transformation process.
• TemplateProcessor
TemplateProcessor is responsible for reading the template file and make available the
rules to ModelProcessor. When ModelProcessor encounters a node in the object tree,
it will use the path of the node to locate corresponding rule in template. Both Evalu-
ator and ExpressionMapper are components that assist TemplateProcessor to provide
mapping rule to ModelProcessor.
• Evaluator
52
The value of variables in template is determined by the metamodel that is being
processed by ModelProcessor. Evaluator will provide this service of retrieving value.
ASTBuilder is also a common component used by other ZOOM tools such as ZOOM
Animator and Event Based Framework.
• ModelProcessor
ModelProcessor is the central component of HRMT. Once metamodel is generated
as AST, ModelProcessor traverses the object tree, locates the corresponding rule and
generates the Literate Target Code.
• PostProcessor
PostProcessor is responsible for rearranging the Literate Target Code in a desirable
style that fits to the target technical platform. Here we treat the Literate Target Code
as pieces of segment that can be flexibly rearranged. PostProcessor goes through all
these pieces and places each of them in right places in final models or code. This frees
the ModelProcessor from the details of contextual requirements of target platform.
• ExpressionMapper
In cases where expressions are in different forms in source and target model, Expres-
sionMapper is used to provide a mapping between these forms. Our external expression
mapping is an extension of template. It is a customized template for expression trans-
formation. The definition of expression mapping and example can be found in section
4.4.4.
The advantage of such an expression mapping schema lies in its extensibility. Expres-
53
sion mapping rules can be adequately represented by enumerating all possible target
expressions. Also, different sets of rules can be compiled in such structural way for
different target platforms.
5.3 Use of HRMT Tool Suite
To use the HRMT tool, a user needs to obtain ZOOM Software Suite first. We provide
the latest ZOOM Installer in our research web site [113]. Documentation of how to use the
HRMT is included.
After installation, when running the HRMT tool, a user has to provide the source model,
the choice of template and the location of target files. Once this information is available,
HRMT will automatically perform the transformation. When HRMT finishes the process,
the user can go to the location of target files and check out all the files. The user will be
allowed at this point to make changes to the target files, although it is unnecessary in most
cases. A set of examples that include both the source model and template are provided. One
simple way to get familiar with HRMT tool suite is for the user to take the example files,
make modifications and then check the corresponding changes in target files. This process
will make the transformation process more understandable.
Available templates are under a default directory called Template. Name of the available
template is self-explanatory. For example, Template_NET.xml is a template for .NET plat-
form. The default target directory is called Target. User will be allowed to change these
default settings.
54
6 Development of Transformation
In section 4.4, while we introducing the transformation process we used an example of
Community Sports League(CSL) roster management system. We will continue use the ex-
ample in this section to show how transformation rules are constructed for transformation
into basic classes(both Java and .NET), classes with associations(both Java and .NET), EJB
Entities and a comprehensive EJB application. To facilitate the understanding of the con-
struction of rules, we will use concise and friendly names to depict fragments of code, as
first introduced in section 4.4. All the related rules and generated code can be found in the
Appendix.
6.1 Basic Classes
The way ZOOM notation is designed makes its “struct” a similar counterpart of “class”
in Java and .NET. This similarity in a way simplifies the transformation rules. We will show
you how rules are composed to help generate basic classes with data members and related
accessory methods(getXxx()/setXxx()).
The following is the rule to map “struct” to corresponding Java class.
BasicClassesR = (BasicClassesP → (BasicClassesTpre, BasicClassesTpost))
BasicClassesP = struct
BasicClassesTpre = (File, Import, CONα, FIELDα, GetSetα)
BasicClassesTpost = ()
BasicClassesTpre is described above using a group of code fragment name. Table 6 shows
the meaning of each of these names.
A code fragment placeholder is an anchor to reserve a place for more detailed code frag-
55
Table 6: Explanation of code fragment names
Name Code FragmentFile java file creationImport import listCONα placeholder for class constructorsFIELDα placeholder for class member of fieldsGetSetα placeholder for get and set methods
Table 7: Explanation of code fragment names
Name Code FragmentCONβ class constructorsFIELDβ class member of fieldsGetSetβ class member of get and set methods
ments. In this case, more code will be generated after processing a Variable node. Here is
the rule for variable:
VariableR = (VariableP → (VariableTpre, VariableTpost))
VariableP = struct/Declaration/VariableDeclarator
VariableTpre = (CONβ , FIELDβ , GetSetβ)
VariableTpost = ()
VariableP = struct/Declaration/VariableDeclarator gives the pattern to find the variable
nodes. And Table 7 meaning of code fragment names.
A struct can have multiple variables. In the case of struct Player, it has id, name, position,
salary. Usingk=m∑
k=0
CFk
to represent the concatenation of m code fragment(CF), m being the total number of corre-
sponding code fragment. For example, in the class of Player, it has 4 class members, three
class constructor code fragments will be concatenated. And the representation is:
56
CONα =k=4∑
k=0
CONβk
Using this representation, the relationship between placeholder with subscript α and the
code fragment with subscript β can be shown as:
CONα =k=m∑
k=0
CONβk
FIELDα =k=m∑
k=0
FIELDβk
GetSetα =k=m∑
k=0
GetSetβk
After the process, the resulting is 3 files. In case of Java: Player.java, Team.java and
League.java. And in case of .NET: Player.cs, Team.cs and League.cs. You can find complete
code of these Java files in Appendix A.1.
6.2 Classes with Associations
We have shown above that simple classes can be generated using ZOOM “struct”. As
you may notice that in the PIM of Listing 2, there are associations defined. In ZOOM
model associations are defined as relations or subtypes of relations, i.e., maps and injec-
tions. As shown in Listing 2 line 21-28, role names and multiplicities are specified as the
attributes of the @Association annotation of the relation, which are roleLeft, roleRight,
multiplicityLeft and multiplicityRight. After roster.zoom is parsed, all these infor-
mation will be available to access in metamodel.
57
Object-oriented programming languages do not contain syntax or semantics to express
associations directly [114]. Instead, associations are implemented by a combination of classes,
attributes and methods, depends on the specification of their multiplicity. For example, line
24-26 of Listing 2 show that there is a many-to-one between Team and League. In the target
Java code, Team Class will have attribute with type League, and method getLeague and
setLeague; League Class will have attribute with type List<Team> and method getAllTeam,
addTeam and removeTeam. Using mLeft and mRight as shorthand for multiplicityLeft
and multiplicityRight,the specification of rule is shown as:
AssociationR = (AssociationP → (AssociationTpre, AssociationTpost))
AssociationP = ZOOMModule/Declaration/VariableDeclarator
AssociationTpre =
(Attleft, F IELDright, GetSetleft, GetSetright)
if(mLeft = One and mRight = One)
(Attleft, F IELDright, GetSetleft, V GetSetright, AddRemoveright)
if(mLeft = One and mRight = Many)
(V Attleft, F IELDright, V GetSetleft, GetSetright, AddRemoveleft)
if(mLeft = Many and mRight = One)
(V Attleft, F IELDright, V GetSetleft, V GetSetright, AddRemoveright, AddRemoveright)
if(mLeft = Many and mRight = Many)
AssociationTpost = ()
And the meaning of the code fragment names is shown in Table 8.
58
Table 8: Explanation of code fragment namesName Code Fragment
FIELDleft class member of left role fieldFIELDright class member of right role fieldVFIELDleft class member of vector left role fieldVFIELDright class member of vector right role fieldGetSetleft class member of left role get and set methodsGetSetright class member of right role get and set methodsVGetSetleft class member of vector left role get and set methodsVGetSetright class member of vector right role get and set methodsAddRemoveleft class member of vector left role add and remove methodsAddRemoveright class member of vector right role add and remove methods
6.3 EJB Entities
Enterprise Java Bean(EJB) is a managed, server-sided component for modular construc-
tion of enterprise applications. The latest version of EJB is 3.0. In the EJB 3.0 world, all
kinds of enterprise beans, including entity beans are just plain old Java objects (POJO)
with appropriate annotations. The fact that ZOOM notation supports annotation makes
the transformation between ZOOM model to EJB POJO fairly straightforward. Similarly to
rules in 7.1 shows the rule for generation of Java classes, including construction, operation
and attribution. The EJB 3.0 specification lets you specify O-R metadata via annotations.
It provides a wide range of annotations that cover different types of relationships between
POJOs, constraints, column information, sequence generators, composite primary key, and
inheritance.
EJBEntityR = (EJBEntityP → (EJBEntityTpre, EJBEntityTpost))
P = struct
EJBEntityTpre = (File, Import, Annotation, NamedQueryα, CONα, FIELDα, GetSetα)
EJBEntityTpost = ()
59
Table 9: Explanation of code fragment namesName Code Fragment
File java file creationImport import listAnnotation annotationsNamedQueryα placeholder for named queriesCONα placeholder for class constructorsFIELDα placeholder for class member of fieldsGetSetα placeholder for get and set methods
EJBEntityTpre is described above using a group of code fragment name. Table 9 the
meaning of each of these names. And you can refer to Section 7.1 description for more
details.
6.4 Comprehensive EJB Applications
Compared with the previous version of Enterprise Java Beans, the current generation of
Java EE (EJB3) has several great improvements. Perhaps the most outstanding of these
improvements is the new standard mechanism of EJB persistence, specified by JSR220.
Such mechanism provides a transparent persistence layer based on radical reforms. These
new features not only simplify the development process, while enhancing software reusability
at the same time, but also make EJB3 more object oriented and model-driven friendly. For
example, through elaborating mapping annotations, classes and relationships in a model can
be directly mapped into database schema. For all that, the assignment of annotations and
the code patterns for database manipulation still mean a lot of work for the programmer.
Here we demonstrate how a comprehensive EJB3 application including entity beans and
session beans can be transformed using our model.
The complete Roster EJB application incudes Java Persistence API entities or POJO
60
Table 10: Explanation of code fragment namesName Code Fragment
SessionInterfaceFile session interface java file creationSessionBeanFile session bean java file creationImport import listAnnotation annotationsInterfaceMethodα placeholder for interface member of methodsSessionMethodα placeholder for session class member of methods
(Player, Team, and League), a stateful session bean (RequestBean), an application client
(RosterClient). Except RosterClient, which is manually coded, all the entities and session
beans are generated by the transformation process. We have attached in Appendix A.2 the
complete rules and generated code for all of them.
We have shown the rule for generating POJO. The following are rules for session bean
generation.
EjbR = (EjbP → (EjbTpre, EjbTpost))
EjbP = struct
EjbTpre = (SessionInterfaceFile, SessionBeanFile, Import, Annotation, InterfaceMethodα, SessionMethodα)
EjbTpost = ()
EjbTpre is described above using a group of code fragment names. Table 10 describing the
meaning of each of these names.
The EJB 3.0 specification provides a Query API that can be used for both static and
dynamic queries. A named query can be defined as a standalone query or attached to a
query method of the bean class. You can define named queries in EJBQL or SQL. This is
a boon for Java developers familiar with SQL syntax, as they can become EJB developers
without having to learn another query language. Using our transformation framework, we
can map operation specification in Listing 3 into named queries. The rule is described as
following.
61
Table 11: Explanation of code fragment namesName Code Fragment
SessionInterfaceMethod interface member of methodSessionBeanMethod session class member of methodNamedQueryβ) named query
EJBQueryR = (EJBQueryP → (EJBQueryTpre, EJBQueryTpost))EJBQueryP = struct/OperationEJBQueryTpre = (SessionInterfaceMethod, SessionBeanMethd, NamedQueryβ)EJBQueryTpost = ()
1
2 @Session
3 struct Request {
4 @query(entity=Player)
5 Player findPlayer(String id)
6 {return { Player p : p.id == id @ p};}
7
8 @query(entity=Team)
9 Team findTeam(String id)
10 {return {Team t : t.id == id @ t};}
11
12 @query(entity=Player)
13 Set <Player > findAllPlayers ()
14 {return { Player p @ p};};
15
16 @query(entity=Player)
17 Set <Player > findByPosition(String position)
18 {return { Player p:p.position == position @ p};};
19 }
Listing 3: Session Bean Specification
Again EJBQueryTpre is described above using a group of code fragment name. Table 11
shows the meaning of each of these names.
Here, the relation between place holder NamedQueryα and named query code fragment
NamedQueryβ is:
NamedQueryα =k=m∑
k=0
NamedQueryβk
62
And the result is shown in Listing 4
1
2 @Entity
3 @Table(name="Player")
4
5 @NamedQueries ({
6 @NamedQuery(name = Player.findPlayer ,
7 query = select p from Player p where p.id = :id),
8 @NamedQuery(name = Player.findAllPlayers ,
9 query = select p from Player p ),
10 @NamedQuery(name = Player.findByPosition ,
11 query = select p from Player p where p.position =: position)
12 })
Listing 4: EJB Named Query
63
7 Case Study: A Hospital Information Management
System
7.1 Introduction
In this chapter, we present a case study showing how our transformation framework can be
used to transform a ZOOM model specification to applications running on multi-platforms.
In order to show the power of our approach, the system described is not trivial. It is not a toy
system, but it is a real-life example. This case study demonstrates how a PIM is transformed
automatically into rather complex PSMs and code, and fulfills real-life needs. The complexity
of the complete example is considerable. However, the example is not completely detailed
out in all parts of the system in order to limit the size of this dissertation. In this chapter
the requirements of the example system are stated in Section 7.2 and an overview is given
of the models and transformations involved in Section 7.3. In Section 7.3, we point out the
essential features of our approach that are illustrated in this case and elaborate on how these
features are being illustrated in the case study.
7.2 Requirement of HIMS
7.2.1 Scope of HIMS
The Hospital Information Management System (HIMS) is a web application designed to
improve access to patient information through a central electronic information system, an
Electronic Healthcare Record (EHR) [115–117]. A HIMS’s goal is to streamline patient
information flow and its accessibility for doctors and other health care providers. The im-
64
plementation of HIMS will improve patient care quality and patient safety over time.
Using MDE to develop a Healthcare System is an active research topic. Raistrick in [118]
outlines how MDA and UML were used in the context of an extension of the processing of
clinical data to provide a patient-based electronic record. In [119], a method was tested on a
patient record of a hospital which provided rules for generating SGML/XML DTD element
and parameter entity declarations from object-oriented UML class diagrams. In light of
these research projects, we define the requirements of this case study in a similar complexity
level compared to them.
7.2.2 Functionality Requirements
• Patient Registration
This component allows users to record, update or delete a new patient’s demographical
information. The result will be saved in a centralized database.
• Hospital Personnel Management
This component allows users to record, update or delete hospital personnel, including
doctors, nurses, staff member’s demographical information. The result will be saved
in a centralized database.
• Appointments and Scheduling
This component allows users to record, update or delete an appointment between a
patient and doctor. The result will be saved in a centralized database.
• Medical Reports
This component allows users to record, update, or delete a patient’s medical record.
65
These records need to support storing of heterogeneous data formats such as word
documents or image files. The results will be saved in a centralized database.
7.2.3 Non-Functional Requirements
The support of non-functional requirements(NFR) by our approach is achieved in different
ways depends on a specific requirement. We choose bellow some of the most important non-
functional requirements in the scope of this case study. We have demonstrated how our
framework can support customized solutions to a number of different NFRs. However, we
would like to point out that this is far from a general solution to support all the different
kinds of NFRs. Due to the wide range and vastly different characteristics of NFRs, solutions
to address NFRs are heavily dependent on the target platform. A more comprehensive
framework to address NFRs in the context of MDE remains a challenge for future work.
• Security Requirement
Putting EHR online benefits both healthcare providers and patients: each can access
and utilize relevant information conveniently. However, putting the system on the open
Internet also introduces new security concerns. Protecting privacy is fundamental to
electronic health records and healthcare information exchange. In 2007, the Healthcare
Information Technology Standards Panel [120] specified the technical standards needed
to ensure the security of patient records. A reliable HIMS needs to address the security
issue specifically and provides a security mechanism that is compatible with existing
standards.
• Scalability requirement
66
Hospital information is an ever growing system. With the accumulation of healthcare
records, this HIMS needs to be able to handle growing amounts of back end data and
increasing data requests.
• Performance requirement
One of the key advantages of putting EHR online is ready access. This requires system
response time in a reasonably quick fashion, especially with some data-intensive com-
munications. This HIMS should have a mechanism to maintain desirable performance.
7.2.4 External Interface Requirements
The user interacts with the system using a web browser. Input from the user will be via
keyboard input and mouse point and click. The user will navigate through the system by
clicking on icons and links.
7.3 Modeling and Transformation of HIMS
Figure 13 is the ZOOM graphic representation for this case study. The texture represen-
tation in ZOOM can be found in Appendix A.5. This is the PIM of the software system. It
is the only model that must be created by the model developer of the HIMS system.
The model in Figure 13 defines the information management system independently from
any specific technology, so indeed, it is a PIM. But hospitals do not want a model; they want a
running system. Therefore, we need to transform the PIM into a PSM that is compatible with
the hospital’s technology infrastructure. In our case study, we choose Microsoft .NET and
J2EE as the target web application platform, considering the popularity of both platforms.
We also choose Microsoft Access and SQL Server as target database platforms. Appendix
67
Figure 13: ZOOM Graphical Representation of Hospital Information Management System
A.6 shows screenshots of HIMS in both .NET and J2EE platform.
7.4 Features Illustrated by Case Study
In this case study, we were able to showcase some of the main features of our approach.
Each of these features will be elaborated upon.
7.4.1 Multi-platform support
The goal of this case study is to use the above model, or PIM and our model transformation
framework to generate the final software system that can run on different platform. Since
68
this is a data-driven application, database system or platform plays an especially important
part. We choose Microsoft .Net and J2EE as target web application platforms. We choose
Microsoft Access and SQL Server as target database platform. In the end, we successfully
transformed PIM into these four distinct target platforms.
• Microsoft .NET web application using Access as back end database
• Microsoft .NET web application using SQL Server as back end database
• J2EE web application using Access as back end database
• J2EE web application using SQL as back end database
7.4.2 Security requirement support
One of the most challenging problems in managing large web applications is the complexity
of security administration and user-profile management [121]. Role-Based Access Control
(RBAC) [122,123] has become the predominant model for advanced access control because it
reduces the complexity and cost of administration. Under RBAC, security administration is
greatly simplified by using roles, hierarchies and privileges. However, since different platforms
provide different technical solutions to RBAC, it can be a daunting task to implement exactly
the same kind of security requirements under different platforms. By presenting the example
of automatically implementing the same RBAC security policy under different platforms
based on the same model, we showcase the portability supported by our framework.
Both .Net and J2EE have their proprietary mechanism to support RBAC. They store
the security information differently and require different coding routines to utilize the in-
formation. In our source model specification, we do not need to worry about such specific
69
Table 12: Example of ZOOM AnnotationAnnotation Explanation@Security specify whether role based access control will be enforced@Table specify whether a relational table will be created@id specify whether a primary key will be created@restricted specify whether querying a field will be restricted
proprietary mechanisms. We just need to specify that role-based access control will be
enforced, as this line of specification shows:
@Security(Authentication="Yes", RoleManagement="Yes")
Also in our specification, to map a type of user group to a role, we just need to mark that
struct and provide role name specification as shown in Listing 5.
As you can see, a couple more annotations are used in the specification. These annotations
are used to communicate between the source model and the template so that particular part
of template will be invoked. The use of annotations is similar to Java and EJB’s annotations.
However, we make sure it is platform independent so that transformation templates for
platforms other than Java and EJB can easily understand the annotations. Table 12 shows
some of the annotations being used in the examples.
7.4.3 Scalability requirement support
Hospital information is an ever growing system. There are two main scenarios that an
HIMS can grow. The first possible scenario refers to the increasing complexity of medical
records, and the second one refers to the accumulation of medical records. We will discuss
how our approach helps address both of these scenarios.
When medical records get more complicated, more properties need to be attached to a
70
1 namespace hospital;
2
3 @Security(Authentication="Yes", RoleManagement="Yes")
4
5 @table
6 struct Person {
7 @id
8 int id;
9 String name;
10 String address;
11 }
12
13 @table(role="yes")
14 struct Patient extends Person{
15 int id;
16 String insurance;
17 }
Listing 5: Role Based Access Control Sepcification
record. This means the underlying data structure changes. From an implementation point
of view, the change in data structure requires changing the database design and changing all
the programs that utilize the data structure. It is a time consuming and error prone process
to perform such changes, because more often than not some critical pieces of code will be
missed in the updates. Using our approach, the only change required is to the source model.
Making such changes is a time-consuming and error-prone process, because more often than
not, some critical pieces of code will be missed in the updates. Using our approach, the only
change required is to the PIM. By adding the new properties to the corresponding entities,
a new running system can be generated again without worrying about missing code in the
update .
The accumulation of medical records is best handled by a database system. If the amount
of data collected eventually exceeds the limit of a database system, a more powerful database
71
system needs to be used instead. Again, in a software system that is developed in a traditional
process, potential updates must occur in all the places that perform database operations.
And of course, it is a time-consuming and error-prone process. Using our approach, in this
scenario, we do not even need to change the source model, because the underlying data
structure is not changed. We just need to update in the transformation templates the part
of the database connection that is being specified.
7.4.4 Performance requirement support
There are also two aspects of our case study that our approach can help support perfor-
mance requirements.
First as a data intensive application, such a HIMS’s performance depends on the database
system and database design. A good database design can effectively improve an application’s
performance. Since our support of generating SQL script directly from the source model , this
allows the modeler to change the database design in a modeling level and test the application
performance right away. Also, we can provide a template that generates XML files that can
be read by Hibernate and use Hibernate to map the source model to relational database.
This way, we can utilize Hibernate’s high performance object/relational persistence.
1 namespace hospital;
2
3 @table
4 struct MedicalDataTemplate {
5 int id;
6 String desc;
7 String SecurityLevel;
8 String format;
9 @restricted
10 String attachment;
11 }
Listing 6: Query Restriction
72
Second, as an online application, the performance is predicated upon the speed of the
Internet. This means that an effective way to improve performance is to control the amount
of data that is being transferred to the Intranet. In a traditional application development
process, this task is performed ad hoc by individual pages. Using our approach, we can using
annotation to communicate such restriction.
As shown in Listing 6 line 9, the annotation restricted will communicate the message
to the template that unless specifically requested, the field attachment will not be queried
automatically.
73
8 Related Work
Many contributions related to model transformation have been discussed in literature
[57, 124, 125]. A number of solutions to describe and implement model transformation are
currently available. Different top-level taxonomies can be found in [58], [126] and [127]. We
base our classification mainly on [58] and the following is a list of work that has the closest
relevance to our approach.
8.1 Direct-Manipulation Approach
Direct-manipulation approach offers an internal model representation plus some API to
manipulate it. Tools using this approach are usually implemented as an object-oriented
framework, which may also provide some minimal infrastructure to organize the transforma-
tions (e.g., abstract class for transformations). However, users have to implement transfor-
mation rules and scheduling mostly from scratch using a programming language such as Java.
The direct-manipulation approach consists of providing some visitor mechanism to traverse
the internal representation of a model and write code to a text stream. An example of this
approach is Jamda [60], which is an object-oriented framework providing a set of classes to
represent UML models, an API for manipulating models, and a visitor mechanism (so called
CodeWriters) to generate code. Jamda does not support the MOF standard for defining
new metamodels; however, new model element types can be introduced by subclassing the
existing Java classes that represent the predefined model element types.
Jamda is an open-source framework for building application generators which create Java
code from a model of the business domain. Instead of a generator which produces one
74
fixed architecture, Jamda provides a structure and building blocks so that you can build
an application generator which does exactly what your project needs. It includes a sample
generator for J2EE applications which can either be tailored to the needs of your J2EE
project, or used as the basis of a generator for a completely different architecture.
From a UML model of the application domain, a generator created with Jamda could create
the code for all the standard functions of locating, displaying and updating the business
objects in the application. The developer would then concentrate on the application-specific
business logic, which is merged into the generated application.
An application generator built using Jamda would perform the role of a model compiler in
the Object Management Group’s Model Driven Architecture specification. It takes a UML
domain model as input, adds new classes to the model to support the implementation, and
then generates executable code.
The advantage of the Direct-Manipulation Approach is that it doesn’t require an addi-
tional mechanism to represent the metamodel, instead it traverses the internal representation
directly. However, both [58] and [126] point out it is also it’s weakness because it requires
user implement transformation rules and scheduling mostly from scratch using programming
language such as Java. This makes the transformation process cumbersome and also makes
reusing the transformation almost impossible.
8.2 Transformation using XSLT
Extensible Stylesheet Language Transformations (XSLT) is an XML-based language used
for the transformation of XML documents into other XML. XSLT may be used effectively
for some class of transformations of MOF models, as they may be represented as XML
75
documents via the XMI specification [128].
XMI is the basic language that helps to perform transformations among UML models
as well as between UML models and other notations (especially code and other modelling
languages). To realize XMI transformations it must be possible to get structured data out
of the XMI documents. A promising approach is to use a standardized XML query or
transformation language. There are several such languages [129] and the XSLT is the most
widely used.
St-Denis et al. [130] compare various model interchange formats, e.g. RSF, XIF, XMI, and
discuss the implementation details of an XMI-based model interchange engine. They identify
the XMI’s support for differential model exchange as vital for the scalability, which is one
of the requirements they use to assess the formats. Keienburg and Rausch [131] present an
infrastructure for model evolution, schema migration and data instance migration, which is
based on UML models. Successive differences on the evolution path are represented using
the XMIs differential elements. Yoda [131] presents an approach to developing applications
using parameterize frameworks. The approach applies to the OMGs Model Driven Archi-
tecture (MDA). He recognizes model transformations as a way to customize predefined and
parameterize frameworks.
Since models can be serialized as XML using XMI, implementing model transformations
using XSLT, which is a standard technology for transforming XML, seems very attractive.
Unfortunately, this approach has severe scalability limitations. Manual implementation of
model transformations in XSLT quickly leads to non-maintainable implementations because
of the verbosity and poor readability of XMI and XSLT. A solution to overcome this problem
is to generate the XSLT rules from some more declarative rule descriptions, as demonstrated
76
in [132,133]. However, even this approach suffers from poor efficiency because of the copying
required by the pass-by-value semantics of XSLT and the poor compactness of XMI.
8.3 Template-Based Approaches
Our approach belongs to Template-Based approaches, and the majority of currently avail-
able MDA tools support template-based model-to-code generation, e.g., JET, FUUT-je,
Codagen Architect, AndroMDA, ArcStyler, OptimalJ and XDE (the latter two also provide
model-to-model transformations). AndroMDA [134] reuses existing open-source template-
based generation technology: Velocity [135] and XDoclet [136].
A template usually consists of the target text containing splices of metacode to access
information from the source and to perform code selection and iterative expansion (see [137]
for an introduction to template-based code generation). Template approaches usually offer
user-defined scheduling in the internal form of calling a template from within another one.
The logic accessing the source model may have different forms. The logic could be simply
Java code accessing the API provided by the internal representation of the source model
(e.g., JMI), or it could be declarative queries (e.g., in OCL or XPath [111]).
Compared to a Direct-Manipulation transformation, the structure of a template resembles
more closely the code to be generated. Templates lend themselves to iterative development
as they can be easily derived from examples. Since the template approaches discussed
in this section operate on text, the patterns they contain are untyped and can represent
syntactically or semantically incorrect code fragments. On the other hand, textual templates
are independent of the target language and simplify the generation of any textual artifacts,
including documentation.
77
In our evaluation chapter, we choose AndroMDA as an example. This is in consideration
of AndroMDA being a typical transformation tools that uses template-based approach and
the availability of AndroMDA documentations. AndroMDA is a code generation tool that
takes a UML model as input and generates source code as output. It adopts a template-
based transformation methodology similar to ours in a degree but differs significantly in
handling of metamodel. Both have an extensible architecture consists of cartridges. These
cartridges generate the code specific to a certain concrete technical platform. However, the
fundamental difference between these two approaches are the metamodel that they base
upon. AndroMDA uses MOF while we use HRM. Because of the complexity of the MOF
compliant metamodel, when AndroMDA traverses its AST objects, it has to access them via
a proprietary JMI interfaces, metamodel facades. Comparing to AndroMDA, our approach
simplified the transformation template development by adopting a concise, tree-structure
metamodel.
8.4 QVT(Queries/Views/Transformations)
Model transformation is a critical component of model-driven architectures (MDA). Recog-
nizing this, a Request for proposal (RFP) was issued by OMG in 2002, on MOF Query/View/-
Transformation to seek a standard compatible with the MDA recommendation suite (UML,
MOF, OCL, etc.) [19]. Several replies were provided by a number of companies and re-
search institutions that evolved during three years to produce a common proposal that was
submitted and approved [21–23].
Presently there are several products (commercial or open source) that claim compliance
to the QVT standard. QVT defines a standard way to transform source models into target
78
models. There are several ideas in this proposal. One is that the source and target models
may conform to arbitrary MOF metamodels. Another one is that the transformation program
is considered itself as a model, and as a consequence also conforms to a MOF metamodel.
This means more precisely that the abstract syntax of QVT should conform to a MOF 2.0
metamodel.
As a matter of fact, this is a bit more complex. First the QVT language integrates the
OCL 2.0 standard and also extends it to imperative OCL. Second QVT defines not one
but three domain-specific languages named Relations, Core and Operational Mappings and
these languages are organized in a layered architecture. Relations and Core are declarative
languages at two different levels of abstraction, with a normative mapping between them.
The Relations language has a textual and a graphical concrete syntax. The QVT/Opera-
tionalMapping language is an imperative language that extends both QVT/Relations and
QVT/Core. The syntax of the QVT/OperationalMappings language provides constructs
commonly found in imperative languages (loops, conditions, etc.) [23].
Finally a mechanism called QVT/BlackBox for invoking transformation facilities expressed
in other languages (XSLT, XQuery) is also an important part of the specification. It is
especially useful for integrating existing non-QVT libraries and transformations.
For the time being the QVT standard only addresses model to model transformations,
model meaning some entity conforming to any MOF 2.0 metamodel. All transformations
of type model to text or text to model, whatever the text is (XML, Code, SQL, etc.), are
presently outside the scope of QVT and possibly subject to other standardization initiatives.
They may be viewed as alternative transformation DSLs in the MDA technical space.
Duddy et. al. [138] propose a transformation language which will meet the requirements
79
of QVT RFP, and several others besides. The language is declarative and patterns based.
Transformation descriptions are explicitly reusable and modular. Rules that make up such
descriptions may be aspect-driven, allowing for transformations to be written to address
semantic concepts rather than structural features. Peltier et al [62]. describe a transforma-
tion approach that operates on textual representations of models. The rules are expressed
as a model instance, and then translated into a form that manipulates the textual docu-
ments. The current implementation uses XMI as the textual model format, and generates
XSLT [139] from the model of the transformation rules which can then be applied to the
XMI documents [22,140]. ATL(ATLAS Transformation Language) [141] is a model transfor-
mation language (MTL) developed by OBEO and INRIA to answer the QVT Request For
Proposal. We choose ATL as an example for evaluation in the next chapter. Similar to the
reason of choosing AndroMDA in template-based approach, this is in consideration of ATL
being representative in this category and its availability of documentation.
80
9 Evaluation of Transformation Tools
Chapter 7 showcases what our approach can achieve as a MDE framework. Many of the
features that the framework demonstrated are shared by some existing MDE tools. Chapter
8 lists a set of model transformation approaches that are closely related to our approach.
However, what distinguishes our approach from others is the methodology that we adopted.
The purpose of this chapter is to compare our model transformation approach with other
tools to evaluate its strengths and weaknesses. This chapter is organized as follows. First,
we introduce a set of metrics that we use to evaluate the transformation tools. Second,
we discuss four individual tools that represent the four primary transformation approaches.
These four tools will be compare against HRMR. Finally, we present the evaluation result.
As readability of metamodel and transformation definition is one of the advantages of
our approach, we need to look deeper into the metrics that measure this quality. A large
number of software product metrics have been proposed for the quality of software such
as maintainability. Many of these metrics have not been properly validated due to poor
methods of validation and non acceptance of metrics on scientific grounds [142,143]. In the
literature, two types of validations, namely internal(theoretical) and external(empirical) are
recommended [144]. Internal validation is a theoretical exercise that ensures that the metric
is a proper numerical characterization of the property it claims to measure. Demonstrating
that a metric measures what it purports to measure is a form of theoretical validation.
External validation involves empirically demonstrating that a metric can be an important
component or predictor of some software attributes of interest.
Kumar and Soni [145] have proposed a hierarchical model to evaluate qualities of object-
81
Table 13: Explanation of Metric Factor
Metric ExplanationSource Model Total Lines number of lines in the text of source modelSource Model Total Tokens number of tokens in the text of source modelTemplate Total Lines number of lines in templateTemplate Model Total Tokens number of tokens in templateSource Model Nesting Depth deepest nesting level of source modelTemplate Model Nesting Depth deepest nesting level of templateCross Reference in Source Model number of cross reference in source modelInner Cross Reference in Source Model number of inner cross reference in source modelOuter Cross Reference in Source Model number of outer cross reference in source modelCross Reference in Template number of cross reference in templateInner Cross Reference in Template number of inner cross reference in templateOuter Cross Reference in Template number of outer cross reference in templateReference to Metamodel in Template number of reference to metamodel in templateUnique Reference to Metamodel in Template unique reference to metamodel in template
oriented software. This proposed model has been used for evaluation of maintainability
assessment of object-oriented design quality, especially in design phase. In this model, qual-
ity factors such as maintainability are measured by a set of metrics such as Number of
Classes(NOC), Number of Ancestors(NOA) and Number of Methods(NOM). In [146], they
present empirical experiments to validate this hierarchical model of object-oriented design
quality metrics. We will introduce a set of metrics that we identified for readability, shown in
Table 13. We will explain what each metric means and the rationale of choosing it. Although
we do not conduct individual validation of each metric, our choices of metrics are following
the same practice demonstrated in Kumar and Soni’s study [145], and can be validated using
a similar framework presented in [146].
We will further discuss these metrics by giving their definition and additional explanation.
• Source Model Total Lines(STotalLine)
82
Definition: The total line number of textualized source model excluding comments and
empty lines.
The length of a document affects its readability directly. We measure total line number
because it reflects the length of a document. In our evaluation, two kinds of textual
source models are involved, ZOOM and XMI. Those metrics that are related to source
model reflect the differences between ZOOM textual file and XMI files.
• Source Model Total Tokens(STotalToken)
Definition: The total token number of textualized source model excluding comments.
Two documents that have the same total line number don’t necessarily have the same
length. The one with more tokens is a longer document. So tatal token number is a
measurement of document length in addition to total line number. That is why we
measure total token number of a document. As mentioned above, the comparison of
source models are between ZOOM textual file and XMI files.
• Template Total Lines(TTotalLine)
Definition: The total line number of textualized template excluding comments and
empty lines.
All four tools except Jamda use template to represent transformation rules. Jamda
uses Java API to directly manipulate metamodel. In Jamda’s case, the source code of
Java API is the equivalence of template and will be evaluated the same way as other
tools.
• Template Model Total Tokens(TTotalToken)
83
Definition: The total line number of textualized template excluding comments.
As mentioned above, in the case of Jamda, Java API source code will be evaluated as
template.
• Source Model Nesting Depth(SNestDepth)
Definition: The depth of the deepest nested node in source model.
Nesting depth reflects the levels of hierarchical document. The more levels a hierar-
chical document has, the harder it is for a reader to locate relevant information, which
is why we choose it as an important factor of readability. For example, in the case of
XMI, the depth of a node is clearly defined by XML standard. In other file format
such as ZOOM textual file, we treat bracket {"” and "}" as the delimiter to count the
depth of the deepest nested part of text.
• Template Model Nesting Depth(TNestDepth)
Definition: The depth of the deepest nested node in template.
As mentioned above, in the case of Jamda, Java API source code will be evaluated as
template. And in case of textual files not in XML format in Listing 9, we treat bracket
"{" and "}" as the delimiter to count the depth of the deepest nested part of text.
• Cross Reference in Source Model(SCrossReference)
Definition: A cross reference in the source model is defined as a node or a part of text
that explicitly uses different nodes or parts of text by referencing.
We use the cross reference as an important factor for readability because a cross refer-
ence in a text requires a reader to locate information that is not adjacent to the current
84
text, which makes the document harder to read. We count all reference to nodes that
is not in the local node as cross references. For example, in the excerpt of XMI format
model in Listing 7, Line 12 is a cross reference to node in line 3. In this excerpt, both
Line 12 and 13 will be counted as cross references.
1
2 ...
3 <ownedAttribute xmi:type=’uml:Property ’
4 xmi:id=’_16_6beta_1b480488_ ... _104555_582 ’
5 name=’team’ visibility=’private ’ ... >
6 ...
7 </ownedAttribute >
8 ...
9 <packagedElement xmi:type=’uml:Association ’
10 xmi:id=’_16_6beta_1b480488_ ... _329989_581 ’
11 name=’playerTeam ’ visibility=’public ’>
12 <memberEnd xmi:idref=’_16_6beta_1b480488_ ... _104555_582 ’/>
13 <memberEnd xmi:idref=’_16_6beta_1b480488_ ... _137486_583 ’/>
14 </packagedElement >
15 ...
Listing 7: Excerpt from XMI model
• Inner Cross Reference in Source Model(SInnerCrossReference)
Definition: An inner cross reference in source model is defined as a node or a part
of text that explicitly use different nodes or parts of text within the source model by
referencing.
Inner cross reference is a subset of the cross reference . When a cross reference use only
the node or part of text within the source model, it is counted as inner cross reference.
For example, in the excerpt of XMI format model in Listing 7, Line 12 is an inner cross
reference to node in line 3.
• Outer Cross Reference in Source Model(SOuterCrossReference)
85
Definition: An outer cross reference in source model is defined as a node or a part
of text that explicitly use different node or part of text outside the source model by
referencing. Outer cross reference is a subset of the cross reference . When a cross
reference use the node or part of text that is not included in the source model, it is
counted as outer cross reference.
• Cross Reference in Template(TCrossReference)
Definition: A cross reference in template is defined as a node or a part of text that
explicitly use different node or part of text by referencing.
1 ...
2 <xsl:template match="/">
3 <xsl:for -each select="Content/Class">
4 <xsl:call -template name="java -class">
5 ...
6 </xsl:call -template >
7 </xsl:for -each >
8 </xsl:template >
9 ...
10 <xsl:template name="java -class">
11 ...
12 </xsl:template >
Listing 8: Excerpt from a XSLT template
Similar to cross reference in source model, we use the cross reference within template
as important factors, because a cross reference in a text will require reader to locate
information that is not adjacent to the current text. We count all reference to nodes
that is not in the local node as cross references. For example, in the excerpt of XSLT
template in Listing 8, Line 4 is a cross reference to node in line 10. In this excerpt,
one cross reference will be counted.
• Inner Cross Reference in Template(TInnerCrossReference)
86
Definition: An inner cross reference in template is defined as a node or a part of text
that explicitly use different node or part of text within the template by referencing.
Inner cross reference in template is a subset of cross reference in template. When a
cross reference use only the node or part of text within the template, it is counted as
inner cross reference. For example, in the excerpt of XSLT template in Listing 8, Line
4 is a inner cross reference to node in line 10.
• Outer Cross Reference in Template(TOuterCrossReference)
Definition: An outer cross reference in template is defined as a node or a part of text
that explicitly use different node or part of text outside the template by referencing.
Outer cross reference in template is a subset of cross reference in template. When a
cross reference use the node or part of text outside the template, it is counted as outer
cross reference.
• Reference to Metamodel in Template(MetaReference)
Definition: A reference to metamodel in template is defined as any value inquiry to
metamodel in the form of variable.
1
2 public $target.getterSetterTypeName ${target.getterName }()
3 {
4 return this.${target.name};
5 }
6
7 public void ${target.setterName}
8 ($target.getterSetterTypeName $target.name)
9 {
10 this.${target.name } = ${target.name};
11 }
Listing 9: Excerpt from an AndroMDA template
87
Transformation templates provide the rules or instructions of how source model will
be transferred. It is critical for template to reference to metamodel so that it can get
the necessary information. This is accomplished by special variables that functions as
placeholder for real value. Since more references to metamodel means additional steps
to get real values from metamodel, this implies a more complicated template definition.
That is why we choose this metric. For example, in excerpt of AndraMDA template in
Listing 9, all variable start with $ is a reference to metamodel. In this excerpt, eight
reference to metamodel will be counted.
• Unique Reference to Metamodel in Template(UniqueMetaReference)
Definition: A unique reference to metamodel in template is defined as any unique value
inquiry to metamodel in the form of variable.
Unique reference to metamodel in template is a subset of reference to metamodel in
template. For example, in excerpt of AndraMDA template in Listing 9, three appear-
ance of ${target.name} will only be counted as one unique reference to metamodel.
In this excerpt, 4 unique references to metamodel will be counted.
In the remaining sections of this chapter, we choose one individual tool representing each
transformation approaches that are discussed in Chapter 8. How transformation is accom-
plished in each of this tool is discussed. After that, an evaluation using above mentioned
metrics will be presented and discussed.
88
9.1 Transformation Tools Being Evaluated
9.1.1 Direct-Manipulation Approaches: Jamda
Direct-manipulation approach consists in providing some visitor mechanism to traverse
the internal representation of a model and write code to a text stream. An example of this
approach is Jamda [60], which is an object-oriented framework providing a set of classes
to represent UML models, an API for manipulating models, and a visitor mechanism (so
called CodeWriters) to generate code. Jamda does not support the MOF standard to define
new metamodels; however, new model element types can be introduced by subclassing the
existing Java classes that represent the predefined model element types.
Jamda takes a UML model as its input. This would usually be exported in XMI format
by a case tool such as MagicDraw. To better demonstrate the difference between XMI
and ZOOM notation as the source model, we use the Roster model described in Section 5,
Figure 7.
For example, we show a fragment of the template that builds a file for each of the Java
class tags in Listing 10.
Using Jamda to generate code involves a series of steps, including the followings:
• Define your system architecture
Before starting to generate code, the user must define what he or she wants it to
produce, and also define the different layers, or tiers, in the system.
• Create new metamodel elements
For each of the kinds of classes or interfaces in the system architecture, it is necessary to
89
create a new Jamda metamodel class. The new class extends ClassType if it represents
generated classes, or InterfaceType if it represents generated interfaces.
1
2 <uml:Model xmi:id=’eee_1045467100313_135436_1 ’
3 name=’Data’ visibility=’public ’>
4 <xmi:Extension extender=MagicDraw UML 16.6 beta>
5 <moduleExtension ignoredInModule=’true’/>
6 </xmi:Extension >
7 <ownedComment xmi:type=’uml:Comment ’
8 xmi:id=’_16_6beta_1b480488_1252005317266_589964_343 ’
9 body=Author:jordanadmin . Created:9 /3/09 2 :15 PM .
10 Title: . Comment: . >
11 <annotatedElement xmi:idref=’eee_1045467100313_135436_1 ’/>
12 </ownedComment >
13 <packagedElement xmi:type=’uml:Class ’
14 xmi:id=’_16_6beta_1b480488_1252005357037_50629_501 ’
15 name=’Team’ visibility=’public ’>
16 <ownedAttribute xmi:type=’uml:Property ’
17 xmi:id=’_16_6beta_1b480488_1252005383473_580357_519 ’
18 name=’teamId ’ visibility=’private ’>
19 <type xmi:type=’uml:PrimitiveType ’
20 href=’http:// schema.omg.org/spec/UML /2.2/ uml.xml#String ’>
21 <xmi:Extension extender=’MagicDrawÃUML Ã16.6Ã beta’>
22 <referenceExtension
23 referentPath=UML Standard Profile::UML2 Metamodel
24 ::AuxiliaryConstructs::PrimitiveTypes
25 ::String ’ÃreferentType=’PrimitiveType/>
26 </xmi:Extension >
27 </type>
28 </ownedAttribute >
Listing 10: XMI Excerpt
• Create Model Transformers
The user needs to create one or more ModelTransformer implementations. The user
could have one large ModelTransformer that carries out all the transformations, or
divide it up into one for each kind of class to be generated.
• Create the configuration
90
Once the Model Transformer classes are created, the user needs to create a model
compiler configuration to run them in the appropriate sequence. The final step will
usually be to generate code by running the standard CodeGenTransformer.
As shown by these steps, when using Jamda much of the work that is done by our trans-
formation framework must be done by users. For example, a Jamda user needs to create a
metamodel class each time he uses the system, while in our framework, the metamodel is
pre-defined in the system. And there is no extensible mechanism in Jamda.
9.1.2 Transformation using XSLT: Stylus Studio
Extensible Stylesheet Language Transformations (XSLT) is an XML-based language used
for the transformation of XML documents into other XML document. XSLT may be used
effectively for some class of transformations of MOF models, as they may be represented as
XML documents via the XMI specification.
Stylus Studio is an advanced XML Integrated Development Environment (XML IDE) for
building advanced XML applications. It supports using the XSLT processor to generate Java
code. The XSLT processor ordinarily takes two input files - an XML source document, and
an XSLT stylesheet. The XSLT stylesheet contains the XSLT program text and is itself an
XML document that describes a collection of template rules: instructions and other hints
that guide the processor toward the production of the output document. Since XSLT must
be written in terms of the concepts in the source XMI document (model), and object (or
element) creation explicit, the style is highly procedural and not easily extensible. Due to
its XML basis, the concrete syntax is very user unfriendly. As such, it is unsuitable for
one of the major goals of a declarative transformation language - which is to communicate
91
mapping specifications to human beings. It also requires a complete document as input, and
is therefore not amenable to transforming incremental updates to models.
1
2 <xsl:template match="/">
3 <xsl:for -each select="Content/Class">
4 <xsl:variable name="filename"
5 select="concat(’output/’,@name ,’Base.java ’)" />
6 <xsl:message >Creating
7 <xsl:value -of select="$filename" /></xsl:message >
8 <xsl:document href="{$filename}" method="text">
9 <xsl:call -template name="java -class">
10 <xsl:with -param name="class" select="." />
11 <xsl:with -param name="associations"
12 select="/Content" />
13 </xsl:call -template >
14 </xsl:document >
15 </xsl:for -each >
16 </xsl:template >
17
18 <!-- The main template for a Java class -->
19
20 <xsl:template name="java -class">
21 <xsl:param name="class" />
22 <xsl:param name="associations" />
23 /* This file has been generated */
24
25 import java.util .*;
26
27 public class <xsl:value -of select="$class/@name" /> {
Listing 11: XSLT template for creating a file
For example, we show a fragment of a template that builds a file for each of the Java class
using XSLT and HRMT approach in Listing 11 and Listing 12.
Compared to XSLT, our approach provides a shorter template language syntax. In most
cases, transformation developer just need to fill in the syntax details of target platform when
writing the specific template.
92
9.1.3 Template-Based Approaches: AndroMDA
AndroMDA is a code generation tool that takes a UML model as input and generates
source code as output. It adopts a template-based transformation methodology similar to
ours in a degree but differs significantly in handling of metamodel. Compared to direct-
manipulation transformation, the structure of a template resembles more closely the code
to be generated. Templates lend themselves to iterative development as they can be easily
derived from examples. Since the template approaches discussed in this section operate on
text, the patterns they contain are untyped and can represent syntactically or semantically
incorrect code fragments. On the other hand, textual templates are independent of the target
language and simplify the generation of any textual artifacts, including documentation.
1 <Rule match="Struct">
2 <Pre >
3 <File name="${name}.java">
4 import java.util .*;
5
6 class ${name } {
7 <MacroRef name="${name}. attrDef"/>
8 <MacroRef name="${name}. constrDef"/>
9 <MacroRef name="${name}. operDef"/>
10 }
11 </File >
12 </Pre >
13 </Rule >
Listing 12: Transformation template for creating a file using HRMT approach
Using a series of template files (which you can customize if you wish), AndroMDA can
produce source code from a UML model in any programming language. Default templates
exist to generate Java code (and in particular J2EE code) [134, 147]. AndroMDA was de-
signed to get the information necessary to generate code from MOF compliant models inside
a MOF repository. On the other hand, at the heart of the code generator is a set of dy-
93
namic content templates, which can easily be replaced in order to support different target
platforms. AndroMDA is based on Netbeans Metadata Repository(MDR) [148]. MDR is an
implementation of OMG. Basically, MDR is able to load arbitrary models based on arbitrary
metamodels, provided that you load the metamodel into MDR before you load the model.
1
2 package org.andromda.metafacades.uml14;
3
4 /**
5 * Metaclass facade implementation.
6 */
7 public class AttributeFacadeLogicImpl
8 extends AttributeFacadeLogic
9 {
10 public AttributeFacadeLogicImpl(
11 org.omg.uml.foundation.core.Attribute metaObject ,
12 String context)
13 {
14 super(metaObject , context );
15 }
16
17 /**
18 * @see org.andromda.metafacades.uml.AttributeFacade#getGetterName()
19 */
20 public java.lang.String handleGetGetterName ()
21 {
22 return UMLMetafacadeUtils.getGetterPrefix(this.getType ())
23 + StringUtilsHelper.capitalize(this.getName ());
24 }
25
26 /**
27 * @see org.andromda.metafacades.uml.AttributeFacade#getSetterName()
28 */
29 public java.lang.String handleGetSetterName ()
30 {
31 return "set" + StringUtils.capitalize(metaObject.getName ());
32 }
33
34 ...
35 }
Listing 13: Metafacades example
94
Figure 14: Model Transformation Process Comparison
MDR uses the MOF-to-Java mapping called JMI (Java Metadata Interface) [149], reads
metamodels as XMI and generates JMI interface byte code for them. However, because of the
intrinsic complexity of the MOF repository, AndroMDA uses Metafacades which are facades
that are used to provide access to models loaded by a MDR repository. These “metafacades”
provides a simpler access mechanism to the metamodel, but they also create one extra level
of complexity that model transformation developers have to deal with.
Both AndroMDA and our approach are template-based, metamodel-based model trans-
formation frameworks that support code generation. Both have an extensible architecture
that consists of cartridges. These cartridges generate the code specific to a certain concrete
technical platform. However, the fundamental difference between these two approaches are
the metamodel that they are based upon. AndroMDA uses MOF while we use HRM.
Because of the complexity of the MOF compliant metamodel, when AndroMDA traverses
its AST objects, it has to access them via proprietary JMI interfaces and metamodel facades.
Compared to AndroMDA, our approach simplified the transformation template development
95
by adopting a concise, tree-structure metamodel.
1 <metafacades >
2 ...
3 <property reference="arrayNamePrefix"default="ArrayOf"/>
4 <property reference="schemaTypeMappingsUri"/>
5 <metafacade class=org.andromda.cartridges.webservice
6 .metafacades.WSDLTypeLogicImpl"contextRoot="true >
7 <mapping class="org.omg.uml.foundation.core.Classifier$Impl"/>
8 </metafacade >
9 <metafacade class=org.andromda.cartridges.webservice
10 .metafacades.WSDLTypeLogicImpl"contextRoot="true >
11 <mapping class="org.omg.uml.foundation.core.UmlClass$Impl"/>
12 </metafacade >
13 <metafacade class=org.andromda.cartridges.webservice
14 .metafacades.WSDLTypeLogicImpl"contextRoot="true >
15 <mapping class="org.omg.uml.foundation.core.DataType$Impl"/>
16 </metafacade >
17 <metafacade class=org.andromda.cartridges.webservice
18 .metafacades.WSDLEnumerationTypeLogicImpl >
19 <mapping class="org.omg.uml.foundation.core.Classifier$Impl">
20 <stereotype >ENUMERATION </ stereotype >
21 </mapping >
22 </metafacade >
23 <metafacade class=org.andromda.cartridges.webservice
24 .metafacades.WSDLEnumerationTypeLogicImpl >
25 <mapping class="org.omg.uml.foundation.core.Interface$Impl">
26 <stereotype >ENUMERATION </ stereotype >
27 </mapping >
28 </metafacade >
29 ...
30 </metafacades >
Listing 14: Part of a typical metafacades descriptor
Figure 14 shows the steps involved in model transformation in our approach and An-
dromda.
Writing metafacades is a non-trivial task. The user of a cartridge will load a model into
AndroMDA and the metadata repository in AndroMDA will instantiates a metaobject for
each element of the user’s model. After this, AndroMDA optionally instantiate a metafacade
96
object that shields the metaobject. After that, a metafacades developer can locate those
classes that end with ”LogicImpl” in their names. These classes have been generated but
will never be touched by the generator again. This is the place where metafacades developers
implement their own logic.
Listing 13 shows an example of a LogicImpl class.
The metafacade descriptor allows the AndroMDA Core to discover a set of metafacades
on the classpath automatically. The AndroMDA Core also uses this descriptor to determine
what metafacades must be mapped to what meta model objects. The metafacades descriptor
must reside within the META-INF subdirectory of your cartridge (or shared metafacades
library) and must be named andromda-metafacades.xml. A typical metafacades descriptor
is shown in Listing 14.
9.1.4 QVT(Queries/Views/Transformations): ATL
Presently there are several products (commercial or open source) that claim compliance
to the QVT standard. QVT defines a standard way to transform source models into target
models.
ATL is a model transformation language (MTL) developed by OBEO and INRIA to answer
the QVT Request For Proposal. It can be used to do syntactic or semantic translation. ATL
is built on top of a model transformation Virtual Machine. A model-transformation-oriented
virtual machine has been defined and implemented to provide execution support for ATL
while maintaining a certain level of flexibility. As a matter of fact, ATL becomes executable
simply because a specific transformation from its metamodel to the virtual machine byte
code exists. Extending ATL is therefore mainly a matter of specifying the new language fea-
97
tures execution semantics in terms of simple instructions: basic actions on models (elements
creations and properties assignments).
1
2 module UML2JAVA;
3 create OUT : JAVA from IN : UML;
4
5 rule C2C {
6 from e : UML!Class
7 to out : JAVA!JavaClass (
8 name <- e.name ,
9 isAbstract <- e.isAbstract ,
10 isPublic <- e.isPublic(),
11 package <- e.namespace
12 )
13 }
14
15 rule A2F {
16 from e : UML!Attribute
17 to out : JAVA!Field (
18 name <- e.name ,
19 isStatic <- e.isStatic(),
20 isPublic <- e.isPublic(),
21 isFinal <- e.isFinal(),
22 owner <- e.owner ,
23 type <- e.type
24 )
25 }
Listing 15: ATL Rule example
Figure 15 shows the steps involved in model transformation in ATL. As shown in Figure 15,
the ATL approach takes model Ma.xmi as input and produces model Mb.xmi as output. Both
models may be expressed in the OMG XMI standard. The model Ma conforms to meta-
model MMa. Model Mb conforms to metamodel MMb. An ATL transformation template is
composed of a header, of a set of side-effect free functions called helpers and of a set of rules.
Since the abstract syntax of QVT conform to MOF 2.0 metamodel, one of the strengths
of our approach again is adopting a concise, tree-structure metamodel, HRM. Because of
98
Figure 15: ATL Approach
the simplified metamodel, when transformation engine traverses its AST objects, it can have
direct access to the properties of the objects. This facilitates model transformer to develop
transformation template in a easier and quicker way. Secondly, for the time being the QVT
standard only addresses model to model transformations. All transformations of type model
to text, whatever the text is (XML, Code, SQL, etc.), are presently outside the scope of
QVT and possibly subject to other standardization initiatives. This is a restriction that
our approach doesn’t have, which make our approach more desirable in a code generation
scenario.
In the case of ATL, we can see the difference both from the input model and output model.
ATL use XMI in both input and output model, this makes the model specification much
more verbose than our approach. Also, ATL will require additional steps to accomplish code
generation. There is an associated ATL Development Toolkit plug in available in open source
from the GMT Eclipse Modeling Project (EMP) that implements the ATL transformation
99
language. More detail about that can be found in [150]
1
2 helper context UML!ModelElement def: isPublic () : Boolean =
3 self.visibility = # vk_public;
4
5 helper context UML!Feature def: isStatic () : Boolean =
6 self.ownerScope = # sk_static;
7
8 helper context UML!Attribute def: isFinal () : Boolean =
9 self.changeability = # ck_frozen;
10
11 helper context UML!Namespace def: getExtendedName () : String =
12 if self.namespace.oclIsUndefined () then
13 ’’
14 else if self.namespace.oclIsKindOf(UML!Model) then
15 ’’
16 else
17 self.namespace.getExtendedName () + ’.’
18 endif endif + self.name;
Listing 16: ATL Helper
Listing 15 shows an excerpt of ATL code for the transformation of a UML to Java consists
of several functions and rules.
ATL helpers can be viewed as the ATL equivalence to Java methods. They make it
possible to define factorized ATL code that can be called from different points of an ATL
transformation. Listing 16 shows an excerpt of a typical helper specification. By organizing
transformation rules in modules, ATL provides some extensibility. However it is a lower
level of extensibility compared to AndroMDA and HRMT, where rules are organized in
interchangeable units called cartridges.
9.2 Evaluation Result
After studying how these tools worked, we conducted an experimental trial on each of
them. In the trial case, we used the CSL Roster example mentioned in Chapter 4. Using
100
Table 14: Evaluation Result of Source Model
HRMT Jamda/ Stylus/AndroMDA/ ATLTest Case Generate Java code for RosterMetamodel HRM MOFInput Format ZOOM XMISTotalLine 33 266STotalToken 67 1612SNestDepth 2 8SCrossReference 4 45SInnerCrossReference 4 27SOuterCrossReference 0 18
PIM shown in Listing 2 and Figure 7, we generated Java code with each of the tools and
evaluated the transformation using the metrics mentioned above.
9.2.1 Evaluation Result Reflecting Metamodel Complicity
Since all four tools use XMI as the format of the source model, the metrics evaluation is
between the ZOOM input format and XMI format. We show the results in Table 14 and
Figure 16. Additionally, because the choice of input model reflects essentially the choice of
metamodel, it indeed reflects the complicity of HRM and MOF comparison.
We will discuss the evaluation result one by one:
• STotalLine
STotalLine counts the total line number of textualized source model excluding com-
ments and empty lines. The result in Table 14 shows that the total line number of
XMI model that represents the same Roster model is about 8 times as much as the
ZOOM model(266 vs. 33).
• STotalToken
101
Figure 16: Evaluation Result of Source Model
STotalToken counts the total token number of textualized source model excluding
comments. The result in Table 14 shows that the total token number of XMI model
that represents the same Roster model is about 24 times of the ZOOM model(1612
vs. 67). Considering that XMI model has about 8 times the total number of lines, the
average token number per line in XMI model is about 3 times as many as the ZOOM
model.
• SNestDepth
SNestDepth counts the depth of the deepest nested node in the source model. The
NestDepth of the XMI model is 8, as opposed to 2 of the ZOOM model. This difference
reveals that it will be much harder to trace a node’s ancestors and descendants.
• SCrossReference
SCrossReference counts those references that point to places other than current con-
102
text. The result in Table 14 shows that the XMI model has a much higher SCrossRef-
erence number(45 vs. 4). A cross reference in a text will require the reader to locate
information that is not adjacent to the current text. This result is a good indicator
that ZOOM model is more readable in terms of avoiding cross references.
• SInnerCrossReference
SInnerCrossReference counts only those SCrossReference that are within the source
model. The result in Table 14 shows that all CrossReference in ZOOM is InnerCross-
Reference(4 out of 4) and 60SInnerCrossReference number(27 vs. 4).
• SOuterCrossReference
SOuterCrossReference counts only those SCrossReference that are outside the source
model. The result in Table 14 shows that no CrossReference in ZOOM is InnerCross-
Reference(0 out of 4) and 40to read additional document to fully understand the source
model. It creates additional readability obstacle.
Overall the result in Table 14 shows that in all 6 metrics, ZOOM has significantly lower
value compared to XMI. The STotalLine and STotalToken show that XMI model is much
longer and verbose. The deeper nesting and significant amount of cross-references also made
the XMI model harder to read. The result demonstrates that using HRM can significantly
simplify the metamodel.
9.2.2 Evaluation Result Reflecting Transformation Complicity
The rest of the metrics are about the template. Since the template is the main document
that needs to be developed in the transformation process, these metrics reflect the trans-
103
Table 15: Evaluation Result of Template
HRMT Jamda Stylus AndroMDA ATLTest Case Generate Java code for RosterTTotalLine 44 652 82 207 70TTotalToken 108 1927 327 394 223TNestDepth 4 5 6 5 3TCrossReference 2 37 2 4 4TInnerCrossReference 2 27 2 4 4TOuterCrossReference 0 10 0 0 0MetaReference 17 47 39 73 32UniqueMetaReference 5 29 18 36 27
formation complicity. They are different from each other depending on the tools we are
measuring. Table 15 and Figure 17 shows the result of comparing all the tools.
First of all, Jamdas metric measurement needs to be clarified. Since Jamda belongs to
the Direct-Manipulation approach, it does not use a template like all the other tools do. So
the measurement is taken from the Java API that did the transformation directly. The Java
API in Jamda is treated as the equivalent of the template for measurement purpose. We
will discuss the evaluation result one by one:
• TTotalLine
TTotalLine counts the total line number of template excluding comments and empty
lines. The result in Table 15 shows that HRMT has the lowest TTotalLine number(44).
In other words, HRMT has the shortest template in this test case.
• TTotalToken
TTotalToken counts the total token number of template excluding comments. The
result in Table 15 shows that HRMT has the lowest TTotalToken number(108). In
104
Figure 17: Evaluation Result of Template
other words HRMT is the least verbose in this test case,
• TNestDepth
TNestDepth counts the depth of the deepest nested node in template. The result in
Table 15 shows that all five tools have similar TNestDepth(between 3-6).
• TCrossReference
TCrossReference counts those references that point to places other than current con-
text. The result in Table 15 shows that except Jamda all other four tools have similar
TCrossReference(between 2-4). Jamda has a significantly larger number of Cross-
Reference(37). This shows that Direct-Manipulation approach will use much more
CrossReference than other approaches.
• TInnerCrossReference
105
InnerCrossReference counts only those CrossReference that is within the template. The
result in Table 15 shows that except Jamda all other four tools have similar CrossRef-
erence(between 2-4). Jamda has a significantly larger number of CrossReference(27).
This shows that Direct-Manipulation approach will use much more InnerCrossRefer-
ence than other approaches.
• TOuterCrossReference
TOuterCrossReference counts only those CrossReference that is outside the template.
The result in Table 15 shows that except Jamda all other four tools don’t have TOuter-
CrossReference. Jamda has a 10 TOuterCrossReference. This shows that Direct-
Manipulation approach make use of OuterCrossReference while other approach don’t.
• MetaReference
MetaReference counts any value inquiry to metamodel in the form of variable. The
result in Table 15 shows that HRMT has the smallest number(17). Some of the value
inquiry is repetitive, so counting unique value inquiry or UniqueMetaReference is nec-
essary.
• UniqueMetaReference
UniqueMetaReference counts unique value inquiry to metamodel in the form of vari-
able. Again the result in Table 15 shows that HRMT has the smallest number(5). As
accessing metamodel is the crucial step in model transformation, requiring less number
of reference to metamodel reflects a simpler metamodel.
Overall in the case of TTotalLine and TTotalToken, HRMT uses the shortest template
106
Table 16: Evaluatin Result of Transformation Tools
Tool → HRMT Jamda Stylus AndroMDA ATLQuality ↓Readabilityof Metamodel High Low Low Low LowReadabilityof Transformation Definition High Low Medium Medium MediumExtensibility High None None High MediumAvailabilityof Supporting Tools Low High High High High
compared to others. It is about half of ATL and only a fraction of Jamda, Stylus, and
AndroMDA. Except for Jamda, there is no significant difference between nesting depth and
cross-reference amount of all the approaches. This implies that all the tools except Jamda
are used in a similar way to organize the template. The high number of CrossReference in
Jamda is because it is using Java API to perform the transformation directly, and Java API
organized their functions in different methods, files, and even in different packages. MetaRef-
erence and UniqueMetaReferenc are the most critical metrics because accessing metamodel
information is the crucial step in model transformation. The more times that transformation
has to access the metamodel, the more complicated the transformation process is. From the
evaluation result, we can see that HRMT comes out using the least number of references to
metamodel in both MetaReference and UniqueMetaReference. This is direct demonstration
of having a simplified metamodel.
We recognize the limitation of this evaluation with data collected from only one case study.
The results may vary to some extent when case studies of different scale and complexity are
included. However, this limitation is partly mitigated by the fact the case study used is
carefully chosen to represent a typical class of applications, and it is also used as the case
107
study by several other MDE tools.
It is necessary to point out that some of the lower values of metrics, namely total lines,
tokens and meta references, are affected by HRMT being a lightweight approach. It raises
the question of whether these values will go up if HRMT increases its functionalities. The
answer to this question has everything to do with our fundamental design. The lightweight
approach of using HRM for transformation will not change when adding additional function-
alities. The two essential documents of transformationsource model and template, should not
undergo any significant changes in further development. In other words, the trend of lower
values of these metrics will be kept. However, it is possible that because of this lightweight
design, HRMT may not accomplish all functionalities provided by an alternative approach,
or to accomplish a particular functionality, HRMT has to be fundamentally changed. That
scenario will present a good case study to delineate HRMTs limitation.
The evaluation results for both set of metrics that we discuss above illustrate that HRMT
provides a much shorter, less verbose and more readable source model and template. While
evaluating the transformation tools in Section 9.1, we also compared the extensibility of
each tool. What we found is that template-based transformation tools, namely AndraMDA
and HRMT have a higher level of extensibility than ATL, while Jamda and Stylus Studio
provide no extensible mechanism. However we are not claiming that HRMT exceeds in all
aspects as a transformation tool. Using XMI as the format of the source model does give
other tools some advantages over HRMT. The most obvious one being the availability of
supporting tools such as editors. While the ZOOM notation HRMT based upon is still
in research phrase, HRMT lacks such availability of supporting tools. Putting all these
evaluation results together, Table 16 shows the final result of our evaluation.
108
10 Conclusion
10.1 Contributions
This dissertation provides a solution that uses a simplified metamodel as the foundation
for building a template-based model transformation framework. This simplified metamodel
is called the Hierarchical Relational Metamodel(HRM). The Hierarchical Relational Meta-
model is built upon Z-based Object-Oriented Modeling notation (ZOOM). A template- based
model transformation framework using Hierarchical Relational metamodel (HRM) is intro-
duced. This framework aims to provide a simple, effective, and practical way to define
model transformations. The benefits of this transformation framework include 1) readability
and rigorousness of metamodel definitions; 2) simplicity of transformation definition; and 3)
support of non-functional requirements.
The design of the Hierarchical Relational Metamodel (HRM) provides us a simplified way
to understand and make use of the abstract syntax and semantics of the source models.
This in turn helps the implementation of our transformation tool, the Hierarchical Rela-
tional Metamodel Transformation tool(HRMT). A case study is provided to demonstrate
the validity and ability of HRMT. In this case study, a PIM represented by ZOOM notation
is transformed into a full-fledged web application that can run on multiple platforms. Com-
parisons with related research work are also provided to show the benefits of this framework.
We would like to point out that while HRMT shares many of the benefits of MDE ap-
proaches, it suffers from some of the limitations as well. One of these limitations is the
maintainability of the generated code. HRMT is a one-way transformation approach with
no support for reverse engineering from the generated code. The maintainability problem
109
can be alleviated if modification to the generated code can be limited by making the changes
in the models or the transformation instead . However, in reality, changes to the generated
code is sometimes unavoidable. To fully address the maintainability of generated code will
be a challenge for future work.
The main contribution of my research work is the design and realization of such a model
transformation framework. It fulfills the MDE’s promise of Transforming PIM to PSMs for
different platforms. However, many research projects and commercial tools can claim the
same thing. What distinguishes our approach from others will most potently demonstrate
the achievement of this research work. Such distinguished features of our approach are listed
below.
• Readability and rigorousness of metamodel definitions
Metamodeling is a critical part of our model transformation approach. The Hierarchical
Relational Metamodel(HRM) in our approach provides a mechanism to unambiguously
define modeling languages - ZOOM in our case. The formal specification notation Z
that ZOOM is based on ensures a mathematical rigorousness foundation. The tree
structure among model elements that maintained by HRM provides a simplified way
to read and make use of the abstract syntax and semantics of the source models.
our .
• Simplicity of transformation definition
The design of the Hierarchical Relational Metamodel (HRM) provides us a simplified
way to understand and make use of the abstract syntax and semantics of the source
110
models. The direct result of this a simplified template definition in our approach. This
is also demonstrated in the evaluation result in Chapter 9
• Support of non-functional requirements
The support of non-functional requirements by our approach is demonstrated by the
case study discussed in Chapter 7.
– Support of Security Requirements
Security standards such as Role-Based Access Control (RBAC) are successfully
adopted by modeling and model transformation.
– Support Performance Requirements
HRMT tool can be configured, through modeling, to control or improve the per-
formance of a target software application.
– Support of Scalability Requirements
Depends on the specifics of scalability requirements, HRMT tool can be config-
ured, through modeling or database script generation, to control the complicity
of the transformation result.
10.2 Future Work
We conclude this dissertation by summarizing some future research topics.
• Fine-tuning and optimizing the tool.
The case study in Chapter 7 demonstrates the validity of our approach and the ability
of our tool. No major development of the tool will be necessary. However, there are
111
areas such as the efficient management of templates that can be fine tuned.
• Integration with other tools.
As we pointed out in Section 2.3, one of the issues with XMI is its incompatibility with
different tools. In order for our tool to gain better recognition, it is important that we
provide a solution to the incompatibility issue in order to integrate our tool with other
tools.
• Interaction with other research fields.
While working on this dissertation, we came across a couple of research areas that have
significant overlap with our research. These research areas, such as model checking and
aspect-oriented programming, although not directly related to model transformation,
may provide more potential research opportunities.
112
References
[1] Stuart Kent. Model driven engineering. In Proc. IFM 2002. Springer-Verlag,
2002. LNCS Vol. 2335.
[2] Krishnakumar Balasubramanian, Aniruddha Gokhale, Gabor Karsai, Janos Szti-
panovits, and Sandeep Neema. Developing applications using model-driven de-
sign environments. Computer, 39(2):33, 2006.
[3] Jeff Gray, Yuehua Lin, and Jing Zhang. Automating change evolution in model-
driven engineering. Computer, 39(2):51, 2006.
[4] J. Poole. Model-driven architecture: Vision, standards, and emerging technolo-
gies. In ECOOP’01 – Object-Oriented Programming, 2001.
[5] Andy Lapping. Model driven development with ada. In SIGAda ’04: Proceedings
of the 2004 annual ACM SIGAda international conference on Ada, pages 19–22,
New York, NY, USA, 2004. ACM Press.
[6] Robert France and Bernhard Rumpe. Model-driven development of complex soft-
ware: A research roadmap. In FOSE ’07: 2007 Future of Software Engineering,
pages 37–54, Washington, DC, USA, 2007. IEEE Computer Society.
[7] Axel Uhl. Model-driven development in the enterprise. IEEE SOFTWARE,
25(1):46–49, 2008.
[8] Romain Rouvoy and Philippe Merle. Towards a model-driven approach to build
component-based adaptable middleware. In ARM ’04: Proceedings of the 3rd
113
workshop on Adaptive and reflective middleware, pages 195–200, New York, NY,
USA, 2004. ACM Press.
[9] Marcus Alanen, Johan Lilius, Ivan Porres, and Dragos Truscan. Model driven
engineering: A position paper. In Joao M. Fernandes, Johan Lilius, Ricardo J.
Machado, and Ivan Porres, editors, Proceedings of the 1st International Work-
shop on Model-Based Methodologies for Pervasive and Embedded Software MOM-
PES’04, number 29 in General Publications, pages 25–29. Turku Centre for Com-
puter Science, Jun 2004.
[10] UMLTM 2.2 Superstructure Specification. OMG Document formal/2009-02-04
(February, 2009).
[11] Robert B. France, Sudipto Ghosh, Trung Dinh-Trong, and Arnor Solberg. Model-
driven development using uml 2.0: Promises and pitfalls. Computer, 39(2):59,
2006.
[12] James Rumbaugh, Ivar Jacobson, and Grady Booch. The Unified Modeling Lan-
guage reference manual, 1998.
[13] Shane Sendall and Wojtek Kozaczynski. Model transformation: The heart and
soul of model-driven software development. IEEE Software, 20(5):42–45, 2003.
[14] Andrea D’Ambrogio. A model transformation framework for the automated
building of performance models from uml models. In WOSP ’05: Proceedings of
the 5th international workshop on Software and performance, pages 75–86, New
York, NY, USA, 2005. ACM Press.
114
[15] Jean Bzivin, Nicolas Farcet, Jean-Marc Jzquel, Benot Langlois, and Damien
Pollet. Reflective model driven engineering. In ”UML” 2003 - The Unified
Modeling Language. Springer-Verlag, 2003. LNCS Vol. 2863.
[16] J. Mukerji and J. Miller. Model-Driven Architecture. http://www.omg.org/cgi-
bin/doc?ormsc/2001-07-01.
[17] MDA guide. White Paper, June 2003. http://www.omg.org/mda.
[18] Object Management Group. Meta-Object Facility 1.4. OMG Document
formal/2002-04-03.
[19] MOF 2.0 Query / Views / Transformations RFP. OMG Document ad/04-10-02.
[20] J. Koehler T. Gardner, C. Griffin and R. Hauser. A review of OMG MOF 2.0
Query / Views / Transformations Submissions and Recommendations towards
the final Standard. OMG Document: ad/03-08-02.
[21] QVT-Partners. MOF Query/Views/Transformations, Revised Submission. OMG
Document: ad/2003-08-08.
[22] DSTC CBOP and IBM. MOF Query/Views/Transformations, Revised Submis-
sion. OMG Document: ad/03-08-03.
[23] MOF QVT final adopted specification. OMG Document ad/05-11-01.
[24] Ian Sommerville. Software Engineering. Addison-Wesley, 2001.
[25] Anthony Finkelstein and Jeff Kramer. Software engineering: a roadmap. In ICSE
’00: Proceedings of the Conference on The Future of Software Engineering, pages
3–22, New York, NY, USA, 2000. ACM Press.
115
[26] Kyle Eischen. Software development: An outsider’s view. Computer, 35(5):36–44,
2002.
[27] T. S. E. Maibaum. Mathematical foundations of software engineering: a
roadmap. In ICSE - Future of SE Track, pages 161–172, 2000.
[28] Donald J. Reifer. Is the software engineering state of the practice getting closer
to the state of the art? IEEE Softw., 20(6):78–83, 2003.
[29] Iva Jacobson, Grady Booch, and James Rumbaugh. The Unified Software De-
velopment Process. Addision-Wesley-Longman, 1999.
[30] Grady Booch. Object-oriented design. Ada Lett., I(3):64–76, 1982.
[31] Grady Booch. Object oriented design with applications. Benjamin-Cummings
Publishing Co., Inc., Redwood City, CA, USA, 1991.
[32] Michael G. Hinchey and Jonathan P. Bowen, editors. Applications of Formal
Methods. Prentice-Hall, 1995.
[33] Daniel Jackson and Jeannette Wing. Lightweight formal methods. IEEE Com-
puter, 29(4):21, April 1996.
[34] Albert F. Case. Computer-aided software engineering (case): technology for
improving software development productivity. SIGMIS Database, 17(1):35–43,
1985.
[35] James D. Mooney. Portability and reusability: common issues and differences.
In CSC ’95: Proceedings of the 1995 ACM 23rd annual conference on Computer
science, pages 150–156, New York, NY, USA, 1995. ACM Press.
116
[36] Dennis Smith, Edwin Morris, and David Carney. Interoperability issues affecting
autonomic computing. In DEAS ’05: Proceedings of the 2005 workshop on Design
and evolution of autonomic application software, pages 1–3, New York, NY, USA,
2005. ACM Press.
[37] Christof Ebert and Philip De Neve. Surviving global software development. IEEE
Softw., 18(2):62–69, 2001.
[38] Stephen J. Mellor, Anthony N. Clark, and Takao Futagami. Model-driven devel-
opment. IEEE Software, 20(5):14–18, 2003.
[39] Ed Seidewitz. What models mean. IEEE Software, 20(5):26–32, 2003.
[40] T.Levendovszky. Model reuse with metamodel-based transformations. In ICSR-
7, volume 2319 of Lecture Notes in Computer Science. Springer-Verlag, 2002.
[41] J. Bzivin. In search of a basic principle for model-driven engineering. In Novatica
Journal, Special Issue, 2004.
[42] Jean-Marie Favre. Towards a basic theory to model model driven engineering.
In Proc. WISME 2004, Lisboa, Portugal, 2004.
[43] Bran Selic. The pragmatics of model-driven development. IEEE Software,
20(5):19–25, 2003.
[44] Jeff Kramer. Abstraction and modelling – a complementary partnership. In
MoDELS ’08: Proceedings of the 11th international conference on Model Driven
Engineering Languages and Systems, pages 158–158, Berlin, Heidelberg, 2008.
Springer-Verlag.
117
[45] Yong Xia and Martin Glinz. Rigorous ebnf-based definition for a graphic mod-
eling language. In APSEC ’03: Proceedings of the Tenth Asia-Pacific Software
Engineering Conference Software Engineering Conference, page 186, Washing-
ton, DC, USA, 2003. IEEE Computer Society.
[46] M. Mezini. V. Cepa. Language support for model-driven software development.
In Special Issue Science of Computer Programming (Elsevier) on MDA: Foun-
dations and Applications Model Driven Architecture, 2004.
[47] Reinhard Gotzhein Robert Eschbach, Uwe Glsser and Andreas Prinz. On the
formal semantics of sdl-2000: A compilation approach based on an abstract
sdl machine. In Abstract State Machines - Theory and Applications: Interna-
tional Workshop, ASM 2000, Monte Verit, Switzerland, March 2000. Proceed-
ings. Springer-Verlag, 2000. LNCS Vol. 1912.
[48] Colin Atkinson and Thomas Kuhne. Model-driven development: A metamodel-
ing foundation. IEEE Software, 20(5):36–41, 2003.
[49] Torben Weis, Andreas Ulbich, and Kurt Geihs. Model metamorphosis. IEEE
Software, 20(5):46–51, 2003.
[50] Edsger Wybe Dijkstra. A Discipline of Programming. Prentice Hall PTR, Upper
Saddle River, NJ, USA, 1997.
[51] Adam Childs, Jesse Greenwald, Georg Jung, Matthew Hoosier, and John Hat-
cliff. Calm and cadena: Metamodeling for component-based product-line devel-
opment. Computer, 39(2):42, 2006.
118
[52] Dniel Varr. Model transformation by example. In In Proceedings of the
ACM/IEEE 9th International Conference on Model Driven Engineering Lan-
guages and Systems (MoDELS/UML 2006, page 410424. Springer, 2006.
[53] EJB: Enterprise javabeans technology. http://java.sun.com/products/ejb/.
[54] .NET: Microsoft .net framework. http://www.microsoft.com/net/.
[55] D. Varr A. Balogh, G. Varr and A. Pataricza. Compiling model transformations
to EJB3-specific transformer plugins. In SAC ’06: Proceedings of the 2006 ACM
symposium on Applied computing, pages 1288–1295, New York, NY, USA, 2006.
ACM Press.
[56] Bruce Trask, Dominick Paniscotti, Angel Roman, and Vikram Bhanot. Using
model-driven engineering to complement software product line engineering in de-
veloping software defined radio components and applications. In OOPSLA ’06:
Companion to the 21st ACM SIGPLAN conference on Object-oriented program-
ming languages, systems, and applications, pages 846–853, New York, NY, USA,
2006. ACM Press.
[57] Ivan Kurtev, Klaas van den Berg, and Frdric Jouault. Evaluation of rule-based
modularization in model transformation languages illustrated with ATL. In SAC
’06: Proceedings of the 2006 ACM symposium on Applied computing, pages 1202–
1209, New York, NY, USA, 2006. ACM Press.
[58] S. Helsen Czarnecki K. Classification of model transformation approaches. In
OOPSLA03 Workshop on Generative Techniques in the Context of Model-Driven
Architecture, 2003.
119
[59] Marcus Alanen and Ivan Porres. Coral: A metamodel kernel for transforma-
tion engines. In D. H. Akerhurst, editor, Proceedings of the Second Europena
Workshop on Model Driven Architecture (MDA), number 17, pages 165–170,
Canterbury, Kent CT2 7NF, United Kingdom, Sep 2004. University of Kent.
[60] Jamda: The java model driven architecture.
http://sourceforge.net/projects/jamda/.
[61] The World Wide Web Consortium (W3C). XSL Transformations (XSLT) Version
1.0. http://www.w3c.org/TR/xslt.
[62] J. Bzivin M. Peltier, M. Ziserman. On levels of model transformation. In Pro-
ceedings of XML Europe 2000, Paris, France, 2000.
[63] GME website. http://www.isis.vanderbilt.edu/Projects/gme/.
[64] DSTC, IBM, CBOP. MOF Query/Views/Transformations Submission. OMG
Document ad/2004-01-06.
[65] Gabor Karsai Tihamer Levendovszky and Hassan Charaf. Model refactorings as
rule-based update transformations. In Software Reuse: Methods Techniques and
Tools, volume 2319 of Lecture Notes in Computer Science, page 166, Austin, TX,
USA, Apr 2002. Springer-Verlag.
[66] OMG, MDA Web Site. http://www.omg.org/mda.
[67] Object Management Group and R. Soley. Model-Driven Architecture 2000.
http://www.omg.org/mda.
[68] S. Warmer A. Kleppe. MDA Explained. The Model Driven Architecture: Practice
and Promise. Addison-Wesley, 2003.
120
[69] A.Uhl S.J.Mellor, K.Scott and D.Weise. MDA Distilled: Principles of Model-
Driven Architecture. Addison-Wesley, 2004.
[70] Grady Booch, James Rumbaugh, and Ivar Jacobson. The Unified Modeling Lan-
guage User Guide. Addison-Weslay-Longman, 1999.
[71] R. France et al. The UML as a formal modeling notation . Computer Standards
& Interfaces, 19(7):325–334, November 1998.
[72] Bran Selic. Keynote speech for codegen conference 2008 on ” matching supply
and demand: Challenges in model-based code generation for qos-constrained
software,” cambridge, uk, june 25, 2008.
[73] The World Wide Web Consortium (W3C). Extensible Markup Language (XML)
1.0 (Third Edition). http://www.w3.org/TR/2004/REC-xml-20040204/.
[74] XML Metadata Interchange (XMI) Version 1.1.
http://www.omg.org/docs/ad/99-10-02.pdf.
[75] Louis M. Rose, Richard F. Paige, Dimitrios S. Kolovos, and Fiona A. Polack.
Constructing models with the human-usable textual notation. In MoDELS
’08: Proceedings of the 11th international conference on Model Driven Engineer-
ing Languages and Systems, pages 249–263, Berlin, Heidelberg, 2008. Springer-
Verlag.
[76] Object Management Group. Meta-Object Facility 2.0. OMG Document
formal/2006-01-01.
[77] Marcus Alanen and Ivan Porres. Model interchange using omg standards. In
EUROMICRO ’05: Proceedings of the 31st EUROMICRO Conference on Soft-
121
ware Engineering and Advanced Applications, pages 450–459, Washington, DC,
USA, 2005. IEEE Computer Society.
[78] Juanjuan Jiang and T. Systa. Exploring differences in exchange formats-tool
support and case studies. In Software Maintenance and Reengineering, 2003.
Proceedings. Seventh European Conference on, pages 389–398, March 2003.
[79] Bjrn Lundell, Brian Lings, Anna Persson, and Anders Mattsson. Uml model
interchange in heterogeneous tool environments: An analysis of adoptions of xmi
2. Model Driven Engineering Languages and Systems, pages 619–630, 2006.
[80] Frank Gerhardt. Reengineering with the corba meta object facility. In ECOOP
’98: Workshop ion on Object-Oriented Technology, pages 6–7, London, UK, 1998.
Springer-Verlag.
[81] Joakim Isaksson, Dragos Truscan, and Johan Lilius. A mof-based metamodel
for sa/rt. Technical Report 555, TUCS - Turku Centre for Computer Science,
Turku, Finland, Sep 2003.
[82] Common Warehouse Metamodel(CWM) Version 1.1. http://www.omg.org/cgi-
bin/doc?formal/03-03-02.
[83] UML Profile for enterprise distributed Object Computing (EDOC).
http://www.omg.org/technology/documents/formal/edoc.htm.
[84] Jinyoul Lee, Keng Siau, and Soongoo Hong. Enterprise integration with ERP
and EAI. Commun. ACM, 46(2):54–60, 2003.
[85] Thomas Baar. Metamodels without metacircularities. In LObjet, 9(4), pages
95–114, 2003.
122
[86] D. Varr and A. Pataricza. Metamodeling mathematics: A precise and visual
framework for describing semantics domains of uml models. In UML ’02: Pro-
ceedings of the 5th International Conference on The Unified Modeling Language,
pages 18–33, London, UK, 2002. Springer-Verlag.
[87] Human-Usable Textual Notation Specification.
http://www.omg.org/technology/documents/formal/hutn.htm.
[88] P.-A. Muller and M. Hassenforder. Constructing models with the human-usable
textual notation. In WISME Workshop, MODELS / UML’2005 (WISME), 2005.
[89] Sintaks. http://www.kermeta.org/sintaks/.
[90] Eclipse modeling framework project(emf). http://www.eclipse.org/modeling/emf/.
[91] Thomas Baar. Correctly Defined Concrete Syntax for Visual Modeling Lan-
guages. In Proceedings of the MoDELS’06 Conference, Genova, Italy, October
1-7, 2006, Lecture Notes in Computer Science, pages 111–125, 2006.
[92] F. Jouault, Bezivin, J., and I. Kurtev. Tcs: a dsl for the specification of textual
concrete syntaxes. In GPCE 2006, ACM Press, pages 249–254, 2006.
[93] M. Scheidgen. Textual modelling embedded into graphical modelling. In
ECMDA-FA 2008, volume 5095 of Lecture Notes in Computer Science. Springer-
Verlag, 2008.
[94] Xiaoping Jia. The ZOOM Notation - A Reference Manual. Technical Report,
DePaul University, 2004.
[95] J. Woodcock and J. Davies. Using Z Specification, Refinement, and Proof. Pren-
tice Hall Europe, 1996.
123
[96] J. B. Wordsworth. Software Development with Z. Addison Wesley, Boston, MA,
1992.
[97] J. M. Spivey. The Z Notation: A Reference Manual, 2nd Ed., 1992.
[98] Edmund M. Clarke and Jeannette M. Wing. Formal methods: state of the art
and future directions. ACM Comput. Surv., 28(4):626–643, 1996.
[99] Xiaoping Jia. An approach to animating Z specifications. In Proc. 19th Annual
IEEE Int’l Computer Software and Applications Conf. (COMPSAC 1995), pages
108–113, Dallas, Texas, USA, August 1995.
[100] Lizhang Qin, Hongming Liu, Chris Jones, and Xiaoping Jia. An Integrated Event-
Driven Framework Supporting MDD. In Proc. of the 2004 Midwest Software
Engineering Conference (MSEC’04), pages 32–44, Chicago,IL USA., April 2004.
[101] C. Lopes and W. Hrsh. Separation of concerns. Technical Report, Computer
Science School, Northeastern University, Boston, US, 1995.
[102] Object Management Group. UML 2.0 OCL, January 2003.
http://www.omg.org/docs/ad/03-01-07.pdf.
[103] Jos Warmer and Anneke Kleppe. The Object Constraint Language, Precise Mod-
eling with UML. Addison-Weslay, 1999.
[104] Bertrand Meyer. Applying design by contract. 2nd Ed. Prentice Hall PTR, Upper
Saddle River, NJ, 1997.
[105] Jos Warmer and Anneke Kleppe. The Object Constraint Language. Addison
Wesley, Boston, MA, 1999.
124
[106] Xiaoping Jia and Adam Steele. Incorporating uidls into model-driven develop-
ment. In Proc. of the 1st workshop on XML-based User Interface Description
Language (UIXML’04), Gallipoli, Italy, May 2004.
[107] Paulo Pinheiro da Silva and Norman W. Paton. User interface modeling in umli.
20(4):62–60, 2003.
[108] Alfred V. Aho and Jeffrey D. Ullman. Theory of Parsing, Translation and Com-
piling. Prentice Hall Professional Technical Reference, 1973.
[109] David S. Wile. Abstract syntax from concrete syntax. In ICSE ’97: Proceedings
of the 19th international conference on Software engineering, pages 472–480, New
York, NY, USA, 1997. ACM Press.
[110] W3C. XML Path Language (XPath Version 1.0). W3C Recommendation, 16
November 1999.
[111] W3C. XML Path Language (XPath Version 2.0). W3C Recommendation, 23
January 2007.
[112] Donald E. Knuth. Literate programming. CSLI Lecture Notes, (27), 2003.
[113] ZOOM project web site. http://se.cs.depaul.edu/ise/zoom/.
[114] Carlos Ruiz del Castillo Gonzalo Gnova and Juan Llorens. Mapping uml associ-
ations into java code. Journal of Object Technology, 2(5):135–162, 2003.
[115] EHR definition, attributes and essential requirements. Healthcare Information
and Management Systems Society, 2003.
125
[116] J. Vijayan. HIPAA audit at hospital riles health care it: Industry on edge after
feds examine data security procedures at atlanta facility. Computerworld, 15,
2007.
[117] Health Level 7. http://www.bl7.org, July 2003.
[118] Chris Raistrick. Applying mda and uml in the development of a healthcare
system. In UML Satellite Activities, pages 203–218, 2004.
[119] Eila Kuikka and Anne Eerola. A correspondence between uml diagrams and
sgml/xml dtds. In DDEP/PODDP, pages 161–175, 2000.
[120] Healthcare Information Technology Standards Panel. http://www.hitsp.org.
[121] Tejeddine Mouelhi, Franck Fleurey, Benoit Baudry, and Yves Traon. A model-
based framework for security policy specification, deployment and testing. In
MoDELS ’08: Proceedings of the 11th international conference on Model Driven
Engineering Languages and Systems, pages 537–552, Berlin, Heidelberg, 2008.
Springer-Verlag.
[122] D.F. Ferraiolo, D.R. Kuhn, and R. Chandramouli. Role base access control.
Computer Security Series, 2003.
[123] R. Sandhu. Role-based access control models. IEEE Computer, 29, 1996.
[124] Daniel Varro and Zoltan Balogh. Automating model transformation by example
using inductive logic programming. In SAC ’07: Proceedings of the 2007 ACM
symposium on Applied computing, pages 978–984, New York, NY, USA, 2007.
ACM.
126
[125] Manuel Wimmer, Michael Strommer, Horst Kargl, and Gerhard Kramler. To-
wards model transformation generation by-example. In HICSS ’07: Proceedings
of the 40th Annual Hawaii International Conference on System Sciences, page
285b, Washington, DC, USA, 2007. IEEE Computer Society.
[126] Tom Mens and Pieter Van Gorp. A taxonomy of model transformation. Electronic
Notes in Theoretical Computer Science, 152:125 – 142, 2006. Proceedings of the
International Workshop on Graph and Model Transformation (GraMoT 2005).
[127] INRIA. Classification of model transformation approaches, 2007. available at
http://modelware.inria.fr/rubrique21.html.
[128] Jernej Kovse and Theo Hrder. Generic xmi-based uml model transformations. In
Proc. 8th Int. Conf. on Object-Oriented Information Systems (OOIS’02, pages
192–198. Springer-Verlag, 2002.
[129] Tim Furche, Franois Bry, Sebastian Schaffert, Renzo Orsini, Ian Horrocks,
Michael Kraus, and Oliver Bolzer. Survey over existing query and transformation
languages, 2004.
[130] Birgit Demuth, Heinrich Hussmann, and Sven Obermaier. Experiments with xmi
based transformations of software models. In In Workshop on Transformations
in UML. 2001, 2001.
[131] Frank Keienburg and Andreas Rausch. Using xml/xmi for tool supported evo-
lution of uml models. In In the Proc. of the 34th Annual Hawaii International
Conference on System Sciences (HICSS-34), Maui, pages 3–6. IEEE Computer
Society, 2001.
127
[132] M. Peltier, J. Bzivin, and G. Guillaume. Mtrans: A general framework based on
xslt for model transformations. In WTUML01: Proceedings of the Workshop on
Transformations in UML, 2001.
[133] M. Peltier, F. Ziserman, and J. Bzivin. On levels of model transformation. In
XML Europe 2000, 2000.
[134] Andromda website. http://www.andromda.org/.
[135] Velocity. The apache jakarta project, http://jakarta.apache.org/velocity/.
[136] XDoclet. Attribute oriented programming, http://xdoclet.sourceforge.net/.
[137] C. Cleaveland. Program generators with xml and java. prentice-hall, 2001,
http://www.craigc.com/pg/.
[138] Keith Duddy et al. Model transformation: A declarative, reusable patterns ap-
proach. In Proceedings of the Seventh IEEE International Enterprise Distributed
Object Computing Conference (EDOC03).
[139] Doug Tidwell. XSLT, 1st Ed. O’Reilly & Associates, 2001.
[140] Alcatel et al. A review of OMG MOF 2.0 Query / Views / Transformations
Submissions and Recommendations towards the final Standard. OMG Document:
ad/03-08-05.
[141] ATL. Atlas transformation language, eclipse, http://www.eclipse.org/m2m/atl/.
[142] Cem Kaner, Senior Member, and Walter P. Bond. Software engineering metrics:
What do they measure and how do we know? In In METRICS 2004. IEEE CS.
Press, 2004.
128
[143] Terence L. Woodings and Gary A. Bundell. A framework for software project
metrics. In In ESCOM01: Proceedings of the 12th European Conference on
Software Control and Metrics, 2001.
[144] N. E. Fenton. Software metrics: theory, tools and validation. Softw. Eng. J.,
5(1):65–78, 1990.
[145] M. Kumar and Devpriya Soni. Observations on object-oriented design assessment
and evolving new model. In In Proc of The National Conference on Software
Engineering, pages 161–164, 2007.
[146] Devpriya Soni, Ritu Shrivastava, and M. Kumar. A framework for validation of
object oriented design metrics. IJCSIS, 6:046, 2009.
[147] Java platform, enterprise edition. http://java.sun.com/javaee/.
[148] Netbeans website. http://www.netbeans.org/.
[149] JMI: Java metadata interface. http://java.sun.com/products/jmi/index.jsp.
[150] Eclipse modeling project(EMP). http://www.eclipse.org/modeling/.
129
A Development of Transformation
A.1 Generation of Basic Classes
Transformation Rule to Generate Basic Java Classes
1
2
3 <?xml version=” 1 .0 ”?>4
5 < !DOCTYPE RuleSet SYSTEM ” r u l e s . dtd”>6
7 <RuleSet name=” s imple ” t a r g e t=”Java” po s tp ro c e s s o r=”xweb” import=” s t r i n g f un c t i o n . zoom”>8
9 <Rule match=”ZOOMModule”>10 <Pre>< ! [CDATA[<?xml ve r s i on =”1.0”?>11 <!DOCTYPE XWeb SYSTEM ”xweb . dtd”>12 <XWeb>13 ] ]></Pre>14 <Post>< ! [CDATA[15 </XWeb> ] ]></Post>16 </Rule>17
18
19 <Rule match=” Struct ”>20 <Pre>21 < ! [CDATA[22 <F i l e name=”${name } . java”>23 import java . u t i l . ∗ ;24
25 c l a s s ${name} {26 <MacroRef name=”${name } . a t t rDe f”/>27 <MacroRef name=”${name } . constrDef”/>28 <MacroRef name=”${name } . operDef”/>29 }30 </Fi l e>31 <MacroDef name=”${name } . constrDef”>32 ${name} (<MacroRef name=”${name } . constrAttrParamDef ” / >) {33 <MacroRef name=”${name } . constrAttrDef”/>34 }35 </MacroDef>36
37 <%38 i f ( ( ch i l d r en != nu l l ) && ( ch i l d r en . s i z e ( ) > 0 ) ) {39 %>40 <MacroDef name=”${name } . constrAttrParamDef”>41 <%42 pr in t ( ” ” ) ;43 f o r ( i n t i =0; i<ch i l d r en . s i z e ( ) ; i++)44 {45 i f ( c h i l d r en [ i ] . elementName == ” Dec la ra t i on ” ) {46 i f ( i == ch i l d r en . s i z e ( ) −1) {
130
47 pr in t ( f i l t e r l t g t ( ch i l d r en [ i ] . type . t oS t r i ng ( ) ) ) ;48 pr in t ( ” ” ) ;49 pr in t ( ch i l d r en [ i ] . name ) ;50 } e l s e {51 pr in t ( f i l t e r l t g t ( ch i l d r en [ i ] . type . t oS t r i ng ( ) ) ) ;52 pr in t ( ” ” ) ;53 pr in t ( ch i l d r en [ i ] . name ) ;54 pr in t ( ” , ” ) ;55 }56 }57 }58 }59 %>60 </MacroDef>61 ] ]></Pre>62 </Rule>63
64
65
66 <Rule match=” Struct / Dec la ra t i on / Var iab l eDec la ra to r ”>67 <Pre>< ! [CDATA[68
69 <MacroDef name=”${parent . parent . name } . constrAttrDef”>70 t h i s . ${name} = ${name } ;71 </MacroDef>72
73 <MacroDef name=”${parent . parent . name } . a t t rDe f”>74 protec ted ${ f i l t e r l t g t ( parent . type . t oS t r i ng ( ) ) } ${name } ;75 </MacroDef>76
77 <MacroDef name=”${parent . parent . name } . operDef”>78 pub l i c ${ f i l t e r l t g t ( parent . type . t oS t r i ng ( ) ) } get ${ c a p i t a l i z e (name . t oS t r i ng ( ) ) } ( ) {79 re turn ${name } ;80 }81 </MacroDef>82 <MacroDef name=”${parent . parent . name } . operDef”>83 pub l i c void s e t ${ c a p i t a l i z e (name . t oS t r i ng ( ) )}84 (${ f i l t e r l t g t ( parent . type . t oS t r i ng ( ) ) } ${name} ) {85 t h i s . ${name} = ${name } ;86 }87 </MacroDef>88
89 ] ]></Pre>90 </Rule>91
92
93 </RuleSet>
131
Player.java referenced in Section 6.1
1
2 import java . u t i l . ∗ ;3
4 class Player {5 protected St r ing id ;6
7 protected St r ing name ;8
9 protected St r ing po s i t i o n ;10
11 protected double s a l a r y ;12
13
14 Player ( S t r ing id , S t r ing name , S t r ing po s i t i on , double s a l a r y ){15 this . id = id ;16
17 this . name = name ;18
19 this . p o s i t i o n = po s i t i o n ;20
21 this . s a l a r y = sa l a r y ;22
23 }24
25 public St r ing get Id ( ) {26 return id ;27 }28
29 public void s e t I d ( S t r ing id ) {30 this . id = id ;31 }32
33 public St r ing getName ( ) {34 return name ;35 }36
37 public void setName ( St r ing name ) {38 this . name = name ;39 }40
41 public St r ing g e tPo s i t i on ( ) {42 return po s i t i o n ;43 }44
45 public void s e tPo s i t i o n ( S t r ing po s i t i o n ) {46 this . p o s i t i o n = po s i t i o n ;47 }48
49 public double ge tSa la ry ( ) {50 return s a l a r y ;51 }52
132
53 public void s e tSa l a r y ( double s a l a r y ) {54 this . s a l a r y = sa l a r y ;55 }56
57 }
133
Team.java referenced in Section 6.1
1
2 import java . u t i l . ∗ ;3
4 class Team {5 protected St r ing id ;6
7 protected St r ing name ;8
9 protected St r ing c i t y ;10
11 Team ( St r ing id , S t r ing name , S t r ing c i t y ) {12 this . id = id ;13 this . name = name ;14 this . c i t y = c i t y ;15 }16
17 public St r ing get Id ( ) {18 return id ;19 }20
21 public void s e t I d ( S t r ing id ) {22 this . id = id ;23 }24
25 public St r ing getName ( ) {26 return name ;27 }28
29 public void setName ( St r ing name ) {30 this . name = name ;31 }32
33 public St r ing getCity ( ) {34 return c i t y ;35 }36
37 public void s e tC i ty ( S t r ing c i t y ) {38 this . c i t y = c i t y ;39 }40
41 }
134
League.java referenced in Section 6.1
1
2 import java . u t i l . ∗ ;3
4 class League {5 protected St r ing id ;6
7 protected St r ing name ;8
9 protected St r ing spor t ;10
11 League ( S t r ing id , S t r ing name , S t r ing spor t ){12 this . id = id ;13
14 this . name = name ;15
16 this . spor t = spor t ;17
18 }19
20 public St r ing get Id ( ) {21 return id ;22 }23
24 public void s e t I d ( S t r ing id ) {25 this . id = id ;26 }27
28 public St r ing getName ( ) {29 return name ;30 }31
32 public void setName ( St r ing name ) {33 this . name = name ;34 }35
36 public St r ing getSport ( ) {37 return spor t ;38 }39
40 public void s e tSpor t ( S t r ing spor t ) {41 this . spor t = spor t ;42 }43
44 }
135
Transformation Rule to Generate Basic .NET Classes
1
2 <?xml version=” 1 .0 ”?>3 < !DOCTYPE RuleSet SYSTEM ” r u l e s . dtd”>4 <RuleSet name=” s imple ” t a r g e t=” .NET” pos tp ro c e s s o r=”xweb” import=” s t r i n g f un c t i o n . zoom”>5 <Rule match=”ZOOMModule”>6 <Pre>< ! [CDATA[<?xml ve r s i on =”1.0”?>7 <!DOCTYPE XWeb SYSTEM ”xweb . dtd”>8 <XWeb>9 ] ]></Pre>
10 <Post>< ! [CDATA[11 </XWeb> ] ]></Post>12 </Rule>13 <Rule match=” Struct ”>14 <Pre>15 < ! [CDATA[16 <F i l e name=”${name } . c s”>17 us ing System ;18 c l a s s ${name} {19 <MacroRef name=”${name } . a t t rDe f”/>20 <MacroRef name=”${name } . operDef”/>21 }22 </Fi l e>23 ] ]></Pre>24 </Rule>25
26 <Rule match=” Struct / Dec la ra t i on / Var iab l eDec la ra to r ”>27 <Pre>< ! [CDATA[28 <MacroDef name=”${parent . parent . name } . a t t rDe f”>29 pr i va t e ${ f i l t e r l t g t ( parent . type . t oS t r i ng ( ) ) } ${name } ;30 </MacroDef>31 <MacroDef name=”${parent . parent . name } . operDef”>32 pub l i c ${ f i l t e r l t g t ( parent . type . t oS t r i ng ( ) )} ${ c a p i t a l i z e (name . t oS t r i ng ( ) ) } ( ) {33 get { re turn ${name} ;}34 s e t { ${name} = value ;}35 }36 </MacroDef>37 ] ]></Pre>38 </Rule>39 </RuleSet>
136
Player.cs referenced in Section 6.1
1
2 us ing System ;3 class Player {4 private St r ing id ;5
6 private St r ing name ;7
8 private St r ing po s i t i o n ;9
10 private double s a l a r y ;11
12 public St r ing Id ( ) {13 get { return id ;}14 s e t { id = value ;}15 }16
17 public St r ing Name( ) {18 get { return name ;}19 s e t { name = value ;}20 }21
22 public St r ing Pos i t i on ( ) {23 get { return po s i t i o n ;}24 s e t { po s i t i o n = value ;}25 }26
27 public double Sa lary ( ) {28 get { return s a l a r y ;}29 s e t { s a l a r y = value ;}30 }31
32 }
137
Team.cs referenced in Section 6.1
1
2 us ing System ;3 class Team {4 private St r ing id ;5
6 private St r ing name ;7
8 private St r ing c i t y ;9
10 public St r ing Id ( ) {11 get { return id ;}12 s e t { id = value ;}13 }14
15 public St r ing Name( ) {16 get { return name ;}17 s e t { name = value ;}18 }19
20 public St r ing City ( ) {21 get { return c i t y ;}22 s e t { c i t y = value ;}23 }24
25 }
138
League.cs referenced in Section 6.1
1
2 us ing System ;3 class League {4 private St r ing id ;5
6 private St r ing name ;7
8 private St r ing spor t ;9
10 public St r ing Id ( ) {11 get { return id ;}12 s e t { id = value ;}13 }14
15 public St r ing Name( ) {16 get { return name ;}17 s e t { name = value ;}18 }19
20 public St r ing Sport ( ) {21 get { return spor t ;}22 s e t { spor t = value ;}23 }24
25 }
139
A.2 Generation of Classes with Associations
Transformation Rule to Generate Basic Java Classes with Associations
1
2
3 <?xml version=” 1 .0 ”?>4
5 < !DOCTYPE RuleSet SYSTEM ” r u l e s . dtd”>6
7 <RuleSet name=” s imple ” t a r g e t=”Java” po s tp ro c e s s o r=”xweb” import=” s t r i n g f un c t i o n . zoom”>8
9 <Rule match=”ZOOMModule”>10 <Pre>< ! [CDATA[<?xml ve r s i on =”1.0”?>11 <!DOCTYPE XWeb SYSTEM ”xweb . dtd”>12 <XWeb>13 ] ]></Pre>14 <Post>< ! [CDATA[15 </XWeb> ] ]></Post>16 </Rule>17
18
19 <Rule match=” Struct ”>20 <Pre>21 < ! [CDATA[22 <F i l e name=”${name } . java”>23 import java . u t i l . ∗ ;24
25 c l a s s ${name} {26 <MacroRef name=”${name } . a t t rDe f”/>27 <MacroRef name=”${name } . constrDef”/>28 <MacroRef name=”${name } . operDef”/>29 }30 </Fi l e>31 <MacroDef name=”${name } . constrDef”>32 ${name} (<MacroRef name=”${name } . constrAttrParamDef ” / >) {33 <MacroRef name=”${name } . constrAttrDef”/>34 }35 </MacroDef>36
37 <%38 i f ( ( ch i l d r en != nu l l ) && ( ch i l d r en . s i z e ( ) > 0 ) ) {39 %>40 <MacroDef name=”${name } . constrAttrParamDef”>41 <%42 pr in t ( ” ” ) ;43 f o r ( i n t i =0; i<ch i l d r en . s i z e ( ) ; i++)44 {45 i f ( c h i l d r en [ i ] . elementName == ” Dec la ra t i on ” ) {46 i f ( i == ch i l d r en . s i z e ( ) −1) {47 pr in t ( f i l t e r l t g t ( ch i l d r en [ i ] . type . t oS t r i ng ( ) ) ) ;48 pr in t ( ” ” ) ;49 pr in t ( ch i l d r en [ i ] . name ) ;50 } e l s e {
140
51 pr in t ( f i l t e r l t g t ( ch i l d r en [ i ] . type . t oS t r i ng ( ) ) ) ;52 pr in t ( ” ” ) ;53 pr in t ( ch i l d r en [ i ] . name ) ;54 pr in t ( ” , ” ) ;55 }56 }57 }58 }59 %>60 </MacroDef>61 ] ]></Pre>62 </Rule>63
64
65
66 <Rule match=” Struct / Dec la ra t i on / Var iab l eDec la ra to r ”>67 <Pre>< ! [CDATA[68
69 <MacroDef name=”${parent . parent . name } . constrAttrDef”>70 t h i s . ${name} = ${name } ;71 </MacroDef>72
73 <MacroDef name=”${parent . parent . name } . a t t rDe f”>74 protec ted ${ f i l t e r l t g t ( parent . type . t oS t r i ng ( ) ) } ${name } ;75 </MacroDef>76
77 <MacroDef name=”${parent . parent . name } . operDef”>78 pub l i c ${ f i l t e r l t g t ( parent . type . t oS t r i ng ( ) ) } get ${ c a p i t a l i z e (name . t oS t r i ng ( ) ) } ( ) {79 re turn ${name } ;80 }81 </MacroDef>82 <MacroDef name=”${parent . parent . name } . operDef”>83 pub l i c void s e t ${ c a p i t a l i z e (name . t oS t r i ng ( ) )}84 (${ f i l t e r l t g t ( parent . type . t oS t r i ng ( ) ) } ${name} ) {85 t h i s . ${name} = ${name } ;86 }87 </MacroDef>88
89 ] ]></Pre>90 </Rule>91
92
93 <Rule match=” Struct /Operation ”>94 <Pre>< ! [CDATA[95
96 <MacroDef name=”${parent . name } . operDef”>97 pub l i c ${ f i l t e r l t g t ( type . t oS t r i ng ( ) )} ${name} (${ parameter . t oS t r i ng ( ) } ) {98 <MacroRef name=”${name } . exprDef”/>99 }
100 </MacroDef>101 ] ]></Pre>102 </Rule>103
104 <Rule match=” Struct /Operation /BlockStatement /Express ionStatement ”
141
105 express ionmapping=”yes ”>106 <Pre>< ! [CDATA[107 <MacroDef name=”${parent . parent . name } . exprDef”>108 ] ]></Pre>109 <Post>< ! [CDATA[110 </MacroDef>111 ] ]></Post>112 </Rule>113
114 <Rule match=”ZOOMModule/ Dec la ra t i on / Var iab l eDec l a ra to r ”>115 <Pre>< ! [CDATA[116 <%117 i f ( parent . type != nu l l && parent . type . gentype != nu l l118 && parent . annotat ions != nu l l && parent . annotat ions . s i z e ( ) > 0) {119 %>120 <MacroDef name=”${parent . type . gentype [ 0 ] } . a t t rDe f”>121 <%122 i f ( parent . annotat ions [ 0 ] . mu l t i p l i c i t yR i gh t . t oS t r i ng () == ” Mu l t i p l i c i t y .Many”) {123 %>124 protec ted L i s t&l t ; ${ parent . type . gentype [1 ]}& gt ; $ { parent . annotat ions [ 0 ] . r o l eR ight } ;125
126 </MacroDef>127 <MacroDef name=”${parent . type . gentype [ 0 ] } . operDef”>128 pub l i c void add ${ parent . type . gentype [ 1 ] }129 (${ parent . type . gentype [ 1 ] } $ { parent . type . gentype [ 1 ] } ) {130 ${ parent . annotat ions [ 0 ] . r o l eR ight } . add (${ parent . type . gentype [ 1 ] } ) ;131 }132 </MacroDef>133
134 <MacroDef name=”${parent . type . gentype [ 0 ] } . operDef”>135 pub l i c void remove ${ parent . type . gentype [ 1 ] }136 (${ parent . type . gentype [ 1 ] } $ { parent . type . gentype [ 1 ] } ) {137 ${ parent . annotat ions [ 0 ] . r o l eR ight } . remove (${ parent . type . gentype [ 1 ] } ) ;138 }139 </MacroDef>140
141 <%142 } e l s e {143 %>144 protec ted ${ parent . type . gentype [ 1 ] } $ { parent . annotat ions [ 0 ] . r o l eR ight } ;145 </MacroDef>146 <%}%>147 <MacroDef name=”${parent . type . gentype [ 1 ] } . a t t rDe f”>148 <%149 i f ( parent . annotat ions [ 0 ] . mu l t i p l i c i t y L e f t . t oS t r i ng () == ” Mu l t i p l i c i t y .Many”) {150 %>151 protec ted L i s t&l t ; ${ parent . type . gentype [0 ]}& gt ; $ { parent . annotat ions [ 0 ] . r o l e L e f t } ;152 </MacroDef>153
154 <MacroDef name=”${parent . type . gentype [ 1 ] } . operDef”>155 pub l i c void add ${ parent . type . gentype [ 0 ] }156 (${ parent . type . gentype [ 0 ] } $ { parent . type . gentype [ 0 ] } ) {157 ${ parent . annotat ions [ 0 ] . r o l e L e f t } . add (${ parent . type . gentype [ 0 ] } ) ;158 }
142
159 </MacroDef>160
161 <MacroDef name=”${ parent . type . gentype [ 1 ] } . operDef ”>162 pub l i c void remove ${ parent . type . gentype [ 0 ] }163 (${ parent . type . gentype [ 0 ] } $ { parent . type . gentype [ 0 ] } ) {164 ${ parent . annotat ions [ 0 ] . r o l e L e f t } . remove (${ parent . type . gentype [ 0 ] } ) ;165 }166 </MacroDef>167 <%168 } e l s e {169 %>170 protec ted ${ parent . type . gentype [ 0 ] } $ { parent . annotat ions [ 0 ] . r o l e L e f t } ;171 </MacroDef>172 <%}173 }174 %>175
176 ] ]></Pre>177 </Rule>178
179
180 </RuleSet>
143
Player.java referenced in Section 6.2
1
2 import java . u t i l . ∗ ;3
4 class Player {5 protected St r ing id ;6
7 protected St r ing name ;8
9 protected St r ing po s i t i o n ;10
11 protected double s a l a r y ;12
13
14 protected List<Team> teams ;15
16 Player (17 St r ing id , S t r ing name , S t r ing pos i t i on , double s a l a r y18
19 ) {20 this . id = id ;21
22 this . name = name ;23
24 this . p o s i t i o n = po s i t i o n ;25
26 this . s a l a r y = sa l a r y ;27
28 }29
30 public St r ing get Id ( ) {31 return id ;32 }33
34 public void s e t I d ( S t r ing id ) {35 this . id = id ;36 }37
38 public St r ing getName ( ) {39 return name ;40 }41
42 public void setName ( St r ing name ) {43 this . name = name ;44 }45
46 public St r ing g e tPo s i t i on ( ) {47 return po s i t i o n ;48 }49
50 public void s e tPo s i t i o n ( S t r ing po s i t i o n ) {51 this . p o s i t i o n = po s i t i o n ;52 }
144
53
54 public double ge tSa la ry ( ) {55 return s a l a r y ;56 }57
58 public void s e tSa l a r y ( double s a l a r y ) {59 this . s a l a r y = sa l a r y ;60 }61
62 public void add Team (Team Team) {63 teams . add (Team) ;64 }65 public void remove Team (Team Team) {66 teams . remove (Team) ;67 }68 }
145
Team.java referenced in Section 6.2
1
2 import java . u t i l . ∗ ;3
4 class Team {5 protected St r ing id ;6
7 protected St r ing name ;8
9 protected St r ing c i t y ;10
11
12 protected List<Player > p l aye r s ;13
14 protected League l eague ;15 Team (16 St r ing id , S t r ing name , S t r ing c i t y17
18 ) {19 this . id = id ;20
21 this . name = name ;22
23 this . c i t y = c i t y ;24
25 }26
27 public St r ing get Id ( ) {28 return id ;29 }30
31 public void s e t I d ( S t r ing id ) {32 this . id = id ;33 }34
35 public St r ing getName ( ) {36 return name ;37 }38
39 public void setName ( St r ing name ) {40 this . name = name ;41 }42
43 public St r ing getCity ( ) {44 return c i t y ;45 }46
47 public void s e tC i ty ( S t r ing c i t y ) {48 this . c i t y = c i t y ;49 }50
51 public void add Player ( Player Player ) {52 p l aye r s . add ( Player ) ;
146
53 }54 public void remove Player ( Player Player ) {55 p l aye r s . remove ( Player ) ;56 }57 }
147
League.java referenced in Section 6.2
1
2 import java . u t i l . ∗ ;3
4 class League {5 protected St r ing id ;6
7 protected St r ing name ;8
9 protected St r ing spor t ;10
11
12 protected List<Team> teams ;13 League (14 St r ing id , S t r ing name , S t r ing spor t15
16 ) {17 this . id = id ;18
19 this . name = name ;20
21 this . spor t = spor t ;22
23 }24
25 public St r ing get Id ( ) {26 return id ;27 }28
29 public void s e t I d ( S t r ing id ) {30 this . id = id ;31 }32
33 public St r ing getName ( ) {34 return name ;35 }36
37 public void setName ( St r ing name ) {38 this . name = name ;39 }40
41 public St r ing getSport ( ) {42 return spor t ;43 }44
45 public void s e tSpor t ( S t r ing spor t ) {46 this . spor t = spor t ;47 }48
49 public void add Team (Team Team) {50 teams . add (Team) ;51 }52 public void remove Team (Team Team) {
148
53 teams . remove (Team) ;54 }55 }
149
A.3 Generation of EJB Entities
Transformation Rule to Generate EJB Entities
1
2 <?xml version=” 1 .0 ”?>3
4 < !DOCTYPE RuleSet SYSTEM ” r u l e s . dtd”>5
6 <RuleSet name=” s imple ” t a r g e t=”EJB” po s tp ro c e s s o r=”xweb” import=” s t r i n g f un c t i o n . zoom”>7
8 <Rule match=”ZOOMModule”>9 <Pre>< ! [CDATA[<?xml ve r s i on =”1.0”?>
10 <!DOCTYPE XWeb SYSTEM ”xweb . dtd”>11 <XWeb>12 ] ]></Pre>13 <Post>< ! [CDATA[14 </XWeb> ] ]></Post>15 </Rule>16
17 <Rule match=” Struct ”>18 <Mark>19 <Stereotype name=”Entity ”/>20 </Mark>21 <Pre>22 < ! [CDATA[23 <MacroDef name=”${parent . name } . import”>24 import org .${ parent . name } . e n t i t y . ${name } ;25 </MacroDef>26 <MacroDef name=”${parent . name } . c r e a t eEn t i t y I n t e r f a c e”>27 pub l i c void c r ea t e ${name}(${name} ${ d e c a p i t a l i z e (name ) } ) ;28 </MacroDef>29 <MacroDef name=”${parent . name } . c reateEnt i tyOper”>30 pub l i c void c r ea t e ${name}(${name} ${ d e c a p i t a l i z e (name )} ) {31 em. p e r s i s t ($name ) ;32 }33 </MacroDef>34 <F i l e name=”${name } . java”>35 package org .${ parent . name } . e n t i t y ;36
37 import java . i o . S e r i a l i z a b l e ;38 import java . u t i l . ∗ ;39 import javax . p e r s i s t e n c e . ∗ ;40 import s t a t i c javax . p e r s i s t e n c e . FetchType . ∗ ;41
42 @Entity43
44 pub l i c c l a s s ${name} implements S e r i a l i z a b l e {45 <MacroRef name=”${name } . a t t rDe f”/>46 <MacroRef name=”${name } . constrDef”/>47 <MacroRef name=”${name } . operDef”/>48 }49 </Fi l e>50 <MacroDef name=”${name } . constrDef”>
150
51 ${name } ( ) {52 }53
54 ${name } (<MacroRef name=”${name } . constrAttrParamDef ” />) {55 <MacroRef name=”${name } . constrAttrDef ”/>56 }57 </MacroDef>58
59 <%60 i f ( ( ch i l d r en != nu l l ) && ( ch i l d r en . s i z e ( ) > 0 ) ) {61 %>62 <MacroDef name=”${name } . constrAttrParamDef ”>63 <%64 pr in t ( ” ” ) ;65 f o r ( i n t i =0; i<ch i l d r en . s i z e ( ) ; i++)66 {67 i f ( c h i l d r en [ i ] . elementName == ” Dec la ra t i on ” ) {68 i f ( i == ch i l d r en . s i z e ( ) −1) {69 pr in t ( ch i l d r en [ i ] ) ;70 } e l s e {71 pr in t ( ch i l d r en [ i ] ) ;72 pr in t ( ” , ” ) ;73 }74 }75 }76 }77 %>78 </MacroDef>79 ] ]></Pre>80 </Rule>81
82
83 </RuleSet>
151
Player.java referenced in Section 6.3
1
2 package org . r o s t e r . e n t i t y ;3
4 import java . i o . S e r i a l i z a b l e ;5 import java . u t i l . ∗ ;6 import javax . p e r s i s t e n c e . ∗ ;7 import stat ic javax . p e r s i s t e n c e . FetchType . ∗ ;8
9 @Entity10
11 public class Player implements S e r i a l i z a b l e {12
13 protected St r ing id ;14
15 protected St r ing name ;16
17 protected St r ing po s i t i o n ;18
19 protected double s a l a r y ;20
21 Player ( ) {22 }23
24 Player ( S t r ing id , S t r ing name , S t r ing pos i t i on , double s a l a r y ) {25 this . id = id ;26
27 this . name = name ;28
29 this . p o s i t i o n = po s i t i o n ;30
31 this . s a l a r y = sa l a r y ;32
33 }34
35 public St r ing get Id ( ) {36 return id ;37 }38
39 public void s e t I d ( S t r ing id ) {40 this . id = id ;41 }42
43
44 public St r ing getName ( ) {45 return name ;46 }47
48 public void setName ( St r ing name ) {49 this . name = name ;50 }51
52
152
53 public St r ing g e tPo s i t i on ( ) {54 return po s i t i o n ;55 }56
57 public void s e tPo s i t i o n ( S t r ing po s i t i o n ) {58 this . p o s i t i o n = po s i t i o n ;59 }60
61
62 public double ge tSa la ry ( ) {63 return s a l a r y ;64 }65
66 public void s e tSa l a r y (double s a l a r y ) {67 this . s a l a r y = sa l a r y ;68 }69
70 }
153
Team.java referenced in Section 6.3
1
2 package org . r o s t e r . e n t i t y ;3
4 import java . i o . S e r i a l i z a b l e ;5 import java . u t i l . ∗ ;6 import javax . p e r s i s t e n c e . ∗ ;7 import stat ic javax . p e r s i s t e n c e . FetchType . ∗ ;8
9 @Entity10
11 public class Team implements S e r i a l i z a b l e {12
13
14 protected St r ing id ;15
16 protected St r ing name ;17
18 protected St r ing c i t y ;19
20
21 Team ( ) {22 }23
24 Team (25 St r ing id , S t r ing name , S t r ing c i t y26
27 ) {28 this . id = id ;29
30 this . name = name ;31
32 this . c i t y = c i t y ;33
34 }35
36 public St r ing get Id ( ) {37 return id ;38 }39
40 public void s e t I d ( S t r ing id ) {41 this . id = id ;42 }43
44
45 public St r ing getName ( ) {46 return name ;47 }48
49 public void setName ( St r ing name ) {50 this . name = name ;51 }52
154
53
54 public St r ing getCity ( ) {55 return c i t y ;56 }57
58 public void s e tC i ty ( S t r ing c i t y ) {59 this . c i t y = c i t y ;60 }61
62
63 }
155
League.java referenced in Section 6.3
1
2 package org . r o s t e r . e n t i t y ;3
4 import java . i o . S e r i a l i z a b l e ;5 import java . u t i l . ∗ ;6 import javax . p e r s i s t e n c e . ∗ ;7 import stat ic javax . p e r s i s t e n c e . FetchType . ∗ ;8
9 @Entity10 public class League implements S e r i a l i z a b l e {11
12 protected St r ing id ;13
14 protected St r ing name ;15
16 protected St r ing spor t ;17
18 League ( ) {19 }20
21 League (22 St r ing id , S t r ing name , S t r ing spor t23
24 ) {25 this . id = id ;26
27 this . name = name ;28
29 this . spor t = spor t ;30
31 }32
33 public St r ing get Id ( ) {34 return id ;35 }36
37 public void s e t I d ( S t r ing id ) {38 this . id = id ;39 }40
41
42 public St r ing getName ( ) {43 return name ;44 }45
46 public void setName ( St r ing name ) {47 this . name = name ;48 }49
50
51 public St r ing getSport ( ) {52 return spor t ;
156
53 }54
55 public void s e tSpor t ( S t r ing spor t ) {56 this . spor t = spor t ;57 }58
59
60 }
157
A.4 Generation of Comprehensive EJB Applications
Transformation Rule to Generate Comprehensive EJB Applications
1
2 <?xml version=” 1 .0 ”?>3
4 < !DOCTYPE RuleSet SYSTEM ” r u l e s . dtd”>5
6 <RuleSet name=” s imple ” t a r g e t=”EJB” po s tp ro c e s s o r=”xweb” import=” s t r i n g f un c t i o n . zoom”>7
8 <Rule match=”ZOOMModule”>9 <Pre>< ! [CDATA[<?xml ve r s i on =”1.0”?>
10 <!DOCTYPE XWeb SYSTEM ”xweb . dtd”>11 <XWeb>12 ] ]></Pre>13 <Post>< ! [CDATA[14 </XWeb> ] ]></Post>15 </Rule>16
17 <Rule match=” Struct ”>18 <Mark>19 <Stereotype name=”Entity ”/>20 </Mark>21 <Pre>22 < ! [CDATA[23 <MacroDef name=”${parent . name } . import”>24 import org .${ parent . name } . e n t i t y . ${name } ;25 </MacroDef>26 <MacroDef name=”${parent . name } . c r e a t eEn t i t y I n t e r f a c e”>27 pub l i c void c r ea t e ${name}(${name} ${ d e c a p i t a l i z e (name ) } ) ;28 </MacroDef>29 <MacroDef name=”${parent . name } . c reateEnt i tyOper”>30 pub l i c void c r ea t e ${name}(${name} ${ d e c a p i t a l i z e (name )} ) {31 em. p e r s i s t ($name ) ;32 }33 </MacroDef>34 <F i l e name=”${name } . java”>35 package org .${ parent . name } . e n t i t y ;36
37 import java . i o . S e r i a l i z a b l e ;38 import java . u t i l . ∗ ;39 import javax . p e r s i s t e n c e . ∗ ;40 import s t a t i c javax . p e r s i s t e n c e . FetchType . ∗ ;41
42 @Entity43 @Table (name=”${name}”)44
45 @NamedQueries ({46 <MacroRef name=”${name } . queryDef”/>47 })48
49 pub l i c c l a s s ${name} implements S e r i a l i z a b l e {50 <MacroRef name=”${name } . a t t rDe f”/>
158
51 <MacroRef name=”${name } . constrDef”/>52 <MacroRef name=”${name } . operDef ”/>53 }54 </ F i l e>55 <MacroDef name=”${name } . constrDef ”>56 ${name } ( ) {57 }58
59 ${name } (<MacroRef name=”${name } . constrAttrParamDef ” />) {60 <MacroRef name=”${name } . constrAttrDef ”/>61 }62 </MacroDef>63
64 <%65 i f ( ( ch i l d r en != nu l l ) && ( ch i l d r en . s i z e ( ) > 0 ) ) {66 %>67 <MacroDef name=”${name } . constrAttrParamDef ”>68 <%69 pr in t ( ” ” ) ;70 f o r ( i n t i =0; i<ch i l d r en . s i z e ( ) ; i++)71 {72 i f ( c h i l d r en [ i ] . elementName == ” Dec la ra t i on ” ) {73 i f ( i == ch i l d r en . s i z e ( ) −1) {74 pr in t ( ch i l d r en [ i ] ) ;75 } e l s e {76 pr in t ( ch i l d r en [ i ] ) ;77 pr in t ( ” , ” ) ;78 }79 }80 }81 }82 %>83 </MacroDef>84 ] ]></Pre>85 </Rule>86
87 <Rule match=” Struct ”>88 <Mark>89 <Stereotype name=” Ses s i on ”/>90 </Mark>91 <Pre>< ! [CDATA[92 <F i l e name=”${name } . java”>93 package org .${name } . s e s s i o n ;94 import java . u t i l . L i s t ;95 import javax . e jb . Remote ;96 <MacroRef name=”${name } . import”/>97 @Remote98 pub l i c i n t e r f a c e ${name} {99 <MacroRef name=”${name } . s e s s i o n I n t e r f a c e ”/>
100 }101 </Fi l e>102
103 <F i l e name=”${name}Bean . java”>104 package org .${name } . s e s s i o n ;
159
105 import java . u t i l . L i s t ;106 import javax . e jb . Remote ;107 <MacroRef name=”${name } . import ”/>108 @Remote109 pub l i c c l a s s ${name}Bean implements ${name}{110 @Pers istenceContext111 pr i va t e EntityManager em;112 <MacroRef name=”${name } . s e s s ionOper ”/>113 }114 </ F i l e>115
116 ] ]></Pre>117 </Rule>118
119
120 <Rule match=” Struct /Operation ”>121 <Mark>122 <Stereotype name=”query”/>123 </Mark>124 <Pre>< ! [CDATA[125 <%126 St r ing parameterStr ing =””;127 i f ( ( ch i l d r en != nu l l ) && ( ch i l d r en . s i z e ( ) > 0 ) ) {128 f o r ( i n t i =0; i<ch i l d r en . s i z e ( ) ; i++)129 {130 i f ( c h i l d r en [ i ] . elementName == ”Parameter ” ) {131 i f ( parameterStr ing != ”” ) parameterStr ing += ” , ” ;132 parameterStr ing += ch i l d r en [ i ] . t oS t r i ng ( ) ;133 }134 }135 }136 %>137 <MacroDef name=”${parent . name } . s e s s i o n I n t e r f a c e ”>138 pub l i c ${ f i l t e r l t g t ( type . t oS t r i ng ( ) ) } ${name}(${ parameterStr ing } ) ;139 </MacroDef>140
141 <MacroDef name=”${parent . name } . s e s s ionOper”>142 pub l i c ${ f i l t e r l t g t ( type . t oS t r i ng ( ) ) } ${name}(${ parameterStr ing } ) {143 <MacroRef name=”${name } . exprDef”/>144 }145 </MacroDef>146
147
148 <%149
150 i f ( t h i s . annotat ions != nu l l && th i s . annotat ions . s i z e ( ) > 0) {151 St r ing entityname =””;152 entityname=th i s . annotat ions [ 0 ] . e n t i t y . t oS t r i ng ( ) ;153 %>154 <MacroDef name=”${entityname } . queryDef ” d e l im i t e r =”,” >155 @NamedQuery(name = ”${ entityname } . ${name}” , <MacroRef name=”${name } . namedqueryDef”/>)156 </MacroDef>157 <%158 }
160
159 %>160 ] ]></Pre>161 </Rule>162
163
164 <Rule match=” Struct /Operation ”>165 <Pre>< ! [CDATA[166 <%167 St r ing parameterStr ing =””;168 i f ( ( ch i l d r en != nu l l ) && ( ch i l d r en . s i z e ( ) > 0 ) ) {169 f o r ( i n t i =0; i<ch i l d r en . s i z e ( ) ; i++)170 {171 i f ( c h i l d r en [ i ] . elementName == ”Parameter ” ) {172 i f ( parameterStr ing != ”” ) parameterStr ing += ” , ” ;173 parameterStr ing += ch i l d r en [ i ] . t oS t r i ng ( ) ;174 }175 }176 }177 %>178 <MacroDef name=”${parent . name } . s e s s i o n I n t e r f a c e ”>179 pub l i c ${ f i l t e r l t g t ( type . t oS t r i ng ( ) ) } ${name}(${ parameterStr ing } ) ;180 </MacroDef>181
182 <MacroDef name=”${parent . name } . s e s s ionOper”>183 pub l i c ${ f i l t e r l t g t ( type . t oS t r i ng ( ) ) } ${name}(${ parameterStr ing } ) {184 <MacroRef name=”${name } . exprDef”/>185 }186 </MacroDef>187
188 ] ]></Pre>189 </Rule>190
191 <Rule match=” Struct /Operation /BlockStatement /ReturnStatement/ Col l ect ionFormat ion ”>192 <Pre>< ! [CDATA[193 <MacroDef name=”${parent . parent . parent . name } . namedqueryDef”>194 <%195 St r ing var = ”” ;196 St r ing exp = ”” ;197 St r ing dec = ”” ;198
199 i f ( ( ch i l d r en != nu l l ) && ( ch i l d r en . s i z e ( ) > 0 ) ) {200 f o r ( i n t i =0; i<ch i l d r en . s i z e ( ) ; i++)201 {202 i f ( c h i l d r en [ i ] . elementName == ” Dec la ra t i on ” ) {203 dec = ch i l d r en [ i ] . t oS t r i ng ( ) ;204 }205 i f ( c h i l d r en [ i ] . elementName == ”BinaryExpress ion ” ) {206 exp = ” where ” + ch i l d r en [ i ] . l e f tOperand + ” = : ” + ch i l d r en [ i ] . r ightOperand ;207 }208 i f ( c h i l d r en [ i ] . elementName == ”Name”) {209 var = ch i l d r en [ i ] . t oS t r i ng ( ) ;210 }211 }212 }
161
213 %>214 query = ” s e l e c t ${ var } from ${ dec } ${ exp}”215 </MacroDef>216 <MacroDef name=”${ parent . parent . parent . name } . exprDef ”>217 <%218 St r ing optype = ”” ;219 optype = parent . parent . parent . type . t oS t r i ng ( ) ;220 optype = f i l t e r l t g t ( optype ) ;221 %>222 re turn (${ optype })223 em. createNamedQuery ( ”${ parent . parent . parent . name}” ) . g e tRe su l tL i s t ( ) ;224 </MacroDef>225 ] ]></Pre>226 </Rule>227
228 <Rule match=” Struct /Operation /BlockStatement /Express ionStatement ”229 express ionmapping=”yes ”>230 <Pre>< ! [CDATA[231 <MacroDef name=”${parent . parent . name } . exprDef”>232 ] ]></Pre>233 <Post>< ! [CDATA[234 </MacroDef>235 ] ]></Post>236 </Rule>237
238 <Rule match=” Struct /Operation /BlockStatement / Loca lVar i ab l eDec l a ra t i on ”239 express ionmapping=”yes ”>240 <Pre>< ! [CDATA[241 <MacroDef name=”${parent . parent . name } . exprDef”>242 ] ]></Pre>243 <Post>< ! [CDATA[244 </MacroDef>245 ] ]></Post>246 </Rule>247
248
249 <Rule match=”ZOOMModule/ Dec la ra t i on / Var iab l eDec l a ra to r ”>250 <Pre>< ! [CDATA[251 <%252 i f ( parent . type != nu l l && parent . type . gentype != nu l l253 && parent . annotat ions != nu l l && parent . annotat ions . s i z e ( ) > 0) {254
255 i f ( ( parent . annotat ions [ 0 ] . mu l t i p l i c i t yR i gh t . t oS t r i ng () == ” Mu l t i p l i c i t y . One”) &&256 ( parent . annotat ions [ 0 ] . mu l t i p l i c i t y L e f t . t oS t r i ng () == ” Mu l t i p l i c i t y .One ” ) ) {257 %>258 <%−− Right:One ; L e f t : One−−%>259
260 <MacroDef name=”${parent . type . gentype [ 0 ] } . a t t rDe f”>261 protec ted ${ parent . type . gentype [ 1 ] } $ { parent . annotat ions [ 0 ] . r o l eR ight } ;262 </MacroDef>263
264 <MacroDef name=”${parent . type . gentype [ 0 ] } . operDef”>265 <%−−Entity t ab l e annotat ion −−%>266 @OneToOne
162
267 pub l i c ${ parent . type . gentype [ 1 ] }268 get ${ c a p i t a l i z e ( parent . annotat ions [ 0 ] . r o l eR ight . t oS t r i ng ( ) ) } ( ) {269 re turn ${ parent . annotat ions [ 0 ] . r o l eR ight } ;270 }271 </MacroDef>272 <MacroDef name=”${ parent . type . gentype [ 0 ] } . operDef ”>273 pub l i c void s e t ${ c a p i t a l i z e ( parent . annotat ions [ 0 ] . r o l eR ight . t oS t r i ng ( ) )}274 (${ parent . type . gentype [ 1 ] } $ { parent . annotat ions [ 0 ] . r o l eR ight } ) {275 t h i s . ${ parent . annotat ions [ 0 ] . r o l eR ight } = ${ parent . annotat ions [ 0 ] . r o l eR ight } ;276 }277 </MacroDef>278
279 <MacroDef name=”${ parent . type . gentype [ 0 ] } . operDef ”>280 <%−−Ent i t y t a b l e annotat ion −−%>281 @OneToOne282 pub l i c ${ parent . type . gentype [ 1 ] }283 get ${ c a p i t a l i z e ( parent . annotat ions [ 0 ] . r o l eR ight . t oS t r i ng ( ) ) } ( ) {284 re turn ${ parent . annotat ions [ 0 ] . r o l eR ight } ;285 }286 </MacroDef>287 <MacroDef name=”${ parent . type . gentype [ 0 ] } . operDef ”>288 pub l i c void s e t ${ c a p i t a l i z e ( parent . annotat ions [ 0 ] . r o l eR ight . t oS t r i ng ( ) )}289 (${ parent . type . gentype [ 1 ] } $ { parent . annotat ions [ 0 ] . r o l eR ight } ) {290 t h i s . ${ parent . annotat ions [ 0 ] . r o l eR ight } = ${ parent . annotat ions [ 0 ] . r o l eR ight } ;291 }292 </MacroDef>293
294 <MacroDef name=”${ parent . type . gentype [ 1 ] } . a t t rDe f ”>295 protec ted ${ parent . type . gentype [ 0 ] } $ { parent . annotat ions [ 0 ] . r o l e L e f t } ;296 </MacroDef>297
298 <MacroDef name=”${ parent . type . gentype [ 1 ] } . operDef ”>299 <%−−Ent i t y t a b l e annotat ion −−%>300 @OneToOne301 pub l i c ${ parent . type . gentype [ 0 ] }302 get ${ c a p i t a l i z e ( parent . annotat ions [ 0 ] . r o l e L e f t . t oS t r i ng ( ) ) } ( ) {303 re turn ${ parent . annotat ions [ 0 ] . r o l e L e f t } ;304 }305 </MacroDef>306 <MacroDef name=”${ parent . type . gentype [ 1 ] } . operDef ”>307 pub l i c void s e t ${ c a p i t a l i z e ( parent . annotat ions [ 0 ] . r o l e L e f t . t oS t r i ng ( ) )}308 (${ parent . type . gentype [ 0 ] } $ { parent . annotat ions [ 0 ] . r o l e L e f t } ) {309 t h i s . ${ parent . annotat ions [ 0 ] . r o l e L e f t } = ${ parent . annotat ions [ 0 ] . r o l e L e f t } ;310 }311 </MacroDef>312
313 <%314 }315
316 i f ( ( parent . annotat ions [ 0 ] . mu l t i p l i c i t yR i gh t . t oS t r i ng () == ” Mu l t i p l i c i t y . One”) &&317 ( parent . annotat ions [ 0 ] . mu l t i p l i c i t y L e f t . t oS t r i ng () == ” Mu l t i p l i c i t y .Many” ) ) {318 %>319 <%−− Right:One ; L e f t : Many−−%>320
163
321 <MacroDef name=”${ parent . type . gentype [ 0 ] } . a t t rDe f ”>322 protec ted ${ parent . type . gentype [ 1 ] } $ { parent . annotat ions [ 0 ] . r o l eR ight } ;323 </MacroDef>324
325 <MacroDef name=”${ parent . type . gentype [ 0 ] } . operDef ”>326 <%−−Ent i t y t a b l e annotat ion −−%>327 @ManyToOne328 pub l i c ${ parent . type . gentype [ 1 ] }329 get ${ c a p i t a l i z e ( parent . annotat ions [ 0 ] . r o l eR ight . t oS t r i ng ( ) ) } ( ) {330 re turn ${ parent . annotat ions [ 0 ] . r o l eR ight } ;331 }332 </MacroDef>333 <MacroDef name=”${ parent . type . gentype [ 0 ] } . operDef ”>334 pub l i c void s e t ${ c a p i t a l i z e ( parent . annotat ions [ 0 ] . r o l eR ight . t oS t r i ng ( ) )}335 (${ parent . type . gentype [ 1 ] } $ { parent . annotat ions [ 0 ] . r o l eR ight } ) {336 t h i s . ${ parent . annotat ions [ 0 ] . r o l eR ight } = ${ parent . annotat ions [ 0 ] . r o l eR ight } ;337 }338 </MacroDef>339
340 <MacroDef name=”${ parent . type . gentype [ 1 ] } . a t t rDe f ”>341 protec ted L i s t&l t ; ${ parent . type . gentype [0 ]}& gt ; $ { parent . annotat ions [ 0 ] . r o l e L e f t } ;342 </MacroDef>343
344 <MacroDef name=”${ parent . type . gentype [ 1 ] } . operDef ”>345 <%−−Ent i t y t a b l e annotat ion −−%>346 @OneToMany347 pub l i c L i s t&l t ; ${ parent . type . gentype [0 ]}& gt ;348 get ${ c a p i t a l i z e ( parent . annotat ions [ 0 ] . r o l e L e f t . t oS t r i ng ( ) ) } ( ) {349 re turn ${ parent . annotat ions [ 0 ] . r o l e L e f t } ;350 }351 </MacroDef>352 <MacroDef name=”${ parent . type . gentype [ 1 ] } . operDef ”>353 pub l i c void s e t ${ c a p i t a l i z e ( parent . annotat ions [ 0 ] . r o l e L e f t . t oS t r i ng ( ) )}354 ( L i s t&l t ; ${ parent . type . gentype [0 ]}& gt ; $ { parent . annotat ions [ 0 ] . r o l e L e f t } ) {355 t h i s . ${ parent . annotat ions [ 0 ] . r o l e L e f t } = ${ parent . annotat ions [ 0 ] . r o l e L e f t } ;356 }357 </MacroDef>358
359
360 <%361 }362
363 i f ( ( parent . annotat ions [ 0 ] . mu l t i p l i c i t yR i gh t . t oS t r i ng () == ” Mu l t i p l i c i t y .Many”) &&364 ( parent . annotat ions [ 0 ] . mu l t i p l i c i t y L e f t . t oS t r i ng () == ” Mu l t i p l i c i t y .One” ) ) {365 %>366 <%−− Right:Many ; L e f t : One−−%>367
368 <MacroDef name=”${ parent . type . gentype [ 0 ] } . a t t rDe f ”>369 protec ted L i s t&l t ; ${ parent . type . gentype [1 ]}& gt ; $ { parent . annotat ions [ 0 ] . r o l eR ight } ;370 </MacroDef>371
372 <MacroDef name=”${ parent . type . gentype [ 0 ] } . operDef ”>373 <%−−Ent i t y t a b l e annotat ion −−%>374 @ManyToOne
164
375 pub l i c L i s t&l t ; ${ parent . type . gentype [1 ]}& gt ;376 get ${ c a p i t a l i z e ( parent . annotat ions [ 0 ] . r o l eR ight . t oS t r i ng ( ) ) } ( ) {377 re turn ${ parent . annotat ions [ 0 ] . r o l eR ight } ;378 }379 </MacroDef>380 <MacroDef name=”${ parent . type . gentype [ 0 ] } . operDef ”>381 pub l i c void s e t ${ c a p i t a l i z e ( parent . annotat ions [ 0 ] . r o l eR ight . t oS t r i ng ( ) )}382 ( L i s t&l t ; ${ parent . type . gentype [1 ]}& gt ; $ { parent . annotat ions [ 0 ] . r o l eR ight } ) {383 t h i s . ${ parent . annotat ions [ 0 ] . r o l eR ight } = ${ parent . annotat ions [ 0 ] . r o l eR ight } ;384 }385 </MacroDef>386
387 <MacroDef name=”${ parent . type . gentype [ 1 ] } . a t t rDe f ”>388 protec ted ${ parent . type . gentype [ 0 ] } $ { parent . annotat ions [ 0 ] . r o l e L e f t } ;389 </MacroDef>390
391 <MacroDef name=”${ parent . type . gentype [ 1 ] } . operDef ”>392 <%−−Ent i t y t a b l e annotat ion −−%>393 @ManyToOne394 pub l i c ${ parent . type . gentype [ 0 ] }395 get ${ c a p i t a l i z e ( parent . annotat ions [ 0 ] . r o l e L e f t . t oS t r i ng ( ) ) } ( ) {396 re turn ${ parent . annotat ions [ 0 ] . r o l e L e f t } ;397 }398 </MacroDef>399 <MacroDef name=”${ parent . type . gentype [ 1 ] } . operDef ”>400 pub l i c void s e t ${ c a p i t a l i z e ( parent . annotat ions [ 0 ] . r o l e L e f t . t oS t r i ng ( ) )}401 (${ parent . type . gentype [ 0 ] } $ { parent . annotat ions [ 0 ] . r o l e L e f t } ) {402 t h i s . ${ parent . annotat ions [ 0 ] . r o l e L e f t } = ${ parent . annotat ions [ 0 ] . r o l e L e f t } ;403 }404 </MacroDef>405 <%406 }407
408 i f ( ( parent . annotat ions [ 0 ] . mu l t i p l i c i t yR i gh t . t oS t r i ng () == ” Mu l t i p l i c i t y .Many”) &&409 ( parent . annotat ions [ 0 ] . mu l t i p l i c i t y L e f t . t oS t r i ng () == ” Mu l t i p l i c i t y .Many” ) ) {410 %>411 <%−− Right:Many Left:Many−−%>412
413 <MacroDef name=”${ parent . type . gentype [ 0 ] } . a t t rDe f ”>414 protec ted L i s t&l t ; ${ parent . type . gentype [1 ]}& gt ; $ { parent . annotat ions [ 0 ] . r o l eR ight } ;415 </MacroDef>416
417 <MacroDef name=”${ parent . type . gentype [ 0 ] } . operDef ”>418 <%−−Ent i t y t a b l e annotat ion −−%>419 @ManyToMany420 @ManyToMany(mappedBy=”${ parent . annotat ions [ 0 ] . r o l e L e f t }” , f e t ch=EAGER)421 pub l i c L i s t&l t ; ${ parent . type . gentype [1 ]}& gt ;422 get ${ c a p i t a l i z e ( parent . annotat ions [ 0 ] . r o l eR ight . t oS t r i ng ( ) ) } ( ) {423 re turn ${ parent . annotat ions [ 0 ] . r o l eR ight } ;424 }425 </MacroDef>426 <MacroDef name=”${ parent . type . gentype [ 0 ] } . operDef ”>427 pub l i c void s e t ${ c a p i t a l i z e ( parent . annotat ions [ 0 ] . r o l eR ight . t oS t r i ng ( ) )}428 ( L i s t&l t ; ${ parent . type . gentype [1 ]}& gt ; $ { parent . annotat ions [ 0 ] . r o l eR ight } ) {
165
429 t h i s . ${ parent . annotat ions [ 0 ] . r o l eR ight } = ${ parent . annotat ions [ 0 ] . r o l eR ight } ;430 }431 </MacroDef>432
433 <MacroDef name=”${ parent . type . gentype [ 1 ] } . a t t rDe f ”>434 protec ted L i s t&l t ; ${ parent . type . gentype [0 ]}& gt ; $ { parent . annotat ions [ 0 ] . r o l e L e f t } ;435 </MacroDef>436
437 <MacroDef name=”${ parent . type . gentype [ 1 ] } . operDef ”>438 <%−−Ent i t y t a b l e annotat ion −−%>439 @ManyToMany440 @JoinTable (name=”${ parent . type . gentype [ 1 ] } ${ parent . type . gentype [ 0 ] } ” ,441 joinColumns=@JoinColumn(name=”${ parent . type . gentype [ 1 ] } ID” , referencedColumnName=”ID” ) ,442 inverseJoinColumns=@JoinColumn (name=”${ parent . type . gentype [ 0 ] } ID” , referencedColumnName=”ID” )443 )444 pub l i c L i s t&l t ; ${ parent . type . gentype [0 ]}& gt ;445 get ${ c a p i t a l i z e ( parent . annotat ions [ 0 ] . r o l e L e f t . t oS t r i ng ( ) ) } ( ) {446 re turn ${ parent . annotat ions [ 0 ] . r o l e L e f t } ;447 }448 </MacroDef>449 <MacroDef name=”${ parent . type . gentype [ 1 ] } . operDef ”>450 pub l i c void s e t ${ c a p i t a l i z e ( parent . annotat ions [ 0 ] . r o l e L e f t . t oS t r i ng ( ) )}451 ( L i s t&l t ; ${ parent . type . gentype [0 ]}& gt ; $ { parent . annotat ions [ 0 ] . r o l e L e f t } ) {452 t h i s . ${ parent . annotat ions [ 0 ] . r o l e L e f t } = ${ parent . annotat ions [ 0 ] . r o l e L e f t } ;453 }454 </MacroDef>455
456 <MacroDef name=”${ parent . type . gentype [ 1 ] } . operDef ”>457 <%−−Ent i t y t a b l e annotat ion −−%>458 @ManyToMany459 pub l i c L i s t&l t ; ${ parent . type . gentype [0 ]}& gt ;460 get ${ c a p i t a l i z e ( parent . annotat ions [ 0 ] . r o l e L e f t . t oS t r i ng ( ) ) } ( ) {461 re turn ${ parent . annotat ions [ 0 ] . r o l e L e f t } ;462 }463 </MacroDef>464 <MacroDef name=”${ parent . type . gentype [ 1 ] } . operDef ”>465 pub l i c void s e t ${ c a p i t a l i z e ( parent . annotat ions [ 0 ] . r o l e L e f t . t oS t r i ng ( ) )}466 ( L i s t&l t ; ${ parent . type . gentype [0 ]}& gt ; $ { parent . annotat ions [ 0 ] . r o l e L e f t } ) {467 t h i s . ${ parent . annotat ions [ 0 ] . r o l e L e f t } = ${ parent . annotat ions [ 0 ] . r o l e L e f t } ;468 }469 </MacroDef>470
471 <%472 }473 }474 %>475 ] ]></Pre>476 </Rule>477
478 <Rule match=” Struct / Dec la ra t i on / Var iab l eDec la ra to r ”>479 <Pre>< ! [CDATA[480 <MacroDef name=”${parent . parent . name } . constrAttrDef”>481 t h i s . ${name} = ${name } ;482 </MacroDef>
166
483
484 <MacroDef name=”${ parent . parent . name } . a t t rDe f ”>485 protec ted ${ parent . type . name} ${name } ;486 </MacroDef>487
488 <MacroDef name=”${ parent . parent . name } . operDef ”>489 <%490 i f ( name . t oS t r i ng () == ” id ” ) {491 pr in t ( ”@Id” ) ;492 }493 %>494 @Column(name = ”${name}” )495 pub l i c ${ parent . type } get ${ c a p i t a l i z e (name . t oS t r i ng ( ) ) } ( ) {496 re turn ${name } ;497 }498 </MacroDef>499 <MacroDef name=”${ parent . parent . name } . operDef ”>500 pub l i c void s e t ${ c a p i t a l i z e (name . t oS t r i ng ( ) )} ( ${ parent . type } ${name} ) {501 t h i s . ${name} = ${name } ;502 }503 </MacroDef>504 ] ]></Pre>505 </Rule>506
507 </RuleSet>
167
Player.java referenced in Section 6.4
1
2
3 package org . r o s t e r . e n t i t y ;4
5 import java . i o . S e r i a l i z a b l e ;6 import java . u t i l . ∗ ;7 import javax . p e r s i s t e n c e . ∗ ;8 import stat ic javax . p e r s i s t e n c e . FetchType . ∗ ;9
10 @Entity11 @Table (name=”Player ” )12
13 @NamedQueries ({14 @NamedQuery(name = ”Player . f i ndP laye r ” ,15
16 query = ” s e l e c t p from Player p where p . id = : id ”17
18 )19
20 ,21 @NamedQuery(name = ”Player . f i ndA l lP l ay e r s ” ,22
23 query = ” s e l e c t p from Player p ”24
25 )26
27 ,28 @NamedQuery(name = ”Player . f indByPos i t i on ” ,29
30 query = ” s e l e c t p from Player p where p . p o s i t i o n = : po s i t i o n ”31
32 )33
34 })35
36 public class Player implements S e r i a l i z a b l e {37 Player ( ) {38 }39
40 Player (41 St r ing id , S t r ing name , S t r ing pos i t i on , double s a l a r y42
43 ) {44 this . id = id ;45
46 this . name = name ;47
48 this . p o s i t i o n = po s i t i o n ;49
50 this . s a l a r y = sa l a r y ;51
52 }
168
53
54 @Id55 @Column(name = ” id ” )56 public St r ing get Id ( ) {57 return id ;58 }59
60 public void s e t I d ( S t r ing id ) {61 this . id = id ;62 }63
64
65 @Column(name = ”name” )66 public St r ing getName ( ) {67 return name ;68 }69
70 public void setName ( St r ing name ) {71 this . name = name ;72 }73
74
75 @Column(name = ” po s i t i o n ” )76 public St r ing g e tPo s i t i on ( ) {77 return po s i t i o n ;78 }79
80 public void s e tPo s i t i o n ( S t r ing po s i t i o n ) {81 this . p o s i t i o n = po s i t i o n ;82 }83
84
85 @Column(name = ” sa l a r y ” )86 public double ge tSa la ry ( ) {87 return s a l a r y ;88 }89
90 public void s e tSa l a r y (double s a l a r y ) {91 this . s a l a r y = sa l a r y ;92 }93
94
95 @ManyToMany96 @ManyToMany(mappedBy=” p l aye r s ” , f e t ch=EAGER)97 public List<Team> getTeams ( ) {98 return teams ;99 }
100 public void setTeams ( Lis t<Team> teams ) {101 this . teams = teams ;102 }103 protected St r ing id ;104
105 protected St r ing name ;106
169
107 protected St r ing po s i t i o n ;108
109 protected double s a l a r y ;110
111 protected List<Team> teams ;112 }
170
Team.java referenced in Section 6.4
1
2 package org . r o s t e r . e n t i t y ;3
4 import java . i o . S e r i a l i z a b l e ;5 import java . u t i l . ∗ ;6 import javax . p e r s i s t e n c e . ∗ ;7 import stat ic javax . p e r s i s t e n c e . FetchType . ∗ ;8
9 @Entity10 @Table (name=”Team” )11
12 @NamedQueries ({13 @NamedQuery(name = ”Team. findTeam” ,14
15 query = ” s e l e c t t from Team t where t . id = : id ”16
17 )18
19 })20
21 public class Team implements S e r i a l i z a b l e {22 Team ( ) {23 }24
25 Team ( St r ing id , S t r ing name , S t r ing c i t y ) {26 this . id = id ;27
28 this . name = name ;29
30 this . c i t y = c i t y ;31
32 }33
34 @Id35 @Column(name = ” id ” )36 public St r ing get Id ( ) {37 return id ;38 }39
40 public void s e t I d ( S t r ing id ) {41 this . id = id ;42 }43
44
45 @Column(name = ”name” )46 public St r ing getName ( ) {47 return name ;48 }49
50 public void setName ( St r ing name ) {51 this . name = name ;52 }
171
53
54
55 @Column(name = ” c i t y ” )56 public St r ing getCity ( ) {57 return c i t y ;58 }59
60 public void s e tC i ty ( S t r ing c i t y ) {61 this . c i t y = c i t y ;62 }63
64
65 @ManyToMany66 @JoinTable (name=”Team Player” ,67 joinColumns=@JoinColumn (name=”Team ID” , referencedColumnName=”ID” ) ,68 inverseJoinColumns=@JoinColumn (name=”Player ID” , referencedColumnName=”ID” )69 )70 public List<Player > ge tP laye r s ( ) {71 return p l aye r s ;72 }73 public void s e tP l ay e r s ( L i s t<Player > p l aye r s ) {74 this . p l aye r s = p l aye r s ;75 }76
77 @ManyToMany78 public List<Player > ge tP laye r s ( ) {79 return p l aye r s ;80 }81 public void s e tP l ay e r s ( L i s t<Player > p l aye r s ) {82 this . p l aye r s = p l aye r s ;83 }84
85 @ManyToOne86 public League getLeague ( ) {87 return l eague ;88 }89 public void setLeague ( League l eague ) {90 this . l eague = league ;91 }92 protected St r ing id ;93
94 protected St r ing name ;95
96 protected St r ing c i t y ;97
98 protected List<Player > p l aye r s ;99 protected League l eague ;
100 }
172
League.java referenced in Section 7.4
1
2 package org . r o s t e r . e n t i t y ;3
4 import java . i o . S e r i a l i z a b l e ;5 import java . u t i l . ∗ ;6 import javax . p e r s i s t e n c e . ∗ ;7 import stat ic javax . p e r s i s t e n c e . FetchType . ∗ ;8
9 @Entity10 @Table (name=”League” )11
12 @NamedQueries ({13 })14
15 public class League implements S e r i a l i z a b l e {16 League ( ) {17 }18
19 League (20 St r ing id , S t r ing name , S t r ing spor t21
22 ) {23 this . id = id ;24
25 this . name = name ;26
27 this . spor t = spor t ;28
29 }30
31 @Id32 @Column(name = ” id ” )33 public St r ing get Id ( ) {34 return id ;35 }36
37 public void s e t I d ( S t r ing id ) {38 this . id = id ;39 }40
41
42 @Column(name = ”name” )43 public St r ing getName ( ) {44 return name ;45 }46
47 public void setName ( St r ing name ) {48 this . name = name ;49 }50
51
52 @Column(name = ” spor t ” )
173
53 public St r ing getSport ( ) {54 return spor t ;55 }56
57 public void s e tSpor t ( S t r ing spor t ) {58 this . spor t = spor t ;59 }60
61
62 @OneToMany63 public List<Team> getTeams ( ) {64 return teams ;65 }66 public void setTeams ( Lis t<Team> teams ) {67 this . teams = teams ;68 }69 protected St r ing id ;70
71 protected St r ing name ;72
73 protected St r ing spor t ;74
75 protected List<Team> teams ;76 }
174
Request.java referenced in Section 6.4
1
2 package org . Request . s e s s i o n ;3 import java . u t i l . L i s t ;4 import javax . e jb . Remote ;5 @Remote6 public interface Request {7 public void c r ea t eP laye r ( Player p laye r ) ;8
9 public void addPlayer ( S t r ing p laye r Id , S t r ing teamId ) ;10
11 public Player f i ndP laye r ( S t r ing id ) ;12
13 public Team findTeam ( St r ing id ) ;14
15 public Set<Player > f i ndA l lP l ay e r s ( ) ;16
17 public Set<Player > f indByPos i t i on ( S t r ing po s i t i o n ) ;18
19 }
175
RequestBean.java referenced in Section 6.4
1
2
3 package org . Request . s e s s i o n ;4 import java . u t i l . L i s t ;5 import javax . e jb . Remote ;6 @Remote7 public class RequestBean implements Request{8 @Pers istenceContext9 private EntityManager em;
10 public void c r ea t eP laye r ( Player p laye r ) {11 em. p e r s i s t ( p laye r ) ;12 }13
14 public void addPlayer ( S t r ing p laye r Id , S t r ing teamId ) {15
16 Team team = findTeam ( teamId ) ;17
18 Player p laye r = f indP laye r ( p laye r Id ) ;19
20 team . addPlayer ( p laye r ) ;21
22 p layer . addTeam( team ) ;23 }24
25 public Player f i ndP laye r ( S t r ing id ) {26
27 return ( Player ) em. createNamedQuery ( ” f i ndP laye r ” ) . g e tRe su l tL i s t ( ) ;28
29 }30
31 public Team findTeam ( St r ing id ) {32
33 return (Team) em. createNamedQuery ( ” findTeam” ) . g e tRe su l tL i s t ( ) ;34
35 }36
37 public Set<Player > f i ndA l lP l ay e r s ( ) {38
39 return ( Set<Player >) em. createNamedQuery ( ” f i ndA l lP l ay e r s ” ) . g e tRe su l tL i s t ( ) ;40
41 }42
43 public Set<Player > f indByPos i t i on ( S t r ing po s i t i o n ) {44
45 return ( Set<Player >) em. createNamedQuery ( ” f indByPos i t i on ” ) . g e tRe su l tL i s t ( ) ;46
47 }48
49 }
176
B ZOOM Model for Hospital Information Manage-
ment System
ZOOM model for HIMS referenced in Chapter 7
1
2 namespace ho sp i t a l ;3
4 @Security ( Authent icat ion=”Yes” , RoleManagement=”Yes” )5 @table6 s t r u c t Person {7 @id8 int id ;9 St r ing name ;
10 St r ing address ;11 }12
13 @table14 s t r u c t Pat ient extends Person{15 int id ;16 St r ing insurance ;17 }18
19 @table20 s t r u c t Doctor extends Person{21 int id ;22 St r ing e xp e r t i s e ;23 St r ing academicDegree ;24 }25
26 @table27 s t r u c t Nurse extends Person{28 int id ;29 St r ing s k i l l ;30 }31
32 @table33 s t r u c t S t a f f extends Person{34 int id ;35 St r ing po s i t i o n ;36 }37
38 @table39 s t r u c t Appointment {40 int id ;41 St r ing date ;42 St r ing time ;43 }44
45 @Associat ion ( mu l t i p l i c i t y L e f t=Mu l t i p l i c i t y .One , mu l t i p l i c i t yR i gh t=Mu l t i p l i c i t y .One ,46 r o l e L e f t = pat ient , r o l eR ight = appointment )47 Relat ion<Patient , Appointment> pat ientappointment ;48
177
49 @Associat ion ( mu l t i p l i c i t y L e f t=Mu l t i p l i c i t y .One , mu l t i p l i c i t yR i gh t=Mu l t i p l i c i t y .One ,50 r o l e L e f t = doctor , r o l eR ight = appointment )51 Relat ion<Doctor , Appointment> doctorappointment ;52
53 @table54 s t r u c t Operation {55 int id ;56 St r ing type ;57 }58
59 @Associat ion ( mu l t i p l i c i t y L e f t=Mu l t i p l i c i t y .One , mu l t i p l i c i t yR i gh t=Mu l t i p l i c i t y .One ,60 r o l e L e f t = pat ient , r o l eR ight = operat i on )61 Relat ion<Patient , Operation > pa t i en t op e r a t i on t ;62
63 @Associat ion ( mu l t i p l i c i t y L e f t=Mu l t i p l i c i t y .Many , mu l t i p l i c i t yR i gh t=Mu l t i p l i c i t y .One ,64 r o l e L e f t = doctor , r o l eR ight = operat i on )65 Relat ion<Doctor , Operation > doc to rope ra t i on ;66
67 @Associat ion ( mu l t i p l i c i t y L e f t=Mu l t i p l i c i t y .Many , mu l t i p l i c i t yR i gh t=Mu l t i p l i c i t y .One ,68 r o l e L e f t = nurse , r o l eR ight = operat ion )69 Relat ion<Nurse , Operation > nurseopera t i on ;70
71 @table72 s t r u c t MedicalRecord {73 @id74 int id ;75 St r ing desc ;76 }77
78 @table79 s t r u c t LabReport extends MedicalRecord{80 int id ;81 St r ing insurance ;82 }83
84 @table85 s t r u c t Medica lHistory extends MedicalRecord{86 int id ;87 St r ing e xp e r t i s e ;88 St r ing academicDegree ;89 }90
91 @table92 s t r u c t Cl in icRecord extends MedicalRecord{93 int id ;94 St r ing s k i l l ;95 }96
97 @Associat ion ( mu l t i p l i c i t y L e f t=Mu l t i p l i c i t y .One , mu l t i p l i c i t yR i gh t=Mu l t i p l i c i t y .One ,98 r o l e L e f t = s t a f f , r o l eR ight = c l i n i c r e p o r t )99 Relat ion<Sta f f , Cl in icRecord > s t a f f c l i n i c r e p o r t ;
100
101 @Associat ion ( mu l t i p l i c i t y L e f t=Mu l t i p l i c i t y .One , mu l t i p l i c i t yR i gh t=Mu l t i p l i c i t y .One ,102 r o l e L e f t = operat ion , ro l eR ight = c l i n i c r e p o r t )
178
103 Relat ion<Operation , Cl in icRecord > o p e r a t i o n c l i n i c r e p o r t ;104
105
106
107 @table108 s t r u c t MedicalDataTemplate {109 int id ;110 St r ing desc ;111 St r ing Secu r i t yLeve l ;112 St r ing format ;113 St r ing attachment ;114 }115
116 @Associat ion ( mu l t i p l i c i t y L e f t=Mu l t i p l i c i t y .Many , mu l t i p l i c i t yR i gh t=Mu l t i p l i c i t y .One ,117 r o l e L e f t = medicalDatatemplate , r o l eR ight = medica l r ecord )118 Relat ion<MedicalDataTemplate , MedicalRecord > templaterecord ;119
120 @table121 s t r u c t B i l l {122 @id123 int id ;124 f loat amount ;125 }126
127 @Associat ion ( mu l t i p l i c i t y L e f t=Mu l t i p l i c i t y .One , mu l t i p l i c i t yR i gh t=Mu l t i p l i c i t y .One ,128 r o l e L e f t = pat ient , r o l eR ight = b i l l )129 Relat ion<Patient , B i l l > p a t i e n t b i l l ;130
131
132 @table133 s t r u c t Lab {134 @id135 int id ;136 St r ing name ;137 }138
139 @Associat ion ( mu l t i p l i c i t y L e f t=Mu l t i p l i c i t y .One , mu l t i p l i c i t yR i gh t=Mu l t i p l i c i t y .One ,140 r o l e L e f t = pat ient , r o l eR ight = lab )141 Relat ion<Patient , Lab> pa t i en t l ab ;142
143
144 @Associat ion ( mu l t i p l i c i t y L e f t=Mu l t i p l i c i t y .One , mu l t i p l i c i t yR i gh t=Mu l t i p l i c i t y .One ,145 r o l e L e f t = lab , ro l eR ight = lab r epo r t )146 Relat ion<Lab , LabReport> l a b l ab r epo r t ;
179
C Screenshots of Hospital Information Management
System
Figure 18: HIMS Main Page ASP.NET version
180
Figure 19: HIMS Main Page JSP version
181
Figure 20: HIMS View Medical Data ASP.NET version
182
Figure 21: HIMS View Medical Data JSP version
183