Ph.D. Dissertation A Template-Based Model Transformation …se.cs.depaul.edu/ise/zoom/projects/transformation/... · 2012-04-10 · 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







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



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 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


Name Code FragmentFile java file creationImport import listCONα placeholder for class constructorsFIELDα placeholder for class member of fieldsGetSetα placeholder for get and set methods


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


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


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


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


13 Set <Player > findAllPlayers ()

14 {return { Player p @ p};};

15


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 

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 >



11 <mapping class="org.omg.uml.foundation.core.UmlClass$Impl"/>

12 </metafacade >



15 <mapping class="org.omg.uml.foundation.core.DataType$Impl"/>

16 </metafacade >


18 .metafacades.WSDLEnumerationTypeLogicImpl >

19 <mapping class="org.omg.uml.foundation.core.Classifier$Impl">

20 <stereotype >ENUMERATION </ stereotype >

21 </mapping >

22 </metafacade >


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


4 class Team {5 protected St r ing id ;6


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





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


4 class League {5 protected St r ing id ;6


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


16 this . spor t = spor t ;17

18 }19





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


8 private St r ing c i t y ;9



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


8 private St r ing spor t ;9



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


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


1


4 class Player {5 protected St r ing id ;6




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




28 }29






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


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


1


4 class Team {5 protected St r ing id ;6



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


23 this . c i t y = c i t y ;24

25 }26







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


1


4 class League {5 protected St r ing id ;6



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



23 }24







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


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 19 <Stereotype name=”Entity ”/>20 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


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




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




33 }34



43



52

152



61


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


1



9 @Entity10

11 public class Team implements S e r i a l i z a b l e {12

13




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


32 this . c i t y = c i t y ;33

34 }35



44



154

53



62

63 }

155


1



9 @Entity10 public class League implements S e r i a l i z a b l e {11




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



31 }32



41



50

51 public St r ing getSport ( ) {52 return spor t ;

156

53 }54


59

60 }

157

A.4 Generation of Comprehensive EJB Applications

Transformation Rule to Generate Comprehensive EJB Applications

1

2 <?xml version=” 1 .0 ”?>3


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 19 <Stereotype name=”Entity ”/>20 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 89 <Stereotype name=” Ses s i on ”/>90 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 122 <Stereotype name=”query”/>123 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


1

2



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




52 }

168

53

54 @Id55 @Column(name = ” id ” )56 public St r ing get Id ( ) {57 return id ;58 }59


64

65 @Column(name = ”name” )66 public St r ing getName ( ) {67 return name ;68 }69


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


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


169



111 protected List<Team> teams ;112 }

170


1



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


30 this . c i t y = c i t y ;31

32 }33



44


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


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



98 protected List<Player > p l aye r s ;99 protected League l eague ;

100 }

172


1



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



29 }30



41



51

52 @Column(name = ” spor t ” )

173



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



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

Documents

Ph.D. Dissertation A Template-Based Model Transformation …se.cs.depaul.edu/ise/zoom/projects/transformation/... · 2012-04-10 · Ph.D. Dissertation A Template-Based Model Transformation