EDOC to EJB transformations within MDA Dariusz Gall Michal Molenda

EDOC to EJB transformations within MDA Dariusz Gall Michal Molenda

Master Thesis

Software Engineering

Thesis no: MSE-2005:15

June 2005

EDOC to EJB transformations within

MDA

Dariusz Gall

Michal Molenda

School of Engineering

Blekinge Institute of Technology

Box 520

SE – 372 25 Ronneby

Sweden

This thesis is submitted to the School of Engineering at Blekinge Institute of Technology in partial fulfilment of the requirements for the degree of Master of Science in Software

Engineering. The thesis is equivalent to 20 weeks of full time studies.

Contact Information:

Author(s):

Dariusz Gall,

E- mail: [email protected]

Michal Molenda

E- mail: [email protected]

Wroclaw University of Technology advisor:

Prof. Zbigniew Huzar

Institute of Applied Informatics

Blekinge Institute of Technology advisor:

Ph.D. Ludwik Kuzniarz

School of Engineering

School of Engineering

Blekinge Institute of Technology

Box 520

SE – 372 25 Ronneby

Sweden

Internet : www.bth.se/tek

Phone : +46 457 38 50 00

Fax : + 46 457 271 25

ii

A

BSTRACT

The Model Driven Architecture is a proposition of the framework of software development process where main accent is put on system models, i.e. platform independent and platform dependent models, and transformations between them. Applying the MDA is related with preparation of these two types of assets. In the thesis, the EDOC and the EJB platform are considered as an examples of platform-independent and platform dependent models. In order to complete this picture, additionally transformations between these two models are required.

The authors focus in the thesis on transformations.

In particular, the authors present the transformation specification description, and specify set of transformations between the EDOC and EJB models.

The transformations are narrowed to the subset of structural aspects of the EDOC models.

Keywords: EDOC, EJB, MDA, transformation, UML models.

“I would rather write programs to help me write programs than write programs”

Dick Sites ii

C

ONTENTS

ABSTRACT .................................................................................................................I

CONTENTS ..............................................................................................................III

1 INTRODUCTION............................................................................................... 5

1.1

B

ACKGROUND

......................................................................................................................................5

1.2

A

IMS AND

O

BJECTIVES

.......................................................................................................................5

1.3

R

ESEARCH QUESTIONS

........................................................................................................................6

1.4

R

ESEARCH APPROACH

.........................................................................................................................6

2 THE MDA............................................................................................................ 7

2.1

I

NTRODUCTION

.....................................................................................................................................7

2.2

C

ONCEPT OF THE

MDA.......................................................................................................................8

2.3

MDA D

EVELOPMENT

P

ROCESS

.........................................................................................................9

2.3.1

Traditional Software Development..............................................................................................9

2.3.2

The Model Driven Architecture Development Life Cycle..................................................... 10

2.4

MDA F

RAMEWORK

...........................................................................................................................12

3 MODELS IN THE MDA.................................................................................. 13

3.1

I

NTRODUCTION

...................................................................................................................................13

3.2

T

HE

MDA

MODELS STRUCTURE

......................................................................................................14

3.2.1

Relations between the models.................................................................................................... 16

3.2.2

Computational independent models......................................................................................... 18

3.2.3

Platform independent models.................................................................................................... 18

3.2.4

Platform dependent models ....................................................................................................... 20

3.3

D

EFINING MODEL LANGUAGES

........................................................................................................23

3.3.1

Extending modelling languages................................................................................................ 23

3.3.2

Creating New Modelling Languages ....................................................................................... 28

3.4

M

ODELLING APPROACHES

................................................................................................................30

3.4.1

UML 1.x......................................................................................................................................... 30

3.4.2

Executable UML .......................................................................................................................... 31

3.4.3

UML 2.0 ........................................................................................................................................ 31

3.4.4

The AL and OCL.......................................................................................................................... 32

3.5

S

UMMARY

...........................................................................................................................................33

4 TRANSFORMATIONS IN THE MDA.......................................................... 35

4.1

I

NTRODUCTION

...................................................................................................................................35

4.2

T

RANSFORMATION

.............................................................................................................................36

4.2.1

Vertical and horizontal transformations................................................................................. 39

4.2.2

Kinds of transformations............................................................................................................ 41

4.3

A

PPROACHES TO TRANSFORMATION SPECIFICATION AND IMPLEMENTATION

..........................43

4.3.1

Process of transformation’s development............................................................................... 43

4.3.2

Requirements on transformation approaches......................................................................... 45

4.3.3

Model transformation features.................................................................................................. 49

4.3.4

Review of Transformation’s Approaches ................................................................................ 54

4.4

S

UMMARY

...........................................................................................................................................72

5 PIM – EDOC ..................................................................................................... 75

5.1

I

NTRODUCTION

...................................................................................................................................75

5.2

EDOC..................................................................................................................................................75

5.3

ECA .....................................................................................................................................................75

5.3.1

Views in ECA................................................................................................................................ 76

5.4

C

OMPONENT

C

OLLABORATION

A

RCHITECTURE

...........................................................................77

5.4.1

Component Specification............................................................................................................ 78

iii

5.4.2

Choreography .............................................................................................................................. 80

5.4.3

Composition.................................................................................................................................. 81

5.4.4

Document Model.......................................................................................................................... 82

5.4.5

Model Management..................................................................................................................... 84

5.4.6

Example......................................................................................................................................... 85

6 PSM – EJB......................................................................................................... 87

6.1

I

NTRODUCTION

...................................................................................................................................87

6.2

D

ESCRIPTION OF

E

NTERPRISE

J

AVA

B

EAN

S

..................................................................................87

6.2.1

Enterprise beans.......................................................................................................................... 88

6.2.2

Session beans................................................................................................................................ 89

6.2.3

Entity beans.................................................................................................................................. 90

6.2.4

Message-Driven Bean................................................................................................................. 93

6.3

D

ESCRIPTION OF

EJB UML

PROFILE

..............................................................................................94

6.3.1

Java Design Model...................................................................................................................... 94

6.3.2

EJB Design Model....................................................................................................................... 95

6.3.3

Message-Driven Bean................................................................................................................. 97

6.3.4

Example......................................................................................................................................... 99

7 TRANSFORMATIONS EDOC-EJB ............................................................ 100

7.1

I

NTRODUCTION

.................................................................................................................................100

7.2

D

ESCRIPTION OF TRANSFORMATION SPECIFICATION

..................................................................100

7.2.1

Description of transformation intention................................................................................100

7.2.2

Formal specification of transformation.................................................................................100

7.3

O

VERVIEW OF THE TRANSFORMATION SPECIFICATIONS

............................................................106

7.3.1

Transformation of Document Model ......................................................................................108

7.3.2

Transformation of Systems’ structure to Transitional Model ............................................108

7.3.3

Final transformation of structure ...........................................................................................108

7.4

S

PECIFICATIONS

...............................................................................................................................109

7.4.1

Composition transformations..................................................................................................109

7.4.2

Component transformations....................................................................................................112

7.4.3

Document Model transformations..........................................................................................141

7.4.4

OCL Function Specifications ..................................................................................................155

8 IMPLEMENTATION OF THE TRANSFORMATIONS .......................... 178

8.1

I

NTRODUCTION

.................................................................................................................................178

8.2

T

HE TOOL

..........................................................................................................................................179

8.3

T

ESTING OF THE TRANSFORMATIONS

............................................................................................179

8.3.2

DocumentModel.........................................................................................................................183

9 CONCLUSIONS ............................................................................................. 186

9.1

S

UMMARY

.........................................................................................................................................186

9.2

C

ONCLUSIONS

...................................................................................................................................186

9.3

F

UTURE WORK

..................................................................................................................................187

10 REFERENCES ............................................................................................ 188

APPENDIX 1 – DESIGN OF THE TOOL .......................................................... 194

APPENDIX 2 - OCL FUNCTIONS INDEX........................................................ 197

APPENDIX 3 – LIST OF FIGURES .................................................................... 199 iv

1 I

NTRODUCTION

1.1 Background

The computer industry is always looking for ways to improve software development productivity as well as the quality and longevity of the software that it creates. Object-orientation, component-based development, patterns, and distributed computing infrastructures are examples of new approaches that have aided in this quest.

However, now new issues arise, which correspond to portability, interoperability of software solutions, since computing solutions have spanned into every dimension.

To address these problems Object Management Group (OMG) introduced new approach the Model Driven Architecture (MDA).

The MDA starts with the well-known and long established idea of separating the specification of operation of a system from the details of the way that system uses the capabilities of its platform.

MDA provides an approach for, and enables tools to be provided for:

• specifying a system independently of the platform that supports it,

• specifying platforms,

• choosing a particular platform for the system,

• transforming the system specification into one for a particular platform.

The three primary goals of the MDA are portability, interoperability and reusability through architectural separation of concerns [42] [34] [25].

If the MDA wants to become a reality, the model-driven software developments approaches shall offer more automated creation, evolution and maintenance of the models utilized during the software lifecycle.

One of the key areas is the model transformation. The transformation is characterized as taking one or more models as input and producing one or more models as output according to a set of rules specific to the purpose in hand or in more concise way [42] “Model transformation is the process of converting one model to another model of the same system.”

Description of system specification is held in the MDA in form of models. The models contain a description of the structural and behavioural aspects of the development system. The Enterprise Distributed Object Computing (EDOC) and

Enterprise JavaBeans (EJB) are example s of system specification holders.

The Enterprise Distributed Object Computing (EDOC) architecture is used to make a specification of platform independent model. The standard provides solution for specification component-oriented systems and it is used to develop enterprisedistributed application [48].

The Enterprise JavaBeans (EJB) technology is the server-side component architecture for the Java 2 Enterprise Edition (J2EE) platform. The Enterprise

JavaBeans technology enables rapid and simplified development of distributed, transactional, secure and portable applications based on Java technology [71].

1.2 Aims and Objectives

The aim of the thesis is to achieve automation of the EDOC structure aspects to the EJB transformations within the MDA.

In order to realize the aim following objectives have to be fulfilled.

Complete a literature search and literature review of existing model transformation techniques

Prepare analysis of transformation approaches

Prepare list of model transformations

5

Specify pre- and post-conditions of selected model transformations (using declarative and/or imperative language)

Develop a tool for platform independent model to platform specific model transformation.

1.3 Research questions

The research questions to the thesis are:

How should the process of the EDOC to the EJB transformation look like

(required kind of tools, stages, artefacts, etc.)?

How are currently transformation approaches able to carry on transformation within the MDA? o

What is the most suitable approach for performing the EDOC to the EJB transformation of structural aspects of system models? o

What is scope of automation of the EDOC to the EJB transformation?

How shall the transformation and its counterparts be described? Which language, which kind of transformation language one shall use (e.g. declarative imperative, hybrid)?

1.4 Research approach

In the thesis, the authors use action research as research approach.

At the beginning, the authors will perform a literature search and literature review of existing transformation approaches and languages.

Next, the authors will explore these approaches and languages in order to investigate the possibility of using them in process of model transformation.

In successor step, the authors will introduce specification of the EDOC to the EJB transformation, and its counterpart transformations , for example in form of pre and post-condition.

Finally, the authors will develop a tool for performing the transformation described previously.

During these actions, following outcomes will be produced:

Literature survey on transformation techniques,

Analysis of transformation approaches,

A transformation and its counterparts of EDOC to EJB UML profile . It will be followed by specification and implementation of it.

Finally, the tool for performing transformation from the EDOC to the EJB will be developed.

6

2 T

HE

MDA

This chapter is an introduction to the idea of the MDA. In this chapter, the reader is able to understand what the model-driven development is, why it is worth to develop such concept as the MDA, i.e. which current problems of the software development are addressed by the MDA. Next, the authors show the place of the MDA in software development processes. Finally, the chapter is closed by presentation of basic framework of the MDA, which gives to the reader general idea about elements and processes within the MDA approach.

2.1 Introduction

The history of the software development is in fact a history of raising the level of abstraction of programming languages [39].

It started from assemblers that main task was to generate a sequence of binary code from a mnemonics that represented hardware instructions. The programming languages, as FORTRAN, made available to translate the specification at “formula” level into particular assembler language. Next generation of the languages as COBOL,

C, did the task of programming less cumbersome, and allowed to portability between different platforms. For instance, with COBOL and C languages, the paradigm of structuring programming was developed, to make programs easier to write, and maintain. Nowadays software industry use another paradigm, object-oriented programming, which has become very popular after the introduction of the C++ in mid-1980’s. It is used in such languages as Eiffel, Java, Smalltalk and C++ obviously.

Moving from the first-generation languages programming, through secondgeneration finally to the fourth, or fifth-generation, one can notice the raising of the level of abstraction. In general, after an elaboration of new programming paradigm at higher abstraction level, an introduction of a language that realises this new paradigm is made.

A specification made within language at a particular level is translated into lowerlevel ones, e.g., programs written in the C++, are translated to C language and next to assembler, or directly to assembler, then to machine code and hardware, see Figure 1.

Figure 1 - The increase of language abstraction levels within the space of years [39]

The results of raising the level of the specification had two implications, first it hided the details of a lower layers, thereby one did not have to care about a way concepts of the language were implemented, living it for a translator program, in particular for developers, who had encoded knowledge of transformation from high-

7

level to low-level specification. Secondly, as details were hidden one did not have full control over the implementation of the specified program, which was not always optimal, for instance, because of performance issues, etc.

Nevertheless, the high-level languages started to be used in the software industry, and development of the translation tools, at proper quality level, made from high-level languages common standard.

The evolution of languages is made within particular schema. In first place, a developed application is formalized in as high-level language as it is possible . Next, after experience with the new language a set of conventions for its use is developed.

As they become formally described, they constitute a higher-level language that is translated into the lower-level language. Obviously, the same case is with the new higher-level language, and so forth.

2.2 Concept of the MDA

The MDA is a framework for software development proposed by the Object

Management Group (OMG). The characteristic for the framework is to utilize a model in software development process [41, p. 2.2]. The MDA provides means for using a model to direct the course of software development.

A model is on the focus of the MDA, since they are primary artefacts of the development process. The general procedure is to take an abstract model of a system and transform it to a concrete model, which contains platform specific details. Then, the platform specific model is utilized for generation of executable artefacts, e.g. code, deployment files etc.

A model in the MDA does not have to be implemented manually by programmers.

Information stored in a model contains all or much of the structure and behaviour of the system, which is sufficient to generate the executable model, in form of the code, deployment specification and other artefacts.

Another benefit is that the knowledge of the target platform is encoded in transformations; thereby it may be reused many times when a new system has to be developed [26].

The MDA is a realization of well-known concept of separation of the specification of the system from details of the system implementation within particular platform. It provides the ability to model a system at a high level of abstraction, e.g., at a level of domain specific languages, and transform the model to any platform if a proper transformation specification is developed. Thereby, using the MDA, one can defer a decision about implementation technology of ones system. What is more, one can develop several implementation of the system, with respect to ones needs.

The separation of a system’s specification relates to term ‘platform-independence’.

The independence in context of the software-platform might be understood per analogy to hardware-platform independence, which is preserved by hardwareplatform-independent languages as C, C++ or Pascal, etc. Programs written within these languages can be executed on any hardware platform on which the proper language compiler is developed. The independence in context of software-platform is achieved if a specification made within the software-platform independent model, without any modification, can be transformed to the CORBA middleware, as well as to

EJB pla tform, or some other platform.

The MDA provides also a capability to systems integration by relating their models. Thereby, the MDA is not only the approach that is able to generate one systems’ implementation on several platforms. It also gives a possibility to develop an integration solution between different platforms to make the systems to cooperate.

8

The features described above would not be able without the metamodelling discipline. The metamodelling is an activity that makes the specification of a metamodel possible. In fact, a meta-model, through sharing of meta-data, is the reason why interoperability of the heterogeneous environments is possible [61].

The basic difference between the MDA and other development approaches that use a model for systems specification is that, in the MDA, a model is treated as key elements of a system definition, in difference to other approaches where a model is created mainly for aiding an understanding and communication between stakeholders of a developed system.

The realization of MDA philosophy provides facilities to specifying the system independently from an implementation platform, choosing platform among previously defined, and in the end transformation of the specification to platform dependent model [41, p.2.2].

Following the statements of the authors of the paper [69], in the MDA, amount of software developers’ work in area of implementation is decreased, however more work is required in area of software solution specification. Following the opinion of the authors of the book [20, p.333], it raises the intentionality of system description, as it provides an automation of a transformation process, and it leaves time for proper system specification, and makes possible to bring the specification language closer to a modelled domain of application.

Following benefits are contributed by the MDA framework to development of the software [21]. It promises improved portability separating model of application domain from an implementation platform. As a transformation between models is automated, it increases software productivity. Well-proven patterns and best practices used to transformation’s specification are the reason of better quality of system generated using transformations. Finally , because of stronger separation of concerns, better consistency, and traceability between models, the MDA improves system maintainability.

The next part presents the place of the MDA in the development process.

2.3 MDA Development Process

Software development makes a progress from the early times of the beginnings of the computers. Much more complex and larger systems can be built by nowadays developers than it was in previous time. Nevertheless, software development is still not mature and struggle s with a number of problems.

First problem is related to that software development is an effort-consuming task, which has to be repeated each time when a developer wants to introduce solution on another platform. System is not developed in a void, it has to communicate with other systems, thereby developer has to care about adapting ones product to new standards, protocols, etc. Finally yet importantly problem are changes made in software’s requirements and adoption of software in order to fulfil them [34]. The MDA approach is a solution that is able to cope with the problems enlisted above. In the book [34], the way the MDA deals with these problems is described in more details. Nevertheless, the authors show in the following part, to gives the reader understanding, the difference between the traditional software development and the MDA development life cycle .

2.3.1 Traditional Software Development

An example of a typical development process is presented on Figure 2, it consists of analysis and functional description, design, coding, testing, and deployment phases.

The documentation produced during phases 1 to 3 is made on the highest level of a system specification. In particular, it includes requirements description, often the UML model, which contains, uses cases diagrams, class diagrams, activity diagrams, state

9

machines, etc. Nevertheless, in many cases these documents are not used in the proper way when successive development steps come.

Nowadays practice of a software development process is often driven by a lowlevel design and coding. Thus, the documents that were written during the first phases of the development process are not updated anymore as soon as the phase of implementation of the system begins. This kind of behave makes very fast these document inconsistent with a real state of the implementation, since introducing a changes over time only at the code level makes only a distance between documents, from 1 to 3 phase and code, bigger, hence the documentation become unrelated and unimportant papers.

Figure 2 - Traditional software development life cycle [34]

2.3.2 The Model Driven Architecture Development Life Cycle

The development process related to the MDA is shown in [34] is similar to the traditional life cycle. Main difference is in type of a content of the artefacts created during the phases. In the MDA, a model is formal specification of the system; thereby it might be interpreted and processed by the computer. Four common types of models are distinguished [34].

The first type is a class of the CIM (the computation independent model). This type of models focuses on the requirements of the modelled system [42]. It describes system in the situation within that will be used.

Next is the type of model at a high-level abstraction system specification that is independent of any imple mentation platform, implementation technology. It is called the PIM (Platform Independent Model). The PIM describes the system in terms of domain of system.

The important for this type of models is that it does not specify which technology or technologies are going to be used to implement the system. The description of the system made within this type of model is free from details of an implementation.

10

Figure 3 - MDA software development life cycle [34]

In the next step of the development, one or more PSMs (the Platform Specific

Model) are created. The aim of this type of models is to provide details required for system implementation. The information provided in this type of models is platform specific, thereby different platforms require different models.

Example of platform and PSMs are EJB, and PSM in form of EJB Profile, which express a model in terms of elements of the EJB as “home interface”, “entity bean”,

“session bean”, etc.

The development process may use many PIMs for generation also more than one

PSM. A system may be described using several aspects; hence, many PIMs might be required to system specification. On the other hand, nowadays system more often require many technologies, which results in many generated PSMs.

As the PSM is a model expressed in terms that are very close to particular implementation platform, it is a small step to generate the code from the PSM specification.

Summing up, the MDA defines the types of models and relation between them.

The MDA itself is a description of an infrastructure for defining and executing transformations between models. It means that the MDA organises models and transformations into categories, and specify relations, and way of cooperation between each element of these categories.

The CIM, PIM, PSM and code are artefacts of different phase of the development supported by the MDA. The aim of these types of models is to represent different abstraction leve ls of the system specification.

The CIM and PIM are created and then they are transformed into one or more

PSMs, and further into code. Thereby, if automated generation is added, one can focus only on specification made on high-level abstraction, leaving implementation details for defined transformations.

Obviously, the most complex and interested one are transformation from CIM and

PIMs to PSMs, which are in the focus on the authors of this paper.

11

2.4 MDA Framework

In the previous section, basic elements of the MDA as PIMs, PSMs, transformation are enlisted. Adding to the elements transformation tools, i.e. tools that are able to execute transformations specified by transformation definition, the basic

MDA framework is created presented on Figure 4.

Figure 4 - The basic elements of the MDA framework

Taking into consideration the developers point of view the most important elements of the MDA are PIM and PSM. The task of the developer is to prepare the system model using the high-level specification model, the PIM. If the transformation is already specified, the next is to choose transformation tool in order to perform the transformation from the PIM to PSM model, and further into code.

Obvious ly, nowadays this scenario is not in force, at least not in so optimistic version. The developer has to implement many parts of the system, oneself, however in the future such scenario will become a reality and the process will be almost fully automated.

The Figure 4, as it is a simplification of the MDA framework, omits such thinks as code generation from the PSM, or transformation from multiple PIMs to multiple

PSMs, since a system specification might be made from different aspects, and the system may require many implementation platforms. It also does not show interoperability bridges that might be generated between the platform models.

Nevertheless, it illustrates the basic idea of the MDA.

12

3 M

ODELS IN THE

MDA

The authors in this chapter focus on general problems related with models, modelling languages, and models coexistence in context of the MDA. In particular, the general introduction to software modelling problem, in accordance to the MDA, is made. Further, the models structure in the MDA is presented, and the presentation is followed by examples of languages of basic model types.

3.1 Introduction

In the book [13], authors defines a model as a way of presenting a reality removing from it unnecessary elements, i.e. elements that does not contribute any important information from a selected point of view. For instance, a model of a computer network, might not concern about particular type of connected computers, type of network connections, etc. However, it may concern only about network nodes, and connections between them, leaving behind all consideration about types of nodes, or a type of particular network connections.

A model is a representation of a theoretical construct that corresponds to particular phenomena in the real word, like physical or social process, etc. This representation contains sets of logical and quantitative relationships between elements of a model. A model might be additionally configurable, i.e. it may also contain a set of variables, which adapts the model to particular situation. A model is also a simplification of the described reality, in order to make them capable to use.

In case of the software engineering, a model is a description or specification of a system and its surroundings. A mode l is used to make specification of structures and behaviour of a system. A model is expressed in some particular modelling language, in most cases it is represented in form of drawings and text [41].

Reasons why a model is created are in [13] [41]. In general, it helps to understand the complexity of the modelled system. Even in case of small systems, amounts of complexity can be large; and a model is indispensable in case of a complex system, since there is not a possibility to comprehend all the system at once. A modelling process gives an ability to divide a problem into small pieces, and focus on solving of particular problem, in accordance to the principle “divide and conquer”.

It gives also a vision of a modelled system, i.e. one is more capable to understand a problem domain that a software system is going to support. A model gives a possibility of manipulation and reasoning about it. A model is also a documentation of the system.

The authors of the paper [39] give the characteristic that model shall have.

As the model shall help in understanding a modelling phenomenon, it shall always omit information that is not necessary from an angle of viewers. Thereby, a good model is not the same as the real thing; it is rather an essence of information required for particular purpose.

Another desirable characteristic of model is its cost. The author of [39] underline, a model must be a cheaper to build than the real thing. This statement refers not only to the financial aspects, since in case of, e.g., medical, car industry projects, a model is made to check whether, the real thing builds upon a model will be safe to human. It concerns also a development of software system in case it is one of components of mentioned projects.

However, in other cases a model is a forecast about the total cost of a system, level of satisfaction of the client, etc. In other words, it shows important features of a built system, without engaging efforts and money that would be needed for developing of a complete system. One can say a model is built to increase productivity, as it is obvious

13

that it is cheaper to manipulate the system’s model than the system itself. In general, a model allow for cheaper exploration and reasoning about particular system domain.

Last, but important feature is communication issue. Since the development of more complex systems cannot be done by one person, it shall be split between developers who work within development groups. One of more important problem is a communication between development groups’ members. A well-prepared model is a mean of communication between the members, since they are capable to illustrate ideas quickly and easily. Further, a model, if it bases on well-defined languages, makes understanding of concepts expressed in a model unambiguous for other members.

What is more, a well-defined model, as it has specified syntax and semantic , is also understandable for machines, which indeed is the base for the model-driven development, and in particular the MDA.

The basic issues related with a MDA model are a degree of language abstraction level, a role of a model in a development process, a relationship between particular modelling la nguage and the MDA.

The degree of language abstraction level corresponds to level of abstraction that is modelle d. If the level of abstraction is high, a model is closely related to a domain of a developed system, e.g. a business domain that the system is going to support. On the opposite side, there is a low-level model, expressed in low-level language. It might be a specification of a database, or software system design, etc. These kinds of models are description of a system in the implementation domain.

The role of a model in other than model-driven development is to document and specify of the system, which main purpose is to facilitate communication between customers and developers, and become kind of blueprints used in the construction phase of system development process.

The idea that is recognized as basic one of the model-driven development is to use a model as input artefact for development process activities, in order to automate the development process. Obviously, these activities shall be specified in machineunderstanding manner, which indeed is made in form of models transformation, for more details see next chapter.

The MDA is free from giving specification of particular languages used for modelling. It is obvious, since the MDA wants to support many types of system domains, different system platforms, and wants to hold models at different levels of abstraction; hence, one general-purpose language might be not sufficient. Taking into consideration the previous statements, one shall develop a way to make various model languages able to be processed within the MDA approach. Thereby, a language that is able to specify other languages has to be developed. The example of such languages is the MOF [51] proposed by the OMG.

The order of content of the chapter is as follows. Firstly, the authors of this paper present the structure of models in the MDA, which focus on types of models used in the MDA, and present the relation between them. Next, in the subchapter Defining model languages, the description and discussion about issues related with modelling languages, specification is made. The following part of the chapter is closed by giving examples of model languages and presentation of their characteristics.

3.2 The MDA models structure

In successor part, the structure of the MDA that draws the relations between models in the MDA is depicted.

The issue of level of abstraction is already introduced in the part above. Now, it is investigated in more details by showing types of models utilized in the MDA, and explanation of this division.

14

In the article [33], the authors suggest dividing software models into three categories, this kind of division is made with respect to type of transformations that shall be carried out in order to transform one type of model to another. The categories are a hi-fidelity platform specific model, a design and specification model, and a business model.

The most abstract from a point of implementation view is a business model. A model presents the rules and processes of the business that a system is going to support. A model is not only use for specification purpose; its other crucial objective is to build a bridge of understanding between all stakeholders in the development process. It is because a system is still expressed within concepts of the modelled reality, however these concepts now are precise, well formed, to become unambiguous , thereby they might be used as entry for the machine transformation.

Thus, they are well understood by stakeholders of the system, and are formal basis for software developers. This type of models is structured in very different manner than hi-fidelity or design and specification models, for instance it does not take for account issues related to way of data persistence and other implementation dilemmas, leaving it for low-levelled models and transformation processes.

A design and specification model is between business and hi-fidelity models.

Whether this kind of models is used is conditioned by abstractness of business and construction richness of a hi-fidelity model. It might be case, where a business model is transformed to hi-fidelity one, omitting the intermediate, a design and specification model. This is when a hi-fidelity model is able to support some of mechanisms of a design and specification model, e.g. composition mechanisms, and in a situation when one is able to develop transformation from a business to hi-fidelity models directly. In other cases, the complexity of transformation specification makes it too hard to develop.

On the bottom of the abstraction ladder, a hi-fidelity model is recognized. It contains all information required for developing artefacts of a system deployment within one or more technologies. Thereby, the concepts used within model might be tightly related to several technology domains. The examples of technologies specified with help of a hi-fidelity model is .NET [40] J2EE, WSDL or BPEL. Moreover, a hifidelity mode l is able to unify the concepts among few heterogeneous technologies, but it does not abstract its too far, its main purpose is to deliver language to specification of particula r technology, or technologies, rather than developing of new, in conceptual sense, specification language. The important issue of a hi-fidelity model is to develop fully automated transformations between the model and deployment technologies.

The concepts presented above are fundamental for the MDA, as a description of system specification is hold in form of models. A model contains a specification of the structure and behavioural aspects of a developed system. The MDA framework shall operate with a formal model, i.e. a model with well-defined “form”, meaning “syntax”, and additionally rules of analysis, inference (used to deduce other feature of a model), or proof for its constructs. Moreover, the syntax may be graphical or textual. In case of a model semantic , as it is described in [42], it might be defined more or less formally, in terms of described domain, (e.g. message sends and replies, object states and state changes, etc.).

As it is stated in document [42], a model that does not fulfil the criteria enumerated above is not formal, thus cannot be used in the MDA approach. It is essential to distinguish between well-formed model, and diagrams of boxes and lines, which do not have any syntax and semantic behind them. The informal diagrams cannot be utilized in development approach of the MDA.

There are certain key models in the MDA. They are realisation of principle of separation between system specification and system implementation. The system within MDA is structured in to the Platform Specific Model (PSM), the Platform

Independent Model (PIM), and the Computation Independent Model (CIM).

15

The CIM model is viewed as the requirements model for the system. A model is a description of situation in which system is going to be used. It is also known as a domain model, or business model. Characteristic for the CIM is concealment of the computational details of the system capabilities. In most cases, the model is independent from the system implementation. More details about the model in chapter

Computational independent models.

The PIM is a high-level abstraction of a software system and it is independent of any implementation technology [41]. The PIM is a model of a subject matter, such as banking, telephony, or the operation of a copier. A PIM represents abstractions from one or more platform models, i.e. it does not provide details. It provides formal specification of system structure and functions, but it does not show a detail of its implementation, i.e., whether a system will be implemented, e.g., on a mainframe with a relational database or on an EJB application server plays no role in a PIM [34, c.1.2.1]. The PIM may contain enterprise, information and computational models.

Moreover, PIM construction is suited to particular architectural style [41]. More details about the model in chapter Platform independent models.

Transformation of the PIM models will result in the PSM’s artefacts, which are models of the system described by the PIM, but expressed in terms of implementation platform concepts, a.k.a. PSM specifies how the system will make use of the chosen platform [41].

The justification of that division into these categories is caused by realisation of principle of separation between system specification and system implementation.

There are certain advantages of such model division. The authors of the paper [42] enlist three of them.

Firstly, the process of validation and verification of a model uncluttered by platform specific semantic is easier to do. For instance, the PSM for system description uses all expressivity required by particular platform, thereby it might be concepts of exception mechanism, parameter types, which are further constrained by rules about value types, references, etc., and the PIM does not have to contain all these implementation details, using concepts required in modelled domain. Hence, the developers focus on task of a system specification.

Secondly, as one has a specification of the system in for m of platform-independent description, it is easier to generate the implementation on different platforms. Since the structure and behaviour of the system are defined as a well-formed model, it is just matter of transformations execution to get one or other PSM for particular platform.

The third consequence of model separation is a possibility of interoperability transformations specification for two or more different target platforms. This kind of transformations is used in case when one wants to transform a PIM into more PSMs, in case when resulting implementation has to be spread among many target platforms. In order to enable interoperability the transformation has to be extended to include specification of connectors used to bridge between cooperating platforms. A result of the interoperability transformation is PSMs for these platforms, which include interoperability mechanisms between these platforms.

3.2.1 Relations between the models

Following the statement in the paper [41], the MDA might be perceived as description of kinds of used models, and the relationships between these kinds of models. The following text introduces the relationship, indeed part of the architecture of the MDA. The Figure 5 and Figure 6 represent the structure of the models in the

MDA.

The business, platform independent and platform specific models are connected by refinement relations. Additionally, the models are integrated horizontally across to different systems (System A, and, System B), which makes possible to define the interactions at different levels of the systems abstraction.

16

The most abstract model is a business model the most detailed and concrete is a platform-specific model. There are no strict boundaries between each type of the model. In addition, within particular type of models, models may vary in level of specification’s abstraction.

The CIMs, PIMs and PSMs are a different view of modelled system, where each view differs from other by level of abstraction of presented specification.

Figure 5 - Model Relationships in the MDA [42]

On the Figure 6, the basic elements of the MDA and relations between them are depicted (since the CIM is somehow similar to PIM it is omitted on the figure). The

PIM, PSM and transformation approaches base on meta-models made within solutions provided by the OMG, like the MOF [51], CWM [46], and UML [55].

Figure 6 - The architecture of the models in the MDA [42]

Although the transformation are described in more details in Chapter 4, the relations between models and transformation type is presented in current chapter.

The transformation contains set of rules that describe a modification of one model to get the result model. In case of the MDA, transformations between models are used to perform transformation in four following cases [42].

The transformation of the PIM to PIM model is made when models are extended filtered, specialized while the development process of the system is performed. The

PIM to PIM transformation is performed in case, when introduction of any platform-

17

dependent information is not required. Mostly , these transformations are model refinement.

The transformation from the PIM to the PSM seems to be the most essential for the MDA. The transformation is used in case when enough refined PIM is ready to be transformed to model that is a realization of the PIM within the execution infrastructure. The transformation is made with accordance to the platform characteristics. The result of transformation is a model, which describes a use of particular platform. An example is a transformation from logical component models, like the EDOC [57], to component models, e.g. the EJB [72], the CCM, etc.

Even the PSM is generated; it does not mean that the implementation of the system is already made. The PSM needs further transformations. The PSM to PSM refinement is performed until the PSM does not contain information necessary for a system implementation.

Last group constitutes the PSM to PIM transformations. A transformation is used in case of abstracting the platform-independent information from a model of an existing system. A PSM to PIM transformation is very hard to automate. In the ideal case, the result of such transformation shall be identical to the entry of the PIM to PSM transformation.

In the following chapters, the types of the models used within the MDA are focused in more details.

3.2.2 Computational independent models

The CIM is a view of a system from the computation independent angle . The focus of the view from which the CIM describes the system is environment, in which it is going to operate, and requirements against the system. These requirements should be traceable , in both ways to and from the others models of the MDA, i.e. the PIM and

PSM constructs. A CIM does not specify the details of the structure and processing of the system, hence it extracts unnecessary information and it helps in presenting exactly what the system is expected to do.

The authors of the paper [41] pay attention on the CIM’s features. It might be expressed in terms that are familiar to the practitioners of the domain. In the concept of the CIM, it is assumed that the users of the models, the domain practitioners, shall focus only on preparation on a specification within its domain. It shall not be knowledgeable about particular way of implementation of the specification. Thereby, the CIMs are kind of models that are a communication bridge between those that are experts in particular business model, and know how to specify requirements within the model, and those whose knowledge is focused on design and construction approaches used for creation of artefacts that are realisation of the requirements.

The advantage of the CIM is to show the system in environment in which it is going to operate, thus it is more obvious to stakeholders, like customers, to understand what system is planned to do. Moreover, the CIM is the source of the vocabulary shared among other MDA models. The CIM has to be traceable to PIM and PSM constructs, and vice versa. The CIM is a business domain model in which the computational details are hidden, or are not yet determined.

3.2.3 Platform independent models

As the CIM has only provided requirements about a system, the platformindependent model (PIM), contains a description of the structures and functions, however abstracting from away technical details. The PIM is platform-independent; it means that the specification of a system is made without consideration of particular platform solution, from the platform independent viewpoint. The PIM is an expression of a model made in the view that describes the computational components and their interactions in a platform-independent manner. A platform independent view shows

18

that part of the complete specification that does not change from one platform to another. A content of the PIM in turn is a realization of the concepts presented in the

CIM.

To recognise what is platform and what is not, a following definition of the authors of [42] is given. A platform provides a set of subsystem and technologies, which gives a coherent set of functionality through specified interfaces and usage patterns. These interfaces and usage patterns might be used in accordance to theirs specification, leaving behind concerns about details of the way of functionality implementation.

Example of generic platform type is an object platform, which supports the architectural style of objects with interfaces, providing mechanisms of services, etc.

Other generic platform type is dataflow platform, which supports a continuous flow of data between software elements.

The technology specific platform type is related to technologies as CORBA [47], an object platform enabling remote invocations and event architectural styles, or its object version, CORBA Components [49], an object platform, which additionally provides components and containers architectural styles. Another platform enabling components and containers style is Java 2 Enterprise Edition (J2EE) [77].

The example of the PIM is presented below. A model of typical librarian system is depicted on Figure 7. This model does not show aspects related to implementation of the system, e.g. distinction between objects accessed locally or remotely. Obviously, developer is aware that a target technology utilized for the system development has to provide mechanism able to offer objects accessed locally and remotely.

Figure 7- Example of PIM. An example class diagram of librarian system at domain abstraction level.

However, the implementation details’ extraction is made on purpose.

Considerations whether remote objects are used or not is out of scope in discussion about a domain model of the librarian system. Extra-information is unnecessary for a model at this level of abstraction, and causes that business domain experts are glutted by information that is not required for modelling process. Thereby, the PIM is a model that abstract from remote accessibility of the objects.

The PIM models may utilize a general purpose modelling language, e.g. the UML

[55], or a language that is required by the specific area in which the system will be used.

Other important feature of the PIM is that it mig ht be composed from many models, where each model is representation of particular viewpoint of the system. The necessity of usage of many points of view in system specificatio n one can find in the

19

case of the RM-ODP proposition. In this proposition, a system is viewed from different perspective as the enterprise, information or computational viewpoint. One can prepare a specification of a system using the perspective of these viewpoints, and store it in form of platform-independent models, which further will be transformed together to one or more platform-specific model.

This means also that the MDA encourage not only many abstraction viewpoints, as the computational, the platform-independent, or platform-specific . It also gives an ability of supporting the system specification from different point of view within one level of abstraction. It is useful, for instance, in situation when the system is very complex and specification has to be split according to some aspects of modelled system, like separation between logic of the system and description of its user interface, or already mentioned separation between computational and information aspects.

Summing up, the PIM is a platform independent model, i.e. a model that is a specification of a system; however, it does not contain parts that are meant to be for particular target platform. It entails that a platform-independent model might be transformed to various platform-specific models.

Finally, the PIM may consist of several models describing the system from different points of view. Each presents an aspect of the modelled system, e.g. information or computational point of view.

3.2.4 Platform dependent models

After the PIMs of a system are made, next step is to choose a platform or platforms that enable implementation of the system with the desired architectural qualities.

The PSM is a model that contains details about implementation of the system, which are specific for the particular platform.

In the platform specific model, a view of a system is taken from the platform specific viewpoint. The platform specific viewpoint is a metamorphosis of the platform independent viewpoint to a set of details that represent a way a system is using a particular target platform. Sometimes, a transformation means to enrich the

PIM by additional information about the implementation’s details of the target platform, but not only. For example, optimization, or re-factoring transformations metamorphose infor mation enclosed in the PIM to the PSM with changing a structure of the PIM. These transformations obviously refine the PIM by implementation information; however, they may also remove information from models of higher level of abstraction, for instance because of performance, or other quality reasons. Thereby, the PSM represents a set of concepts that specify how to use the target platform in order to realize the specification of the system described in the PIM.

Following the paper [41], the PSM, with respect to its purpose, may contain more or less details. An implementation of the system might be done if PSM provides enough information necessary to “construct a system and put it into operation” [41].

Otherwise, the aim of the PSM is to use it as PIM in further refinement to PSM model.

Moreover, one should reflect that there is relative whether the model is called platform specific or platform independent. Following the author of the paper [41], the model that plays role of PSM, because it is the output of one transformation, might be the platform specific model when it is an input to transformation, which refines the model in order to achieve, for example, particular quality requirements. It is worth to understand that platform specific models are described in terms of platform concepts; however, these descriptions may vary in number of contained details. Following the example from paper [41], a PSM specific for CORBA may hide the information about programming language or operation system.

The authors of the paper [41] understand the platform independence as a quality characteristic , which a model may exhibit. The quality presents a degree of independence of model from features of any type of platform, thus saying that

20

something is platform dependent, or independent is a matter of set bar. In particular, in one case a platform dependent model is this that assumes availability of very general features like remote invocation or data persistency, at the same time , other platformdependent models may assume set of details for realizing the remote invocation or data persistency on the EJB platform. The difference is that one can recognize a model as platform-dependent, only assuming the availability of some implementation features, and other recognize a model as platform independent in case when models contain all implementation features’ details typical for particular platform, as the EJB.

Obviously, the dilemma of model being platform-independent or platform specific is related with the point of view from which one is considering particular model. The situation is show in more details on the Figure 8. This picture presents the curve, which is passed along by all kind of models through the development process, i.e. starting from right top corner, which represents business models , and falling down to the left bottom corner, which represents a detailed implementation model, like source code.

Figure 8 - Specification and abstraction levels of languages

The platform independence is a relative concept. One has to notice that taking two arbitrary models; it is not possible to say which is platform-independent. However, one can say that the model that is higher on the curve than the other, placed lower, is more platform-independent than the second model. Following the statement of the authors from the paper [39], the smoothness of the curve, and the mixing of modelling domain elements, is the genesis of the arguments about which models are part of the analys is and which constitutes design. Thereby, the shape of the curve is also a reason of discussions about boundaries between platform specific and platform independent models.

Following the example of the system presented in the chapter above on Figure 7, now an example PSM of the system is presented on Figure 8.

As the PSM is a model that contains detailed information about target platforms, a following model represents the concepts of the Figure 7], enriched with the implementation details. One can imagine that the system is realized using the platform that provides a relational database as a persistence mechanisms, thus the PSM would refer to tables for persistent data that describes librarian accounts and transient information about those librarian accounts. When librarians require introducing some security or user authorisation facilities to the system, one will weave together the

PIM’s elements, a database, a security and authorisation mechanisms.

On the Figure 8, the PSM for the librarian system is shown. Indeed, it is the PIM model enriched with platform-specific concepts, in particular access to remote and local objects. In this particular example, this simple PSM is expressed using the UML

21

stereotypes on the Reader, the Account and the LibraryItem classes, which are stereotyped as “local” or “remote”, depending from access style.

Figure 9 - Example of PSM. An example class diagram of librarian system at design abstraction level.

The PSM provides a set of technical concepts for different parts of a platform, and services provided by the platform.

The PSM is recognized as implementation when it provides all the information required to construction and putting a system into operation. Otherwise, the PSM is utilized in further steps of development process, as entry to successive transformations, which in result gives the implementation of the system.

The authors of the paper [41] mention that if the platform specific model is an implementation of a system, it effects in addition varies type of information to a model, e.g., source code, program linking and loading specifications, deployment description, and other configuration descriptions of different kind.

Examples of the PSMs and platforms are enlisted below. For instance, the CORBA

Component Model (CCM) provides the concepts of the EntityComponent,

SessionComponet, ProcessComponent, Facet, Receptacle, EventSource and others.

Within these concepts, the specification of an application that runs on the CCM is made.

In the MDA, PSMs base on detailed models expressed, for instance, in the UML and OCL, or in platform-specific la nguage described within the MOF, and stored in the repository compliant with the MOF meta-meta-model.

Example of the PSM is and OMG’s model of a part of the CORBA platform in the

UML profile for CORBA. The profile document is a specification of the modelling language that presents the concepts required for specifying an application within the

CORBA middleware platform. Indeed the language of the specification is precised using the UML, since it provides extension mechanisms, which allows for introduc ing new concepts to the UML.

Summing up, the PSM may be recognized as a model that is represents the system specification, given in the PIM, using the concepts of the target platform. Whether a model is platform-specific or platform-dependent is related to the point of view of an assessor, and there is no sharp border between being platform-specific or platformindependent. In final, the PSM are described within meta-models that are compliant with the MOF, or are an enhancement of already exist approaches, like the UML.

22

3.3 Defining model languages

This part of the paper treats about approaches utilized for modelling languages, also referred as meta-modelling. As it is underlined in one of the previous paragraphs, a model is on focus in the MDA. It is used obviously for modelling system specification, but also a transformation in the MDA has a form of models expressed in the MOF language.

A model is useful in the MDA, and other model-driven approaches, only if it is well defined, i.e. whether syntax and semantic rules are specified. In this paper, specification of the semantic rules is not discussed, since it is out of the scope.

The purpose of the syntax rules is to describe in unambiguous way concepts or classes used within particular language, relationships between them, and finally constraints that are posed on these concepts and relationships. The constraints are divided in two main groups, constraints in first group, specify which instances of modelling concepts might be linked using instances of particular relationships , i.e. it selects particular concepts and relation, which is used for linking instances of these concepts. In the second group, constraints are put on instances of the relationships that might link these particular concepts. These constraints may specify, e.g. circumstances under which instances of the concepts are connected, it may pose a number of the instances put on each end of the relationship, etc.

A model is a set of instances of classes and instances of relations, created in accordance to the specification. The syntax specification, which is part of the meta model, is used for checking whether particular an instance of the meta-model, i.e. a model, is created in accordance to rules given in the syntax specification. Besides that, the syntax specification is also used as guide in process of a model creation, and a model exploration, because it delivers set of concepts and relations according to whic h one can create or traverse through a model.

The specification of particular meta-model might be also made in the manner similar to this described above, however it requires a language that is capable to express a specification of the modelling language. For instance, the MOF language is an example of language for other language specification. One can prepare a tool, for instance transformation approach, which is able to cope with this kind of specification, and thereby support many languages within one solution. This kind of approach might be used in case when for system specification many kind of the model are required, as system may be described from many viewpoints, e.g. models describing, informational, computational, and user interface aspects, or models describing system from different abstract levels, i.e. CIMs, PIMs, and PSMs. Indeed, to make these kinds of software development tools possible, the special kind of the tools, called model repositories, are required. Example of this tool is the MDR, which is able to store, and manipulates models which languages are described in the MOF.

In the following parts of the paper, two basic types of meta-modelling approaches are described. The first is related indeed with the modelling language extension, which is presented on example of the UML model extension mechanisms. Second part of presents in more details case of the metamodelling made within the MOF language, in which a language is created from the scratches.

3.3.1 Extending modelling languages

The concern of this part of the paper is the modelling languages extensions using one of the available approaches, the UML profiles, which are investigated in more details in the successor part of the paper.

While the UML language was constructed, its architects made a very clever decision about it. They were aware of that it is not possible to create the modelling language that was going to satisfied all interested people and they did not try to equip the UML in order to make everybody satisfied. However, they knew also that in order to make the UML a flexible approach, they had to provide some kind of extension

23

mechanisms. The mechanisms should give an ability to user to define language constructions that are beyond those defined usually as the base for the general-purpose language as the UML is; thereby a user can profile the UML in accordance to ones needs.

The creators of the UML equip the language with the extension mechanism called a profile. Using the extension mechanisms, one creates the dialect of the UML, which might be thought as separately language. Because of this mechanism, the UML might be perceived as the language for other languages specification that may be used for definition of a set of UML-based language. This ability of the UML is often used in the MDA, since the MDA often requires defining models of various aspects of the system on different abstraction levels. Another important issue related to the pragmatic perspective is that the UML, thereby the extension mechanisms are supported by many mature developments, and modelling tools, thus it makes the integration with the

MDA much simpler, than in case when the special MDA tools should be developed.

The provided extension mechanisms consist of three basic elements, stereotypes, constraints, and tagged values [55]. A UML profile itself is a definit ion of a set of these elements, i.e., stereotypes, tagged values and constraints that extends elements of the UML meta-model. The fundamental limitation of the profile is that it has strictly additive extension mechanism; hence, to the standard UML semantics may be only enhanced by the extension. Thereby, the profile mechanism gives to a user a possibility of refining the semantic presented in the UML; however, it forbids an introduction of any other semantic that is in contradiction the standard semantic.

In most situations, the profiles are specified in order to encourage modelling the concepts of a particular domain, for instance the domain of the distributed application as it is in case of the EDOC, or implementation language-specific domain, e.g. the EJB or Java UML profile.

Now, main elements of the profile are characterized.

3.3.1.1 Constraints

A constraint is a semantic condition or restriction posed on the model element in the UML. It indicates a restriction that must be enforced by correct design of a system.

This restriction might be stated in a natural language, but it is better if it is stated in a well-defined language. In fact, the restrictions stated within constraints have a character of an assertion, and are not an executable mechanism [55].

The constraints might be attached to any model element of the UML model, to precise semantic. Similar situation is in case of the stereotypes, which semantics might be refined by set of constraints. As the stereotypes are a representation of particular modelling concept, they also transfer the constraints posed on them to any model element, which is marked by that stereotypes.

If one uses for constraint specification a formal language, as it may take place in case of a profile, it is possible to evaluate these constraints automatically by a tool, and aids a developer in applying, or checking a model against a particular profile.

3.3.1.2 Stereotypes

The stereotypes are the way for creating user-defined virtual meta-classes. The stereotypes represent a refinement meaning of element that is stereotyped, which is introduced by the creator of the stereotype. As the authors of the specification [55] explain : “the stereotype concept provides a way of branding model elements so that they behave […] as […] instances of new virtual meta-model” . Stereotypes themselves are the meta -class of the UML. Thereby, a user is able to define its own stereotypes as it is made in case of classes, or other modelling concepts in the UML. However, in most cases stereotypes are not created but applied by the user, in order to indicate that particular element of model has meaning related to the stereotype.

24

Marking the particular model element by the stereotype does not change facilities of the element, as its structure, i.e. attributes, associations, constructs. However, the stereotypes are often enhancement of the model definition by new tag definitions, and additional constraints.

Stereotypes can extend a meaning of any of UML meta-model class. Example of these classes are Classes, Attributes, one could also define stereotypes that extend

Association, Parameter, etc. It is true that stereotypes are not limited to extending

elements used for structure modelling; they can also extend elements used in modelling of system behaviour, in particular, elements of collaborations, state machines, and so forth.

Within a stereotype specification a definition of additional values, using tag values, and additional constraints is made. Optionally , the extension mechanism gives a possibility to define , a new graphical representation, an icon for a stereotype, and to represent a stereotyped model element using the icon, which sometimes is more preferable than denoting the stereotyped model elements by keywords with stereotype name. All model elements marked by one or more particular stereotypes receive these values and constraints.

Examples of the stereotypes are provided below Figure 10. The LibraryItem class is presented. This class is marked by the stereotype <<entity>> and graphical symbol in the top-right corner, thereby it extends the meaning of the class to the entity object, which has additional constraints posed on them, for example, the instances of the class shall be stored using some persistence mechanism, or its attributes may be only of simple data-types etc. Addit ionally, the stereotype <<uniqueId>>, which makes the attribute unique among all instances of the class, is branched to the attribute id, which shows that not only Class model element may be stereotyped.

Figure 10 - Example of stereotyped model element

3.3.1.3 Tag Definitions and Tagged Values

To add new kinds of the properties to the set of model elements of the UML, one has to specify the Tag Definitions. The tag definitions are very similar to metaattributes, since they are values attached to model element, however they are created using the extension mechanisms and sometimes they are called the virtual metaattributes, which is made in analogy to stereotypes. The actual values of the properties are made via Tagged Values. The values of the tags might be values of simple data type, or references to other model elements.

Tagged definitions are utilized for representing properties related with management information, or they may contain information that specifies a way of code generation, like optimization levels, type of class, etc [55].

The tag definitions are rather not defined alone, and in most cases, they are specified in cooperation with other elements of the extensions mechanisms like stereotypes. In case of the example Figure 10, the stereotype <<uniqueId>> might be extended tagged definition, which indicates, whether the identifier’s values are userassigned, or system-assigned. The proper illustration is presented below Figure 11. On the picture, the example LibraryItem is depicted, where the attribute id is stereotyped by <<uniqueId>> and additionally the tagged value, of tag definition system-assigned is put. In this particular example, the ids of the entity class LibraryItem are managed by the user of that class, since value of the tag definition is false.

25

Figure 11 - Example of tagged value

Tag definitions should be defined in conjunction with a stereotype since that allows them to be used in a more disciplined manner [55]. Nevertheless, the tag definition might also be made in stand-alone manner, thereby not as part of a stereotype definition.

3.3.1.4 Defining a profile formally

The OMG provides with the UML [55], a powerful mechanism of profiles, following the opinion presented in the book [25, p.150]. The specification of the UML allows for formal definition of the profiles. Thereby, they might be used in automated model processing.

In the specification, a profile is a stereotyped package that contains model elements that have been customized for a specific domain or purpose by extending the meta-model. This package contains such elements as specific stereotypes, tags, and the

UML meta-model elements, which are extended by them. A formal model of a UML profile is known also as a virtual meta-model.

The example portion of the profile specification is given on the Figure 12. The model formally defines the stereotypes and tags of a simple profile used in the examples above. In particular, a stereotype model element is represented as a classifier with branded stereotype <<stereotype>>. The model element is related to the class stereotyped as <<metaclass>>, which an element is being extended by the stereotype.

In particular, it is shown on the Figure 12 that the stereotype <<entity>> relates to

Class meta-class, and might be presented in form of the icon, drawn in top-right corner

of the stereotype element. In case of the <<uniqueId>> stereotype, besides pointing on the meta-class Attribute , additionally the specification of system-assigned tag definition is provided.

Figure 12 - Example of the profile specification

A profile specification is not only the stereotypes, and tag definitions. Often, on elements enclosed in the profile additional rigours in form of model invariant are included. For instance, in case of the presented example, one may wish to put constraints that assure one unique attributes per each class stereotyped by the

<<entity>>. This rule is described by a constraint posed on the stereotype

<<entity>> Figure 13, as a formal invariant, which in this particular example is

expressed in the OCL [54].

26

--One attribute is stereotyped <<uniqueId>>.

context entity inv:

self.feature->exists(attr:Foundation::Core::Attribute| attr.stereotype->exists(name=‘uniqueId’))

Figure 13 - Example of a constraint of the sample profile.

Obviously, in order to make this kind of the profile specification, the strong knowledge of the UML meta-model is required. For instance one has to know how to traverse through associations in the meta-model [55], when specifies profile constraints.

Last thing to make profile a formal one, is to specify explicitly the subset of the

UML meta-model that is profiled. It is done by specification of the packages of the meta-model, which are imported in the profile specification. In the case of the simple profile, the Foundation::Core package is in the scope of the profile interest.

In conclusion, the UML profiling is a mechanism that allows extending the UML modelling approach in a way required by a user of the UML. In most cases, this extension is made because the user wants to create a new language that is tailored to particular domain, in which the user is interested, for instance, business domain [55], etc.

The profiles are very important from a perspective of the MDA. The most important attitude of the MDA is a support of the transformations between the models.

However, to this one needs formal description of languages within input and output models are expressed, and this might be made using the UML profile mechanism. The languages dialects, create using the profiles, are compliant with the UML. They may be used within modelling tools that support the UML, which is another advantage of described mechanism.

Obviously, the disadvantage of the profiles exists, and the most crucial is that

UML based languages created using the profile mechanism can only extend the semantics of the UML, however they are not able to change it. Thereby, in case when one needs to express in a model concepts that are out of the scope of the UML, the profiles are not the suitable mechanisms to do this. In many cases, UML will be used for specifying some, but not all, of the aspects of a system.

In addition, one has to know that the UML might extended not only by provided mechanisms. It is also a possibility to enhance the UML meta-model itself , by adding new meta-constructs as meta -classes, meta-attributes etc. [55]. Formally, the extension of the UML meta-model might be made within the language it is specified, i.e. the

MOF. In a practise it means that used modelling and model repositories gives an ability to the user to change the meta-model that is beneath the UML, which is not often possible.

To distinguish between these two types of the UML extensions, in case using built-in mechanisms, one says about the lightweight UML tailoring. The heavyweight extension of the UML takes place when one has to do with the UML meta-model enhancing.

The advantage of making such extension is that it does not have to be done in an additive manner, since within the MOF, theoretically, any meta-model can be created.

The meta-model creation is in fact a subject of the next part of the paper.

27

3.3.2 Creating New Modelling Languages

The well definition is a basic requirements stated by the MDA approach against models used in transformation process. It means that languages, within models are expressed; have to be defined in form readable and understandable by the computer.

In case of the text languages, grammars of the languages are defined. The grammar definition in that case is given, for instance in the BNF notation (Backus

Naur Form), which is a description of series of tokens that constitutes a correct expression in a language. Obviously, this method is only suitable and used in case of text-based languages and it is a formal specification that might be used for automatic language processing, which is made e.g. by languages compilers. As the BNF is text based it does not suit for modelling languages, which might have a graphical syntax, as the UML. To specify these kinds of languages a meta-modelling approach is used.

The result of the meta-modelling approach is a language specification, a.k.a. metamodel. Within the meta-model concepts, used in the language, i.e. meta-classes, with attributes attached to them, known as meta-attributes, associations, a.k.a. metaassociations , between the concepts, etc. and constraints posed on these elements are defined. For instance, the meta-model of the UML language, defines meta-classes

Class, Attribute, Association, etc., which appropriately represents classes, and

attributes attached to them in model created by the users. Respectively, names of the classes, attributes, and associations are stored in the meta-attribute, name, which is attached to general abstract meta-class ModelElement, see Figure 14.

Figure 14 - Part of the UML meta-model [55]

The modeller can use only elements defined in a language specification, hence if the meta-model of the UML did not include, for instance Attribute meta-class, there would not be a possibility to attach attributes to classes defined within the UML model.

The meta-model is also a model, which itself might be specified in well-defined language. Such languages are recognized as a meta-languages, or meta-meta-models.

Example of such meta-language is obviously , discussed above, BNF. The illustration of this approach is made on

Figure 15.

It is clear that meta-languages are different languages that these one used for modelling purposes. The goal of the second one is to model some aspects of the system, as the aim of the meta-languages is to specify the modelling languages itself

[34].

28

Figure 15 - Relations between model, language and meta-language [34]

The UML meta-model is defined within the MOF language [51]. The MOF approach is a meta-language that includes set of mechanisms of object-oriented languages, as encapsulation, inheritance, etc.

The MOF was created in order to support two distinct viewpoints [51]. It might be considered as language for creation information models for particular domains, which are used in development process, for instance one prepare within the MOF, metamodels that represent different aspects of modelled system.

The question is why one shall prepare new language using the MOF, if one has, for instance, the UML. The reason of developing of the MOF defined models is that some kinds of models are conceptually very different from existing modelling approaches as the UML. Exemplary, the attempts of extension of the UML in possible ways, i.e. lightweight or heavyweight, will not bring expected results, because modelling constructs of these kinds of models do not fit easily within the UML. Even if it is possible to do in some manner, the creation of solutions using MOF metalanguage to define the abstract syntax of such modelling constructs is just simpler task to do. Extending the UML with baggage of already existing concepts, which in turn has to be somehow configured to meet user concepts, one is forced to express, is much more troublesome. Thus, the question of whether to extend existing la nguages, or create own one depends on scale of divergence between modelled concepts, and concepts of the extended language. The more divergence is the more problems occur during attempts of the language extension.

The other view at the MOF approach is from a perspective of language that is able to express the modelling languages form the higher meta-level, thereby it provides a unification mechanisms, which may integrate different kind of meta-models. In addition, from that point of view the MOF approach is essential for the MDA, since it provides a meta-language, according to which the MDA may provides all elements of its architecture. For example, one can imagine a transformation approach that is able to work with different modelling languages, because it is able to set up different metamodels expressed in the MDA.

There are two important reasons why metamodelling is so crucial for the MDA framework [34]. Firstly, using the metamodelling, the MOF meta-language in particular, a mechanism for formal meta-model definition is provided, thereby the transformation tool is capable to operate the models. It is why the models in the MDA are defined through meta-models.

Secondly, a transformation specification is made in terms of the meta-models. In other words, it shows how to transform source model to a target model, by posing rules specified as statement of meta-models elements. Thus, to make transformation definition, one has to understand the meta-models of the source and target models.

In conclusion, the metamodelling is a crucial element of the MDA, which together with transformation constitutes the main properties of the MDA. The meta-modelling technique, which in case of the MDA preferably shall be made using the MOF language, constitutes for all type of models present in the MDA the common basis , see

Figure 6, by which mechanisms of the MDA may access any required model. Thereby, the MOF is somehow, or should become, a common denominator for all modelling concept that are present in the MDA.

29

3.4 Modelling approaches

In this part, the examples of existing modelling approach of each type of the

MDA’s models are introduced. This part of the chapter focus on that issue, and shortly discuss most known languages that might be use for PIMs or PSMs specification. The discussion content is focused on languages that seem to be most important from the

MDA’s point of view. In particular, the following parts of the paper shortly describe and present such modelling approaches as the UML 1.x, the Executable UML, the

UML 2.0, and finally AL (Action Language), and the OCL (Object Constraint

Language), which in fact support the enlisted modelling languages.

3.4.1 UML 1.x

The UML is a language that is well known to the software industry. Thereby it is very important for the MDA approach to support the UML. There newest version of the UML, the UML 2.0 is presented in the sub-chapters below; here the focus is made on the UML 1.x [55].

The UML 1.x language is a modelling language that is not an application specification language. The specification made within the UML 1.x does not limit to software development, it also capable to deal with other kind of models, like business models [36].

In general, the UML 1.x is a modelling language, within one can describe models using both graphical as textual notation. The specification made within the UML 1.x, are semantically reach, since its provides a lot of construction that express, besides syntax, constraints and behaviours of system that are modelled within the UML 1.x, such as static invariants constraints on attributes, pre and post-conditions for operation specification, which supports the contract-based design, patterns of designs, etc.

In addition, the UML 1.x language is enriched by the OCL (Object Constraints

Language) [54], which makes easier specification of certain constraints. Further, specifications prepared within combination of the UML 1.x and the OCL might be made in way that is more formal, thus, they are no or very few ambiguity in this kind of specification. Obviously, there are several reasons of making the specification in much formalized manner. The authors of the [42], encounters such advantages; improvement of a communication between programmers and designer of the system, decreasing a work required for implementing the same specification on different platforms, simplification of a task of providing the integration between specification implemented on different platforms , or finally providing a basic content for preparation of implementation’s tests.

It is obvious that models specified with high level of precision are deeply different from these one not formally specified. It shall be noted that in order to perform fully automated transformation, the very formal specification of a system mode l has to be provided, otherwise, the process of the transformation has to be human-aided by a developer. Following the statement of the author of the book [34], PIMs, in order to make it useful for transformation, have to provide very high level of completeness, consistency and certainty. In other words, the MDA requires from the models a rigour specification, in order to make this approach worth of farther evolution.

The advantages of the UML 1.x, besides mentioned above, are capabilities of the modelling the structural aspects of a system. The structural specification of a system, made using class models, is enough precise to generate fully a system PSM.

The biggest issue related to the UML is a weak area of the behavioural or dynamic model specification. Although many different diagrams of the behavioural aspect of system might be made there are not formal and complete enough to generate a PSM on an implementation level of details, level that indeed is required for development of the

MDA approach [34].

30

In general, the UML 1.x will not become in a future a modelling approach that dominates the MDA framework. The main reason of this are evidently lacks in the behavioural features of the language. Other problems, not discussed in this part of the paper, as issues related with management of large models, are enlisted by the author of the paper [36] further lower its ability for providing proper solution for PIMs, or PSMs specification.

The UML 1.x strong points are its structural capabilities. Using these features, one can create basic PIM models that contain mainly structure aspects of the system, thereby the UML 1.x models might be used for generation of parts of PSM’s, which should be further refinement by a developer.

3.4.2 Executable UML

The Executable UML is somehow the mutation of the UML 1.x. It is defined as a combination of the UML 1.x with the AS (Action Semantics). The main purpose of such combination was to develop a solutions that tights the UML 1.x advantages of the structural capabilities and dynamic behaviour provided by action semantics part. In addition, it tries to deal with some other problems of the UML 1.x, such as large project management.

The action semantics, included in the language, try to make the Executable UML models more expressive. The aim of using the action semantics is to extend the behavioural part of created models, in order to get rid of the necessity of implementation made in intermediate programming languages.

The Executable UML makes the state machine as a common mechanism for defining dynamic aspects of a modelled system. The state machine is extended by procedures written in the AS. Each of these procedures is placed in one the state machine’s state [34].

Although in theory the Executable UML is able to represent the specification of a

PIM from which a complete PSM specification is generated, some issues relate to the language occurs.

First problem is given by author of [36], who expresses opinion that specification of the complete behaviour only by developing state machines is too low to make it general for many domains. It is useful in specific doma ins as development of embedded systems. In case of attempts of providing, the specification in other domains the state machines and specification within them will become too problematic to be accepted it as standard.

Another issue is related with the AS language itself, since it is not very high-level language. The author of the paper [36] understands that the specification made within the AS is in fact on the level of a generated PSM. It further means that there are no particular profits to make specification within the AS, in conformance to preparation of a implementation code manually, since afford put in that work is equal to exertion of model expressed within AS.

In addition, the Executable UML lacks of standardization.

Summing up all information about the Executable UML, one can say that it is rather temporally solution created for supporting executable models rather than the dominating trend. It tries to reduce the shortages of the UML 1.x, by providing better behavioural mechanisms, however it still has drawbacks that does not allow to make it a widely use modelling language, as it is no general enough to support different domains, or it lacks of proper formal specification.

3.4.3 UML 2.0

The newest version of the UML modelling family languages is the UML 2.0 [81].

The OMG claims that the newest version it specially designed for encouraging the facilities of the MDA, thus it is strongly recommended to look at it closer.

The UML 2.0 is created using the knowledge about strong and weak sides of its predecessors. It is a language, that is strong both in structural and behavioural

31

modelling. Further, it includes in new modelling diagrams, and incorporates to the standards meta-models of the OCL, and the AS (Action Semantics) [81].

The improvement of the UML expressiveness is made by introduction of new set of diagrams. Exemplary, in order to express dynamic aspects of the objects by giving periods a new timing diagrams are available. However, in the paper [36], it is mentioned that new diagrams are not still capable enough to deal with some set of required concerns.

The real advantage of the UML 2.0 is the OCL, which now is the part of the UML specification. The incorporation of the OCL gives the UML 2.0 very high level of expressiveness, since the OCL has an ability of the software system properties description, and further the OCL provides an executable subset of the language, which forms the solution expressive enough to specify each required computation function.

The UML 2.0 is application independent language. It can be used for real-time systems as well as to standalone desktop applications, since it provides the mechanisms and set of diagrams, good for specification different software and nonsoftware models.

The language may provide specification on much higher level of abstraction that the UML 1.x. This is because of the capability of executable models, and better expressivity of the OCL. The action model provided by the UML 2.0 is in fact the enhancement of the old action semantics, used in the Executable UML. The OCL used within the UML 2.0 has been also revised and extended, even more improvements are suspected in the OCL 2.0.

The UML 2.0 is currently most suitable approach that is able to provide specification that might be used in the MDA development process [36]. It in contrast to presented approaches is able to specify both structural and behavioural aspects of a system. This is possible because it provides many improvements as better structural modelling, better behavioural modelling, etc., and further it incorporates the OCL and the AS solutions, which play an important role in this improvement [25, p. 76].

3.4.4 The AL and OCL

The concept of action semantics was introduced in 1992, at the same time as object-oriented methodologies for analysis and design were developed. In fact, the executable models have been present in the software industry for a long time. The important milestones that make the idea of executable model closer to became common practice was made by introduction of the OCL (Object Constraints Language)

[54] and incorporating (AS) (Action Semantics) to support AL (Action Language)

[45]. Further steps towards executable models were made when these solutions were integrated with the UML approach [36].

The AL is a specification language that may express the behavioural specification of a system. The expressed specification might be made in way that is independent from the implementation and at a higher level of abstraction. The AL specification is made by an extension of the state diagram and operation on a class diagram. Example of action languages are the Action Specification Language, a public domain language, the BridgePoint Action Language, the Kabira Action Semantics, the action language subset of SDL, and others [55].

The OCL is a language that allows writing constraints and queries over elements of a model. Using this approach one is able to apply unique and complex rules on the software systems.

The basic elements of the OCL are expressions, constraints [34, c.11.5.3]. The expression is a specification of certain value, extracted from investigated model.

Typical expressions might be used, e.g. for setting the initial value of an attribute, or association, specification of an operation’s body, specification of guard conditions in state-charts, or writing end-user queries on a UML model.

A constraint is a specification of a restriction put on elements of a model. Four types of such constraints exist. An invariant is a constraint set on all instances of

32

model elements, such as classes, interfaces, etc. The invariant is a logical expression, which is true all the time. Another constraint type constitutes pre-conditions and postconditions applied to an operation, i.e. restric tions that must be fulfilled before the operations start its execution, and before operations stop its execution. Last type of constraint is a guard, which is checked before a transition in a UML statemachine takes place.

The OCL enrich the semantic of the UML both within structural and behavioural aspects. In case of the structural aspects, the enrichment is made by setting, e.g. invariants on model’s elements. The behavioural aspects are more precisely expressed by pre and post conditions put on operations, guards, etc.

Another important application of the OCL might be made within the MDA, as the authors of the book [34, c. 11.5.3] explain. It might be used as a method for transformation specification. As a transformation maps elements from source to target model, one can use the OCL for specification of the elements in the source model, and relates it with elements of the target model. Further, as the transformation might be seen as kind of function, see [c. 4.2], and one can use the OCL for pre and post condition specification, i.e. one condition on the source elements, and a second on the target elements. OCL expressions used in transformation’s specifications are made within the meta-models of the source and target models.

3.5 Summary

The task of models is to reflect part of modelled reality in an accurate way. Models and modelling play a crucial role in the software industry, especially in case when more and more complex system have to be developed, often in cooperation of many stakeholders.

Model aids in coping with complex problem following the rule “divide and conquer”, i.e. partitioning a complexity of modelled system into several sub-models that describe system from different aspects. Because of models, the stakeholders have better understanding of built system. In addition, using models one can discover characteristics and verify a system, obviously, saving much more efforts, than it would be spend in case of building a target system, and discovering problems after that.

The idea of utilizing the models in model-driven development, thereby the MDA, is to use them as input of an automatic generator of system’s implementation. The implementation of a system is achieved by a sequence of transformations of models until the models at implementation level are created.

In the MDA, two models types are used, the PIM and the PSM. They describe a modelled system from different abstraction perspectives. The MDA organizes these models into the structure, which describes dependencies between these models, i.e. way, they are transformed; languages within they are expressed, etc.

The PIM focuses on platform independent elements of the system, which because of transformations, are mapped to model that represents the detailed perspective from a particular platform’s point of view. It has to be added that there are not strict boundaries between being platform-specific and platform-independent specification.

Hence, it is important to understand that being whether the PIM or the PSM is relative.

The models have to be expressed in well-defined languages. There are at least two possibilit ies, in which it might be done. First mechanism is by profiling the UML modelling approach. The main problem of such solution is that it is hard to use it in situation when one has to express a concept that changes the semantics of the UML. In this case, the extension has to be made by incorporating changes into the UML meta model, or if it still too troublesome, one has to create language from scratches, and formalize it within a meta-language, e.g. the MOF approach.

The MOF meta-language plays a crucial role in the MDA framework. The MOF provides to the MDA approach meta-data integration, as it is a meta-language within concepts used in the MDA, as mode ls, transformations, etc., are expressed. It brings

33

such advantages, as developing transformation approaches that do not depend on languages of the source and target models , or developing a common repositor y for all models which languages is compliant with the MOF standard.

Finally, the general-purpose modelling approaches, which seem to be important candidates for modelling languages in the MDA, are discussed. From that three modelling approaches, i.e. the UML 1.x, the Executable UML, and the UML 2.0, the last one is most capable , to express models utilized in the MDA framework.

Summing up, models in the MDA base on well-developed standards, such as the

MOF, the UML, etc., used for models authoring, and managing. The rest of work, performed by the OMG, in the area of the MDA models, is to provide languages for particular domain of interest and support of the modelling tools.

34

4 T

RANSFORMATIONS IN THE

MDA

In this chapter, the authors present an overview of the transformations issues related to the MDA. In particular, the authors introduce the model of transformation approach, and the authors discuss the several solutions of transformation problem.

4.1 Introduction

In order to become the reality in mainstream of software development practice, the model-driven software development approaches shall offer better automate creation, evolution and maintenance of the models utilized during the software lifecycle.

According to many publications , e.g. [41] [42] [70] [26] [33] [84] [2] [25], one of the keys areas is the model transformations. As the MDA, approach is an example of the model-driven development, automated transformations plays the crucial role in the

MDA.

The authors of the paper [69] present transformations as the Heart and Soul of

Model-Driven software development. The transformation is characterized by authors of [70] as taking one or more models as input and producing one or more models as output according to a set of rules specific to the purpose in hand. This is a very basic characterisation of transformation, and more details are presented in further parts of the paper.

Understanding of importance of transformations is one of crucial elements for developing of model driven development concept. Indeed without the concept of transformation, the whole idea of the model driven development, and in particular

MDA, is useless, since creation of the platform-specific models would not be performed automatically, even more it would not be described in a way using which one would able to repeat the process. In other words, every creation of platform specific model would be different and would require software engineers’ unique work.

The automation of transformation process is also mentioned as task of high priority by the authors of the article [70]. The authors of the article [70] underline that performing transformation activities by hand can be quite a cumbersome and errorprone task. As the perfect solution for the issues, the authors propose an automation of the tasks in order to improve developer productivity and reduce human error.

Next issue is to point places of the transformations in a software development process. Model transformations might be activities that are performed within software development process, which produce new artefacts or change the existing one.

Formally, a transformation can be seen as a function that generates results based on the values of input parameters. Both inputs and results can be artefacts such as diagrams and model elements as well as not artefacts such as code expressed in Java or requirements expressed in plain text [79].

Following the statement of the author of paper [34], the key challenge in the model-driven approaches is to develop transformation that will perform transformation of the high-level abstract model to platform-specific models and further to generate code of system.

The last but not least issues of transformation approaches are its syntax, and execution semantics of transformations, or in other words, how the transformation description between a source and target models shall be prepared.

Many approaches are available and in many cases there are rather informal than formal solutions. These kinds of descriptions are helpful in understating of intention of depicted transformations. However, it is a reason of ambiguities in interpretation, and it is no possible to execute these kinds of specifications without explicit programming effort.

35

Thus, transformation’s descriptions shall fulfil two more requirements, it should be unambiguous, and it should be readable for computers, i.e. precise semantic and syntactic of specification description should be provided. However, it is difficult to specify precise transformations formally and even harder if one wants these to be readable [11], hence, as usual, a balanced solution shall be considered here. Agreeing with statement of the authors of [26], enlisted issues may become a crucial enabler for an open MDA tools chain, thereby MDA that is accessible for any software developers.

In the following part of this chapter, the authors present what is the basic taxonomy of the model transformation. Further, the requirements against the transformation solutions are presented. Next, the main sort of transformation approaches, i.e. concepts, languages, and existing solutions and tools are described.

4.2 Transformation

There are a quite number of many definitions of what the transformation is indeed, but once you look through them it is possible to find a couple of common denominators. Presentation of some proposals of the transformation definition is made in the following part of the thesis.

In the book [20, p. 334] of Czarnecki and Eisenecker, the authors introduce a term of “generator”, which covers many different transformation approaches, e.g., compilers, pre-processors, code generators, transformation components, etc. for instance, the compilers produce the byte or binary specification of the software system, a.k.a. implementation, from the higher-level, language specification, e.g. Java, or C++.

Another example of the transformation approach is component-based environments, or

Rapid Development Tools, like Delphi, Borland C++ Builder, etc.

According to paper [41], the transformation is a process of conversion of a model to another model of the same system. The transformation process as input takes the model specified in platform independent manner and the transformation, and generates the platform specific model and the record of transformation. The transformation it is something that bridge models specified in platform independent manner with pla tform specific ones.

For the purpose of this paper, the authors’ understanding of transformations is introduced. This understanding uses concepts which are presented in [69] [21] [25], i.e. a functional concept of transformation, as a process of source to target model transformation, [41] [42], i.e. concept of transformation with additional parameters and record of transformation, [20, p.334], i.e. the generator concept, which quite simila r to concept presented in [69]. However, in the book [20] more considerations about generators’ functional requirements, which are closer to implementation, are given.

A transformation can be understood as a function, which domain covers all possible source models produced with respect to certain rules determined by

source_metamodel and range set is, in similar way to the domain, defined as set of all

possible models generated from rules associated, expressed in target_ metamodel with target models. The l-function is a function, which results in all possible models according to its argument Figure 16, [86, p. 67-68].

transforma tion :

source

target

,

source

l

(

source_met amodel

),

target

l

(

target

_

metamodel

)

Figure 16 – Basic transformation’s signature

In a body of the transformation function, a specification of transformation between particular elements in domain and range set is made. The content of function is of the basic issues related to problem of transformations within model-driven development, or in MDA in particular. In successive parts of this chapter, a discussion about classification of this part of transformation’s specification is provided.

36

The definition of transformation presented above is often extended. Extension of this definition was already made in [41], [42]. The extension is made by adding to transformation, for instance, additional information or by adding special set of elements that points which and how elements from the source model shall be transferred.

Following the functional description Figure 16, additional parameters in functional signature shall be added, i.e. additional_information and source_model_marks. The

additional_information is a parameter that range is determined by domains of

additional_information’s components. The parameter can hold all information

necessary to force particular behaviour of transformation itself.

For example, a getter-setter transformation, which for all UML attributes, which visibility is public, in specified UML class, changes this visibility to private and add

get and set methods change or read transformed attributes. However, sometimes a

transformation of attributes of collection type has to be made. In some cases, the collection type shall be accessed by methods that can add, remove, find, etc. elements in the collection, rather than set and get the collection itself. In this situation, one can, by adding new parameter to additional_information, leaves decision about that part of transformation Figure 17.

The next example of extension is specified in [41] a marking mechanism. In general, the marks are elements, which represent some concepts in target model, i.e. they show how marked elements shall be transformed. Moreover, marks by selection of source model’s elements itself, indicate which model’s elements shall be transformed.

According to transformation signature Figure 17, the marks’ part of transformation function is juxtaposition of all possible combinations of subsets of values of particular mark’s domain and elements of source model.

transforma tion

:

source

×

additional

_informati on

×

marks

target

,

source

l

(

source_met amodel

),

target additional marks

_informati marks on

ai_dom

_

set

×

source

,

1

×

l

(

target

_

metamodel

),

ai_dom

2

×

×

ai_dom n

,

marks

_

set

U

{

marks

_

sets

2

{

mark

_

dom

1

,

mark

_

dom

2

, ,

mark

_

dom l

}

:

X

(

marks

_

sets

)}

,

X

({

mark

_

dom k

,

mark

_

dom mark

_

dom k

×

mark

_

dom m

×

m

,...,

mark

...

×

mark

_

dom p

_

dom p

})

,

k

<

m

p

{ 1 , 2 ,

,

l

}

Figure 17 – First extended signature of transformations

Next extension of transformation definition may be made within a range of transformation function. The basic definition of transformation function presented in

Figure 16 assumes that only result of transformation’s execution is a target model.

Nevertheless, sometimes a model that has extra information about transformation process is taken into consideration. This consideration is about getting from transformation process information about relations between source and target elements, which were generated during the transformation process. Thus, transformations may lead to independent or dependent models. An independent model is in case where there is no explicitly stated relationship between a source and a target model after generation of the target model. Moreover, there is a case when transformation generates also a results that tights a source model and a target model

[26], sometimes called as record of transformation. This extra information is used mainly for constituting traceability between these two models, for keeping a source

37

and a target model in synchronization when changes are made to either. The record of transformation has form of transformation between transformed element from source model and elements created by transformation, i.e. elements in target model.

Additionally , information which contains knowledge about parts of the transformation used for each part of the transformation, is included

Using transformation signatures Figure 16, Figure 17, the transformation function has to be extended by ele ments that are responsible for providing the record of transformation. Thus, the result of the function has to be modified as it is made on

Figure 18. As it is mentioned above, record of transformation is a transformation between elements in domain set of function transformation and subsets of target set; additionally this information is expanded by run through, i.e. transf_sequence, particular transformation execution.

Adding the record of transformation has few important reasons. One, which is more close to aspects of transformation’s implementation process, is that transformation functions enriched within range set by information about transformation, gives an opportunity to review a run of transformation in case of bug eliminating process.

However, there is issue that is more important. In many cases, the inverse of process transformation is required, for instance, in or der to synchronise two models. A transformation as it is treated as mathematical function, are fully reversible, i.e. a whole source model may be reproduced from particular target model, only if the mathematical functions, which represents them, are reversible. The mathematical functions are reversible only if they are a one-to-one transformation, a.k.a. injective

[86].

A one-to-one transformation, maps each element from domain set to particular unique value in range set, which means also that during transformation process information, is not lost, since one can always trace domain’s elements using relation between domain’s set element and value in range set. Nevertheless, it is not always the case.

In many cases during transformation process information are lost, thus the reverse transformation might be done only partially, i.e. only part of information about domain’s set elements might be retrieved or not at all. Thus, in order to make transformation inverse possible, the extra information have to be introduced in form of record of transformation.

transforma tion :

source

×

additional _informati on

×

marks

target

×

rec

_

of

_

trans

,

source marks

additional

l

(

source_met amodel

),

_informati marks

_

set on

target ai_dom

1

×

source

,

×

l

(

target ai_dom

2

× Κ

_

metamodel

),

×

ai_dom n rec

_

of

_

trans

dom

(transform ation)

×

2

target

×

transf

_

sequence

Figure 18 – Second extended signature of transformations

It has to be added, that these are only signatures of the transformation functions.

Using specification made with respect to these signatures does not give to user knowledge about more strict constraints than only specification of domain and range of transformation function. In order to give to user knowledge about particular characteristics of elements of source and target models, prerequisites of elements of source model, additional information and marks and post-constraints on target’s element might be specified.

The prerequisites are constraints that might be expressed in terms of sets, i.e. compounds of the domain. The transformation may be processed whether the

38

prerequisites are true. The results of transformation, in particular target component of results, might be checked against the post-constraints. A transformation signature, pre and post-conditions are transformation specification. To express the constraints a constraint language is used, i.e. the language, which, in most cases, combines terms of language used for expressing a source model, and language of predicate logic .

Moreover, these languages are a declarative expression-based, i.e. they do not have side effects on constrained models. Example of these kind of languages is Object

Constraints Language (OCL) [54] [32] or variants of OCL’s solution like MQL [28].

However, many other language solutions for specifying pre and post constraints exist, for instance, solutions presented in [62] [70].

In text above some proposition for transformation definition was given. It assumes that transformation itself is a function, that domains and range is described in presented manner. Besides the transformation’s signature, a body of transformation has to be specified; however, no specification of the function’s body language is given.

Nevertheless, some description of transformation function’s body is made using pre and post constraints.

As it is said at the beginning of this chapter, there are few transformation concepts

[34], [69], [41], [42], [21], [20], [27], [26], [2], [3], [5]. For instance, in [34], [21],

[26], [2], [3] transformation’s definition is no more function, but relation between transformed elements, which is indeed an extension of functional definition, since relation in mathematic s is more abstract then function concept. Further, in [21], [27], and [26] and [5], the transformation is seen as graph transformation, which conceptually does not seem to be different from in case of relational approach.

Nonetheless, the main change is in way of construction of constraints posed on model, but not only.

4.2.1 Vertical and horizontal transformations

Two fundamental division of transformation is made, quoting the paper [5, p.120],

[20, p. 341]. The main criterion according to which separation is made is general concept of transformation.

The first concept is to compose a target model in terms of low-level components, preserving a source model structure, or abstract the higher-level concepts from lowlevel components.

This kind of transformations generates, in most cases, from high–level representation, which is a source model, the low-level representation, i.e. a target model by filling the elements of structure of high-level representation, or in other words by composing the low-level representation, the target model, within the structure of high-level model and in terms of the low-level components. In consequence, a vertical transformation establishes a hierarchical decomposition on source and target models. It is called vertical transformation, or forward refinements.

Of course, opposite case might have place, i.e. when low-level components are abstracted to higher-level concepts. In this case, one can say about backward refinements Figure 19.

This kind of transformations is similar to known in literature [22], as source-driven transformation, i.e. approach in which from single elements of the source model comple x elements in the target model with relationships between them are generated.

It has to be noticed that this kind of transformation preserves the source model’s structure to the target model, and fills it by the complex elements generated during the transformation process, or refine abstract elements, in case of reverse transformation.

A source-driven transformation is in common use in PIM to PSM transformation.

39

Vertical transformations

Figure 19 – Vertical transformations (forward refinements)

The second kind of transformations, named horizontal transformation, does not preserve the source model structure. Result of performing a horizontal transformation is a target model, which structure is altered with respect to a source model. The structures of a target model are at the same level of complexity as the one of a source model. Nevertheless, with respect to a source model, the structures in the target model are result of adding, deleting or merging the structures from the source model Figure

20.

A horizontal transformation has very common with target-driven approach [22]. In the target-driven approach, single elements in target model are in juxtaposition with complex elements in a source model. Indeed, a transformation from this class does not carry the structure from a source model to a target model, which makes them equivalent to a horizontal transformation.

Finally, an oblique transformation, i.e. transformation, which conceptually is a combination of vertical and horizontal transformations, is present. An oblique transformation changes structure and as well as fill the high-level structures from the source model with low-level components, or do it backwards, and store it as the target model, see Figure 20.

In the paper [22], the aspect-driven transformation class is introduced. In similar to refinement, this transformation is a combination of source-driven and target-driven approaches. Thus, the rules, which are in an aspect-driven transformation, tight single elements from the source model with complex sets of elements from target model, and complex sets of elements from the source model to single elements of the target model.

An oblique transformation is used in model optimizations, aspect weaving among model [20] etc., since it provides not only forward and backward refinements of elements of structure, but also it can change the structure from the source model.

Example of this kind of transformation is forward refinement, in which an optimization and refinement process is done at the same time.

The transformation of an architectural design from a component-based system description, for instance, a model within EDOC platform independent specification, to a set of interfaces of a middleware platform, which in case of the paper might be EJB platform, is an example of aspect-driven transformation. Using this style of transformation, several aspects might be distinguished. One of the aspects might be set of transformation from EDOC, in particular ECA platform specificatio n to Java

40

interfaces. Another group might map settings in the ECA model, to transactional policies for the EJB’s components [22].

Vertical transformations

Horizontal transformations

Oblique transformations

Figure 20 – Vertical, horizontal, and oblique transformations

In general, these groups of transformation are three basic groups that might be recognized if one takes into consideration concepts of model transformation. The very basic transformation might be expressed in terms in the forward or backward refinements approach. In order to introduce transformation that is more complicated a vertical compound of transformation approach has been added. The vertical concepts of transformation combined with forward or backward refinements gives a powerful transformation tool, which seems to be capable to conduct the most important transformation required by model-driven development and MDA in particular [22].

4.2.2 Kinds of transformations

Taking into consideration the previous transformation’s classification, further transformation grouping might be made. In the book [20, p.344], classification of transformation with respect to task that are performed by them is introduced. This transformation classification is presented in context of source-to-source transformation, but it does not mean that this classification is not valid for model-tomodel transformation, since main difference between a source code and model representation of particular system is language within these models are described.

However, this classification lacks of transformation necessary for model-driven development process, hence the set of transformations shall be enhanced by abstraction, representing, migrating, lightweight migrating and merging, in other words weaving transformation [22] [25].

4.2.2.1 Vertical transformations

First group of transformations constitutes refinement transformations. This kind of transformations, as it is mentioned earlier, adds to high-level structures, low-level components. In other words, refinement transformation fills the gaps in high-level with implementation details. Among the refinements several subtypes are further recognized, i.e. decomposition, choice of representation, specialization and concretization. In decomposition, concepts of higher level are decomposed into

41

concepts of a lower level. Choice of representation means to select the appropriate low-level representation for high-level concepts, where about choosing of particular decides desired characteristics posed on generated target model. In specialization and concretization, an abstraction is specialized according to certain context and concretized by adding more details to abstract concepts [20, p.345].

Next distinguished group of transformation are optimisation transformation. The main aim of optimisations is to improve some of performance characteristics of a system. An optimisation transformation is divided between two groups, i.e. an interleaving transformation, and a delocalization transformation. The interleaving transformation in a model means to realize few higher-level concepts in one section of lower-level model, e.g., classes, packages, etc. At the other side, the delocalization transformation spreads a higher-level concept among many lower-level concepts [20, p. 346].

The concept that is opposite to forward refinements transformation is comprised by abstracting transformation. “When one cannot see the forest for the trees, it is helpful to abstract stuff away that does not add to one understanding of the model or source code” [25], which is a very good example of necessity of this type of transformations. The abstracting transformation, using transformation that coordinates the abstract view with the detailed model, elicits elements necessary for particular abstraction level.

With connection to the abstract transformation, a transformation, a migrating

transformation, that moves the high-level concepts expressed in one low-level set of

components, which in partic ular situation is named a platform, to another low-level set of components is differentiated. This kind of transformation is very handy when one wants to move an existing model of system to a different platform. In this case the forward and backward refinements are combined in order to abstract existing model of the system to refine it forward again on particular platform [25].

4.2.2.2 Horizontal transformations

The representing transformation are used in situation whether a necessity of translation between languages, a.k.a. meta-models, within concepts are expressed occurs. This necessity occurs mostly in cases when a used meta -model is not supported by readily available notations, or when a plethora of meta-models exists, where each requires different notations and tool support. In these cases, the representing transformation delivers a support in moving between different meta-models. A representing transformation is most useful if it is a reversible, because it gives a possibility to move to and back from particular meta-model.

The lightweight migrating is transformation when moving between abstraction layers in the migrating transformation is too affordable. Example of situation is when migration from one version of a data model to another is made. The lightweight migrating reformats and regroups existing information to make it amenable to other transformations [25].

4.2.2.3 Oblique transformations

The merging transformation is a combination of vertical and horizontal transformation, which combines aspects of multiple source models into a single target model. To make the combination possible, the merging transformation has to create link between model elements not related to each other Figure 21.

The concept of weaving also appears in aspect-oriented programming. Each aspect is similar to a problem domain, and each aspect is woven together with others by defining a set of merging transformations [25].

42

Source

Model 1

Link Info

Merging

Transformation

Merged

Model

Source

Model 2

Figure 21 - Schema of merging transformation

Last group of transformations that shall be mentioned are re-factorin g transformations. Re-factoring is focused on models’ restructuring [39]. It changes a horizontal structure, or moving concepts among vertical level of abstraction. Refactorings are mainly used in evolutionary development and maintenance of a system

[20, p.349].

To sum up, the groups of transformation are the main representative of transformation categories that are required to perform transformation specification among models in MDA [25]. They are juxtapositions of general transformation concepts presented in paragraph above.

4.3 Approaches to transformation specification and implementation

The previous paragraph treats about general concepts among transformation problem. The general ideas are presented, and explained. Now, it is time to go to direction where more details about transformation are specified. In particular, it means firstly to elicit concepts about process of specification’s creation of particular transformation, and content of the transformation function’s body, i.e. transformation language. Next step is to present requirements against transformation approaches, i.e. against transformation language and transformation system itself. Finally present existing transformation approaches in the light of these requirements. This presentation is made in two steps. First transformation taxonomy described by Czarnecki and

Helsen in paper [21] is introduced, in order to juxtaposition this and requirements with investigating transformation approaches in second part.

4.3.1 Process of transformation’s development

To make definition of transformation different ways and means are used. In typical situations, the transformation is described in informal, intuitive way, and then according to this description implementation, i.e. an executable code is created.

The process of transformation development might be seen as multistage action.

The three main steps might be enumerated: establishing of transformation intention and requirements, transformation specification, and transformation implementation

[79].

An approach that might is suggested in paper [79], is to use a schema of transformation specification that consist of two steps: an informal specification, which is necessary to elicit intention, basic concepts of transformation, and formal specification, which is a transformation description expressed using one of formal approach.

43

To these two steps, the implementation phase shall be added, i.e. this is a stage during which an implementation of transformation against specification is stated.

The implementation is an imperative specification of transformation, i.e. it describes in imperative way how a source model is used to creation of elements of target model, additionally, if parts of other type of specification are placed, e.g. declarative parts in OCL, and there are automatically translatable to imperative form, this is also an implementation. In the implementation, elements of the transformation result are created explicitly [26].

It is important to notice here, that the implementation does not have to mean implementation in one of general purpose, for instance, C, C++ or Java. Of course, this approach is used for implementation of transformation tools. Since the languages, and tools related with these languages, i.e. builder, debugger, etc., have been proven many times before, it shall give for transformation developers more self-assurance that developed tool will have got better quality attributes. Nonetheless, these tools is not always a very good solutions, the better is to model transformation in terms that are closer to transformation domain itself, or concepts of transformed models. It is in opposition to general-purpose languages, where concepts are not directed in particular domains of implemented systems, since they are general-purpose solutions.

The specification of transformation is often made in form of contract between the transformation and transformation system, which uses particular transformation. The contract has two parts, pre-condition, in which conditions about legal usage of transformation are expressed, and post-condition, i.e. obligation for the transformation

[79].

Other treatment for transformation specification is in case when explicitly declaration of relation between a source and a target model are set. A declaration contains enough information to comprehensive description of transformation from elements of a source model to elements of a target model, and from elements of a target model to element of a source model, which are a case of unidirectional transformation, or relations describe transformation in both directions, which is a case of bidirectional transformation [26].

Obviously one can say that if the formal specification of transformation is provided, a translation between this specification and executable aspect of transformation might be made. For instance, if constraints are expressed as OCL invariants, with some extensions to the OCL language, one might want to use this formal specification to check that a transformation program has performed correctly the transformation and even further generate the program from these constraints.

Nevertheless, that it is not always the case, since the maturity of this type of tools is still on childhood level and most of translation has to be done by developers itself.

Moreover, some kinds of specifications, e.g. part of declarative specifications, are very difficult or even impossible to be used as generators of transformations’ implementation from its specification [21], [11], [25, p. 30].

Above the formal specification, the most readable and less detailed specification is informal, text description of transformation. One of the basic approaches in transformation description is obviously a natural language. This concept was presented by authors of [34], [79]. The solution presented in the book [34] is an example of description of transformation. It describes transformation in a pseudo-algorithmic matter, step by step, where each step contains actions that shall be performed on the input and output models. These actions specify what to do in terms of concepts of transformed models and the actions presents logic condition posed on transformed models.

The other form of informal specification, sometimes named semi-formal specification, is the correspondences table. This a table which is divide into three columns, description of source element, description of target element, and clarification in natural language about transformation itself.

44

This solution might be useful if it describes simplistic transformation, for example transformation between elements of EJB UML Profile and elements of EJB concepts expressed in Java language. As an addition to the table, often the transformation rules are refined by further constraints. For example, "The name of the terminal is the name of the target end of the association" [11].

Nevertheless, the transformation intention is not always so easy to describe in form of the table. Many transformations require using information from different part of source model, and creating complex elements of target model.

The descriptions in natural language, informal or semi-formal specification, have few important disadvantages. First, these kinds of specifications, as they use for expression of transformation descriptions, the natural language, are not free from ambiguity. The semi-formal specifications offer a limited help to transformation programmers, let alone automated engines. The main problem with natural specification is in multiple ways in which they could be interpreted [11]. Thus, the same transformation description might be performed in different way. Using a formal notation avoids the risk of misinterpretation due to an ambiguous natural language.

Besides that, next problem is the natural languages’ descriptions tend not to be conciseness, if transformation rules are more complex.

Another issue, directly derived from the first one, is an automation of execution of these transformation descriptions. Since, translation of the natural language transformation to computer-understanding specification is difficult, even if ambiguities are avoided.

However, the natural language might be use to formulate basic ideas beneath the transformation. In general, semi-formal or formal specification is useful to the fundamental understanding of the transformation [79] [11]. The intuitive description of the transformation is in many cases the first step in a process of transformation specification, since it is much easier to formulate a general description of transformation first, and then move towards concept and implementation details of transformation. Moreover, an informal description presents intent of transformation, and is easier to understand that formal specifications.

To give a general overview of transformation development, the development might be divided in three stages, informal or semi-forma l specification, for mal specification and implementation. The general description and transformation’s intentions are incepted. Next step is transformation specification, for instance using contractual-based manner, or relations’ specification between models. At the end, the specifications of the transformation are translated to form, which might be compiled, or interpreted by computer.

4.3.2 Requirements on transformation approaches

Above, deliberations about general comments of transformation are made. In this part, requirements against transformation approaches, i.e. languages, and tools are discussed. It is not claimed that they are a complete set of requirements against transformation approaches.

The OMG, as it is a parent of MDA, proposal of requirement against transformation shall be discussed. The OMG provides the standards, which create well-established fundaments for PIMs and PSMs foundation. These basic standards are

Meta Object Facility (MOF) [51] and the UML [55], however the OMG has not welldefined equivalent that establish groundwork for transformation PIMs into PSMs [27].

Finally, in the 2002 the OMG determined to change this situation. The OMG initiated a standardization process by publishing a Request for Proposal on Query/

Views/ Transformations (QVT) [52]. An aim of proposal was to make a step towards definition of model transformation that will universally enough to express not only

PIM to PSM transformation, but also it will capable for definition of views on model, or model synchronization, i.e. both directions transformation, where changes on one

45

model generate updates on another. This proposal has a wide response, and a large number of approaches to model transformation have been answered [21].

The QVT is perceived as one of fundaments of MDA, which successful establishing is one of condition for further MDA evolution.

Now focus on requirements against transformation that were enumerated in the paper is made [52].

The issue is the way an approach is going to access to elements of models. In the

MDA’s related documents [41], [42], basic approach is to access to the model using the level of meta-models, thereby relationships between models element shall be stated at the level of meta-model.

In paper [41], the transformation is the specification of transformation from one model, e.g. PIM, to another model, e.g. PSM. There are three basic transformation types: model type transformation, model instance transformation, and the hybrid combination of these two approaches.

The model type transformation specify the transformation of any model expressed using types in source language, to model described by types of target language. The rules of this transformation are expressed in the concepts of the languages within the model are specified. Moreover, as the authors in the paper [41] claim, statements of the model type transformation may be specified in terms of the instance values that may be found in model.

In the paper [41], two sorts of a transformation are differentiated; a meta-model transformation, that focus on languages that are instances of meta -languages, for example, MOF meta-language. Well-known example of this type of language is UML.

Other type of transformations are concerned in models that are created within the languages that are not expressed by meta-languages like MOF, but are compliant with grammar-based languages, for instance, C++, CORBA IDL, etc. Of course, one can consider the meta-model to this sort of languages; however, this generalization is not widely used [21].

Another transformation approach presented in [41] is to select the elements of one model and transform them, in particular way, to output model. Example of model instance transformation is transformation-using marking of elements of model. In the paper [41], marks indicate how these elements should be transformed.

However, in most cases, a transformation is a combination of approaches mentioned above. The model type transformation provides the specification in terms of rules about elements of one type expressed in one language and elements of another type within another language, but usually it is necessary to put additional information about transformation process associated with particular element. Thus, the approach combination is essential.

As the way in which transformation approaches access elements of models are established, next step is to place language description in meta-model hierarchy, from which it could manipulate appropriate model’s elements.

As meta-models might be represented in MOF, it is further possible to create a single transformation language that is transforming all meta-models that are expressed using MOF. Any other model that is planned to be transformed using this language has to be described using also MOF approach [26]. This kind of language is called a transformation definition language.

The transformation language shall be defined as part of the MOF, thus specification of transformation is a MOF instance and thereby it is the same level of abstraction as definition of UML model, which is an example of model language

Figure 22. It is obvious requirement, since the particular transformation definition has to manipulate using concepts from languages, which are used for expression of a source and a target model. Therefore, to make the language of transformation definit ion powerful enough, its description shall be placed on abstract level above, i.e. extends meta-language, or MOF in particular Figure 22, [34, c. 9.4.].

46

Figure 22 – Relation between transformation definition language and metalanguage

Following the issues of expressivity, the transformation language shall be capable to describe all information necessary to make a comprehensive specification of automatically generation of a target from a source model. Summing up, languages shall operate on models, i.e. instances of meta-models defined in some meta-language, e.g. MOF 2.0, which is pointed in case of paper [26], and [52].

Obviously, the language created in that manner shall be a well-defined language, i.e. syntactic and semantic rules are specified [34, c. 9.4.].

Further requirements posed in QVT RFP are listed in following part. Firstly, a transformation should be defined symmetrically , i.e. not only using the functional approach, a source to a target model metamorphosis, in bi-directional manner.

Bidirectional transformation may modify a model after the application of the transformation in either direction, sources and targets model are changed. If this is done then there is the possibility of uprising of conflicting changes. Whether it is the case, firstly it is necessary to detect such conflicts; secondly, proper actions shall be made. If it is in power of transformation approach the automatically resolve process might be executed. Nevertheless, there may not be possible to resolve the conflicts automatically, since it is impossible to direct the resolving process in determined way, then the user should be asked for selecting particular way, or there is no way at all.

A transformation should be able to make changes within a same model, i.e. it should implement updates. Repeated application of the transformation should not overwrite any information introduced to the target model.

Other important characteristic of the transformation is its possibility to be executed backward. It is an ability of transformation inversion, which should be understand such that T

-1

(T(M)) = M, i.e. using result of transformation as an argument of its reverse

should give a model that was an argument of the transformation.

In order to make transformation inversion possible , it might be necessary to support it by other mechanism, the traceability of transformation. Using information that is delivered by trace saving, one can use it for re-building of information that is lost in the transformation process. In addition, the trace information is used for transformation’s course review.

A transformation shall also have a transactional character, i.e. a tool that provides environment for transformation should also adds commit and rollback operations, which will be used, e.g., in case of transformation process failure to come back to state before the execution.

47

Last two important requirements are discussed, a supporting of transformation reuse and extension, and using of additional transformation data. The reuse and extension of a generic transformation might be provided by mechanisms for the inheritance, overriding of a transformation, or by instantiation of templates or patterns.

The additional transformation data, or transformation parameters specifies supplementary information that parameterizes the transformation process [26] [52].

Obviously, the transformation definitions should facilitate the construction of tools. It can be made by providing the generator of proper transformation tools, which base on prepared specification of particular transformation. It also might be an approach, which interprets the definition of transformation. In any case, it is important to provide a clear description, a specification, of a way of generation of such tool [33].

Following the discussion of tool support for transformation definitions, Czarnecki and Eisenecker in the book [20, p.334] Figure 23, present the general tasks, requirements of the tools that perform transformation, besides performing transformation itself. The tools shall be able to check the validity of an input specification and provide errors and warnings reporting. If it is necessary and allowed, it should complete specification with default settings and perform optimizations.

System specification, e.g. system model, system source

Generator:

Check specification

Complete specification

Perform optimizations

Generate specification

System specification, e.g. system model, system source

Figure 23- Main tasks of transformation tools [20, p.334]

To select requirements against transformation approaches, important for this paper, the proposition of the requirements on transformation approaches by author of the book [34] is presented.

The source language reference.

The target language reference.

The language reference is a meta-model, of source and target models. These references might be used for verification whether transformation definition accesses source and target models in manner that fulfils rules described in appropriate metamodels.

Optional transformation parameters might be used

Examples of transformation parameters might be constants used in the generation of the target. Another example is parameters that steer a process of models transformation, for instance, choose kind of solutions used for transformation process.

A source models, i.e. a set of na med source elements from the source meta-models.

A target models, i.e. a set of named target elements from the target metamodels.

These are the input and output of transformation. Usually, the source model is read-only and results are written in target model. If transformation is an update transformation, a source and a target model is the same model. If the transformation is bi-directional, the changes are made in both models.

The source language condition.

A precondition is an invariant that states the conditions that must hold in a source model for the transformation rule to apply. If they are not fulfilled the transformation

48

rules cannot be executed. The source language condition shall be expressed only in the terms of source language.

The target language condition.

A post-condition is an invariant that states the conditions that must hold in the target model for this transformation rule to apply, or that needs to be generated when the target model is not yet present. The target language condition shall be expressed only in the terms of target language.

A set of transformation rules.

The transformation rules describes how elements from the source model are transformed to elements in the target model. A transformation’s rules are specified using a well-formed language. The rules are executed only if the preconditions are true. Effects of execution of transformation rules shall generate model’s elements that fulfil post-condition of transformation definition.

In next part, steps towards transformation approach’s implementation are made, i.e. concepts of solutions that realize the requirements are bring closer.

4.3.3 Model transformation features

The previous parts of this chapter focused mainly on concepts that formulate the transformation idea. They present how the transformation shall look like but it does not describe how it shall be realized.

In first place, the taxonomy of transformation approaches is presented [21]. This taxonomy is a result of performing domain analysis to existing model transformation approaches. These analyses are concerted with discovering and modelling distinctions and similarities of transformation approaches.

Next part of this chapter is focused on presentation nowadays main transformation approaches. In this presentation, besides approaches idea itself, the main representative from each transformation approach class are enlisted.

The top-level diagram of model’s feature is shown on Figure 24. This figure presents taxonomy, i.e. a hierarchical classification of things or the principles underlying the classification, of model transformation approaches, where each subnode represents a major point of variation [21]. The features diagram and additional information is referred as feature model. Summary of feature model introduced in [21] is presented further in the thesis.

Figure 24 - Diagram of the model transformation top- level features [21]

49

4.3.3.1 Transformation Rules

The variations within Transformation Rules are depicted in details in Figure 25, according to taxonomy introduced in the paper [21]. The following is a detailed description of five sub-categories, i.e. LHS/RHS, LHS/RHS syntactic separation, Bidirectionality, Parameterization and Intermediate Structures.

LHS/RHS, i.e. Left-Hand Side and Right-Hand Side, are parts of transformation rules. The LHS accesses the source model, whereas the RHS explores the target model. Both of them might be represented using a mixture of the follow ing concepts.

Variables or sometimes referred as meta-variables hold elements from the source or target models. They might be un-typed, syntactically or semantically typed. Patterns are elements of models associated with zero or more variables. They take kind of string, term or graph, are associated with variables and are represented by abstract or concrete syntax, i.e. textual or graphic syntax. Patterns can be un-typed, syntactically or semantically typed.

The explanation concerning the differentiation among variables type has to be provided. According to the taxonomy [21], both variables and patterns can be untyped, syntactically typed, or semantically typed. The case of the un-typed variable or pattern is obvious; no constraints are imposed on the variable. The syntactic typing variable is connected to a meta-model element whose instances it can hold. The strongest properties can be asserted using semantic typing. In the paper [21], the difference between syntactic typing and semantic typing is given. The syntactic type of a variable could be “expression,” whereas its semantic type could be “expression evaluating to an integer value.” As it is latter stated, the semantic typing is not available in the current model transformation languages, but is supported in some meta-programming languages such as MetaML and MetaOcaml [344] [345].

Logic expresses computations and constraints on model elements in form of nonexecutable or executable statements, where executable statements might be declarative or imperative.

The declarative term is related to a group of relational or functional languages. A task specification in a declarative language is a description of expected results by stating relationships between variables in terms of functions, in functional languages, or between variables in inference rules, in logic programming languages. Some fixed algorithm is applied to these stated relationships and it generates a result, i.e. values of variables are set to fulfil constraints stated in the relations. Most common of declarative programming languages, for logic programming group are languages such as Prolog, and in case of functional languages, Haskel, LISP.

As opposite to declarative paradigm, imperative languages, or enriched by concept of modularity and scope of program code, a procedural languages, are description kind in which the task is specified by explicit sequences of steps, during which manipulation of the state of the computer system is made, to follow in order to produce a result [26].

Non-executable logic is used to specify relations between models. Executable imperative logic often has a form of an imperative language that manipulates elements of the model that uses repository’s API. Examples of the executable imperative logic are the Rose Extensibility Interface (REI), i.e. interface to Rational Rose, or Java

Metadata Interface (JMI) [74], i.e. java interface to manipulate directly in a Meta-

Object Facility (MOF) [51] type repository. Other example is proposition of OCL actions, introduced by Jezequel et al. in paper [32], i.e. an imperative extension to the

OCL language. Executable declarative logic is found when selection of elements of a source model is specified, for instance, by OCL-Queries [54], or implicit creation of elements of destination model using declarative constraints is made [34].

Selection of elements in a source model is often described as the matching process.

The match occurs during the application of a transformation when elements from the left-hand and/or right-hand model are selected because they meet the constraints specified by the declaration of a rule. After the selection is made, the action connected

50

with this matching is preformed and it is creation, update operations or invocation of other transformations.

LHS/RHS Syntactic Separation states whether RHS and LHS are syntactically separated. In other words, the rule syntax may distinguish between RHS and LHS as such or there might be no syntactic distinction, as it is in a transformation rule implemented as a Java program.

Bi-directionality specifies if rule may be executable in both directions.

Transformation rules may have additional control parameters allowing configuration and tuning, and this is related to parameterization of the transformation rules. In addition, in case of some approaches, for instance GreAT [1] or VIATRA

[82], the intermediate structures are utilized in order to perform transformation, mainly if transformation is performed within a same model [21].

Figure 25 - Features of Transformation Rules [21]

4.3.3.2 Rule Application Scoping

Let us now return to the top-level of the feature tree Figure 24, further categories are presented.

Rule Application Scoping constraints part of the model that may participate in transformation. Two scopes are possible : source and target, which might be narrowed in some tools, e.g. GreAT [1] to particular parts of the model.

Source-Target Relationship, Figure 24, regulates whether the target model will be new target or existing target. New target is created in case of a creation transformation, which incorporate creating only new elements because of the transformation. Existing target can be updated in destructive or extension only way or transformed in-place, which means that a modification transformation includes alternation of an already existing model, or set of models, using the addition, modification and removal of elements. The latter one may be used in cases of non-deterministic and fix-point iteration scheduling approaches in order to ensure termination of the transformation process [82]

Rules selection and application requires rule application strategy Figure 24. This is especially whether transformation’s scopes are overlapped, i.e. rules are applied to source-model’s scopes that overlap, and selection decision has to be made. There are three possible strategies, i.e. deterministic, interactive, and non-deterministic, in form

51

of concurrent or one-point selection. Example of deterministic strategy might be one of standard traversal method, like breath-first strategy. The interactive selection takes place when user is asked for pointing particular transformation rules to execution. The non-deterministic approach is made by non-deterministically pointing of location, in one-point selection, or if transformation rules are executed concurrently.

Results of transformation are placed in a target model in deterministic manner; different case is with an update transformation, where a source and target model is the same models.

4.3.3.3 Rule scheduling

The order in which rules are scheduling is determined by scheduling mechanisms ,

Figure 24. This mechanism is varied by four aspects, aspect of form, rule selection, rule iteration and phasing Figure 26.

Figure 26 - Features of rule scheduling [21]

Firstly, one should focus on the form of expression of rules scheduling. The rules expression can be made in implicitly, i.e. user does not have explicit control on transformation and scheduling is made by internal mechanism of transformation tool.

In order to make some influence on scheduling algorithm a proper design of transformation rules to force demanded order of transformation rule execution.

As opposite to the implicit, an explicit rules scheduling is realized in external way, with a clear separation between the rules and the scheduling logic, or internal, with a mechanism allowing a transformation rule to invoke directly other rules, manner where dedicated mechanism are developed in to control the execution order.

Other issue is to establish a mechanism of rule selection. Rules can be selected by an explicit condition, in non-deterministic way, in situation of ambiguous; a conflict resolution mechanism is utilized. Some tools provide rule interactive selection.

Last two issues are related to way in which rules can be repeated, and phasing in transformation process.

There are three kinds of rule iterations approaches, which include recursion, looping, fix-point iteration, i.e. repeating an application until no changes detected.

In addition, phasing separates transformation process into several phases. Each phase has a specific purpose and is related to certain group of rules that may be invoked by particular group, also having forbidden execution rules outside the group.

52

4.3.3.4 Rule organization

The next important main characteristic of model transformatio n is a manner in which rule are organized, i.e. issues related with composing and structuring multiple transformation rules.

The transformation approaches provides modularity mechanisms, i.e. mechanisms that allow packaging rules into modules. The modules’ content might be accessed after they are imported.

Composing mechanisms are realized using reuse mechanism. The reuse mechanisms offer a way to define a rule based on one or more other rules. Two types of reuse are utilized, inheritance and logical compos ition. Inheritance is an application of one or more generally transformations to newly created transformation by passing and extending some of theirs characteristics. Logical composition, which is a creation of new transformation by composing defined transformations, gives characteristics of a new transformation that is juxtaposition of characteristics of a composed transformation.

The organizational structure describes manner in which rules are organised in structure. The organisation might be done in accordance to the structure of a source language or a target language. The last possibility is to use own independent organization.

Defining the transformation is an easier task to do if it is compounded by simpler transformations, instead of creation one complex transformation. This kind of solution uses ideas of procedural programming paradigm, which is division of programming implementation to parts, i.e. modules, and further to subprograms.

The example transformation organisation is made by organising in transformation rules. This technique made possible defines a complex transformation using simpler transformations as distinct rule s. A complex transformation defines the required ordering of rules application, but also ordering of basic transformation operations, i.e. these one used in transformation rules.

Transformation rules are responsible for transforming a particular selection of a source model to corresponding target model elements. Each transformation rules shall be responsible for particular well specified a transformation’s concept.

The rules may contain pure declarative parts, which make them pure declarative rules. They may contain only imperative parts, which make them pure imperative rules. Finally, a hybrid combination is possible, in case when both declarative and imperative parts are present in transformation rules.

This twofold separation of transformation specifications is found very useful, since it promotes scalability and reuse. It makes a simpler rule specification language, due to the separation of concerns. To these organization aspects, iteration and conditional branching mechanisms are added, in order to steer the transformation process.

Moreover, the rules may be used as regular functions, and results of theirs execution may state for inputs of another rules. Obviously, a rule -ordering schema also refers to other as well as to complex transformation as to transformation rules, which brings a possibility to have a composition hierarchy.

4.3.3.5 Tracing

During the transformation, process between elements of a source and a target model might be stored. These links could be used in analysis of changes’ impact, to synchronize changes in source or target models. Further, it may be utilized in modelbased debugging, and in determining the target of a transformation.

The way the tracing is realized depends upon the tools. In some cases, the tracing mechanism is provided by tools itself, in other situation the tracing mechanism has to be incorporate manually, for instance by stating that links between models element has to set. Even if the tool provides traceability support, it sometimes requires making

53

proper link creation manually , or in case of more automatically solutions, configuration of the mechanism is made.

The links might be stored as well as in the source model, the target model or separately.

4.3.3.6 Directionality

A transformation has two type of direction unidirectional or bidirectional.

The one-way transformation’s execution is a unidirectional transformation. The unidirectional is in case a target model is computed or updated. It bases on a source model.

A bidirectional transformation might be performed in two directions i.e. bidirectional rules, and complementary pairs, and it can be achieved using bidirectional rules or by defining two separate complementary, a pair unidirectional rules, one for each direction.

A transformation in most cases is designed to have functional character, at the input, a source model is given and a target model, result, is generated. A problem arises when from the same output different inputs may be deduced, i.e. transformation is not a one-to-one function. In case, when the inverse of transformation is not a function, a number of possible solutions could be generated. Propose solution is to establish part of the result in a concrete way, which is common for all possible transformations, or use extra information, e.g. traceability, that is written during a transformation process. It is important to notice that the invertibility of a transformation is not only related to invertibility of transformation elements, but also to way, these parts were executed, i.e. scheduling method [21].

In next part of review of transformation approaches is made. The basic kinds of transformation solutions are described and main representatives are listed.

4.3.4 Review of Transformation’s Approaches

In order to perform the transformation, the transformation tactic is necessary. The transformation has several approaches. In the paper [21], author presents some main categories. The top-level classif ication divides the transformation in two: model-tocode and model-to-model transformation. The model-to-code transformation covers all transformation in which an implementation of the system, in form of a source code is generated. A model-to-model transformation is all this kind of transformations that from a source model a generated target model that is one of the intermediate models of the system.

However, the model-to-code might be seen as special subcategory of model-tomodel approach, in case when one considers the model-to-code transformation as transformation to meta-model of specific programming language. Nonetheless, as it was mentioned above, because of practical aspects this distinction is sustained.

This part focus presents two main transformation approaches categories, i.e. model-to-code and a model-to-model transformation. Each of these categories is presented in more details using mainly works [69] [21]. This presentation is enriched by short presentation of transformation tools that user particular concepts.

4.3.4.1 Model – to – code

The model-to-code approach is better know and an easier to solve problem of model transformation. It is a popular solution and many tools can generate some code from models. It is easier task than model-to-model transformation, since usually an abstraction levels of a transformed model and a source code are relatively close to each other, i.e. in terms of the MDA; it is platform-specific model to code transformation.

Nevertheless, that process usually goes no further than the generation of some template code, where most of the work still has to be filled in by hand. It is made in most cases

54

by black-box transformation modules, which has encoded inside transformation process [34, c. 3.3.1].

A bit different situation for a model-to-code transformation whether concepts used in model definition and concepts of language that express the code of the system are at very different level of abstraction. A platform-independent model to code transformation is more complex that PSM to code, however it is also offered by subgroup of the tools, in form of black-box modules, which transforms the high-level concepts of source models’ elements to the code-level form.

These conversions are made of course with some limitation, indeed the result of a transformation is very often a delineation of structure of transformed system in the code, leaving a burden of implementation of behavioural aspects for software developers.

Nevertheless, the task of preparation of structural aspect transformation of models is no an easy one, since expression of high-level concepts in terms of low-level code it is no straight forward. It requires taking into accounts many characteristics of an implementation platform, which might be conflicted with transformed concepts that are different for different implementation platform.

The issues of structural aspect of transformation of models are valid for transformation of behavioural aspects. In addition, another issue is how to express fully a behavioural aspect of a system in a platform-independent model.

In model-to-code approach to transformation class are differentia te, visitor-based approaches and template-based approaches. In next two subchapters, they are described in more details.

4.3.4.1.1 Visitor-based

The tactic in visitor-based approach depends on providing some visitor mechanism, which is able to traverse through model and generate the text stream of code. The visitor-based approach requires each model element, which is going to be transferred, to be visit-able. The implementation template for the visitor-based approach is essentially a visitor to a source model. To make the visitation working the visit methods have to be filled out with the specification of source code generation.

Each visit is related with details that are deduced from the nature of the particular constraints linked with the model element being visited. According to these details, proper actions of the source code generation are made.

A visitor-based example approach is Jamda tool [30], which is an object-oriented framework. The models are expressed in the UML; thereby it provides a set of classes to represent UML models. To make model manipulation and code generation possible an API for manipulating models and a visitor mechanism, called CodeWriters, to generate code is provided[21].

4.3.4.1.2 Template-based

Another approach presented in the article [21], i.e. template-based, also related as archetype-based approach [25]. It generates target code, use meta-code to access information from the source.

A template is a sequence of the text that represents in partial the result of transformation, i.e. source code text in many variations to use. In addition, this text is enriched by splices of the meta-code that access information from the source model.

The meta-code specification is made to control of source code text’s variation selection and iterative expansion, with respect to information taken from the source model. If one wanted to view it in terms of LHS and RHS parts of transformation, one can notice that LHS uses executable logic, i.e. meta-code specification, to access the source model’s elements. In addition, combination of un-typed, string patterns, i.e. source code variations, with the executable logic is made in RHS part of transformation. Further, the LHS and RHS part of transformation are syntactically

55

inseparable. The scheduling of the transformation rules execution in the template approaches usually has internal form of calling one within another template.

The LHS part of transformation might be made at different ways. The logic accessing a source model could be simple accessed via API that is provided for internal representation of a source model, for instance using Java language and JMI

[74] repository. Other approach is to access the source model by declarative queries for instance expressed in OCL [85], language of constraints used mostly together with

UML, XPath [87], i.e. query language for addressing parts of XML document [43], etc.

In the case of more complex source access logic, or in other words, in more complicated queries, e.g. queries that gathers information necessary to perform transformation from different part places of the source model, it is moved from templates into operations of a source-model’s elements. This solution is used in template–based tool b+m Generator Framework [8].

The template-based approach seems to be closer to generated code that a visitorbased transformation, since it is defined in terms of source code patterns.

The templates in template-based approach have the characteristic that since they operate on text, the patterns that are defined within them are un-typed, thus cannot be checked against syntactical or semantic correctness; thereby syntactically and semantically incorrect fragments of code may occur. Nevertheless, this characteristic has also a positive aspect. As templates are not checked against syntactic or semantic correctness, they may be used to generation of any textual artefacts.

A related technology is frame processing, which extends templates with adaptation that is more sophisticated and structuring mechanisms , e.g. Bassett’s frames [9]. This technology is also used to generate source code from system models [21].

4.3.4.2 Model-to-model

Model-to-model category considers the kind of transformations that inputs and outputs are models, which not necessary have to have form of code. This distinction does not rise up from that code and model differs very much in sense of general concept. Indeed, there are quite similar to each other, since they are an instance of particular languages, meta-models. However, in most cases model-to-code transformation means in fact forward refinement transformation, or transformation where main role plays forward refinement, thus the techniques used in these approaches are designed better for that kind of transformations, e.g., visitor-based, template-based approach etc.

A model-to-model transformation is often a transformation in which the horizontal factor plays crucial roles, for instance, a re-factoring transformation, some aspectdriven transformation, etc. To cope with these requirements different approaches must be used, and this part of the work treats about that.

The specification of models’ syntax and the relationships between model elements is made by metamodelling. The metamodelling, in fact, is a process of language modelling using concepts, terms and elements of meta-meta-model, a.k.a. metalanguage, e.g. MOF [51]. The UML [55] is an example of such modelling language, which is specified in terms of meta-model concepts, in particular within MOF approach.

The authors of article [69] underlines that practice has shown that visual modelling languages have a number of advantages in that tool’s implementation base upon the meta-model of the language, which is another reason of taking into consideration in particular model-to-model transformation, and modelling as general.

Transformation approaches perform translations between a source and target models that do not have to be described within the same meta-models. In fact, they are often cross-language transformation, i.e. using several different meta-models, for instance in case of aspect, multi-model transformation.

56

The transformation process is taking one or more input models, and generating one or more output models. To perform this process correctly, a clear understanding of syntax and semantics of all models used in transformation process are required. It is obvious that the approaches that perform model-to-model transformation are syntactic aware, which is in opposite to template – based approaches. Thus, they support syntactic verification of variables and patterns used in transformation [21].

A model-to-model transformation is distinguished in several categories; most raw, i.e. direct-manipulation approaches, relational approaches and graph-transformationbased approaches that to transformation’s specification use domain specific languages, i.e. transformation languages. Next transformation classes are structure-driven approaches, which add structure capabilities to transformation process, hybrid approaches of the enlisted approaches, and finally approaches that are not put into any category enumerated above.

4.3.4.2.1 Direct manipulation

The idea of the approach is to implement transformation directly in modelling tool.

This kind of solutions is defined as tool dependent implementation, or as manipulation front-end, application program interface (API) – dependent. A particular transformation solution might cooperate only with different version of the same tool, and attempts of moving a transformation solution from one to another tool might be related with translation of tool’s API to another API, which is not often possible.

The direct manipulation is a class of most low-level approaches. It offers little or no support or guidance in implementing a transformation. The accession and manipulation of the model representation is made by a set of class and methods, i.e.

API, which makes available accessing to and manipulation of an internal model representation. The direct manipulation front-end might deliver a set of methods that are able to operate on data structures representing the domain specific models. The way these data structure are organized, the way objects and relationship are permissible, etc. are the manner of a tool is internal meta-model.

In these approaches, the API is mostly implemented as an object-oriented framework, and sometimes to the framework, some basic infrastructure that organizes a transformation, for instance, in form of abstract classes to represent transformation, is added.

Nevertheless, completely burden of transformation implementation, e.g. implementation of transformation rules, seeking of models’ elements required for transformation rules invocation, transformation rules organization, scheduling of these rules, etc. are dropped on shoulder of user who is implementing a particular transformation. All work has to be done by the user. The transformation are encoded directly in a procedural language using set of procedures contained in API to access to model repository offered by tool. In general, transformation structure, in fact must be built form scratch using a programming language such, as Java, C++, etc. In the end, this approach will become impractical [21].

Examples of tool offering direct-manipulation is Jamda [30], Rational Rose [63],

Rational XDE [64], MagicDraw UML [44], Telelogic Tau G2 [80] or transformation might be made by directly manipulation on API provided by repository tools, such as

MOF [51] repository MDR [37] that adapts JMI [74]. The approach is offered by vendors of almost all modelling tools. Rational Rose [63] offers a version of

VisualBasic with a set of APIs to manipulate models. Rational XDE [64] exposes an extensive set of APIs to its model server that can be used from Java, VB or C#.

MagicDraw UML [44] gives to user an API, which is set of Java classes, in which concepts of the UML [55] are mapped to the tool’s API specification, in form of set of classes that corresponds meta-classes of the UML meta-model, etc.

The general mechanism of direct-manipulation approaches is presented on Figure

27. A particular transformation solution, in form of script, e.g. in case of Rational Rose

57

[63], Java application if Rose Extension Interface (REI) is used, or plug-in in

MagicDraw UML [44] open an access to the tool repository and manipulates the repository in which model is storied using the provided API.

During this manipulation process, an original model that is stored in a model repository is altered in a way it is required by the transformation solutions. The manner the changes are programmed in a transformation solution depends from the kind of the repository’s API. Two basic kinds of API’s are distinguished [79].

In first, APIs are set of large number of functions that are specific for particular type of element of models. On the other hand, an API might be created using a small set of powerful functions, which does not operate on particular concepts of modelling language, as it was made previous. They access model e lements on a meta-model level i.e., by creating, deleting particular instances of meta-classes, changing links between instances of meta-classes, and modifying particular values of meta-attributes.

Thereby the direct-manipulation solutions might be divided between two classes, language-specific , and language-independent solutions. The further difference might be illustrated on examples of tools offering direct-model manipulation.

Figure 27 - Schema of direct manipulation model transformation approach [79]

The representative of group of meta-model driven tools is Telelogic Tau G2 [80].

The structure of its repository bases on the tool’s vendor meta-model, which is publicly available. The interface to the model repository is available via COM mechanism and it provides a set containing a small number of basic primitives, interfaces, which allow manipulating model in the repository. It is because, this few number of primitives is enough to represents all concepts in the meta-model and operations on them that are required to change model in a way intended by a certain transformation solution.

The other group of tools creates all tools that assume that functions and structures in the API are representative of concepts in particular modelling language. For instance in case of UML [44], the functions and structures in the API, represents particular elements of modelling language, like classes, attributes, etc. In this kind of attitude, the basic the focus is on particular access methods and attributes for specific structures that represents concepts of particular modelling language, and what is more, it does not allow modifying a modelling language itself, as it is theoretically possible in the case of the group of meta-model driven tools. Examples of such tools are

Rational Rose [63] and MagicDraw UML [44].

58

The direct-manipulation approaches, even they are most low-level approaches among transformation attitudes presented here, has important advantages.

Firstly, the direct manipulation approach has this advantages that to specify the transformation either a common language like Java or variations of a common languages are used. Thus, from that point of view developers do not need to spend any extra, or maybe only little time on training to become able to implement this type of solutions. As it is underlined in article [69], the developers are also more comfortable with using to transformation specification algorithms that are encoded in procedural languages.

An unavoidable disadvantage of using this approach is that the API usually restricts the kind of transformations that can be performed. The reason is that information required for model manipulation might be not achievable by the API [70].

Another important issue is related to language in which transformation are specified in case of the direct-manipulation solutions. The used programming languages are “general-purpose”, hence it lacks of high-level abstractions , like models’ elements matching mechanism, which are helpful for specifying a transformation. In addition, quoting arguments from paper [70], because of that, transformation expressed in general purpose languages can be time-consuming and difficult to understand and maintain due to a lack of high-level abstractions.

One of the proposals to overcome the issues is a language that promises to raise the level of abstraction of operations on model, in particular on UML. This language is action language [55], and is a proposition for transformation definitions, since it is a special-purpose language for UML models edition, made in a procedurally way [78].

Nevertheless, two main disadvantages are of this approach. Firstly , because of its

“general-purpose” character, the action language still lacks of high-level abstraction for coping with transformation problem [70]. Secondly, it is language-depended solution, i.e. UML solutions, and transformation that shall be made across different languages might be impossible to implement using the action language.

To sum up, the direct-model manipula tio n seems not be a direction on the transformation approaches map that will become a primary solution type for building transformation system development, since it force user to operate on very low-level of transformation specification. This might be compared with assembly languages that were almost totally displaced by third generation languages as C, C++, Java, etc.

Nevertheless, as it is in case of assembly languages, it always occurs a necessity of developing a transformation solution or at least part of a transformation using the direct-model manipulation technique, for instance because of performance problems.

4.3.4.2.2 Relational approaches

The main disadvantage of the previous approach is that to low-level description of transformation has to be provided in specification. In order to cope with this problem the solution that do not force a transformation developer to specify every piece of transformation at a low-level must be provided. This kind of solutions has to deliver abstraction and specialization concepts Figure 28 that make transformation developer free from thinking about particular implementation problems of transformation specifications, and focus his attention on preparation of the transformation problem description itself. It means that the developer, focus on a way one is going to specify transformation within the concepts of the transformation language. It means also that the developer leaves most of implementation details to background of translation process, which automatically translates the all concepts used in the specification to a transformation implementation.

This kind of solutions is known as domain-specific languages [20], [19, p.44]. The domain-specific languages, also referred to as “surface languages”, are languages specialized for direct and declarative expression of a system, in particular domain, specification’s description. These languages always base on concepts in modelled

59

domain, for instance, the transformation-domain languages focus on concepts adequate for models inspection, and manipulation.

Providing domain-languages at least two aspects of the language, as in case of all languages, shall be considered, i.e. specialization and abstraction level of the language

Figure 28. Following the explanation in the work [19, p.224], the level of the language’s abstraction in fact means the effort of work done by language behalf the language’s user. Obviously, more difference between abstraction’s levels of the modelled concepts and the target implementation causes more translation problems.

Firstly, as it does work in transformation developer’s behalf, it also makes implementation decisions in one’s behalf. In other words, the developer not always has enough expressive power to steer all aspects of an implementation result. Secondly, higher abstraction is also a problem of efficiency, expansion of an implementation code. In case of abstraction, as it is in almost all situations, it is important to find a compromise between afford that the user want to spend and level of control over implementation’s generation process.

The other characteristic of the languages is a language’s specialization level. The domain-specific languages are at high specialization level, which has some advantages

[19, p.223].

Figure 28 - Classification of languages with respect to them specialization and abstraction level [19]

Firstly, it gives to user a possibility of declarative description of problem, whic h is an ability of problem specification in form of problem description rather than developing the particular algorithm solving it. The domain-specific languages can provide also they own notification; for instance, languages for mathematics domain can use in their notations symbols of integrals, matrixes, etc., or in transformation approaches, one can create special notation that symbols represent relation between elements, and so long.

Using in languages concepts and notation very familiar to modelled domain makes the specific ation simpler to analyzing and reasoning, since intentions of developer are almost directly expressed within the language. The user does not have to recreate intentions that are hidden beneath particular language construction, as it is in case of general purpose languages.

As the domain-languages are narrowed to particular domain, it can provide better mechanism of specification checking and optimizations. Narrowing language to particular domain brings more information about characteristics of models specified in that language, which might be used for improving the checking and optimizations mechanisms.

60

Thus, the future of transformation approaches is directed to the solutions that give to users the ability of a transformation’s specification using the languages that have characteristics previously enlisted.

The class of relational approaches is an example of such domain-specific approach. It develops concepts for transformation domain. The relational approaches use the mathematical relation, as a main concept, to tie the elements of model and to create specification of transformation’s rules. The representatives of this group of approaches, for instance are, [3], [62], [17], [27], [4].

In the relational approaches, basic idea is to narrow the elements of relation, i.e. source and target element types, and secondly make further elements specification by putting constraints on the elements.

A relation might be a set of elements R Figure 29, which constraints elements that are a pair of two objects like a, and b, which map to each other. These objects are taken from other sets, which are named as domain and range of the relation. These sets are also known as languages of an input and an output mode l. The additional matching condition, i.e. the constraints, can be specified. The additional matching expression is a relation specific, and in order to make the relation valid, all elements of the relation have to fulfil this requirement. On figure Figure 29, it is shown in mathematics way.

R

=

{(

x

,

y

)

X

×

Y x

domain

y

range

condition

}

Figure 29 - Definition of relation in the relational approaches

The relational approach might be also expressed in Object-Oriented manner [2].

The pair is given as an object that tights two other objects, from domain and range set,

X and Y. On the Figure 30, the object XY is a representation of the relation that tights X

and Y objects.

Figure 30 - A pair XY of objects X and Y [3]

The relation itself is expressed in form of classes XRelY and constraints, as it is shown in Figure 31 and Figure 32.

Figure 31 - Relation in Object Oriented Modelling context [3]

context XrelY inv: elements->forAll( e | condition(e))

Figure 32 - Constraints on a relation, matching condition

61

The relational approach in the OO modelling context substitute the additional constraints on elements of the relation by stating pattern of classes, which describes the model instance that should be mapped, i.e. placed in the relation Figure 32.

The second part that has to be enclosed in the relation’s specification is information about domain and range types, or classes, of relation’s participants. The domain and range types might be sets of all possible instances, which are created within specified set of domain and range. Nevertheless, it is not always the case.

Sometimes, the scope of instances generated from the domain and range sets are narrowed by further restriction. It is a result of a hierarchical structure of relation.

As the relations rather not often have form of a simply transformation, mechanism, which allows combining them, is required. The authors of [2] and [3] extend the OO modelling by hierarchical definition of a relation, where each component of a hierarchical structure defines a sub-relation. The sub-relation defines its own domain and range sets. The domain and range sets of a parent relation are sum of all domains and ranges of all contained relations. The hierarchical structure of relations increase its ability to being reuse and recursively nested.

The main idea of hierarchical relations is to associate another relation. On Figure

33 there is an example of simply hierarchical structure of container relation and associated to it sub-rela tion.

The example presents a specification of a relation between two containers of X and

Y, containing respectively objects x and y. The relation between contents of

XContainer and YContainer has to be stated, and this is made in by modelling a

relation between

X’s and Y’s, XRelY, which is associated with the

XContainerYContainer. To the relation XContainerYContainer additional constraints

might be added.

Figure 33 - Example of hierarchical relation [2]

This pattern of hierarchical relation might be repeated further whether one needs to create more relations that are complex.

The specification of relation might be visualized using graphical representation, as icons presented on Figure 34. There might be many forms of relation graphical representation. For instance, on the picture the relation is represented in form class with a <<relation>> stereotype.

62

X

<<relation>>

R

Y

Figure 34 - Graphical icon and class with a <<relation>> stereotype to represent relation pattern of classes [2]

The example that illustrates a use of relation approach is taken from [2]. In the paper, the example transformation between UML [55] and BPEL Figure 35 is presented. The Business Process Execution Language for Web Services bases on an

XML. Using the BPEL one can implement a business process on web services. One of the reasons why the transformation shall be prepared is that the BPEL does not provide graphical syntax and it is better, first to define a process in a graphical notation, e.g.

UML, and maps it to BPEL.

Figure 35 - Segment of a metamodel for the BPEL language

The transformation between UML and BPEL is described in [35], and it a base for example transformation presented below Figure 36, and OCL expressions that define domain, range, and matching conditions Figure 37.

Figure 36 - Example transformations between UML and BPEL [2]

63

As it can be seen on Figure 37, three main part of transformation represents

ClsRelProc transformation, and two sub-transformations AttRelVar and GrphRe lAct,

which are responsible for

Attribute-Variable and ActivityGraph-Activity

transformation. The domains and ranges of sub-transformations are defined in

ClsRelProc. The particular matching conditions are stated separately for AttRelVar and

GrphRelAct transformations.

Moreover, as relations maps one model into another, the changes made at either side are used for updating model. As particular domains and ranges are specified for sub-transformations, changes that occurs in one of the domain or range sets, indicate which of sub-transformations can be used to make proper update, or model checking.

There is no a necessity to use completely transformation specification to update changes, or check models against the transformation.

context ClsRelProc

AttRelVar.domain : class.feature->select( f | f.oclIsKindOf(Attribute) )

AttRelVar.range : proc.variable

GrphRelAct.domain : class.behaviour->select( b | b.oclIsKindOf(ActivityGraph)

)

GrphRelAct.range : proc.activity

context AttRelVar

condition : attribute.name = variable.name and attribute.type.name = variable.type.name

context GrphRelAct

condition : true

Figure 37 - OCL definition of relations specified in Figure 36

In most cases, the relation approach has non-executable form and it are used as formal description of a transformation, e.g. [3], relations specification in approach presented in [62], which distinguishes between bi-directional non-executable specification of relations and unidirectional transformations that implement these relations and transformation rules in [4].

The attempts of relation transformation implementation, making it executable, might be made using a logic programming languages. It is because, the logic programming paradigm is close to way a transformation in relation approach, is specified. The constraints that are given in a declarative way are easily expressed within terms of logic programming languages. As author of [21] underline, the logic programming its mechanism, i.e. unification-based matching, search, and backtracking is a natural choice for making the relation specification executable. The attempts have been already made, for instance, in [27], where Gerber et al. consider using some of particular logic programming, like Mercury, which a typed dialect of Prolog, or Flogic an object-oriented logic language. Other attempt was in QVT proposal [17], were transformation approach, itself base on F-logic paradigm.

Other approach that is proposed for specification of relation is Object Constraints

Language (OCL) [85], which is used as constraints language in UML’s models. The idea is to use it as language for matching constraints specification, in a declaratively manner. The attempts were made in papers, [32] and by Kleppe et al. in the book [34].

In the book of the Kleppe et al., OCL expressions are made for matching condition, input and output elements specification. Obviously, as the OCL specification are declarative, the relation specified in OCL, might be treated as a bi-directional transformation.

64

The relational approaches characterize that there are free of side effect. Further, in opposite to imperative specification in the direct manipulation approaches, see Direct manipulation, content of target model is created implicitly, as in approaches [27], [17].

In some approaches, which base on logic programming, the direction for an executable transformation is fixed, even though it is possible to interpret relation specifications as bi-directional, see [3], relations in [62], and transformation’s rules in

[4], as it is made in [17], [62].

Finally, relational approaches, which are implemented within approaches basing on logic programming, are strict about separation between a source and target model, and in consequence, they forbid in-place update.

Following the opinion presented in the article [21], it seems that relational approaches are well-balanced solutions between flexibility and declarative expression; moreover, they provide flexible scheduling and good control of non-determinism.

4.3.4.2.3 Graph-transformation-based approaches

Another example of approach that uses domain-specific language is the graphtransformation-based approach, which has a strong base in theoretical work on a graph transformation. In more details, the approach use typed, attributed, and labelled graphs, modified to represent models in particular modelling language, e.g. UML.

In the papers [21], [68], [70], examples of approaches including ATOM [7], BOTL

[16], GreAT [1], PROgrammed Graph REplacement System (PROGRES) [67],

UMLX [65] or VIATRA [82] are mentioned as graphical-transformation-based approaches.

A transformation defined with a graph-based approach assemble two parts LHS graph pattern, and RHS graph pattern. The graph patterns are specified using the concrete syntax of a source or a target language, as this is made in VIATRA, or specification can be made within syntax of abstract modelling language, on abstract level equals to MOF language , which is made in BOTL approach.

Using concrete syntax has the advantage that it utilizes concepts from languages, which, as it is underline in the paper [21], this is important since developers are more familiar with a concrete syntax. Moreover, a specification of transformations made with a concrete syntax is more concise than a specification made in abstract transformation language, especially when a transformation is made for complex language as UML. However, the abstract syntax allows for a transformation solution preparation that is appropriate for transformed models that are expressed in any language, which are specified in particular meta-meta-model, for instance MOF [51].

The graph transformation is a process of graph rewriting in accordance to rules, i.e. transformation rules. The rules in graph-rewriting process are used for sub-graph selection, which in next step is replaced in accordance to the rules.

A transformation rule consists of a matching schema, LHS, a graph to match, and a result schema, RHS, a replacement graph. To the RHS part of transformation, some additional functionality, in string, numeric domains , etc. is required to compute values, like names, elements quantity, etc. of target graph attributes. Example of extended

RHS specification model is GreAT [1]. The transformation rule contains condit ions in addition, which specify whether rule can be fire or not.

The rule is executed whether a match for the matching graph is localised and the sub-graphs is replaced by graph defined in RHS.

In the article [5], the problem of rule scheduling is discussed. It is said that during graph transformation process, non-determinism might occur in situation, when one of the applicable transformation rules has to be chosen. What is more, the occurrence may be located in several places of the graph, thus a result of a transformation depends on these choices is arbitrary. This problem is solved adding control condition in several manners. The order on transformation rules application might be prescribed.

65

Other solutions are to determine a successor rules in dependence on one already executed, or the transformation rules prioritisation might be applied.

For instance, in the VMT approach [70], the rule -ordering schema formulates a graph transformation as a sequence of a simple transformation. The rule -ordering schema has a form of an attributed labelled graph with directed edges. In more details, the rule -ordering schema is a graph, in which each vertex, connected with edge, represents a single transformation rule. A single transformation rule cannot change a flow of transformation execution, thus the applicatio n of such rule always terminate and selection, which is made according to explicit condition, of the next transformation rule cannot be ambiguous.

In most approaches, like in PROGRES [67], the scheduling mechanisms is added in external form, for instance in form of imperative language describing a sequence of the rules execution, i.e. explicit conditions and iterations, e.g. fix-point iterations, or scheduling may include non-deterministic selection [21].

Enlisted concepts, in particular, a labelled graph, a sub-graph, transformation rule, matching schema, are very important for graph-based transformation approaches, thus now they are described in more details.

The basic concepts is a labelled graph, which is defined as triple G=(V,E,l), where

V is a finite set of vertices, E a finite set of edges, i.e. 2-elements subsets of V, denoted

by E belongs to [V]^2. Additionally, edges are labelled by symbols that are in l set. A graph is called a sub-graph whether is a subset of graph-set, for instance, a K is a subgraph of G if K belongs to G, what means indeed that elements of triple (V,E,l) of one graph have to be subsets of respective elements of triple of the other graph. Obviously, it shall be added that elements of E and l shall be selected with respect to V set, which is restricted in the other graph.

The occurrence of graph K in graph G has place when there is a transformation t, which maps vertices, and edges, preserving labelling of the graph K onto graph G respectively.

A graph transformation is constructed by transformation rules, which are applied to a graph in some stated order. Each transformation rule, specify a graph pattern, which is used for occurrences detection in one graph, and the set of elements that modify, i.e. element might be removed, added, or both, previously selected graph. A transformation rule is defined as a four r=(M,R,A,c); where M=(N,E,l) is a special graph, called the matching schema, R=(NR,ER,lR), with restriction NR is part of N and

ER is part of E, and A=(NA,RA,lA) groups elements of graphs, which are respectively

removed or added to the graph occurrence. Last in the four, a c condition specification, describes circumstances under with the transformation rule is fired. A whole process of transformation rule , r=(M,R,A,c) application has four steps. The graph G is transformed to graph H in the following steps:

An occurrence of the matching schema M in G is chosen.

The condition c is verified.

Remove the elements of R from G, and all the edges which are incident to removed vertices

Add all elements of A to G, and all the nodes related to an added edge are added.

Following the paper [70], the condition c in most cases has an isomorphic character, since its scope is narrowed to processed elements, i.e. it is a bijective transformation between source and target models. Nevertheless, the condition c might have a global character, thereby it might be used for, e.g. an aspect-driven transformation, see Kinds of transformations subchapter.

In the article [70], authors understand that at the meta-model level, notion of attributes is important. That is why, graph-based solutions shall base on attributed labelled graph, which is proposed in the book [66]. The attributed labelled graph solutions is a graph with attributed nodes and edges, which formally is a

66

transformation that map vertices and edges to set of possible values for attributed vertices and edges.

The attributes has to introduce, obviously , changes in notions in occurrence, transformation rule , and graph derivation. The biggest issues are in the case of the definition of the occurrence. After introduction of the attributes, it has also included the transformations of attributes associated to edges and vertices.

The application of the rule r is made, it is called a direct derivation and is denoted, in case of derivation graph H from G, G =>r H, or in simpler form G => H. A set of rules P might be used to successive direct derivations G0 => G1 => G2 => … =>

Gn, which is a derivation from G0 => Gn by rules of P. There is several possib ility of

matching schema occurrence or different sequence of rules execution or there are many transformation rules, thus a set of derived graphs from particular rules has infinite number of elements.

To describe the set, the graph grammar is made. It is made from three sets, S-set of initial graph, from which graphs are derived, P-set of transformation rules, and set T of all graphs labelled with terminal symbols , which are derived from initial graph S. The set of all possible graphs generated using the graph grammar is denoted by L(S,T,P)

[70].

Summing up, the graph-transformation approaches, similarly to relational approaches, are able to process a model transformation in a declarative manner. The differences is ma inly in the set of mechanisms used in this approach, such as graph patterns, or graph matching, which makes them different from the relational approach.

Obviously, the graph transformation approach, and relational approaches too, are not always capable for all transformation tasks. The author of [70], mention that for some complex algorithms required by a model transformation, it is better to implement it in a procedural language, for instance Java, C++, C# etc. That is why, the authors of

[70], propose integration of such approaches with general-purpose programming languages.

Further, graph-transformation approaches base on advanced theoretical work in field of graphs. These approaches combine a powerful semantic and declarative syntactic, but on the other hand they are most complex one. The biggest complexity is found in field of transformation rules scheduling, where non-determinism in rule application might be used, and the rule application confluence might be hard to control.

The graph-transformation approach seems to have a very big potential, however experience with practical applications still show an immaturity of these solutions, thereby it also indicates the level of complexity graph-based transformation approaches. It, with sureness, will decide about adopting of these kinds of approaches on a wide arena of software industry [70].

4.3.4.2.4 Structure-driven approaches

The structure-driven approach adds structure capabilities to a transformation, i.e. the approach organises the transformation into hierarchy structure.

In this approach, two main phases are distinct. In the first phase, the transformation process is focused on creation of the hierarchical structure of the target model. The second phase is a time during which the attributes and references in the target model are written. The structure driven-approach provides the scheduling and application strategy itself, leaving for user a task of transformation rules specification.

The approach is used in the model-to-model framework Optima lJ [58], which provides a set of classes, in Java language, of so-called incremental copiers. In classes, that extend the copiers, tool’s users may implements they own transformation rule s.

Main concept of this approach is to copy elements form the source model to the target, and adapt them with respect to a desired transformation effect.

67

The basic idea is to call, a transformation rule, which is implemented by a user as a method. The input parameter of the method is typed, with accordance to type of a source of the rule . The method returns a Java object, which presents the class of the generated, target model’s element. The method’s implementation is not allowed to have side effects, since ordering is fully directed by the framework.

Next structure-driven approach presented in [21], is the QVT proposal of

Interactive Objects [29]. This approach distinguish among others that it is the targetoriented rule organization. It means that for each type of elements of a target model’s corresponds one rule , see Horizontal transformations , and in particular, for this approach, a hierarchy structure of a rule specification is an equivalent of containment structure of elements in the target meta-model. The ordering mechanisms in the approach might be seen as top-down configuration of the target model.

The structure-driven approach seems to be developed mainly for support pragmatic group of transformation approach, more or less designed for particular type of development, such as EJB implementation, or task of database schemas generation from UML models. This kind of tasks requires a strong support of particular transformation models correspondences, e.g. 1-to-1, or 1-to-n. Most cases of structuredriven transformation solutions do not need iteration in scheduling, and the scheduling can be internal [21].

4.3.4.2.5 Hybrid transformations

The approach mixes the advantages of declarative easiness of specification, when matching constraints are specified, and high performance of imperative specification, when target model creation in made. In this chapter, focus is made on hybrid transformation approach. The approach is a combination, a hybrid, of two basic way of specification description, i.e. a declarative approach, which is mostly used in matching part of transformation process, and imperative approach, which is used for transformation rules body implementation. The imperative approach is used in all this places where the declarative specifications are not capable to do a transformation tasks, mainly because of lacks in particular transformation tool’s implementation [21].

In the following part, three hybrid approaches are presented, the Transformation

Rule Language (TRL) [4], the Atlas Transformation Language (ATL) [12], and finally

XDE [64].

First approach, the TRL, indeed might be classified as relational approach, however in the approach a strong imperative component exists. It combines two a declarative and an imperative paradigm. In the approach, a division between transformation specification and implementation, similarly to QVTP proposition [62], is made. Firstly, the specification is made by declaration of relationship between sources and target elements, constrained by additional set of matching conditions, which is a declarative component of this transformation approach, thereby moving it to side of relational approaches category.

The differences that make it a hybrid approach is an implementation part of transformation. In the TRL, the operational rules are executable and they are imperative. It means that within these rules, operation of models’ element creation, updating, or deletion are stated explicitly by transformation’s developer, which is in contrast to declarative approach, in which transformation approach cares about execution of declarative statements. The ordering mechanism, is has an internal form, similar to procedural languages, where a rule can explicitly call required rules in its body.

Moreover, this approach supports rule inheritance mechanism, on rule s and units level, and organises rules into unit structure, equal to modules in procedural languages.

As the TRL approach force users to mix both approaches, i.e. declarative and imperative, the Atlas Transformation Language [12] differs in that way from approach previously described.

68

The ATL approach is a hybrid approach, in some way it similar to the TLR, however the main different is that the ATL approach allow for transformation rules specification using two programming concepts, or both of them together.

The declarative parts of transformation specification in the ATL approach, are known as patterns, thus one says about source pattern in case LHS declarative specification, the target pattern is in case RHS specification made in declarative manner. The LHS consist of a set of syntactically typed variables, additionally OCL constraints for model filtering and navigation may be used. The RHS part of specification, in context of declarative specification, is a description of variables and declarative statements, which tight values of these variables within the target model.

The interim form between declarative and imperative, is case when declarative statements in source or target patterns are filled by imperative statements run after patterns application.

In addition, most imperative approach for rules specification is an ordinary procedure with a name, a set of formal parameters, and imperative block with sequences of operations made on transformed model. The imperative part does not allow including any patterns.

In addition, the rules might be reused by inheritance mechanisms. The ATL approach separates source and target models; however, it provides a copy mechanism, which makes an in-place transformation possible.

In the ATL solution implicit and explicit scheduling mechanisms is available . The implicit ordering mechanism has three phases. Firstly, an entry point rules is called, which may call further rules, secondly the source model is checked for the source patterns occurrence and in the case, and proper corresponding rules are fired. At the end, an exit point rule is executed. The explicit, internal ordering mechanism, similarly to the TRL, is a procedural call from within one imperative block to another [21].

The last presented approach in this section of the paper is the XDE approach [64], which is a highly hybrid solution. The XDE approach provides, so-called, pattern mechanism, which bases on parameterized collaboration, from the UML proposition for design patterns modelling.

A XDE pattern is a package of parameterized collaboration and a set of other models that can be customized, copied, or merged into target model.

A specification of matching conditions might be made declaratively using OCL conditions, or imperatively through Java, which makes the approach able to automatic element sele ction. This has its reflection in that a setting of the pattern application parameters might be made interactively using a wizard panel, or automatically by the approach. The approach delivers also mechanisms for repeated pattern application, since it support collection types in transformation parameters. The particular pattern configuration, i.e. parameters bindings, and application might be stored.

In difference to the ATL solution, the XDE does not put any constraints on kinds of relationship between a source and a target model, all combination are possible, e.g. creation of a new target model, model in-place update, or update of another target model, etc.

Two types of scheduling mechanism are used, internal implicit scheduling, through pattern nesting, or internal explicit scheduling programmed in Java in situations, which need more sophisticated solutions.

At the end, it is worth to add that the XDE approach supports model-to-code transformation using JSP-like code templates, which are linked with partic ular patterns.

In the paper [21], authors admit that hybrid approaches probably will play a crucial role in development of transformation solutions. The basic reason that is probably that the hybrid approaches tights together and make them cooperating different specification concepts, which are used with accordance to developers needs.

69

Moreover, the hybrid approaches allow for gradual transit from the full imperative approaches to the declarative one, which shall help improving latest one.

4.3.4.2.6 Other approaches

Representative transformation approaches that do not feet in any category presented above are the subject of this subchapter. Two representatives of transformation approaches are discussed, the transformation framework defined by

OMG’s, i.e. Common Warehouse Metamodel (CWM) in specification [53], and transformation approach that specifies a transformation using XSLT transformation language [88].

The CWM approach presented by the OMG is an answer for a specification that is able to deal with metadata interchange among warehousing, business intelligence, knowledge management and portal technologies [46].

The first impression about the CWM’s is that the approach provides transformation architecture only for data model transformation. Nevertheless, the approach are designed in the manner that allows to use this approach in more general way, as a support in model driven development for system model transformation, not only data model transformation.

The CWM approach bases on another OMG solution, the MOF [51]. In general, the MOF provides a common basis for meta-models. If, for different meta-models specification the MOF solution is used, a bridge that gap between these dissimilar meta-models is built. In case of the CWM, it means that if two different meta-models are both expressed in the MOF meta-meta-model, then models based on them can reside in the same repository, further one can use methods and mechanisms offered by the CWM to all models defined in that manner.

The transformation meta-model available in the CWM approach is capable to deal with any two models expressed within the CWM. It is, because all the main elements of meta-models, for instance the XML meta-model, etc, are created by derivation from a set of general CWM super-classes. As the transformation meta-model is expressed within these super-class concepts, it is applicable for all meta-models that share the super-classes’ set.

The CWM approach treats all kind of managed meta-data, thereby transformation rules also, stored in the MOF repository in similar way, using the general behaviour patterns, hence no particular transformation execution mechanisms are provided.

Moreover, the CWM does not support any language of the expression. Thus, to make transformation rules executable, an additional effort has to be made. Firstly, user has to extend the CWM framework by providing definition of procedural language or reuse, eventually extends language already defined. Secondly, the user has to provide implementation of that procedural language.

Two possible strategies of transformation performing are possible , the transformation code generator, and transformation rules interpretation.

In first strategy, the whole code of the transformation is produced by generator.

The generator reads the transformation specif ication made within the CWM, and in accordance to the specification, it produces an executable code, which is a proper transformation implementation. For example, a set of transformation rules that specifies transformation from the EDOC model to EJB is provided. This transformation rules are stored in the CWM repository, and are used by transformation code generator to create a transformation implementation. The implementation created by the generator, now is used for transformation of particular EDOC models, which are also stored in the CWM repository.

Second solution possible to use in the CWM, is transformation rules interpretation, made by providing a generic transformer. The transformation rules are read dynamically at runtime, from the CWM repository, and the generic transformer executes particular transformation rule on the source model stored in the CWM, thereby executing transformation specification. The important issues is that in some

70

situations, such transformation interpretation might be considerably slower than the transformation made within the first strategy

Summing up, the CWM transformation framework provides a mechanism for expressing relations between source and target elements. Nevertheless, particular transformation mechanism, which makes the transformation rules executable, is not prescribed by the CWM, and it has to be provided by transformation developer. In words of authors of the article [21], CWM provides a general model, but it lacks of a mechanism of model transformation imple mentation.

The second approach is related with Extensible Stylesheet Language

Transformation (XSLT) [88] and the Extensible Markup Language (XML) technology

[59]. It is different from the others in that way it uses to model transformation technology, which base on XSLT and XML technology, independent from particular transformation tools. This kind of solution is tool independent, since it does not use model description format imposed by particular modelling tool, but focus on the UML meta-model itself. The independence is assured by standard format and notation for model representation, i.e. the XML Metadata Interchange (XMI) [89], which is the application of the XML, dedicated form encoding models of languages specified in the

MOF [51].

Model in that approach is encoded in sets of XML tags, which are prescribed by the XMI standard. It makes that representation model independent, since the XMI standard base on the XML, thereby in order to transform a model expressed within

XMI a set of solutions associated with XML technology may be adopted.

The XSTL technology is one of them. It is a standard technology for transforming

XML documents. It is capable to execute stylesheets combined with transformation rules that specifies transformation on XML documents. The main elements and concepts of using the XSTL approach are presented on Figure 38.

In particular, for each stylesheet a set of patterns, in form of XML tags and rules of input to output document transformation are stored. The patterns represent part of matching condition, which are posed on elements of input model, i.e. elements that are searched for in a source model, i.e. the input XML document. Moreover, in the patterns, content of the output model is specified, since from the patterns other transformation rules are called.

As a transformation based on XMI and XSLT approach is performed outside particular UML tool, the only requirement that is posed against the UML tool is functionality for export and import models in XMI standard. The conversion functionality is supported by the most modern UML tools. Moreover, it has another advantage, in case of tool that does not have an API for internal model representation or does not provide any programming language for additional scripts; the XMI approach opens a possibility of transformation performing, obviously, if tool has proper XMI import and export functionality.

The process of the XMI based transformation is presented in Figure 38. First step in transformation process is to generate UML model that is encoded using the XMI.

Second step is to perform the transformation encoded in the XSL stylesheet by a

XSLT processor. Now, the result of the transformation has to be imported to the UML internal model representation again.

71

Figure 38 - Implementation of model transformation based on XSLT [79]

Nevertheless, the manipulation of model outside the tool may be a reason of some drawbacks. The reason is that a XMI document is nothing else that XMI document from the perspective of a XSLT processor and a XSL transformation, thus to guard the internal consistency of the encoded model, additional effort must be made to avoid such problems as unbounded references between model elements, etc [79].

Another important drawback of the approach is connected with serious scalability limitations and a performance problem. The basic reason of that fact is verbosity and poor readability of the XMI and the XSLT, and manual implementation of model transformation, very fast leads to specification that is very hard to maintain. However, this problem might be solved, where the XSLT transformation rules are generated automatically, from other form of transformation specification, e.g. declarative specification. It has to be added that even the automation rules generation does not solve the performance problem of the XML-based approaches [21].

However, as it was stressed this type of the transformation has limitations, especially in aspect of scalability. Despite the attractive perspective of XMI language, the XSLT approach leads to solutions that are non-maintainable and have poor readability.

4.4 Summary

The model transformation area is composed from more established fields of program transformation and meta-programming, however new elements like graphical modelling languages, or adding object-orientation to meta-modelling programming, etc. creates new issues. Thus, it is important to understand, following the authors of

[21], that model transformation is a relatively young area of the computer science, and it still rules using laws of children age, hence no mature transformation approaches, i.e. transformation languages, tools related with a model transformation, as transformation editors, repository tools or transformation engines itself. Thereby a lot of work in this area has to be done, and one should be prepared for many changes in that field, which probably occur, while the model transformation field.

The model-driven development, in order to become a common used practice requires tools that automate the creation, evolution and maintenance of models used throughout model-driven software lifecycle. In particular, tools that aid the description and execution of model transformation plays crucial role in this set [70].

72

The importance of maturing of the transformation model area is obviously crucial for model-driven software development approaches, as it is one of critical elements, apart modelling languages, that decides about future success or failure of solutions based on model-driven software development, like the OMG’s MDA.

Nevertheless, the OMG tries to face up the transformation problem, and initiates a standardization process by publishing a Request for Proposal on Query/Views/

Transformations (QVT) [52]. As author of [27] recognizes, although the QVT standard is not yet set, it probably will became a crucial player in development of the MDA vision.

The transformation itself might be understood as a function that describes the way a source model is reformed to a target model. However, this understanding has some restrictions, especially in case of necessity of performing bi-directional or even an inverse transformation. Thus, the concept of transformation function has to be enhanced or by adding extra information to the transformation function, or by describing a transformation as set of relation between transformed models’ elements.

The distinction of transformation from the point of view of changes posed on generated model three basic types are pondered, vertical, horizontal and oblique transformations. In the model-driven development all kinds of transformation are used, however, the more complex kinds seem to be a horizontal, thereby the oblique kind of transformation. In addition, there is no surprise that this kind of transformation is one of the basic motivations of model-driven development itself, since it is responsible for most important transformation from the platform-independent models to platformindependent or platform-dependent one.

The development of particular transformation might be compared to other software development process. Thus, three basic phases are considered, transformation intentions description, transformation specification, and transformation implementation phase. The first phase, obviously has common denominator with the inception phase of development process, thus description, similar to requirements against transformation, is made. This description is used as input in transformation specification process, for instance made in contract-based manner in most cases using declaratively expressed constraints, e.g. the OCL, which might compared to the elaboration in software development process. In most cases, the implementation of the transformation, which is analogy to the construction of the development process, is made in language, mostly in general-purpose language, different from approach used in specification phase, taking into consideration conceptual aspects, like level of abstraction, concepts used in language, etc. The whole effort in developing of transformation approaches is to prepare the transformation solutions that will use languages conceptually close to language used for transformation specification, or even they will specification language itself.

There are some satisfactory transformation solutions, e.g. template-based approaches, which are able to perform transformation from model to text. However, mostly the type of performed transformation is a forward refinement, which, as it is mentioned above, is one of the simplest types of transformation to perform.

However, the situation is different in case of model-to-model transformation approaches. As the authors of the paper [21] underline, although many new approaches have been proposed, there is still la ck of information about their effectiveness in practical applications. Thus, the transformation approaches are still on phase of exploring possibilities and completing requirements against transformation approaches.

There are some modelling tools , on the market, that offers some model-to-model transformation functionality, for instance the XDE [64], the ArcStyler [6] approaches, however it is mostly added in ad hoc manner, lacking sufficient theoretical preparation. In most cases, this type of tools targets particular type of platform-specific models, like the EJB, or the CCM [18] platforms, however this far away from the spirit

73

of the MDA idea, since one of the basic assumes is different platforms platformspecific models’ generation.

Considering reviewed transformation approaches, it is obvious that two quite different styles of transformation implementation are used. They base on programming paradigms, which are used for implementing them, i.e. imperative and declarative programming approaches. The imperative approach force to make an explicit source model traversal and target object creation and update. In the declarative approach, the implicit source model traversal and implicit target creation are used. The user is only obligate to express the transformation rules specification in language that is much closer to the transformation specification itself, since both are base of concept of declarative statements.

It is obvious that currently preferences tend to development of the declarative approaches due to having semantic model that is closer to transformation domain itself. Thereby, the deve loper has to put less focus on, e.g., an order of rules description, or way the specification shall be expressed in general-purpose language, focusing mainly on functional requirements against transformation.

Nevertheless, one shall not cross out the imperative approaches, since they, in similar to assembly languages, might be useful in certain type of transformation tasks.

One important issue is not considered in the chapter above. It is a problem of correctness of a defined transformation’s rules. The correctness can be considered within several notions. The basic and most simply is a question of syntactic or structural correctness of generated model. In other words, it is verification whether the transformation rules generate from a well-formed instance of a source model a wellformed instance of a target model. The more advantage verification of correctness is in case of semantic checking. In other words, it is a question, whether the result of the transformation has the same meaning as the input model. Following the statements from the paper [27], one shall not assume that the correctness has always to be investigate, otherwise generated models are not worth of interesting. The example is in case when a visual representation of model is generated, and a visualisation, as it is the result model, purely fulfils both correctness criteria .

Since checking against the syntax or structural correctness is rather an simply task, which requires checking the result model against its meta-model syntax, which is already made, the generic issue of semantic correctness is much more complicated. It is complicated by the fact that a source and a target model are usually expressed, not only in different languages, but also in different domains of discourse, thereby the task of relation, between statements in these two models , definition is equivalent to definition of the investigated transformation itself. Following advice of authors of the paper [27], it is worth to perform the task of semantic verification only when the source and target models are at the same level of abstraction, i.e. isomorphic models with not many differences in meanings.

In conclusion, the transformation approaches still requires a lot of evaluation of the different design options. It will require even more experiments in theoretical and practical sphere. Following the comment in the paper [21], already established concepts, issues and opening requirements would become a directions for next stage of transformation approaches development.

The proper evolution of transformation approaches is imperative for the success of the vision of model-driven development, and the MDA in particular. Quoting the statement from [27], unless the mature transformation solution is created, a transformation will remain the missing link of model-driven development.

74

5 PIM – EDOC

5.1 Introduction

The EDOC profile of UML was adopted by the OMG in November of 2001 as the modelling framework for Internet computing, integrating web services, messaging, ebXML [23], .NET [40] and other technologies under a common technologyindependent model. It comprises a set of profiles, which define the Enterprise

Collaboration Architecture (ECA), the Patterns, and the Technology Specific Models and Technology Mappings [60].

5.2 EDOC

Following the description of the MDA, models play crucial roles in software development conducted by this approach. The distinction between platform specific model and platform independent model is one of key elements in the MDA. The

Enterprise Distributed Object Computing (EDOC) is an example of platform independent model.

The standard [50] provides UML profile for specification component-oriented approaches that are used to develop enterprise distributed systems. The models created within the profile can be transformed to existing software component framework, for instance middleware platforms like Enterprise Java Beans (EJB), or CORBA

Component Model (CCM).

Component-oriented specifications can be introduced at distinct levels of abstraction during the software development cycle. Thus, an EDOC/ECA model is likely to be used at an "analysis" level while a CCM based description could be used later at "design" phase, reflecting the specific architecture decisions. Obviously, for an organization that has to maintain distinct models of their systems, it is an important issue to reduce the gap between models located at different levels of abstraction.

Moreover, in the context of the OMG MDA, the problem of the transformation between separate models has been identified as being very important. One can expect that a standard for model transformation will emerge from the OMG organization in a near future [11].

To achieve its goals EDOC provides a set of elements:

a set of Technology specific Models allowing the definition of Platform dependent Models as defined by the MDA

a Patterns Profile that can be applied in specifications that use the ECA

a technology independent profile, the Enterprise Collaboration Architecture

(ECA), which allows the definition of Platform Independent Models as defined by the MDA

Following the paper [50], the submission of the EDOC profile provides capabilities to model event-driven systems and business processes. The core of the architecture, the Enterprise Collaboration Architecture, introduces a general composition model that base on recursion in composition, port specification through protocol specification, configuration specification, etc.

Because patterns for ECA are not part of consideration, the authors will use only

ECA profile.

5.3 ECA

Because ECA is conforming to the MDA, it consists of elements that allow describing architecture in platform independent way with such level of complexity that

75

will allow transforming design model to platform specific model. These are the profiles:

The Component Collaboration Architecture (CCA) – that allow to design computation elements in the system (structure and behaviour).

The Entities profile – that is used to describe entity objects and is used to define entity structure of the domain. Entity profile specialize CCA.

The Events profile – that is used to model event driven systems. Events profile specialize CCA.

The Business Process profile – it specializes CCA to create set of components needed to model system behaviour in the business domain.

As a PIM in transformation process, the authors are going to base on Enterprise

Collaboration Architecture (ECA) or to be more specific, on part of it called CCA. To resolve problems associated with describing behaviour, structure, semantics, infrastructure, and qualitative aspects of the system specification, EDOC uses views introduced in Reference Model of Open Distributed Processing (RM-ODP):

enterprise specification,

computational specificatio n,

information specification,

engineering specification, and

technology specification.

5.3.1 Views in ECA

Figure 39- The ECA models related to viewpoints from RM-ODP [50]

As one can see on Figure 39, platform independent part of this approach consists of three viewpoints: Enterprise viewpoint, Information viewpoint, and Computation viewpoint.

Enterprise viewpoint specifies structure and behaviour of the system in terms of business domain, by describing (as one can read in [50]):

the business processes supported by the system,

steps in those processes and relationships between steps,

business rules (policies) that apply to the steps,

76

artefacts acted on by each step,

enterprise objects representing the business entities involved,

the roles that they fulfil in supporting the business processes, and

the relationships between roles (including interaction relationships) where

roles

Identify responsibility for steps in the business processes.

System (or specific elements of that system) is described as part of one or more business processes. This approach allows determining, which are the system responsibilities (roles of the system) in this process.

Information viewpoint specifies semantics of information related to system roles in the business processes and information processing that follows these system roles. To specify these factors information view includes description of: [50]

a configuration of information objects (static schema),

the behaviour of those information objects (dynamic schema), and

the constraints that apply to either of the above (invariant schema).

This viewpoint is based on Enterprise viewpoint, and it represents information from business perspective only.

Information viewpoint and Enterprise viewpoint, as embedded in business domain, can be considered as Computation Independent Model. Unlike, those Computation viewpoints describe systems architecture and they can be considered as Platform

Independent Model. Computation viewpoint specifies:

Structural part of the system, by describing computation components

(modelled by ProcessComponents) and dependences between them.

Behavioural part of the system by specifying interfaces (modelled by

Ports) and their protocols (Collaboration structures among a set of computational objects are modelled by Compositions with associated

Choreographies).

Computation viewpoint is based on CCA, but also includes its extensions: Entity model for the definition of entity components, and Events model for the definition of event driven computational structures.

5.4 Component Collaboration Architecture

Figure 40 - Structure and dependences of CCA meta- model [50]

77

Component Collaboration Architecture folds up of five elements presented on

[Figure 40]

Specification approach chosen in CCA assumes that external description of system elements is separated from the description of how the system elements are realized and description of their behaviour. The description of outside structure of the component is given by Component Specification. Every element of the system is described within

Component Specification, but it does not contain any information about internal structure of the components, their place in the system and their behaviour. Metamodel for the Component Specification in presented on [Figure 41].

The way that elements of the system are used, configured and connected is described by Composition. This part of system description visualizes how instances of system elements (or system itself) will behave during specific processes in terms of other elements of the system. Elements of the system can be divided on two categories, primitive components that are the smallest elements of Composition and can not be described by internal elements, and Composed Components that do not posses any logic of system, they rather create a kind of interface between group of system elements and the rest of the system. The metamodel for the Composition is presented on [Figure 43].

The Choreography specifies data flow in the system and sequences of the actions taken by different parts of the system. The most important part of choreography in case of transformation is choreography of the protocol - description of dataflow between two elements of the system. The metamodel for the Choreography is presented on

[Figure 42].

The Document Model describes the information that flows in the system. It does not only defines what kind of information is used in the system, but also specifies structure of this information, and creates a base for information model, that can be used by Entities model (this part of EDOC is not considered in this paper). The metamodel for the Document Model is presented on [Figure 44].

The Model Management model is used to organize elements of the system into the package structure. The concepts taken in this model are very similar to those used in

UML. The metamodel for the Model Management is presented on [Figure 45].

5.4.1 Component Specification

The base element of Structural specification is ProcessComponent.

ProcessComponent is an abstract of part of the system that encapsulate piece of functionality of the system. ProcessComponent can define his PropertyDefinitions.

PropertyDefinition specifies properties of that component that may be set, when this component is instantiated. ProcessComponent may have ports that allow them to specify dependences between this and other ProcessComponent. Port defines a way of communication between ProcessComponents. Component Specification distinguishes four kinds of ports:

Flow port – that represents one-way communication with single type of data ,

Protocol port – that defines bidirectional communication between components, and that represents request/response communication between components, and allows

ProcessComponent to model both, document oriented (Flow ports) and method oriented (Protocol port) subsystems.

Operational port – represents request/responds type of communication.

MultiPort - groups ports whose actions are tide together. When ports are connected with MultiPort, information send to MultiPort will be stored, until all ports

(MultiPort can contain only FlowPorts) have information that is needed to use them.

When all of the need information will be gather, every port from MultiPort will handle data stored for him.

Ports can have two roles in communication – initiating and responding. Only

ProcessComponents with initiator ports can start a conversation, but only with ports that have all characteristics the same as initiating port and have responding role.

78

ProcessComponent may also have Interfaces, which are abstracts of standard object interfaces and may contain Operation Ports and Flow Ports – each assessed to specific method in the ProcessComponent.

Figure 41 - Metamodel for Structural Specification [50]

5.4.1.1 UML Profile for Structural Specification

ProcessComponent in UML Profile is represented by Classifier – It is specialized by a Subsystem if it is defined by other ProcessComponents, otherwise it is specialized by a Class, and is stereotyped <<ProcessComponent>>. Name of the

ProcessComponent is represented by ModelElement’s name. The rest of

ProcessComponent attributes are represented by following TaggedValues:

granularity – defines a range of ProcessComponents visibility

primitiveKind – is used if ProcessComponent is specified in some external action or programming language

primitiveSpec – contains a syntax of primitiveKind language

isPersistent – true if ProcessComponent is persistent

The Port in UML Profile is represented by abstract Class. Name of the port is represented by ModelElement’s name, the rest of Port’s attributes is represented by following TaggedValues:

79

isSynchronous – true if Port represents synchronous communication

isTransactional – if true then communication with port is transactional and atomic

direction – indicates if the Port is a initiator or responder

postCondition – it specifies the status of the conversation indicated by the use of this Port.

The relation between Ports and PortOwner is an association, where PortOwner’s

AssociationEnd has to have aggregationKind set on composition.

The FlowPort is represented by Class stereotyped <<FlowPort>> that specializes the Port. Type of the FlowPort is designated by UML Association between FlowPort and specific DataElement. The only exception to this rule is OperationPort represented by UML Operation that has to be an ownedElement.

The ProtocolPort is represented by Class stereotyped <<ProtocolPort>> that specializes the Port. ProtocolPort has a Generalization relation with specific Interface or Protocol that it points out.

The MultiPort is represented by Class stereotyped <<MultiPort>> that specializes the Port.

The OperationPort can be represented by two kinds of ModelElements, it can be represented by Class stereotyped <<OperationPort>> that specializes the Port, or it can correspond to UML Operation with the same stereotype. If it is represented by Class, it owns three types of FlowPorts that describe its input data, return data and exceptions.

Otherwise, it can represent only responds port and looks like standard UML Operation.

The Protocol is represented by Class stereotyped <<Protocol>>. Its name is represented by ModelElement’s name.

The Interface corresponds to the UML Classifier. The interface can only contain

OperationPorts and FlowPorts. OperationPorts have to be represented by UML

Operation, and every port has to be a responder.

The PropertyDefinition corresponds to UML Attribute stereotyped

<<PropertyDefinition>>. The Property Definition name is represented by

ModelElement’s name, initial attribute is represented by UML Attribute’s initialValue attribute and isLocked attribute is represented by StructuralFeature’s changeability attribute. PropertyDefinition belongs to features of specific ProcessComponent. The

PropertyDefinition is typed by the DataElement classifier.

The Structural Specification can be represented as Class Diagram.

5.4.2 Choreography

Choreography defines flow of messages between PortUsages (instances of ports from Structural Specification). It can be externally or internally oriented. Externally oriented Choreography specifies behaviour on intercomponent level. Internal

Choreography can be defined for a ProcessComponent or a protocol. It is modelled as an activity graph, where Nodes (Node is a representation of an entity that can be source and/or target of a connection or transition. The specia l type of node is Port

Usage as node that can perform some task. Node has to relate to PortUsage or

PseudoState). The flow of data and/or control between Nodes is specified by

Transitions (that declare a contract) or Connections (that realize the contract).

80

Figure 42 - Metamodel for Choreography [50]

5.4.2.1 UML Profile for Choreography

Transformations described in this thesis do not use Choreography, because of that, descriptions of this part of UML Profile for ECA is out of scope in this paper.

5.4.3 Composition

The Composition shows which components are used in specific process and what kind of roles do they take in this process. Composition uses ComponentUsages

(instances of ProcessComponents) and PortConnectors (instantiations of ports) in specific background – which can be a ProcessComponent or CommunityProcess (toplevel usage of the system). Any Connection that joins compatible ports marks a flow of data (different for different types of ports). To achieve specialization of

ProcessComponent used in concrete role in the process, CompositionUsages can have

PropertyValues for PropertyDefinition.

81

Figure 43 - Metamodel for Composition [50]

5.4.3.1 UML Profile for Composition

Representation of Composition is not fully compatible with UML Profile for

Composition, but it is changed as it is suggested in chapter “Diagramming CCA” in

[57].

The Composition is represented by UML Subsystem and it owns

ComponentUsages.

The ComponentUsage is represented by UML Object stereotyped

<<ComponentUsage>>. The Uses relation is represented by UML Usage.

PortConnector is represented by UML Object stereotyped <<PortConnector>>.

His connections with other PortConnectors are represented by UML Associations.

PortConnector contained (as owned element) by ComponentUsage.

PropertyValue are represented by UML Constraints (that are set for

ComponentUsage and PropertyDefinition).

5.4.4 Document Model

The Document model is used to describe data that will be used in communication between ProcessComponents and that will be processed in the ProcessComponents.

One can distinguish three types of DataElements:

Enumeration – that has a fixed set of values (EnumerationValues) that it can take.

DataType – represents a primitive data type defined outside of CCA.

Specific Kind of this type is ExternalDocument that represents large document like XML

CompositeData – complex data that consist other types in form of

Attributes

82

Figure 44 - Metamodel for Document Model[50]

5.4.4.1 UML Profile for DocumentModel

The meta-model elements, i.e. Attribute, DataType and Enumeration meta-classes corresponds to the same elements in the UML meta -model [55].

In the Attribute meta-class, following meta-attributes correspond to meta-attributes of the UML’s Attribute. The initialValue is the same as initialValue in the UML’s

Attribute . The meta-attributes required and many are translated into the multiplicity of

the UML’s Attribute. In particular, value of the MulitplicityRange’s lower metaattribute is zero if required is false; otherwise, it is greater than zero. The meta attribute many specifies whether MulitplicityRange’s upper meta-attribute shall be more than one.

The meta-attributes of the meta-class Attribute corresponds to meta-attributes of the UML’s Attribute, besides meta-attribute isByValue, which is represented using the standalone TaggedDefinition of the same name and Boolean type.

The meta-model CompositeData is represented in the UML as Class that is stereotyped by <<CompositeData>>. The <<CompositeData>> may be an owner of attributes. The possible types of the attributes are a DataType, an Enumeration, a Class stereotyped as

<<CompositeData>>, or a DataType stereotyped as

<<ExternalDocument>>. Each attribute of the <<CompositeData>> might be

additionally tagged by a value of isByValue tagged definition. Additionally, the

<<CompositeData>> may be constrained by DataConstraint.

The <<CompositeData>> might be in Generalization relationship only with other

<<CompositeData>>.

The <<CompositeData>> might be set as type of <<PropertyDefinition>>, which corresponds to the meta-association PropertyType in the meta-model. The

<<CompositeData>> might be set as type of the attribute of other

<<CompositeData>>. The <<CompositeData>> might set an association with the

<<FlowPort>>.

The DataType is represented by the UML’s primitive DataType, such as an integer, string. The DataType might be set as type of <<PropertyDefinition>>, which corresponds to the meta-association PropertyType in the meta-model. The DataType

83

might be set as type of the attribute of other <<CompositeData>>. The DataType might set an association with the <<FlowPort>>.

The

<<DataInvariant>> stereotypes Constraint, which is put on

<<CompositeData>>. A constraint is expressed within the body meta-attribute.

Additional, tag isOnCommit, which might be true or false states whether the constraint has to be applied to a fully formed data element, or not to one under construction.

The meta-class Enumeration has meta-attribute initial that corresponds to the

initialValue of the UML’s Attribute, which holds variable of one of Enumeration

types. The initialValue of the Enumeration is chosen from allowed values held in

values, which corresponds to the UML’s Enumeration literal meta-association. The

meta-model EnumerationValue is the equivalent of the UML’s EnumerationLiteral.

The Enumeration might be set as type of <<PropertyDefinition>>, which corresponds to the meta-association PropertyType in the meta-model. The

Enumeration might be set as type of the attribute of other <<CompositeData>>. The

Enumeration might set an association with the <<FlowPort>>.

The <<ExternalDocument>> stereotypes DataType that corresponds to the

ExternalDocument meta-class in the Document Model.

The <<ExternalDocument>> might be in Generalization relationship only with other <<ExternalDocument>>.

The <<ExternalDocument>> might be set as type of <<PropertyDefinition>>, which corresponds to the meta-association PropertyType in the meta-model. The

<<ExternalDocument>> might be set as type of the attribute of other

<<CompositeData>>. The <<ExternalDocument>> might set an association with the

<<FlowPort>>.

In addition, the meta-attributes of the ExternalDocument meta-class are represented as tagged values attached to a data type stereotyped by

<<ExternalDocument>>. In particular following TaggedDefinition of String type are

provided: mimeType, specURL, externalName.

5.4.5 Model Management

Model management defines how CCA models are structured and organized. A package defines a logical hierarchy of reusable model elements. Elements that may be defined in a package are PackageContent and may be ProcessComponents, Protocols,

DataElements, CommunityProcesses, and other packages. An ImportedElement defines a “shortcut” visibility of package content in a package that is not its owner.

Shortcuts are useful to organize reusable elements from different perspectives.

84

Figure 45 - Metamodel for Model Management [50]

5.4.5.1 UML Profile for ModelManagement

Transformations described in this thesis do not use Model Management, because of that, descriptions of this Metamodel is out of scope in this paper.

5.4.6 Example

This chapter presents a simple buyer-seller example. For a conversation between buyer and seller, as shown on [Figure 46], the BuySellProtocol is specified. It folds up of three FlowPorts (Send Order, GetConfirmation, and GetDenied) that use three different types of data (Order, OrderConfirmation, and OrderDenied). The SendOrder port is used by ProcessComponent that is a responder in the conversation, and

GetConfirmation and GetDenied ports are used by ProcessComponent that has initiator role.

Figure 46 - Protocol structure

In this example, as it is show on [Figure 47], we have two ProcessComponents.

The ProcessComponent called Seller will have responder role in BuySellProtocol

85

through Sells ProtocolPort and Buyer ProcessComponent will have initiator role in the same Protocol through Buys ProtocolPort.

Figure 47 – Example of Component structure diagram

As we can see on [Figure 48], there will be only one instance of Buer and one instance of Seller, and they will communicate with each other through instances of ports Buys and Sells.

Figure 48 – Example of Composition diagram

86

6 PSM – EJB

6.1 Introduction

The Enterprise Java Beans (EJB) is a platform that is a target platform for transformations. The goal of these transformations is to translate concepts introduced in source model in the concepts that will be specific for EJB. To model these concepts the authors will use an UML profile for EJB 1.0 [3] that allows to model architecture described in EJB specification [72].

6.2 Description of Enterprise JavaBean’s

The target transformation platform will be Enterprise JavaBeans (EJB) 1.0. As one can read in [24], EJB “are managed, server-side components for the modular construction of enterprise applications”, and are part of J2EE.

By the word “Component”, the authors understand that EJB can be used as black box COTS components, and have to be configurable, to support using them in different applications. The next, very important, characteristic of EJB is that it’s not meant to be used on client side application, it must be part of “server-side” specification, with specific EJB container that will handle all “managing” activities.

Although EJB Container functionalities vary, depending on a vendor, there are some base tasks, which are handled by every Container; these are according to [24]:

Object Persistence

Declarative Security Control

Declarative Transaction Control

Concurrency Management

Scalability Management

The first functionality is Object Persistence – that means that state of all (stateful)

EJB will be persistently stored in some manner, for instance, using database, or other storage solution.

Every EJB Container will take care of storing beans state and synchronization between EJB instance and stored state (even when EJB instance is accessed concurrently).

Managing Declarative Security Control means that Container can, basing on specified security roles, check if client that invokes a method on an EJB has been authenticated. Thanks to that, securit y logic does not have to be included into EJB based application.

Declarative Transaction Control allows not implementing any transactional logic in EJB application. All functionality linked with starting, committing and rolling back transactions will be handled by the Container. Of course, some rules have to be set, but they are not part of program itself.

EJB Containers are also able to manage concurrent method invocations.

Invocations can come from remote clients, which are used also in multithreaded systems, which allow to safely omitt this issue during implementation and design of any EJB application.

The last issue is Scalability Management. It means that when application will need more resources, Container will grant them or will use instance pooling and database connection pooling (one instance can be sued by couple clients, only in the time when they are necessary) .

Very important function of EJB Containers is that it handles all remote communication between client and bean. It allows implementing whole application as

87

extension of client’s application despite connection type used between client and EJB

Container.

6.2.1 Enterprise beans

The core elements of EJB are Enterprise beans and Containers. Enterprise beans are components which instances are created and managed at runtime by Container, and provide both business and persistent logic of (server-side distributed transactionoriented enterprise) application.

During communication between client and Enterprise bean, there is always the same remote API for object creation, lookup, method invocation and destruction.

Distinction between different Enterprise beans is assured by unique identifier, created for each EJB Object by Container. To provide for container information about the way that it should handle communication between Enterprise bean and client, every

Enterprise bean has to implement three types of classes:

Enterprise bean’s home interface

Enterprise bean’s remote interface

Enterprise bean class (implementation class)

Enterprise bean provider needs only to define remote and home interface, and specify a bean’s provider class. Classes that will be used by client will be generated, basing on this information, by container.

The Home interface includes static methods of Entity bean. The Home interface has zero or more create(…) methods, used by Container to create instance of

Enterprise bean. It also can contain finder methods, used by Container to find specific instance of Entity bean, and method provided by javax.ejb.MetaData interface, that allows gathering Session bean meta-data that are used for loose client/server binding and scripting and other methods used by Container to manage Enterprise bean instances. Though in specification of EJB 1.0 [72] is written that these are the only methods that should be in the Home interface, in [24] one can read that it’s common to put there also static business method (in that case of course they need to have implementation in Enterprise bean class).

Remote interface provides business methods that can be called by client. As in the case of Home interface container will handle creating connection between interface and bean class. Every operation in this interface has to be able to throw

java.rmi.RemoteException.

An Enterprise bean is never allowed to be accessed directly by the client. An EJB object holds implementation of every method that will not be generated by container.

It has implementation of every business operation, the EJB object also has to include

ejbCreate (…) method for every create (…) method from Home interface and ejbFind

for every find method. EJB object also supports methods of the javax.ejb.EJBObject interface, that allow client to get the EJB object container, EJB object’s handle, compare two objects and remove EJB object, but implementation of these methods is defined by the Container.

The Enterprise beans should provide mechanisms that allow changing configuration of specific bean; depending on the way, that specific instance of

Enterprise bean will be used. To do that, one can use Environmenta l properties (that are defined as java.util.Properties). Enterprise bean provider should define all

(key:value) pairs that can be chosen during instance configuration.

The Enterprise beans have also some restrictions that they have to obey. The

Enterprise bean cannot start or terminate any thread. It cannot also use any read/write

static fields (though it can have final static fields). It also cannot use any thread

synchronization primitives.

Specification of EJB 1.0 [72] distinguishes two types of Enterprise beans:

88

1. Session beans

2. Entity beans

6.2.2 Session beans

Session Beans are components that are used to implement business logic; they are intended to be private resources used only by the client that created them. Session

Beans can use functionalities provided by other Session Beans, or access to persistent data represented by Entity Beans. They cannot be part of any other beans (this rule also applies to Entity Beans). Because it is transparent for client which Session bean instance he is using, there is no reason to implement any finder method in Home interface.

Session bean class has to implement javax.ejb.SessionBean interface, it also has to be public and cannot be abstract. It also can implement the Enterprise bean’s remote interface and javax.ejb.SessionSynchronization interface in this class all business and

ejbCreate methods have to be implemented. Each ejbCreate method must have name

“ejbCreate”, has to be public, return void type and have argument types belonged to set of Java RMI types. They may throw

java.rmi.RemoteException,

javax.ejb.CreateException, or any application specific exceptions. Business methods

should not have name specific for EJB architecture (like ejbPassivate or

setSessionContext), they have to be public , their return type and arguments have to be

one of Java RMI types and they, besides application specific exception, may throw

java.rmi.RemoteException.

The Enterprise bean’s Remote interface for Session bean has to extend javax.ejb.EJBObject interface. Every method in this interface has to throw

java.rmi.RemoteException, and must have return and argument types matching with

Java RMI types. Every method placed in this interface must have its matching method in the Enterprise bean class, that has to have the same name, identical arguments and return type, and must throw the same set of exceptions.

The Enterprise bean’s home interface in Session bean has to extend the

java.ejb.EJBHome; every method in this interface has to have return value and

argument with Java RMI types, and must throw java.rmi.RemoteException. This interface has to define one or more create methods, each of these methods has to have its equivalent (ejbCreate method) in Enterprise bean class, with the same name and the same argument, return type, and must throw the same exceptions (the

javax.ejb.CreateException is mandatory). Every create method has to return Remote

interface type.

Session bean creates a session for one client at one time that is why Session beans last for relatively short time comparing to Entity beans. State of Session bean is managed by Container and can be handled in one of two ways (specific for each

Session bean):

Stateful – bean’s state is retained for each of the clients

Stateless – bean’s state is not retain, and one instance of that bean can be used for many clients

6.2.2.1 Stateful Session bean

According to [24] “a stateful Session bean’s conversational state is defined as its field values plus the transitive closure of the objects reachable from the session Bean’s field” and “may contain open resources like open files, open sockets, database connections” etc. For closing/opening resources ejbPassivation / ejbActivation method is used.

Every Session bean has to implement the SessionBean interface, which is comprised of following methods:

89

setSessionContext – this method associates Session bean instance with its

context maintained by the Container.

ejbRemove – this method notifies that the instance is going to be removed by

the Container. If Session bean does not have any database or resource state to clean up this method can be empty

ejbPassivate – this methods notifies that Container wants to passivate the

Session bean

ejbActivate – this methods notifies that the instance has just been activated by

the Container

A Session bean can also implement javax.ejb.SessionSynchronization interface to provide its instances in synchronization notifications. Synchronization notifications are used to handle persistent cached in transactions. State of Session bean is not transactional and implementation of it may need to take into account reaction on transaction start and end. This interface consists following methods:

afterBegin – signalize that a Session bean instance is in the new transaction

and may operate on the persistent data within this transaction

beforeCompletion – signals that Session bean client wants to finish current

transaction and wants to commit the instance’s resources, the instance should now write out any database updates it has cached.

afterCompletion – signals that the current transaction has been committed

(true-commit/ false-rollback).

6.2.2.2 Stateless Session bean

Stateless Session beans do not retain hold conversational state after finishing method invoked by client, that cause that every instance of specific Stateless Session bean class are identic al if they do not execute any method at the moment. Home interface can have only one create method and it cannot take any arguments. Of course, there also has to be ejbCreate method in the Bean class and this one cannot take any arguments. As state of this bean does not have to be stored, it does not need any passivation method, also Stateless Session bean does not have to implement javax.ejb.SessionSynchronization interface.

6.2.3 Entity beans

Entity Beans are responsible for persistent data in the application (not direct persistence management, which is done transparently by Container). According to

[24], usually entity beans represent business entities, but they do not implement business logic that is not directly related to contained data. Unlike Session beans,

Entity bean provides shared access from multiple clients.

The Enterprise bean class in Entity bean has to implement javax.ejb.EntityBean interface, it also has to be public and cannot be abstract. It can implement the

Enterprise bean remote interface and must implement ejbCreate, ejbPostCreate and

ejbFind<METHOD> methods.

The ejbCreate methods name must equal “ejbCreate”, it has to be public and return primary key type or collection. Arguments and return types must be Java RMI types. The

ejbCreate method may throw java.rmi.RemoteException,

java.ejb.CreateException and any application specific exceptions.

Every ejbCreate method may have its matching ejbPostCreate method. Each of these methods has to be public and its return type must be void . Return arguments of this method have to be the same as in appropriate ejbCreate method. It may throw

java.rmi.RemoteException, java.ejb.CreateException and arbitrary application specific

exceptions.

90

As for client it is not (and must not to be) indifferent which Entity bean instance is used by the client, there is significant change in Home interface finder methods of

Entity bean in comparison with Session bean’s home interface. This interface has to define at least one finder method. Just as in Session bean, each finder method name has to have prefix “ejbFind”. Each of these methods has to return Enterprise bean’s remote interface or collection of EJB objects, has to throw java.rmi.RemoteException, and usually throws java.rmi.FinderException. Finder method has to be public and must have argument types of Java RMI types. Every home interface of Entity bean has to have findByPrimaryKey (primaryKey) method that finds an Entity instance by its primary key.

Business methods in Entity bean have to be public and cannot have names of methods from EJB architecture. Theirs argument and return types must come from legal types of Java RMI. Business methods can throw java.rmi.RemoteException and application specific exceptions.

Enterprise bean Remote interface has to extend javax.ejb.EJBObject interface.

Arguments types and return values types of every method in this interface must be

Java RMI types, and each method has to throw java.rmi.RemoteException. Every method from this interface must have matching method in Enterprise bean’s class, these methods must have the same name, argument and return type as Remote interface methods, and they have to throw the same exceptions.

The Enterprise bean’s Home interface in Entity bean must extend

java.ejb.EJBHome interface. Arguments types and return values types of every method

in this interface must be Java RMI types, and each method has to throw

java.rmi.RemoteException. According to [72] each of the methods in this interface

must be create or finder methods.

Each create method must have name “create” and must have matching ejbCreate method with the same arguments in Enterprise bean class. The return type of create method has to be the Enterprise bean’s remote interface. The exceptions that are thrown by ejbCreate method and by ejbPostCreate method have to be included in appropriate create method; it also has to throw javax.ejb.CreateException.

Every finder method has to be named “find<METHOD>” and must have matching

ejbFind<METHOD> (with the same arguments and thrown exceptions) in Enterprise

bean class. These methods have to return Enterprise beans Remote interface, or a collection.

Every Entity bean has two identification attributes, pair of these is unique and allows identifying object within its container, and these are the object’s home and primary key. To be a primary key a class has to implement java.io.Serializable interface. If client has access to Entity bean, he has also access to its primary key through getPrimaryKey () method. Entity bean has also method isIdentical (object) that allows comparing two Entity beans.

Entity bean is also transactional component on the contrary to Session bean that can be only transactional aware. Though Containers can handle persistent management, Entity bean can be implemented in two ways:

CMP (Container Managed Persistence) and

BMP (Bean Managed Persistence) - all mechanisms responsible for transformation bean state between Entity Bean and database is implemented for the bean “manually”.

6.2.3.1 BMP Entity bean

Bean manage persistence is more complicated then CMP, because whole persistence logic has to be written manually. In that approach, bean is implemented to cooperate only with a specific database type and structure. To use that type of persistence management following methods have to be implemented by bean provider:

91

public void setEntityContext(EntityContext ic) – this method is used by

container to pass EntityContext interface to bean instance (if this instance wants to use it at any time, it has to be stored in local instance variable)

public void unsetEntityContext(EntityContext ic) – this method is invoked by

Container before termination of the instance

public Object ejbCreate(…) - this method has to validate arguments given by

the client, create a record in database, initialize instances variable s and return primary key to created entity. This method does not has to be created if client do not have right to create persistent data.

public void ejbPostCreate(…) – for every ejbCreate(…) method is a matching

ejbPostCreateMethod(…)

public void ejbActivate() – this method is invoked when container assigns

instance of Entity bean to specific EJB object identity and it should acquire additional resources that are needed by the instance in the ready state.

public void ejbPassivate() – this method is invoked by container when before

disassociation of the instance from an EJB object identity and is used for releasing any resources that should not be held when the instance is in the pool.

public void ejbRemove() this method removes entity correlated an instance

from database and move instance to the pool. IT does not have to be implemented if client does not have right to delete persistent data.

public void ejbLoad() – this method refresh instance state by reading entity

state from database

public void ejbStore() – this method synchronize entity state in the database

with instance variables state (it works in the opposite direction to ejbLoad())

public primary key type or collection ejbFind<METHOD>(…) – this method

finds requested object or collection of objects in database using method’s arguments and returns a primary key or collection of primary keys to container

6.2.3.2 CMP Entity bean

In this case, all persistence management is handled by the Container. The Entity bean provider only has to provide containerManagedFields deployment descriptor property (the value of containerManagedFields property is a list of instance fields) to specify the list of fields whose persistence has to be managed by Container.

Because in this approach the responsibility for contact with database is moved to container, the goals of methods from javax.ejb.EntityBean interface, which can be implemented, are changed:

public void ejbCreate(…), public void ejbPostCreate(…) - the only task of

these methods is to initialize the container-managed fields. When Entity bean has

CMP its ejbCreate(…) methods have to return void.

public void ejbRemove() in this method all actions that have to be performed

before the entity representation is removed can be implemented.

public void ejbLoad() – this method is invoked by Container just after it loads

data from database

public void ejbStore() – this method is invoked by Container before data will

be stored in database

In Entity beans with CMP, bean provider does not implements any

ejbFind<METHOD>(…), but has to provide description of these methods (name and

arguments of these methods are not enough to generate method).

Because the primary key will be used by container, it has to fulfil following requirements stated in [72]:

The primary key type must be public

All fields in the primary key class must be declared as public

92

Primary key class must have a public default constructor

The names of the fields in the primary key class must be a subset of the names of the container-managed fields

6.2.4 Message-Driven Bean

Besides these two main types of Enterprise beans, since EJB 2.0 [73] is distinguished another one – Message-Driven Bean (MDB). MDB is not a normal bean, it is rather (according to [24]) abstraction API on top of Message Oriented Middleware

(MOM) systems. Message Driven Beans are used for receiving asynchronous information through the JMS (Java Messaging System) API, using MOM systems,

(MOM messages are published to, and retrieved from, a queue or channel), and perform some action when message is received.

According to [73] Message-Driven Bean is understood as message consumer. It means that MDB is not responsible for two direction asynchronous communication; it is only responsible for receiving messages and reaction on this messages. Because any other Enterprise Bean cannot communicate in an asynchronous way, in PSM presented in this paper MDB will be responsible for receiving messages and forwarding them to appropriate Enterprise Beans in a synchronous way (using appropriate method from remote interface).

The only way to communicate with MDB is an asynchronous communication, because of that it does not have neither a home nor a component interface. Because of that, the MDB instance is an instance of class that represents MDB.

Lack of external interfaces and a role of message listener played by MDB causes that MDB’s are transparent for client. As it is shown on [Figure 49], the client will send his message to specific destination or endpoint, not to specific MDB or MDB instance. MDB is also stateless, which allows to (as it is in case of stateless Session

Bean) use one Instance of MDB for many clients and switch instances used for one client. The difference between lack of state in Stateless Session Bean and in Message-

Driven Bean is that though MDB does not hold state for specific client, MDB instance can contain state between handling of client messages in form of open database connections and references to EJB objects.

Figure 49 - Client view of Message-Driven Bean Deployed in a Container [73]

MDB Requires implementation of three interfaces:

MessageDrivenBean Interface

MessageListener Interface

MessageDrivenContext Interface

MessageDrivenBean Interface contains two methods: setMessageDrivenContext and ejbRemove. The setMessageDrivenContext method is called by a Container to connect MDB instance with its context and it is used after creating new instance of

MDB. The ejbRemove method is called by a Container before an MDB instance is being removed.

93

The MessageListener Interface determines the kind of messaging type that will be supported by MDB. In PSM presented in this paper, the authors will use only JMS

MDB, which is also the first type of MDB used in EJB. To acquire JMS MDB,

Message-Driven Bean has to implement javax.jms.MessageListener. The most important method from this interface is onMessage, which is called when message is received and it contains business logic tide to this message. In PSM proposed in this paper the onMessage method will be called after receiving any message, than basing on information contained in this received message it will call specific method that will be responsible for forwarding input data included in the message to specific method in instance of specific Enterprise Bean.

The MessageDrivenContext Interface is used by MDB instance to access its context. This Interface contains following methods: setRollbackOnly, getRollbackOnly, getUserTransaction, getTimerService, getCallerPrincipal, isCallerInRole, getEJBHome, getEJBLocal.

In approach proposed in this paper, MDB context will be stored in a way that is not normally used in MDB – all references to remote interfaces will be stored in Entity

Beans and specific reference will be pointed out by information contained by incoming message.

MDB has also implement ejbCreate method with no input parameters. It cannot implement any other ejbCreate method.

6.3 Description of EJB UML profile

The UML provides a number of extension mechanisms that allows adapting it for specific usages. The EJB UML profile is defined using Stereotypes, Constraints and

Tagged Values and complete specification of this profile is described in [31]. In this chapter, the authors will introduce the subject that will allow understanding base meaning of PSM presented in this paper.

In EJB UML Profile, one can distinguish two models:

EJB Design Model

Java Design Model

6.3.1 Java Design Model

Java Design Model presents java concepts used in EJB, and creates base for many of EJB Model Elements. Java Model includes following elements:

Java Package

Java Single Type Import

Java Type Import On Demand

Java Class

Java Interface

Java Field

Java Method

6.3.1.1 Java Package

Java Package is represented by a UML Package with the same name, and hierarchy.

6.3.1.2 Type Imports

One can distinguish two types of type import in Java, which are single type import and type import on demand. The first one takes place when the whole type name is given during the implementation e.g. (import java.lang.String;), and the second means that one do not have to write a full name of type, but one can specify only a package name. Both of these import types are represented by UML Permissions stereotyped as

<<access>>. Client of this permission is a Java Class File that contains the declaration, and supplier is a Java Class or Interface (or Package in type import on demand).

94

6.3.1.3 Java Class

Java Class is represented by UML Class, and has to be directly or contained indirectly by Java Package. It uses two stereotypes, JavaStrictfb that indicates whether

Java Class is or is not FP-strict, and JavaStatic that is used to mark static classes.

6.3.1.4 Java Interface

It can be mapped to UML Interface or UML Class stereotyped as

<<JavaInterface>>. Like Java Class, Java Interface has to be contained by Java

Package. It also has Tag named JavaStatic used to mark static interfaces.

6.3.1.5 Java Field

Java Field in Java Design Model is represented by UML Attribute.

Besides standard UML Class attributes Java Field is described by three additional tags:

JavaVolatile is a Boolean value that is set on true if Java Field is volatile.

JavaDimensions is an integer that specifies the number of array dimensions declared by Java Field.

JavaCollection stores a name of Java Collection Type, which is used if

Java Field has complex multiplicity.

6.3.1.6 Java Method

Java Method can be declared within Java Class or Java Interface, and is mapped to

UML Operation. Java Method has following additional tags:

JavaNative – that has value true if Java Method is native

JavaThrows – that stores list of names of Java Exception Classes thrown by specific method

Java Method can also have JavaFinal and JavaDimensions Tagged Values used for in Parameters, which have the same meaning as those used in Java Field.

6.3.2 EJB Design Model

EJB Design Model is divided in two parts: Internal View and External View.

External View represents system from client perspective. It does not specify internal characteristics of Enterprise Bean and has fewer details in description of the rest of elements. In transformations, the authors use only Internal View of EJB Design Model.

6.3.2.1 EJB Method

The EJB Method specializes Java Method and it is represented by UML

Operation. EJB Method contained by EJB Home Interface is EJB Home Method and contained by EJB Remote Interface is EJB Remote Method (in the EJB Entity Bean it can also be EJB Finder Method).

UML Operation that represents EJB Method can have following stereotypes:

<<EJBCreateMethod>> - this stereotype is specialization of

<<EJBHomeInterfaceMethod>> and marks and operation that represents create method

<<EJBFinderMethod>> - this stereotype is specialization of

<<EJBHomeInterfaceMethod>> and marks and operation that represents find method

<<EJBRemoteMethod>> - this stereotype marks operation that represents

EJB Remote Method

6.3.2.2 EJB Remote Interface

The EJB Remote Interface specializes a Java Interface and it is represented by

UML Class stereotyped by <<EJBRemoteInterface>> stereotype. The EJB Remote

95

Interface is contained or imported by specification part of EJB Enterprise Bean

(represented by a UML Subsystem).

This class is (as supplier) in UML Usage dependency stereotyped by

<<instantiate>> stereotype with EJB Home Interface if the same bean. EJB Remote

Interface is also a supplier of the Abstraction stereotyped by <<EJBRealizeRemote>> for the EJB Implementation represented by the client.

6.3.2.3 EJB Home Interface

The EJB Home Interface specializes a Java Interface and it is represented by UML

Class stereotyped by <<EJBHomeInterface>> stereotype. The EJB Home Interface is contained or imported by specification of part of UML Subsystem that represents EJB

Enterprise Bean.

This class is a client in UML Usage stereotyped by <<instantiate>> stereotype, whose supplier is EJB Remote Interface of the same bean. EJB Home Interface is also a supplier of the Abstraction stereotyped <<EJBRealizeHome>> for the EJB

Implementation represented by the client.

6.3.2.3.1 EJB Session Home

The EJB Session Home specializes EJB Home Interface and it is stereotyped by

<<EJBSessionHomeInterface>>. This is home interface used by EJB Session Bean.

It has additional tag called EJBSessionType that marks if bean is stateful or stateless.

6.3.2.3.2 EJB Entity Home

The EJB Entity Home also specializes EJB Home Interface but it is used in EJB

Entity Bean. It is stereotyped by <<EJBEntityHomeInterface>>.

This class is a client in UML Usage dependency stereotyped by

<<EJBPrimaryKey>>, whose supplier is EJB Primary Key of the same EJB Entity

Bean.

6.3.2.4 EJB Implementation Class

The EJB Implementation Class specializes Java Class and it is stereotyped by

<<EJBImplementation>> stereotype. EJB Implementation Class is contained or imported by realization part of UML Subsystem that represents EJB Enterprise Bean.

EJB implementation Class is a client in two UML Abstractions, one stereotyped by <<EJBRealizeRemote>> stereotype with EJB Remote Interface and second stereotyped by <<EJBRealizeHome>> stereotype with EJB Home Interface as supplier.

6.3.2.5 EJB Enterprise Bean

EJB Enterprise Bean is represented by a UML Subsystem stereotyped as

<<EJBEnterpriseBean>>. This subsystem has to contain EJB Remote Interface and

EJB Home Interface in specification part and EJB Implementation in realization part.

It can also contain Java Classes or Interfaces.

EJB Enterprise Bean has five additional Tagged Values:

EJBEnvEntries

EJBNameInJAR

EJBReferences

EJBResources

EJBSecurityRoles

EJBEnvEntries can have zero or more values. This list represents environment entries of EJB Enterprise Bean. Each position on this list is a tuple that contains name, type and value of one of environment entries.

96

EJBReferences tag represents a list of other EJB Enterprise Beans that are referenced by this EJB Enterprise Bean. Each position on this list is a tuple that contains name of the referenced EJB Enterprise Bean, type of this EJB Enterprise

Bean (Entity or Session) and names of EJB Home Interface and EJB Remote Interface from this EJB Enterprise Bean.

EJBResources tag contains list of resource factories used by the EJB Enterprise

Bean. Each position on this list is a tuple that is comprised of three fields:

Name – name of the resource

Type – defines a name of Java Class or Interface

Auth – specifies if the source of resources is an Application or a Container

EJBResources tag is a comma-delimited list of tuples, designating the role names that may invoke all operations on the EJB Enterprise Bean, of the form <name, link>.

Link – if specified, must be one of the security roles defined in the security role element of the deployment descriptor.

6.3.2.5.1 EJB Session Bean

EJB Session Bean specializes EJB Enterprise Bean and it is stereotyped by

<<EJBSessionBean>>. In lieu of EJB Home Interface EJB Session Bean has EJB

Session Home.

It also has additional Tagged Value – EJBTransType that indicates if the EJB

Session Bean is Bean or Container managed.

6.3.2.5.2 EJB Entity Bean

EJB Entity Bean specializes EJB Enterprise Bean and it is stereotyped by

<<EJBEntityBean>>. Instead, EJB Home Interface EJB Entity Bean uses EJB Entity

Home.

EJB Entity Bean has two additional tags:

EJBPersistanceType

EJBReentrant

EJBPErsistanceType is tag responsible for indicating whether EJB Entity Bean uses Bean or Container managed persistence. If EJB Entity Bean has container managed persistence, all Java Fields that have to be container managed are stereotyped by <<EJBCmpField>>.

EJBReentrant has a Boolean type and value true means that EJB Entity Bean can be called reentrantly.

The primary key in Entity bean can be specified in two ways. One way is creating internal EJB Primary Key Class that specifies a set of fields that create primary key and operations that can be invoked on them. The second is used, when only one attribute from implementation class is going to play a role of primary key. To mark this attribute one can use <<EJBPrimaryKeyField>> stereotype. If EJB Entity Bean has container managed persistence, then primary key is always only one attribute. This attribute has to have type Class, but it cannot be Java Class, java.lang.Object.

6.3.2.6 EJB Primary Key Class

The EJB Primary Key extends Java Class, it is used in EJB Entity Bean and it is contained or imported by specification part of UML Subsystem that represents this

EJB Entity Bean.

This class is a supplier in UML Usage dependency stereotyped by

<<EJBPrimaryKey>>, whose client is EJB Entity Home Interface of the same EJB

Entity Bean.

6.3.3 Message-Driven Bean

PSM used in this paper is an UML profile for EJB 1.0. Because specification of

MDB is included since specification of EJB 2.0 it is not included in this UML profile.

97

To provide handling of asynchronous communication, that is possible on EDOC and is not specified in EJB 1.0, the concept of MDB will be added to UML profile of EJB

1.0. This specification of MDB will describe transformation of concepts that are used to specify MDB, description of included stereotypes, tagged values and constraints.

This specification will not cover every concept of MDB, but only elements used in the transformations described in this thesis.

6.3.3.1 Transformation

The Message-Driven Bean is represented by the UML Class and it extends specification of EJB Enterprise Bean. The name of MDB is described by property.

Name and transactional type of MDB is described by EJBTransType tag.

6.3.3.2 Stereotypes

<<EJBMessageDrivenBean>> - indicates that the UML Class represents an EJB

Message Driven Bean. Specializes <<EJBEnterpriseBean>>

6.3.3.3 Tagged Values

EJBTransType – Value: Bean or Container. Indicates, whether transactions of the

EJB Message-Driven Bean are managed by the EJB Message-Driven Bean or by its container.

6.3.3.4 Constraints

These Constraints base on [73] and apply to a UML Class that represents

Message-Driven Bean:

the Class has to realize element that represents JavaInterface, javax.ejb.MessageDrivenBean.

the Class has to realize element that represents JavaInterface, javax.jms.MessageListener

the Class must have visibility property set on public and cannot be

abstract and final.

the Class can be directly contained only by JavaPackage

the Class can not contain finalize operation

the Class must contain operation named ejbCreate that realize following constraints: o

the visibility property has to be set on public o

the Operation has to be final and static, have isLeaf property set on false and ownerScope property set on Instance o

the return Parameter type of this Operation has to be Java Special

Type void o

the Operation can not have any in Parameters o

the JavaThrows tag can not contain any values

the Class can contain only one Operation named ejbCreate

the Class must have exactly one Operation named ejbRemove, and this

Operation has to fulfil following requirements: o

the visibility property has to be set on public o

the Operation has to be final and static, have isLeaf property set on false and ownerScope property set on Instance o

the return Parameter type of this Operation has to be Java Special

Type void o

the Operation can not have any in Parameters o

the JavaThrows tag can not contain any values

every Operation that has the same name and return and in Parameters as one of Operations contained by JavaInterface -

98

javax.jms.MessageListener, has to be final and static, have isLeaf property set on false and ownerScope property set on Instance

6.3.4 Example

Figure 50 presents a simple stateless EJBSessionBean named Buyer. The

EJBSessionBean has one remote method – sendOrder, and one static method – create.

It is container-managed bean, and it has no environmental entrie s, or any inner Java classes.

Figure 50 – Example of stateless EJBSessionBean

99

7 T

RANSFORMATIONS

EDOC-EJB

7.1 Introduction

This chapter presents the specification of the transformations from the EDOC model, in particular the CCA part, to the EJB platform. However, before the transformation specification is made itself, the description of transformation language has to be developed, which is used in specification process. It is also the content of this chapter.

The attempts to make specification of transformation from the EDOC are made in the following papers [11] [10] [56] [60]. In most cases, the target platforms of this specification are other that the EJB, thereby only some ideas about particular transformation are used in the following specification. The article [56] as only one from enlisted, presents some ideas about transformations between the EDOC and EJB, however these suggestions are made in case of the simple transformations, like transformation of elements of DocumentModel. Nevertheless, there is lack of any specification or even the more concrete ideas of providing the transformation specifications in case of more complex problems, like transformation of composition for instance. That is why the authors of the thesis in many cases have to develop their own specification and ideas.

The rest part of the chapter is organized as follows. In the first place, the specification of the transformation language is made. After that part, the overview on specifications and specifications of the transformations are put, and finally the OCL functions used within the transformations are written.

7.2 Description of transformation specification

The approach used to specify the transformations is presented in this section of the thesis. The approach used in the thesis is developed using concepts presented in papers

[79], [32], and [14].

7.2.1 Description of transformation intention

The first part of description of transformations is presentation of transformation’s intention. This part present what transformation has to do and why it is needed. It also spells requirements against the transformation that are used farther for transformation verification.

7.2.2 Formal specification of transformation

Next step in transformation description is a formal specification [79]. The idea that is beneath the way of transformation specification is to distinguish two main parts in the specification, following the proposition of [79], i.e. declarative and imperative part of the language.

The declarative part describes the prerequisites put on parameters of transformation and queries on models’ elements given within transformation’s parameters. Finally , the imperative body of transformation is given.

7.2.2.1 Prerequisites

The concept of prerequisites of declarative part is derived from the way of transformation specification presented in paper [79] and [14]. It is taken from contractual approach of specification, in which two types of condition exist, first describes what constraints are put on the operation parameters, and second presents how results of operation should look like. In the approach the prerequisites are

100

described in the declarative manner, however there are no post constraints given declaratively. The transformation specification is represented directly in the algorithmic manner, which, authors belie ve, is less cumbersome than post-condition, proposed in the papers [79], [14], made in a declarative manner.

7.2.2.2 Query

The idea of query part in the transformation specification is often mentioned in many proposals presents, for instance, in response for OMG’s QVT proposal but not only, see [52], [26] and [28]. This section of specification is intended to contain description of actions that examine transformed models in order to create collections of information or values of other types that are used in next step of transformation.

The declarative part of the specification, in particular the query part, in the thesis is made in OCL language. The OCL language, in this thesis the subset of the OCL language, is used to selection and filtering of model information, since OCL gives an ability of traversing over the structure of model [79] and provides mechanism for elements collection, selection and filtering [55], [85]. This solution is used in many approaches or it is proposed in many attempts to transformation specification, e.g.

[79], [29], [34, c.9.3], [60]. Moreover, the OCL language was chosen because it fulfils of the requirements presented in OMG’s Request For Proposal (RFP) document [52].

The OCL provides facilitates to prepare ad-hoc queries for, already mentioned, selection and filtering of model elements, and further it is used as well as for the selection of model elements which become source, collection of model elements that is an input of a particular transformation.

However, the OCL specification is not executable [79], and in transformation approach presented in the thesis, an implementation of OCL interpreter is not provided. The OCL language is only used in the thesis , in similar way to the concept presented in paper [14], only for specification purposes, i.e. it leaves the concrete implementation of OCL’s parts of transformation open. In particular, because of the tool presented in the thesis, some constructions of OCL language were implemented in

Java, in order to make process of translation of OCL’s formula to Java an more straightforward to do.

7.2.2.3 Body

The last part of specification is a description of transformation algorithm’s steps

[62] [83] [26], called body. In particular, it presents in imperative manner, how to process the elements sent to transformation and gathered during the query process, in order to fulfil the requirements stated against the executed transformation. In the result, the new model element is created, or the elements given as parameters are updated. However, the declarative description of that part of transformation is also proposed [79], [32], however this causes few problems. Firstly, not all kind of declarative formulas might be translated automatically to imperative way. Secondly, the declarative language, has low performance, as the experiments of the authors of the paper show [27], since often, the approaches used for execution of declarative languages are not efficient. Thus, in order to avoid these disadvantages, this part of specification, used in the thesis, is written in an imperative language and is implemented in the Java language.

The language used in thesis, is a solution that combines the elements of Java and

UML language. Main changes are in names of the class that represent the model elements. In the specification, they are expressed in terms of UML meta-model’s meta-classes [55], which may the specification more readable [83].

7.2.2.4 The specification language

The specification of the transformation specification language is made in the following part of the paper.

101

7.2.2.4.1 Data types

Data types used in the transformation approach are divided into two groups. The first group is formed by the set of references to meta-classes of the UML meta-model

[55], second are predefined data types.

The set of data types contains (type in the query part – type in the body part or the transformation’s header):

Booleanboolean – represents a concept of the Boolean type of value, which can hold true or false values. This type of variable is stored by value.

Integerint – represents the mathematical concept of integer. This type of variable is stored by value.

Realdouble – represents the mathematical concept of real. This type of variable is stored by value.

SequenceList – is a collection where the elements are ordered. An element may be part of a sequence more than once. This type of variable is stored by reference. The operations allowed within the query part of the specification are the same as defined in the OCL specification [55]. The operations allowed in the body part are identical to these specified as operations of java.util.List interface described in the [76].

StringString – represents strings consisting of characters. This type of variable is stored by reference. The operations allowed within the query part of the specification are the same as defined in the OCL specification

[55]. The operations allowed in the body part are identical to these specified as operations of java.lang.String class described in the [76]. In addition, a String constant in the pre and query part of the specification are defined as in the following example: ‘stringConstant’. In difference, a

String constant within the body part of the specification is defined as in the

following example: “stringConstant2”.

The set of meta-classes available in the specification is equal to set of metaclasses, with meta-attributes attached to them, defined in the meta-model of the UML

[55]. Examples of the meta-classes:

Foundation::Core::Class – is a description of a set of objects that share the same attributes, operations, etc.

Foundation::Core::Attribute – is a named variable within a classifier that describes a range of values that instances of the classifier may hold.

Foundation::Core::Operation – is a service that can be requested from an object to effect behaviour.

Model Management::Package – is a grouping of model elements.

In this paper, authors are not presenting meta-classes of the meta -model; all details are in the specification [55].

The references to instances of meta-class, or references to data types, or variables by value of some data type are defined in two-fold way, different for the query part of the specification and the body part of the specification.

Definition of variables in the query part is made using the let instruction Figure 51, following the OCL [55] schema .

let refType1 : pack1::pack2::MetaClassName = expression1

let type2Var : datatype = expression2 in

Figure 51 - Variables definition within the query part of the specification

102

Variable definitions in the body part of the specification, Figure 52, are made following the syntactic rules of Java language [81]. pack1::pack2::MetaClassName refType1= expression1; datatype type2Var = expression2;

Figure 52 - Variables definition within the body part of the specification

7.2.2.4.2 Transformation

The specification of transformation consists of four elements, a transformation header, a transformation’s prerequisites block, a queries block, and a body block

Figure 53. ret_type header(DataType1 param1,…){

pre:

query:

body:

}

Figure 53 - The transformation specification schema

The header consists of:

Type of a transformation result, i.e. only a type from set of meta-classes of the UML meta-model. If the transformation does not generate any result, e.g., it is update in-place transformation no result type is given.

A name of the transformation.

Formal parameters, in form of list. The types of formal parameters might be meta-classes of the UML meta-model, or data type from list of data types available in the specification approach. The value of formal parameters, i.e. actual parameters, is stored by reference, in case of metaclasses, or data types held by reference, or by value, in case of other variables.

Example of a header is presented below Figure 54. In this case, one has a declaration of a transformation named transName, which return reference to instance of some meta-class Pack1::mclass1. There are three formal parameters of the transformation. The first parameter’s name is refVar1 and it is a reference to some meta-class Pack1::mclass2. The last two parameters are named respectively refVar2,

varVal1 and they are values, or references to values of DataType1, DataType2 data

types.

Pack1::mclass1 transName (Pack1::mclass2 refVar1, DataType1 refVar2, DataType2 varVal1)

Figure 54 - An example header of a transformation specification

The prerequisites of the transformation are expressed within the pre block of the specification. The aim of this part is to deliver a condition, which has to be fulfilled in order to execute the query, and the body part of the transformation. Strictly, a logical expression is evaluated to true or false value. If the value is false, the transformation cannot be executed.

Specification of this part of the transformation is made using constructs of the

OCL [55], [85]. To make constraints’ specification one can use values of variables that are actual parameters of the transformation. Example of the pre block is shown below

Figure 56. In this example, the restriction is put on the instance of meta-class

103

Pack1::mclass2. In more details, for all elements, represented by elem, aggregated by

the aggregAttr meta-association value of meta-attribute attr1 has to be ‘val1’.

Pack1::mclass1 transName (Pack1::mclass2 refVar1){

pre:

-- example pre block

refVar1.aggregAttr->forAll(elem|elem.attr1=’val1’)

}

Figure 55 - Example of the pre block of the transformation specification

The query of the transformation is expressed within the query block of the specification. The aim of this block of specification is to deliver additional information required during execution of the body block. The information is delivered in form of values, or references to values that are created and elaborated while the query block is performed. Variables are created using the let instruction of the OCL. The variables might be used within the body block, taking into consideration that within the body block, these values are used with respect to the restriction on the types that corresponds to them among the body block, e.g. the Sequence variable used within the

query block corresponds to List variable used within the body block, etc.

To set the value of variable one can use an expression constructed within the OCL.

In particular, one can use functions attached to a particular type, or can define own

OCL functions that are used within this data type.

On Figure 56, example of the query block is presented. In particular, two variables are set, sequence1, which is a sequence of elements that are subset of elements associated by aggreg1, and bool1, which is a Boolean variable .

In addition, the example OCL function myOwnFun(), which is used to compute

bool1 value, is provided below the transformation specification. The function is

defined in the contract-based manner, i.e. by stating pre and post conditions.

One can used defined OCL functions within both the query and the body block of the transformation specification.

Pack1::mclass1 transName (Pack1::mclass2 refVar1, List list){

… query:

-- example query block

-- new Sequence variable

let sequence1 : Sequence = refVar1.aggreg1

->select(elem|elem.attr1=’val1’)

-- new Boolean variable

let bool1 : Boolean = list->exists(elem:Pack1::mclass2|elem.attr2<>0) and refVar1

->myOwnFun()

}

-- example OCL function used within the transName specification

-- of transformation

context Pack1::mclass2::myOwnFun() : Boolean

pre:

post: true

result = self.aggreg1->size()>0

Figure 56 - Example of the query block of the transformation specification

104

The imperative part of the transformation specification is provided in the body block of the transformation specification. Within this block a transformation actions are specified using instruction from a set of Java language instructions [81].

On the example Figure 57, basic statements used in the specification of the body part are presented.

In particular, one is able to define a new variable, as it is made in the example.

Instances of complex types as List, String, or instances of the meta-classes are created by the operator new. The syntactic of the operator is identical with this presented in

Java specification [75] [15], with the difference that the type of created object is one of types defined within the specification language approach.

The values of the newly created instances of the List and String types are respectively, an list that size is 0, and an empty string, i.e. “”.

The following rules are used in case of newly created instances of the metaclasses.

Values of a meta-attribute are not created if the meta-attribute’s lower multiplicity is zero, or is null if the upper multiplicity is equal to one. In case, the lower multiplicity equals to one or more, it is not defined whether instances of the metaattribute are created.

The meta-attribute that upper multiplicity is equal to one is accessed as a value of a class’ attribute defined within Java language.

The meta-attribute that upper multiplicity is more than one is represented as a collection of the meta-class’ or types’ instances. It is accessed through methods of the

List type.

Instances of a meta-association, meta-links, are not created if a lower multiplicity of an association end of the meta-association, from the side of the instance, is zero. In case, the lower multiplicity, of the same association end, equals to one or more, it is not defined whether instances of the meta-association are created.

The meta-association, which an upper multiplicity of an association end from the side of the instance, is equal to one is treated as a meta-attribute of a meta-class’ type.

Thereby, it is accessed as a value of a class’ attribute defined within Java language. It has the null value.

If the upper multiplic ity of the meta-association, from the side of the instance, is more than one is treated as a collection of the meta-class’ instances. Thereby, it is accessed through methods of the List type. Proper examples are presented on Figure

57.

The language allows for navigation through the UML meta-associations, metaattributes, and meta-class to the way as it is made in the OCL, i.e. by dot-expressions.

The difference is in case of the meta-associations and meta-attributes, that upper multiplicity is more than one, in this situation the particular values of metaassociations and meta-attributes are accessed by the methods of the List type Figure

57.

The language allows for calling other transformations or OCL functions defined by the user. The call of the transformation or the OCL function is made identically as in the Java language.

The basic flow-steering instructions are available , as if and for instruction. The syntax and semantic of these instruction is identical to Java’s equivalents [75] [15].

The return statement indicates end of execution of the transformation body, and in case of transformation with the result, points an instance of the meta-class that is returned by the transformation.

105

}

Pack1::mclass1 transName (Pack1::mclass2 refVar1, List list){

query:

let sequence1…

body:

// example of body block

// new String with initial value

String value1=”val1”;

// new int variable

int intVal10=10;

// new List variable

List list1 = new List();

// definiton of the reference value

// to an instance of the meta-model class

// Pack1::mclass1 and creation of an instance

Pack1::mclass1 refVar2 = new Pack1::mclass1(); refVar2.name=”theClass”;

Pack1::mclass2 refVar3 = new Pack1::mclass2();

// setting the values of the refVar3’s meta-attributes revVar3.attr1=value1; revVar3.attr2=””;

// example of making new meta-association to

// meta-class’ instance referenced by refVar1

revVar3.aggreg1.add(refVar1);

// example of if-statement and OCL function

// call

if(refVar1.myOwnFun()){

}

else{

} list1.add(refVar3); list1.add(refVar1);

// example of for instruction

for(int i=0;i<list.size();i++)

if(list.get(i).attr2>intVal10) list1.add(list.get(i));

// example of making new meta-associations to

// meta-class’ instances referenced by values

// contained by list1

refVar2.aggreg1.addAll(list1);

// and return instruction

return refVar2;

context Pack1::mclass2::myOwnFun() : Boolean …

Figure 57 - Example of the body block of the transformation specification

7.3 Overview of the transformation specifications

“EDOC to EJB transformation”, as presented on Figure 58, is a main transformation that takes PIM and transforms it to PSM. The transformation process is carried out in three stages:

Transformation of Document Model

Transformation of Systems’ structure to Transitional Model

Final transformation of structure

106

Figure 58 - Top-down structure of EDOC to EJB Transformations

107

7.3.1 Transformation of Document Model

The transformation of Document Model called “Document Model to Java Class” translates data types specified in EDOC to appropriate Java classes or Java simple types. EDOC specification separates specification of data types from specification of the rest of the system, which allows to generate all data types before the rest of the system and to use them during the final transformation of system’s structure.

“Document Model to Java Class” transformation uses following component transformations:

“Generate Data Invariant Interface”

“Generate External Document Interface”

“Enumeration to JavaClass”

“Generate Generalization Hierarchy”

“ExternalDocument to JavaClass”

“CompositeData to JavaClass”

“Add Access JavaMethods”

“Generate Data Invariant Interface” transformation is responsible for creation of interface that will specify functions that are needed for data invariant checking.

“Generate Data Invariant Interface” transformation generates IExternalDocument

JavaClass, which is needed for acquiring an access to external documents.

“Enumeration to JavaClass” is responsible for transformation of all EDOC enumeration data types to Java classes.

“Generate Generalization Hierarchy” is responsible transformation of generalization hierarchy. It takes a list of Generalizable Elements and converts it in a way that will fulfil Java restrictions for generalization.

“ExternalDocument to JavaClass” transforms EDOC ExternalDocument to

JavaClasses

“CompositeData to JavaClass” transforms EDOC CompositeData to JavaClass.

“Add Access JavaMethods” is used to create access Java methods to attributes of given Java classes.

7.3.2 Transformation of Systems’ structure to Transitional Model

Transformation of Systems’ structure is performed by “Transformation of Input

Model to Transitional Model”. This transformation is used to acquire knowledge of how will the result system look like. It does not transform particular elements of the system; it rather presents its structure using beans and inner classes, without any details about specific system elements. The main transformation creates structure of

Java Beans and uses “Transform Contained ProcessComponents to

TransitionalModel” transformation to acquire inner Java classes of every Bean. These transformations do not create output model, they are used only to generate transitional model that will be used for final transformation called “ProcessComponents transformation”.

7.3.3 Final transformation of structure

The output model of the system is acquired in two stages, the first one is transformation of data types, which in EDOC is separate from the structure of the system, and the second one is the systems’ structure itself. Systems structure in general is acquired in “Transformation of Input Model to Transitional Model”, but final transformation that generates full structure description in UML profile for EJB is performed by "Process Components transformation”. This transformation uses information acquired by “Document Model to Java Class” and by “Transformation of

Input Model to Transitional Model”. As general structure of the system is known this transformation creates particular elements of the system and connects them in the structure acquired earlier. Three additional transformations that are used in this process are distinguished.

108

“Creation of Message-Driven Bean” is responsible for creation of Message-Driven

Bean. This transformation is performed, when asynchronous communication is used in the system.

“Creation of Entity Bean for Message-Driven Bean”, as “Creation of Message-

Driven Bean”, is used during asynchronous communication, and provides references to

Enterprise Beans remote interfaces for Message-Driven Bean.

“Transformation of ProcessComponent” is the transformation that is responsible for mapping of single ProcessComponent from PIM to Java class or Enterprise Bean.

It uses several transformations for mapping of specific elements that describe

ProcessComponent:

“Transformation of MultiPorts”

“Transformation of FlowPorts”

“Transformation of ProtocolPorts”

“Transformation of Interfaces”

“Transformation of PropertyDefinitions”

“Transformation of OperationPorts”

“Transformation of Protocols”

Each one of these transformations is used for mapping of specific EDOC element, e.g. “Transformation of MultiPorts” is responsible for mapping MultiPorts, and

“Transformation of OperationPorts” is responsible for mapping OperationPorts.

7.4 Specifications

This part of the chapter presents the specifications of the transformation from the

EDOC to EJB platform. Following four groups are distinguished, i.e.: Composition

Transformations, Component Transformations, Model Document Transformations and

Behavioural Transformations. The Behavioural transformations are out of the scope of the authors’ investigation.

The rest of the transformations are presented below.

7.4.1 Composition transformations

This group of transformation is responsible for EDOC to EJB structure transition.

7.4.1.1 Transformation of Input Model to Transitional Model

The aim of this transformation is to create the transitional model during the EDOC

– EJB transformation process. The transitional model represents the structure of a system that is expressed by two types of model elements: UML Subsystems and UML

Classes. Subsystem and Class represent ProcessComponents from the CCA specification. A Subsystem is a representation of the ProcessComponent if the one is going to be transformed to the EJBSessionBean. A Class is a representation of the

ProcessComponents that are going to be transformed to internal JavaClasses.

Every ProcessComponent that is used directly in CommunityProcess or is used in several ProcessComponents that will be transformed to EJBSessionBeans is going to be transformed to EJBSessionBean; otherwise, it will be transformed to inner Class.

The transitional model also stores information about containing of internal

JavaClasses by EJBSessionBeans, which corresponds, in particular cases, to containing of ComponentUsages by one ProcessComponent, however it is possible to use one

ProcessComponent by several other ProcessComponents. In this case such

ProcessComponent is transformed to EJBSessionBean as state alone one. In the

transitional model, the internal JavaClasses are always contained and used by one of the EJBSessionBeans.

The third type of element used in this model is Dependency stereotyped

<<MTrace>>; it is used to mark relation between elements from result model and

ProcessComponents from input model from which the result model’s elements are

109

generated. Dependency takes as client element from transitional model and as supplier proper element (ProcessComponent) from EDOC model.

If ProcessComponent uses directly any other ProcessComponent (it contains

ComponentUsage of this ProcessComponent) it is marked in the Transitional model by

Dependency stereotyped <<Use>>, which points to contained ProcessComponent.

Figure 59 - Input and result of transformation from EDOC model to Transitional model

CreateTransitionalModelTransf takes three input parameters:

mainPack – this is a reference to main project package (this package will hold result of transformation)

structPack – this is a reference to package that contains EDOC Structural

Specification.

composition – this is a reference to EDOC Composition

The transformation acquires also list of every ProcessComponent that will be transformed to EJBSessionBean. After that it creates a transitional model Subsystems for every of those ProcessComponents. When all Subsystems are created, it sets for them inter bean usages. This shows, for every Subsystem, which EJBSessionBeans it will use. After that, for every Subsystem separately, it transforms ProcessComponents to inner JavaClasses using transfContainedPCsToTransitionModel.

7.4.1.1.1 Specification

Model_Management::Package createTransitionalModelTransf

(Model_Management::Package mainPack, Model_Management::Package structPack, Foundation::Core::ModelElement composition){

pre: structPack.stereotype->exists(name=’EDOCStructure’) and composition.stereotype->exists(name=’Composition’)

query:

let beanProcCompCol:Sequence = processComponentPackage->getProcessComponentsToSessionBeans(composition)

in

body:

List beanSubs = createBeanSubs(beanProcCompCol);

Model_Management::Package trensModPackage =

new Model_Management::Package();

SetInterBeanUsages(beanSubs,beanProcCompCol);

for(int i=0;i < beans.size();i++){

Model_Management::Subsystem bean = beanSubs.get(i);

110

}

}

ModelElement beanProcComp =

getSuppOfMTrace((ModelElement)beanSubs.get(i)); transfContainedPCsToTransitionModel( bean,beanProcComp,beanProcCompCol, new List()); transModPackage.ownedElement.add(bean); transModPackage.name="TransitionalModelPackage"; mainPack.addElement(transModPackage);

return transModPackage;

7.4.1.2 Transform Contained ProcessComponents to Transitional Model

This transformation is responsible for finding ProcessComponents that are used by

ProcessComponent transformed to UML Subsystem referenced by bean parameter.

This transformation is used by CreateTransitionalModelTransf when all future

EJBSessionBeans are marked in Transitional Model, but none of inner Classes has

been marked yet.

transfContainedPCsToTransitionModel transformation requires four input

parameters:

bean – this is a reference to Subsystem that will contain all created Classes

element – this is a reference to ProcessComponent for which transformation will look for and transform directly contained

ProcessComponents

beanPC – this is a list that contains all ProcessComponents that will be transformed to EJBSessionBeans

innerClasses – this list contains ProcessComponents that have already been transformed to bean’s inner Classes.

The transformation takes all ProcessComponents which usages are contained by

ProcessComponent pointed out by bean. If contained ProcessComponent has been

marked in Transitional Model as Subsystem, then this transformation will only set a

Dependency stereotyped by <<Use>>. Otherwise, it will transform

ProcessComponent to UML Class, add it to bean’s ownedElements, set <<Use>>

Dependency and transform ProcessComponents that usages are contained by the

transformed ProcessComponent, and are not transformed yet.

7.4.1.2.1 Specification transfContainedPCsToTransitionModel(

Foundation::Model Management::Subsystem bean,

Foundation::Core::ModelElement element,

List beanPC, List innerClasses){

pre: bean->getSuppOfMTrace().

query:

body: stereotype->exists(name=’ProcessComponent’) and element.stereotype->exists(name=’ProcessComponent’) and beanPC->forAll(elem|elem.stereotype-> exists(name=’ProcessComponent’)

List subPC = getComponentsUsedBy(element);

Foundation::Core::ModelElement procComp,elem, beanClient, beanSuplier;

Foundation::Core::ModelClass newClass;

for(int i=0; i<subPC.size();i++){ procComp = subPC.get(i);

if(beanPC.contains(procComp)){

if(innerClasses.contains(procComp)){ newClass = procComp.getClientOfMTrace();

111

}

}

}else{ innerClasses.add(procComp); newClass = new Foundation::Core::ModelClass(); newClass.name= getPCFullName(procComp,mainPackage); newClass.setMTrace(procComp); bean.ownedElement.add(newClass);

} elem = element.getClientOfMTrace(); elem.setUsage(newClass);

if(!innerClasses.contains(procComp)){ transfContainedPCsToTransitionModel

}

(bean,procComp,beanPC,innerClasses);

}else{ beanClient = element.getClientOfMTrace(); beanSuplier = procComp.getClientOfMTrace(); beanClient.setUsage(beanSuplier);

}

7.4.2 Component transformations

This group of transformation is responsible for transformation elements of the

EDOC structure into elements of EJB structure.

7.4.2.1 Transformation of FlowPorts

This transformation is responsible for transformation of FlowPort to JavaMethod

(represented by UML Operation). One can distinguish four types of FlowPorts:

Synchronous and Initiate

Synchronous and Respond

Asynchronous and Initiate

Asynchronous and Respond

The first type of FlowPort is used only to signalize a method call and is not transformed.

The rest of FlowPort types are always transformed to some kind of method.

Synchronous FlowPort will be transformed to a public JavaMethod with one input parameter that reflects data associated with the FlowPort and return void type.

Asynchronous FlowPorts will be transformed to private methods. The Initiates asynchronous FlowPort will be transformed to send JavaMethod that will be responsible for sending a message in an asynchronous way. The Responds asynchronous

FlowPort will be transformed to executeMessage, with

javax.jms.Message as input type, JavaMeth od that will be responsible for carrying out

the message received from onMessage() method.

The transformation creates JavaMethods for specific destinations, which are

ImplementationClass in EJBSessionBean, RemoteInterface in EJBSessionBean,

JavaClass or JavaInterfaces. For each of these locations it sets different property and

tag values.

The transformation has two input parameters:

flowport –references the FlowPort

destination –holds the JavaMethod destination name

7.4.2.1.1 Specification of transformation from FlowPort to Operation

Foundation::Core::Operation flowPortToOperation (Foundation::Core::Class flowPort, String destination){

pre:

retPort.stereotype.name = ‘FlowPort’ and( destination = ‘ImplementationClass’ or destination = ‘RemoteInterface’ or destination = ‘JavaClass’ or destination = ‘JavaInterface’)

112

query:

body:

Foundation::Data_Types::VisibilityKind.visibility;

String name; boolean isAbstract; boolean isStatic = false; boolean isFinal = false; boolean isNative = false; boolean isSynchronized = false;

Foundation::Core::Classifier type;

List exceptions;

Foundation::Core::Operation operation;

if(flowPort.isSynchronous()){

if(flowPort.isResponds()){ name = "sf"+flowPort.name.substring(0, 1).toUpperCase()+ flowPort.name.substring(1); visibility = Foundation::Data_Types::VisibilityKind.public;

if(destination = "JavaInterface"){ isAbstract = true;

}else{ isAbstract = false;

} type = getModel().getModelElement("void"); exceptions = new List();

if(destination = "JavaInterface"){

} exceptions.add("java.lang.Exception");

if(destination = "ImplementationClass"

|| destination = "RemoteInterface"){

} exceptions.add("java.rmi.RemoteException"); operation = createJavaMethod(name, visibility, isAbstract, isStatic, isFinal, isNative, isSynchronized, type, exceptions); operation.query = false;

if(destination = "ImplementationClass"

|| destination = "RemoteInterface"){ operation.concurency =

Foundation::Data_Type::CallConcurencyKind.sequential;

}

if(flowPort.isTransactional()){ operation.setEJBTransAttribute("Supports");

}else{

} operation.setEJBTransAttribute("Not Supported");

if(destination = "RemoteInterface"){ operation.addStereotypeByString("EJBRemoteMethod");

}

Foundation::Core::Parameter arg =

new Foundation::Core::Parameter(); arg.name = "arg"; type = flowPort.getFlowTypeValue().getDataElementJavaClass(); arg.type = type; arg.kind = Foundation::Data_Types::ParameterDirectionKind.in; arg.setJavaFinalTaggedValue("false");

} operation.ownedElement.add(arg);

}else{

if(flowPort.isResponds()){ name = "executeMessage" + flowPort.name.substring(0, 1)

.toUpperCase() + flowPort.name.substring(1);

if(destination = "JavaClass"){ visibility=

}else{

Foundation::Data_Types::VisibilityKind.public; visibility=

}

Foundation::Data_Types::VisibilityKind.private; isAbstract = false; type = getModel().getModelElement("void"); exceptions = new List();

113

}

if(destination = "ImplementationClass"){ exceptions.add("java.rmi.RemoteException");

} operation = createJavaMethod(name, visibility, isAbstract, isStatic, isFinal, isNative, isSynchronized, type, exceptions); operation.query = false;

if(destination = "ImplementationClass"){ operation.concurency =

Foundation::Data_Types::CallConcurencyKind.sequential;

if(flowPort.isTransactional()){ operation.setEJBTransAttribute("Supports");

}else{ operation.setEJBTransAttribute("Not Supported");

}

}

Foundation::Core::Parameter arg =

new Foundation::Core::Parameter(); arg.name = "executeMessage"; type = getModel().getModelElement("javax::jms::Message"); arg.type = type; arg.kind = Foundation::Data_Types::ParameterDirectionKind.in; arg.setJavaFinalTaggedValue("false"); operation.ownedElement.add(arg);

}else{ name = "send" + flowPort.name.substring(0, 1).toUpperCase() + flowPort.name.substring(1); visibility = Foundation::Data_Types::VisibilityKind.private; isAbstract = false; type = getModel().getModelElement("void"); exceptions = new List();

if (destination = “ImplementationClass”) { exceptions.add("java.rmi.RemoteException");

} operation = createJavaMethod(name, visibility, isAbstract,

} isStatic, isFinal, isNative, isSynchronized, type, exceptions); operation.query = false;

if (destination = "ImplementationClass") { operation.concurency =

Foundation::Data_Types::CallConcurencyKind.SEQUNTIAL;

if (flowPort.isTransactional()) { operation.setEJBTransAttribute("Supports");

}else {

} operation.setEJBTransAttribute("Not Supported");

Foundation::Core::Parameter arg =

new Foundation::Core::Parameter(); arg.name = "message"; type = flowPort.getFlowTypeValue().getDataElementJavaClass(); arg.kind = Foundation::Data_Types::ParameterDirectionKind.in; arg.setJavaFinalTaggedValue("false"); operation.ownedElement.add(arg);

}

return operation;

7.4.2.2 Transformation of OperationPorts

As OperationPort can be represented by UML Class or UML Operation there are two transformations specific for each of them.

The operationPortToOperation for UML Class takes OperationPort and creates from it a public JavaMethod. Input parameter in the JavaMethod has type that reflects data associated with the Initiates FlowPort contained by the UML Class. The return type in the JavaMethod reflects type associated by Respond FlowPort with

114

postCondition TaggedValue set on Success. Properties and TaggedValues of created

JavaMethod depend on the destination of this method.

Transformation for UML Class does not transform Initiate OperationPorts.

The transformation has following input parameters:

operationPort – references OperationPort

destination – specifies the destination of created JavaMethod

The OperationPort is represented by UML Operation in the EDOC Interface only, which is transformed to JavaInterface that is why it does not need destination parameter.

In this transformation, the JavaMethod that is created always fulfils constraints for

JavaMethod for JavaInterface; the properties that are not constrained by those

constraints remain the same. The input and return types are transformed to Java types.

7.4.2.2.1 Specification of transformation from Class OperationPort to Operation

Foundation::Core::Operation operationPortToOperation

(Foundation::Core::Class operationPort, String destination){

pre:

operationPort.stereotype.name = ‘OperationPort’ and operationPort->isResponds() and operationPort->isSynchronous() and

(destination = ‘ImplementationClass’ or destination = ‘RemoteInterface’ or destination = ‘JavaClass’)

in query:

let returnPort:Foundation::Core::Class = operationPort.ownedElements-> select(retPort:Foundation::Core::Class| retPort.stereotype.name =

‘FlowPort’ and retPort->isResponds() and retPort.taggedValues-> exists(taggedValue|taggedValue.type.name=’postCondition’ and taggedValue.dataValue->asSequence()->at(1)->oclAsType(String) =

‘Success’))->first()->oclAsType(Foundation::Core::Class)

let exceptionPorts:Collection = operationPort.ownedElements-> select(exceptionPort:Foundation::Core::Class| exceptionPort.stereotype.name = ‘FlowPort’ and exceptionPort-> isResponds() and not retPort. taggedValues->exists(taggedValue| taggedValue.type.name=’postCondition’ and taggedValue.dataValue-> asSequence()->first()->oclAsType(String) = ‘Success’))->first()-> oclAsType(Foundation::Core::Class)

let paramPort:Foundation::Core::Class = operationPort.ownedElements-> select(paramPort:Foundation::Core::Class| paramPort.stereotype.name = ‘FlowPort’ and not paramPort->

in body:

isResponds())->first()->oclAsType(Foundation::Core::Class)

String name = "so" + operationPort.name.substring(0, 1). toUpperCase() + operationPort.name.substring(1);

Foundation::Data_Types::VisibilityKind visibility =

Foundation::Data_Types::VisibilityKind.public; boolean isAbstract = false; boolean isStatic = false; boolean isFinal = false; boolean isNative = false; boolean isSynchronized = false;

Foundation::Core::Classifier type = returnPort.getFlowTypeValue().getDataElementJavaClass();

List exceptions = getExceptions(exceptionPorts);

if(destination = "ImplementationClass"

}

|| destination = "RemoteInterface"){ exceptions.add("java.rmi.RemoteException");

Foundation::Core::Operation operation = createJavaMethod(name, visibility, isAbstract, isStatic, isFinal, isNative,

115

isSynchronized, type, exceptions); operation.query = false;

if(destination = "ImplementationClass"

}

|| destination = "RemoteInterface"){ operation.concurency =

}

Foundation::Data_Types::CallConcurencyKind.sequential;

if(operationPort.isTransactional()){ operation.setEJBTransAttribute("Supports");

}else{ operation.setEJBTransAttribute("Not Supported");

if(destination = "RemoteInterface")){

} operation.addStereotypeByString("EJBRemoteMethod");

if(paramPort!= null){ name = paramPort.name; isFinal = false;

Foundation::Data_Types::ParameterDirectionKind paramDirect =

Foundation::Data_Types::ParameterDirectionKind.in; type =

} paramPort.getFlowTypeValue().getDataElementJavaClass();

Foundation::Core::Parameter arg = createJParameter(name,isFinal,paramDirect,type);

} operation.ownedElement.add(arg);

return operation;

7.4.2.2.2 Specification of transformation from Operation OperationPort to Operation

Foundation::Core::Operation operationPortToOperation

(Foundation::Core::Operation operationPort){

pre:

operationPort.stereotype->exists(name = ‘OperationPort’) and operationPort->isResponds()

query:

let returnParam :Foundation::Core::Parameter = operationPort.ownedElements-> select(retParam:Foundation::Core::Parameter| retParam.kind =

Foundation::Data_Types::ParameterDirectionKind.return)->at(1)-> oclAsType(Foundation::Core::Parameter)

let params :Collection = operationPort.ownedElements-> select(retParam:Foundation::Core::Parameter| retParam.kind =

Foundation::Data_Types::ParameterDirectionKind.in)

in

body:

Foundation::Core::Classifier type = null;

String name = "so" + operationPort.name.substring(0, 1). toUpperCase() + operationPort.name.substring(1);

Foundation::Data_Types::VisibilityKind visibility =

Foundation::Core::Data_Types::VisibilityKind.public; boolean isAbstract = true; boolean isStatic = false; boolean isFinal = false; boolean isNative = false; boolean isSynchronized = false;

if(returnParam != null) type = returnParam.getType().getDataElementJavaClass();

List exceptions = new List(); exceptions.add("java.lang.Exception");

Foundation::Core::Operation operation = createJavaMethod(name, visibility, isAbstract, isStatic, isFinal, isNative, isSynchronized, type, exceptions);

116

} operation.query = false;

for(int i=0;i<params.size();++i){

Foundation::Core::Parameter paramPort = params.get(i); name = paramPort.name; isFinal = false;

Foundation::Data_Types::ParameterDirectionKind paramDirect =

Foundation::Data_Types::ParameterDirectionKind.in; type = paramPort.getType().getDataElementJavaClass();

Foundation::Core::Parameter arg = createJParameter(name, isFinal, paramDirect, type); operation.ownedElement.add(arg);

}

return operation;

7.4.2.3 Transformation of MultiPorts

MultiPort has no direct translation to any element that exists in the EJB. To assure

that transformation of MultiPort will transfer behaviourism it has to create additional elements responsible for MultiPort-specific logic.

For each MultiPort, three types of elements are created:

MultiPort JavaClass

JavaMethods that represent ports contained by MultiPort

performMultiportAction()

MultiPort JavaClass is created for every MultiPort. EJBSessionBean or

JavaClass, for which MultiPort is transformed for, has a JavaField with MultiPort

JavaClass as type. This JavaClass always contains isBufferFull JavaMethod, which

checks if all data required by all FlowPorts contained by MultiPort are set.

The buffers for data required by these FlowPorts are created by

transfFlowPortForMultipClass transformation. The transformation has two input

parameters:

fPort – references FlowPort from MultiPort

multipClass – references MultiPort JavaClass

This transformation is responsible for acquiring data that is associated with

FlowPort from MultiPort and generation of JavaField in MultiPort JavaClass that will

store it. The transformation generates also getter and setter methods for created

JavaField.

JavaMethods that represent ports contained by MultiPort are transformed just as

standard FlowPorts, but JavaMethods generated from them should not contain ports logic, but they should just store received data in MultiPort JavaClass, call the

isBufferFull method and if it will return true call performMultiportAction() method.

The performMultuportAction() method is created for every MultiPort, and fulfils actions of every port from MultiPort.

As MultiPort may be transformed for EJBSessionBean and JavaClass, there are two main transformations for it. Transformation for EJBSessionBean has four input parameters:

multip – reference to MultiPort

session – reference to EJBSessionBean

impl – reference to EJBImplementation class from session

rem – reference to EJBRemoteInterface from session

Transformation for JavaClass has two input parameters:

multip – reference to MultiPort

inClass – reference to JavaClass

7.4.2.3.1 Specification of MultiPort transformation for Enterprise Bean

multiPortTransf (Foundation::Core::Class multip, Foundation::Core::Class impl, Foundation::Core::Class rem, Model_Management::Subsystem session){

117

}

pre:

multip.stereotype->exists(name=’MultiPort’) and impl.stereotype->exists(name=’EJBImplementation’) and rem.stereotype->exists(name=’EJBRemoteInterface’) and session.stereotype->exists(name=’EJBSessionBean’) and session.ownedElement->exists(impl) and

query:

session.ownedElement->exists(rem) and session.association-> exists(assEnd| assEnd.association.connection-> exists(assEnd|assEnd.participant = multip))

let flowPorts:Foundation::Core::Class = Foundation::Core::Class->

AllInstances->select(port | port.stereotype.name=’FlowPort’ and port.association->exists(assEnd| assEnd.association.connection-> exists(assEnd|assEnd.participant = multip)))->at(1)->

in body:

oclAsType(Foundation::Core::Class

Foundation::Core::Class multipClass = null; multipClass = createMultiportClass(multip, impl); session.ownedElement.add(multipClass);

// //////////////////////////////

// transformation of flowPorts //

// //////////////////////////////

for(int i=0; i<asynchFlowPorts.size();++i){

}

Foundation::Core::Class fPort = asynchFlowPorts.get(i);

if(!(fPort.isSynchronous() && ! fPort.isResponds())){

Foundation::Core::Operation implOp = flowPortToOperation

(asynchFPort, “ImplementationClass”); impl.ownedElement.add(implOp);

}

if(fPort.isSynchronous() && fPort.isResponds()){

Foundation::Core::Operation remOp = flowPortToOperation

(asynchFPort, “RemoteInterface”);

} rem.ownedElement.add(remOp); transfFlowPortForMultipClass(asynchInitPort, multipClass);

// ////////////////////////////////////////////////////////

// add performMultiportAction() method to implementation //

// class interface ------------------------------------- //

// ////////////////////////////////////////////////////////

List exceptions = new List(); exceptions.add("java.rmi.RemoteException");

Foundation::Core::Operation perfMA = createJavaMethod("performActionFor" + multip.name,

Foundation::Data_Types::VisibilityKind.private, false, false, false, false, false, getModel().getModelElement("void"),exceptions); perfMA.concurency =

Foundation::Data_Type::CallConcurencyKind.sequential; impl.ownedElement.add(perfMA);

return multipClass;

7.4.2.3.2 Specification of MultiPort transformation for JavaClass

multiPortTransf (Foundation::Core::Class multip, Foundation::Core::Class inClass){

pre:

multip.stereotype->exists(name=’MultiPort’) and

query:

inclass.association-> exists(assEnd| assEnd.association.connection-> exists(assEnd|assEnd.participant = multip))

118

}

let flowPorts:List = Foundation::Core::Class->AllInstances->select(port | port.stereotype.name=’FlowPort’ and port.association-> exists(assEnd| assEnd.association.connection-> exists(assEnd|assEnd.participant = multip)))

in body:

Foundation::Core::Class multipClass = createMultiportClass(multip, inClass); inClass.ownedElement.add(multipClass);

for(int i=0; i< flowPorts.size();++i){

Foundation::Core::Class fPort = flowPorts.get(i);

if(!(fPort.isSynchronous() && ! fPort.isResponds())){

Foundation::Core::Operation jcOp = flowPortToOperation

(asynchFPort, “JavaClass“); impl.ownedElement.add(jcOp);

}

} transfFlowPortForMultipClass(asynchInitPort, multipClass);

// //////////////////////////////////////////////

// add performMultiportAction() method to java //

// class ------------------------------------- //

// //////////////////////////////////////////////

List exceptions = new List();

Foundation::Core::Operation perfMA = createJavaMethod("performActionFor" + multip.name,

Foundation::Data_Types::VisibilityKind.private, false, false, false, false, false, getModel().getModelElement("void"),exceptions); perfMA.concurency =

Foundation::Data_Type::CallConcurencyKind.sequential; impl.ownedElement.add(perfMA);

return multipClass;

7.4.2.3.3 Specification of transfFlowPortForMultipClass void transfFlowPortForMultipClass(Foundation::Core::Class fPort,

Foundation::Core::Class multipClass)

pre:

fport.stereotype->exists(name=’FlowPort’) and fport.namespace.stereotype->exists(name=’MultiPort’)

query:

let flowPorts:List= Foundation::Core::Class->AllInstances->select(port | port.stereotype.name=’FlowPort’ and port.association-> exists(assEnd| assEnd.association.connection-> exists(assEnd|assEnd.participant = multip)))

in body:

for(int i=0; i< flowPorts.size();++i){

Foundation::Core::Class fPort = flowPorts.get(i);

String name = fPort.name;

Foundation::Data_Types::VisibilityKind visibility =

Foundation::Data_Types::VisibilityKind.private; boolean isStatic = false; boolean isFinal = false; boolean isVolatile = false; boolean isTransient = false;

Foundation::Core::Classifier type = fPort.getFlowTypeValue().getDataElementJavaClass();

Foundation::Core::Attribute att = createJavaField(name, visibility, isStatic, isFinal,isVolatile, isTransient, type);

List exceptions = new List();

Foundation::Core::Operation getter = createJavaMethod(("get"+att.name.substring(0,1).

119

}

+

} toUpperCase() + att.name.substring(1),

Foundation::Data_Types::VisibilityKind.public, false, false, false, false, false, att.type, exceptions); getter.setConcurency =

Foundation::Data_Types::CallConcurencyKind.sequential;

Foundation::Core::Operation setter = createJavaMethod(("set" att.name.substring(0,1).toUpperCase() + att.name.substring(1),

Foundation::Core::VisibilityKind.public, false, false, false, false, false, getModel().getModelElement("void"), exceptions); setter.concurency =

Foundation::Data_Types::CallConcurencyKind.sequential;

Parameter input = createJParameter(att.name + "Value", false,

Foundation::Data_Types::ParameterDirectionKind.in, att.type); setter. ownedElement.add(input); multipClass.ownedElement.add(att); multipClass.ownedElement.add(getter); multipClass.ownedElement.add(setter);

7.4.2.4 Transformation of Property Definitions

The transformation has following input parameters:

procComp – reference to ProcessComponent that has been transformed to

destElem

destElem – element for which this transformation is conducted

destination- specifies type of destElem

If PropertyDefinitions are going to be transformed for EJBSessionBean, they are transformed to tuples in EJBEnvEntries TaggedValue. Tuple in this TaggedValue will contain name and transformed type of the PropertyDefinition, and one of values that can be contained by PropertyDefinition (there is going to be created one tuple for each

PropertyValue for each PropertyDefinition).

If the PropertyDefinitions are going to be transformed for JavaClass, then each of them will be represented by an input parameter in new constructor method for this

JavaClass.

7.4.2.4.1 Specification of transformation of Property Definition

Foundation::Core::Operation tranformationOfPropertyDefinition

(Foundation::Core::Classifier procComp, Foundation::Core::ModelElement destElem, String destination){

pre:

procComp.stereotype->exists(name=’ProcessComponent’) and

(destElem.stereotype->exists(‘EJBSessionBean’) or destElem->oclIsType(Foundation::Core::Class)) and

(destination=’EnterpriseBean’ or destination=’JavaClass’)

query:

let propLst :List = procComp.typedFeature->select(prop

:Foundation::Core::Attribute| prop.stereotype->exists(ster| ster.name=”PropertyDefinition”))

in body:

if(destination = “EnterpriseBean”;{

List envEntLst = new List();

for(int i=0;i<propLst.size();++i) {

Foundation::Core::Attribute property = propLst.get(i);

List envEntries = new List();

List usageValLst = new List();

List consts = property.constraint;

for(int j=0; j< consts.size();++j) {

120

}

}

Foundation::Core::Constraint cons = consts.get(j); usageValLst.add(cons.body)

}

Foundation::Core::Classifier type = property.type.getDataElementJavaClass();

String propTypeName = type.name;

String envVarPrefix = property.name + ";" + propTypeName

+ ";";

for(int j=0; j<usageValLst.size(); ++j) {

String specVal = usageValLst.get(j);

String envVar = envVarPrefix + specVal; envEntries.add(envVar);

} envEntLst.addAll(envEntries); destElem.setEJBEnvEntries(envEntLst);

}else if(destination = “JavaClass”){

String name = destElem.name;

Foundation::Core::VisibilityKind visibility =

Foundation::Core::VisibilityKind.public; boolean isAbstract = false; boolean isStatic = true;

}

} boolean isFinal = false; boolean isNative = false; boolean isSynchronized = false;

List exceptions = new List();

Foundation::Core::Operation create = createJavaMethod(name, visibility, isAbstract, isStatic, isFinal, isNative, isSynchronized, null, exceptions); destElem.ownedElement.add(create);

List envEntLst = new List();

if (propLst.size()>0) { create = createJavaMethod(name, visibility, isAbstract, isStatic, isFinal, isNative, isSynchronized, null, exceptions);

for(int i=0; i<propLst.size();++i){

Foundation::Core::Attribute property = propLst.get(i); name = property.name; isFinal = false;

Foundation::Data_Types::ParameterDirectionKind paramDirect = Foundation::Data_Types::

ParameterDirectionKind.in;

Foundation::Core::Classifier type = property.type.getDataElementJavaClass();

Foundation::Core::Parameter inParam = createJParameter(name, isFinal, paramDirect, type); create.ownedElement.add(inParam);

} destElem.ownedElement.add(create);

7.4.2.5 Transformation of Interfaces

This transformation maps EDOC’s Interfaces to JavaInterfaces stored in <<

EDOCDataModel>> UML Package. In addition, the abstraction relation between

EDOC Interface and JavaInterface is set. It is used during the further transformation

steps to localize accurate JavaInterface.

The transformation has following input parameters:

interf – reference to EDOC Interface

dataTypePackage – reference to EDOC Data Model Package

The ImplementJavaInterface is an example of in-place transformation. It allows for updating clazz in accordance to the specification of given JavaInterface. In particular, it copies all specifications of operations to the clazz, if destination is set to

JavaInterface”. In other cases, it sets additionally certain TaggedValues and stereotypes.

121

7.4.2.5.1 Specification of Interfaces

Foundation::Core::Class tranformationOfInterfaces

(Foundation::Core::Class interf, Model_Management::Package dataTypePackage){

pre:

interf.namespace.stereotype->exists(name=’EDOCProtocol’) and interf.stereotype->size()=0 and dataTypePackage.stereotype->exists(name=’EDOCDataModel’)

query:

let List operations = interf.feature-> select(oper:Foundation::Core::Operation) in

let flowPorts:List= Foundation::Core::Class->AllInstances->select(port | port.stereotype.name=’FlowPort’ and port.association->

in

exists(assEnd| assEnd.association.connection-> exists(assEnd|assEnd.participant = multip)))

body:

String interfacePrefix="Interface";

String trace="trace";

String interfaceName; interfaceName = interf.name;

// set name of the interface interfaceName = interfacePrefix + interfaceName.substring(0,1).toUpperCase() + interfaceName.substring(1);

// create interface

Foundation::Core::Class resultInterface = createJavaInterface(interfaceName,

Foundation::Core::VisibilityKind.public, false);

// adds element to datatypes package dataTypePackage.ownedElement.add(resultInterface); resultInterface.addStereotypedAbstraction(interf, dataTypePackage, trace);

for(int i=0; i<operations.size();++i){

} resultInterface.feature.ownedElement.add( operationPortToOperation(operations.get(i)));

for(int i=0;i<flowPorts.size();++i){

Foundation::Core::Class flowPort = flowPorts.get(i);

Foundation::Core::Operation oper = flowPortToOperation(flowPort, “JavaInterface”); resultInterface.ownedElement.add(oper);

}

return resultInterface;

}

7.4.2.5.2 Setting realization of Java Interface

Foundation::Core::Class ImplementJavaInterface(

Foundation::Core::Class clazz,

Foundation::Core::Class classInterface, String destination){

pre:

classInterface.stereotype->exists(name=’JavaInterface’) and

(destination=’JavaInterface’ or destination=’JavaClass’ or destination=’ImplementationClass’ or destination=’RemoteInterface’ or destination=’HomeInterface’)

query:

let operations :List = classInterface.feature->select(oper:

Foundation::Core:Operation)

in body:

Foundation::Core::Operation srcOper;

Foundation::Core::Operation dstOper;

Foundation::Core::Parameter srcPar;

122

}

Foundaiton::Core::Parameter dstPar;

if(!(destination="JavaInterface")){

// adds realize abstraction

} classInterface.addStereotypedAbstraction(clazz, classInterface.namespace,"realize");

for(int i = 0; i < operations.size();i++){ srcOper = operations.get(i); dstOper = createJavaMethod(srcOper.name, srcOper.visibility,

false, srcOper.ownerScope =

Foundation::Data_Types::ScopeKind.classifier, srcOper.isLeaf, isJavaNative(srcOper), srcOper.concurency =

Foundation::Data_Types::CallConcurencyKind.guarded, srcOper.getReturnType(),srcOper.getThrows());

if(destination = “ImplementationClass" || destination = “RemoteInterface" || destination = HomeInterface"){ dstOper.concurency =

Foundation::Data_Types::CallConcurencyKind.sequential; dstOper.setEJBTransAttribute("Supports");

if(destination = "RemoteInterface"){ dstOper.addStereotypeByString("EJBRemoteMethod");

}else if(destination = "HomeInterface"){ dstOper.addStereotypeByString(

"EJBHomeInterfaceMethod");

}

Foundation::Core::TaggedValue tagVal = dstOper.getTaggedValue("JavaThrows");

if(tagVal!=null){ dstOper.remove(tagVal);

}

List exceptions = new List(); exceptions.add("java.rmi.RemoteException");

} params = srcOper.parameter;

for(int i=0; i<params.size();++i){

//Setting JavaThrows tag value tagVal = new Foundation::Core::TaggedValue(); tagVal.name = "JavaThrows”; tagVal.dataValue = exceptions; dstOper.ownedElement.add(tagVal); srcPar = params.get(i); dstPar = createJParameter( srcPar.name, srcPar.isJavaFinal(), srcPar.kind, srcPar.type);

} dstOper.parameter.add(dstPar); clazz.feature.add(dstOper);

}

return clazz;

7.4.2.6 Transformation of Protocols

The transformation aim is to generate interfaces that are a representation of the

CCA’s protocols. The protocols that are defined in the CCA’s model are represented in the authors’ approach as set of interfaces. They are realized by session beans or inner classes, which are a result of transformation of process components that in turn use these protocols.

123

The behaviour related with the protocols is realized by implementations of the interfaces’ operation. However, this is out of scope of this paper to transform behavioural aspects of the system. The content of the operations is not in scope of the transformation.

The transformation takes two input parameters:

protocol – is a processed protocol,

dataTypePackage – is data type package, i.e. package to which all result of performing of transformation the transformation is stored.

7.4.2.6.1 Specification

Foundation::Core::Class

transformationOfProtocols(

Foundation::Core::Class protocol,

Model_Management::Package dataTypePackage){

pre:

protocol.stereotype->exists(name=’Protocol’) and dataTypePackage.stereotype->exists(name=’EDOCDataModel’)

query:

let flowPortInitSynch:Sequence = Foundation::Core::Class->allInstances-> select(port | port.stereotype.name=’FlowPort’ and port->isSynchronous() and

not port->isResponds() and port.association->exists(assEnd| assEnd.association.connection-> exists(assEnd|assEnd.participant = protocol)))

let flowPortRespSynch:Sequence = Foundation::Core::Class->allInstances-> select(port | port.stereotype.name=’FlowPort’ and port->isSynchronous() and port->isResponds() and port.association->exists(assEnd| assEnd.association.connection-> exists(assEnd|assEnd.participant = protocol)))

let flowPortInitAsynch:Sequence = Foundation::Core::Class->allInstances-> select(port | port.stereotype.name=’FlowPort’ and

not port->isSynchronous() and

not port->isResponds() and port.association->exists(assEnd| assEnd.association.connection-> exists(assEnd|assEnd.participant = protocol)))

let flowPortRespAsynch:Sequence = Foundation::Core::Class->allInstances-> select(port | port.stereotype.name=’FlowPort’ and

not port->isSynchronous() and port->isResponds() and port.association->exists(assEnd| assEnd.association.connection-> exists(assEnd|assEnd.participant = protocol)))

let operationPortInitSynch:Sequence = Foundation::Core::Class-> allInstances-> select(port | port.stereotype.name=’OperationPort’ and port->isSynchronous() and

not port->isResponds() and port.association->exists(assEnd| assEnd.association.connection-> exists(assEnd|assEnd.participant = protocol)))

let operationPortRespSynch:Sequence = Foundation::Core::Class-> allInstances-> select(port | port.stereotype.name=’FlowPort’ and port->isSynchronous() and port->isResponds() and port.association->exists(assEnd| assEnd.association.connection-> exists(assEnd|assEnd.participant = protocol)))

in body:

List exceptions;

Foundation::Core::Class port;

Foundation::Core::Operation operation;

String initiateInterfacePrefix="InitiateInterface",

124

respondsInterfacePrefix="RespondsInterface", traceInitiates="traceInitiatesInterface", traceResponds="traceRespondsInterface", interfaceName;

//generate initiates interface interfaceName = protocol.name;

// set name of the interface

if(protocol.name.length() > 0) interfaceName = initiateInterfacePrefix + interfaceName.substring(0,1).toUpperCase() + interfaceName.substring(1,interfaceName.length());

else interfaceName = initiateInterfacePrefix;

// create interface

ModelClass resultInterface = createJavaInterface( interfaceName, Foundation::Data Types::VisibilityKind.public,

false);

// adds element to datatypes package dataTypePackage.ownedElements.add(resultInterface); addStereotypedAbstraction(protocol, resultInterface, dataTypePackage, traceInitiates);

// SYNCH FLOW PORTS RESP exceptions = new List(); exceptions.add("java.lang.Exception");

for(int i=0; i < flowPortRespSynch.size(); i++){ port = flowPortRespSynch.get(i); operation = flowPortToOperation(port, "JavaClass"); setJavaThrows(operation, exceptions);

} resultInterface.feature.add(operation);

// ASYNCH FLOW PORTS INIT exceptions = new List(); exceptions.add("java.lang.Exception");

for(int i=0; i < flowPortInitAsynch.size(); i++){ port = flowPortInitAsynch.get(i); operation = flowPortToOperation(port, "JavaClass"); operation.visibility =

Foundation::Data Types::VisibilityKind.public; setJavaThrows(operation, exceptions); resultInterface.feature.add(operation);

}

// ASYNCH FLOW PORTS RESP exceptions = new List(); exceptions.add("java.lang.Exception");

for(int i=0; i < flowPortRespAsynch.size(); i++){ port = flowPortRespSynch.get(i); operation = flowPortToOperation(port, "JavaClass"); operation.visibility =

}

Foundation::Data Types::VisibilityKind.public; setJavaThrows(operation, exceptions); resultInterface.feature.add(operation);

// SYNCH OPER PORTS RESP exceptions = new List(); exceptions.add("java.lang.Exception");

for(int i=0; i < operationPortRespSynch.size(); i++){ port = flowPortRespSynch.get(i);

} operation = operationPortToOperation(port, "JavaClass"); setJavaThrows(operation, exceptions); resultInterface.feature.add(operation);

125

//generate responds interface interfaceName = protocol.name;

// set name of the interface

if(protocol.name.length() > 0) interfaceName = respondsInterfacePrefix+ interfaceName.substring(0,1).toUpperCase() + interfaceName.substring(1,interfaceName.length());

else interfaceName = respondsInterfacePrefix;

// create interface

ModelClass resultInterface = createJavaInterface( interfaceName, Foundation::Data Types::VisibilityKind.public,

false);

// adds element to datatypes package dataTypePackage.ownedElements.add(resultInterface); addStereotypedAbstraction(protocol, resultInterface, dataTypePackage, traceResponds);

// SYNCH FLOW PORTS RESP exceptions = new List(); exceptions.add("java.lang.Exception");

for(int i=0; i < flowPortInitSynch.size(); i++){ port = flowPortInitSynch.get(i);

// change direction to responds port.setDirection(“Responds”); operation = flowPortToOperation(port, "JavaClass"); port.setDirection(“Initiates”);

} setJavaThrows(operation, exceptions); resultInterface.feature.add(operation);

// ASYNCH FLOW PORTS INIT

for(int i=0; i < flowPortRespAsynch.size(); i++){ port = flowPortRespAsynch.get(i);

// change direction to initiates port.setDirection(“Initiates”); operation = flowPortToOperation(port, "JavaClass"); port.setDirection(“Responds”);

}

} setJavaThrows(operation, exceptions); resultInterface.feature.add(operation);

// ASYNCH FLOW PORTS RESP

for(int i=0; i < flowPortInitAsynch.size(); i++){ port = flowPortInitAsynch.get(i);

// change direction to responds port.setDirection(“Responds”); operation = flowPortToOperation(port, "JavaClass"); port.setDirection(“Initiates”); setJavaThrows(operation, exceptions); resultInterface.feature.add(operation);

// SYNCH OPER PORTS exceptions = new List(); exceptions.add("java.lang.Exception");

for(int i=0; i < operationPortInitSynch.size(); i++){ port = operationPortInitSynch.get(i);

// change direction to responds port.setDirection(“Responds”);

126

}

} operation = operationPortToOperation(port, "JavaClass"); port.setDirection(“Initiates”); setJavaThrows(operation, exceptions); resultInterface.feature.add(operation);

7.4.2.7 Transformation of Process Component

One can distinguish two results of ProcessComponent to EJB transformation, which are EJBSessionBean and JavaClass. Main Concepts of transformation to these elements are the same. One has to create a skeleton of specific element, and then transform its ports, protocols, interfaces, and PropertyDefinitions that are used by transformed ProcessComponent. Those aspects of ProcessComponent transformation are very similar and base on other transformations (specific for ports, protocols or interfaces).

The

tranformationOfProcessComponentToSessionBean transformation has

following input parameters:

procComp – is a reference to one of the ProcessComponents, which in the

Transitional Model is represented by Subsystem.

mdb –reference to Message-Driven Bean or null if there is no asynchronous ports in the project.

Besides being responsible for EJBSessionBean skeleton, mapping ports, protocol and PropertyDefinitions this transformation has cope with creating the mechanism that will be responsible for asynchronous methods handling. It is represented by

onMessage method, called by Message-Driven Bean, which use the method to forward

all messages to EJBSessionBean. This method will forward asynchronous messages not only to other methods contained directly in EJBSessionBean, but also to methods contained by innerClasses.

The tranformationOfProcessComponentToInnerClass performs transformation for every ProcessComponent that in the Transitional Model is marked as innerClass. Its input parameter is reference to

EJBSessionBean created in

tranformationOfProcessComponentToSessionBean.

The transformation creates JavaClass skeleton that fulfils requirements of EJB

UML Profile, and performs port, protocol and PropertyDefinition transformations.

7.4.2.7.1 Specification of Transformation of Process Component to Session Bean

Model_Management::Subsystem tranformationOfProcessComponentToSessionBean

(Foundation::Core::Classifier procComp, Foundation::Core::Class mdb){

pre:

procComp.stereotype->exists(name=’ProcessComponent’) and procComp->getClientOfMTrace()-> oclIsType(Model_Management::Subsystem) and mdb.stereotype->exists(name=’EJBMessageDrivenBean’)

query:

let flowPorts:List = Foundation::Core::Class->AllInstances->select(port | port.stereotype.name=’FlowPort’ and port.association-> exists(assEnd| assEnd.association.connection-> exists(assEnd|assEnd.participant = procComp)))

let operationPorts:List = Foundation::Core::Class->AllInstances-> select(port | port.stereotype.name=’OperationPort’ and port-> isSynchronous() and port->isResponds() and port.association-> exists(assEnd| assEnd.association.connection-> exists(assEnd|assEnd.participant = procComp)))

let multiPorts:List = Foundation::Core::Class->AllInstances->select(port

| port.stereotype.name=’MultiPort’ and port.association-> exists(assEnd| assEnd.association.connection-> exists(assEnd|assEnd.participant = procComp)))

let protocPorts:List = Foundation::Core::Class->AllInstances->select(port

127

| port.stereotype.name=’ProtocolPort’ and port.association-> exists(assEnd| assEnd.association.connection-> exists(assEnd|assEnd.participant = procComp))) in

let interfLst: List = Foundation::Core::Class->AllInstances-> select(interf | interf.specalization-> exists(gen|protocPorts.includes(gen.child))

in

body:

// ////////////////////////////////////

// creation of Session Bean skeleton //

// ////////////////////////////////////

Model_Management::Subsystem session =

new Model_Management::Subsystem(); session.addStereotypeByString("EJBSessionBean");

// session bean has the same name as process component session.name = procComp.name(); session.elementOwnership.visibility =

Foundation::Data_Types::VisibilityKind.public; session.isLeaf = false; session.isAbstract = false; tranformationOfPropertyDefinition (procComp, session,

Foundation::Core::ModelElement transModElem = session.setMTrace(transModElem); session.setEJBTransType("Container");

//Implementation Class

Foundation::Core::Class impl = createJavaClass(session.name + impl.addStereotypeByString("EJBImplementation"); impl.setRealizeEJBSessionBean(); impl.setPersistent("false");

if(procComp.isPersistent()) {

}

“EnterpriseBean”); procComp.getClientOfMTraceBySupplier();

"Bean", Foundation::Data_Types::VisibilityKind.public, false, false, false, false, false); impl.setRealizeSessionSynchronization(); session.ownedElement.add(impl);

//Remote Interface

Foundation::Core::Class remote = createJavaInterface(session.name,

Foundation::Data_Types::VisibilityKind.public, false); remote.addStereotypeByString("EJBRemoteInterface"); session.ownedElement.add(remote); remote.setSpecializeEJBObject(impl);

//Home Interface

Foundation::Data_Types::Class home = createJavaInterface(session.name + "Home",

Foundation::Data_Types::VisibilityKind.public, true); home.setSpecializeEJBHome(,impl); home.addStereotypeByString("EJBSessionHomeInterface"); home.setPersistent("false");

if(procComp->isPersistent()) { sessionHome.setEJBSessionType("Stateful");

} else { sessionHome.setEJBSessionType("Stateless");

}

List exceptions = new List(); exceptions.add("java.rmi.RemoteException");

128

Foundation::Core::Operation ejbCreate = createJavaMethod("ejbCreate",

Foundation::Data_Types::VisibilityKind.public, false, true, false, false, false, getModel().getModelElement("void"), exceptions);

Create.concurency =

Foundation::Data_Types::CallConcurencyKind.sequential; impl. ownedElement.add(ejbCreate); exceptions.add("javax.ejb.CreateException");

Foundation::Core::Operation create = createJavaMethod("create",

Foundation::Data_Types::VisibilityKind.public,false, true, false, false, false, rem, exceptions); create.concurency =

Foundation::Data_Types::CallConcurencyKind.sequential; create.addStereotypeByString("EJBCreateMethod"); home.ownedElement.add(create); session.ownedElement.add(home);

// client - supplier impl.setEJBRealizeHome(home);// UML Abstraction impl.setEJBRealizeRemote(remote);// UML Abstraction home.setInstantiate(remote);// UML Usage

// ////////////////////////////////////////////////////

// creation of asynchronous method handler mechanism //

// ////////////////////////////////////////////////////

if (session.hasAsynchMethods()) {

// onMessage exceptions = new List(); exceptions.add("java.rmi.RemoteException");

Foundation::Core::Operation onMessageImpl = createJavaMethod("onMessage",

Foundation::Data_Types::VisibilityKind.PUBLIC, false, false, false, false, false,getModel().getModelElement("void”), exceptions); onMessageImpl.concurency =

Foundation::Data_Types::CallConcurencyKind.sequential; onMessageImpl.setEJBTransAttribute("Not Supported");

Foundation::Core::Parameter stringInParam = createJParameter("message", false,

Foundation::Data_Types::ParameterDirectionKind.IN, false, getModel().getModelElement("String”)); onMessageImpl.ownedElement.add(stringInParam);

Foundation::Core::Operation onMessageRem = createJavaMethod("onMessage", VisibilityKind.PUBLIC, false, false, false, false, false, getModel().getModelElement("void”), exceptions); onMessageRem.concurency =

Foundation::data_Types::CallConcurencyKind.sequential; onMessageRem.setEJBTransAttribute("Not Supported"); onMessageRem.addStereotypeByString("EJBRemoteMethod");

String inParam = createJParameter("message", false,Foundation::Data_Type::ParameterDirectionKind.in, getModel().getModelElement("javax::jms::Message")); onMessageRem.ownedElement.add(inParam); remote.ownedElement.add(onMessageRem); impl.ownedElement.add(onMessageImpl);

// Operaiton for Message-Driven Bean exceptions = new List(); exceptions.add("java.rmi.RemoteException");

Operation onMessageMDB = createJavaMethod("onMessage" + session.name,

Foundation::Data_Types::VisibilityKind.public, false, false, false, false, false, getModel().getModelElement("void”), exceptions); onMessageMDB.concurency =

Foundation::Data_Types::CallConcurencyKind.sequential);

129

}

} onMessageMDB.setEJBTransAttribute("Not Supported");

Foundation::Core::Parameter stringInParam = createJParameter("message", false,

Foundation::Data_Types::ParameterDirectionKind.in, getModel().getModelElement("javax::jms::Message")); onMessageMDB.ownedElement.add(stringInParam); mdb.ownedElement.add(onMessageMDB);

// //////////////////////////////

// Transformation of FlowPorts //

// //////////////////////////////

for(int i=0; i< flowPorts.size();++i){

Foundation::Core::Class fPort = flowPorts.get(i);

if(!(fPort.isSynchronous() && ! fPort.isResponds())){

Foundation::Core::Operation implOp = flowPortToOperation

(fPort, “ImplementationClass“); impl.ownedElement.add(implOp);

}

if(fPort.isSynchronous() && fPort.isResponds()){

}

Foundation::Core::Operation remOp = flowPortToOperation

(fPort, “RemoteInterface“); rem.ownedElement.add(remOp);

// ////////////////////////////////////////////////

// transformation of synchronous operation ports //

// ////////////////////////////////////////////////

for(int i=0; i< operationPorts.size();++i){

Foundation::Core::Class oPort = operationPorts.get(i);

Foundation::Core::Operation implOp = operationPortToOperation

(oPort, “ImplementationClass“);

Foundation::Core::Operation remOp = operationPortToOperation

(oPort, “RemoteInterface“); impl.ownedElement.add(implOp); rem.ownedElement.add(remOp);

}

// ///////////////////////////////

// transformation of multiports //

// ///////////////////////////////

for(int i=0; i< multiPorts.size();++i){

Foundation::Core::Class mPort = multiPorts.get(i); multiPortTransf (mPort, impl, rem, session);

}

// ///////////////////////////////

// transformation of interfaces //

// ///////////////////////////////

for(int i=0; i< interfLst.size();++i){

Foundation::Core::Class interf = interfLst.get(i);

} session.realizePortInterface(interf. getDataElementJavaClass(), impl, rem);

// ///////////////////////////////

// transformation of protocols //

// ///////////////////////////////

for(int i=0; i<protocPorts.size();i++){

Foundation::Core::Class protocPort = protocPorts.get(i);

List interfaces = new List(); interfaces = protocPort.getProtocolInterfaces(interfaces, protocPort.isResponds()?

130

}

}

}

(CCA::DirectionKind.responds):

(CCA::DirectionKind.Initiates));

for(int j=0; j< interfaces.size();j++){ realizeProtocolInterface(interfaces.get(j), impl, rem);

return session;

7.4.2.7.2 Specification of Transformation of Process Component to Inner Class

Model_Management::Subsystem tranformationOfProcessComponentToInnerClass

(Model_Management::Package session){

pre:

session.stereotype->exists(name=’EJBSessionBean’)

query:

let innerProcCompLst:List = session->getSuppOfMTrace().ownedElement-> select(cl: Foundation::Core::Class)

in

body:

for(int i=0;i<innerProcCompLst.size();++i){

// process component that is going to be transformed

Foundation::Core::Classifier procComp = innerProcCompLst.get(i);

// ////////////////////////////////////////

// creation of inner java class skeleton //

// ////////////////////////////////////////

String name = procComp.name

Foundation::Data_Types::VisibilityKind visibility =

Foundation::Data_Types:: VisibilityKind.private; boolean isAbstract = false; boolean isStatic = false; boolean isFinal = false; boolean isStricfp = false; boolean isActive = false;

Foundation::Core::Class inClass = createJavaClass(name, visibility, isAbstract,isStatic, isFinal, isStricfp, isActive); tranformationOfPropertyDefinition (procComp, inClass ,

„JavaClass”) inClass.setMTrace(procComp.getClientOfMTrace());

// //////////////////////////////

// Transformation of FlowPorts //

// //////////////////////////////

List flowPorts = procComp.getFlowPorts();

for(int i=0; i< flowPorts.size();++i){

Foundation::Core::Class fPort = flowPorts.get(i);

}

if(!(fPort.isSynchronous() && ! fPort.isResponds())){

}

Foundation::Core::Operation jcOp = flowPortToOperation(fPort, “JavaClass“); inClass.ownedElement.add(jcOp);

// ////////////////////////////////////////////////

// transformation of synchronous operation ports //

// ////////////////////////////////////////////////

List operationPorts = procComp.getOperationPorts();

for(int i=0; i< operationPorts.size();++i){

}

Foundation::Core::Class oPort = operationPorts.get(i);

Foundation::Core::Operation jcOp = operationPortToOperation(oPort, “JavaClass“); inClass.ownedElement.add(implOp);

131

}

// ///////////////////////////////

// transformation of multiports //

// ///////////////////////////////

List multiPorts = procComp.getMultiPorts();

for(int i=0; i< multiPorts.size();++i){

Foundation::Core::Class mPort = multiPorts.get(i); multiPortTransf (mPort, inClass)

}

// ///////////////////////////////

// transformation of interfaces //

// ///////////////////////////////

List interfLst = procComp.getInterfaces();

for(int i=0; i< interfLst.size();++i){

Foundation::Core::Class interf = interfLst.get(i);

}

for(int i=0; i<protocPorts.size();i++){

ImplementJavaInterface (inClass, interf.getDataElementJavaClass(),”JavaClass”);

// ///////////////////////////////

// transformation of protocols //

// ///////////////////////////////

Foundation::Core::Class protocPort = protocPorts.get(i);

List interfaces = new List(); interfaces = protocPort.getProtocolInterfaces(interfaces, protocPort.isResponds()?

(CCA::DirectionKind.responds):

(CCA::DirectionKind.Initiates));

}

for(int j=0; j< interfaces.size();j++){

}

ImplementJavaInterface (inClass, interfaces.get(j),”JavaClass”); session.addElement(inClass);

}

return session;

7.4.2.8 Creation of Message -Driven Bean

The transformation creates an EJBMessageDrivenBean (MDB) in order to handle the asynchronous communication. The MDB receives all asynchronous messages. The onMessage method is responsible for receiving the message and invokes method for the specific EJBSessionBean, which further forward the message to onMessage method in proper EJBSessionBean instance. To locate proper EJBSessionBean instances MDB uses EJBEntityBean that holds reference to remote interfaces.

The message has to be sent by JMS topic, used by every instance of

EJBSessionBean and MDB.

Figure 60 - Basic result of the creation of Message-Driven Bean

132

7.4.2.8.1 Specification of Message-Driven Bean Creation

}

Foundation::Core::Class createMessageDrivenBean (){

pre: true query: body:

// messageDrivenBean uml class that will represent

// message-driven bean

Foundation::Core::Class messageDrivenBean =

new Foundation::Core::Class(); messageDrivenBean.addStereotypeByString("EJBMessageDrivenBean"); messageDrivenBean.name = "MDB"; messageDrivenBean.setEJBTransType("Container"); messageDrivenBean.setRealizeMessageDrivenBeanInterface(); messageDrivenBean.setRealizeMessageListenerInterface(); messageDrivenBean.visibility =

Foundation::Data_Types::VisibilityKind.public; messageDrivenBean.isLeaf = false; messageDrivenBean.isAbstract = false;

//EJB Creation method

Foundation::Core::Operation ejbCreate = createJavaMethod("ejbCreate",

Foundation::Data_Types::VisibilityKind.public, false, false,

false, false, false, getModel().getModelElement("void"),

new List()); ejbCreate.addStereotypeByString("JavaMethod"); ejbCreate.name = "ejbCreate"; ejbCreate.isLeaf = false; ejbCreate.ownerScope = Foundation::Data_Types:ScopeKind.instance; messageDrivenBean.ownedElementadd(ejbCreate);

//EJB Remove method

Operation ejbRemove = createJavaMethod("ejbRemove",

Foundation::Data_Types::VisibilityKind.public, false, false, false, false, false, getModel().getModelElement("void"),

new List()); ejbRemove.addStereotypeByString("JavaMethod"); ejbRemove.name = "ejbRemove"; ejbRemove.isLeaf = false; ejbRemove.ownerScope = Foundation::Data_Types::ScopeKind.instance; messageDrivenBean.ownedElement.add(ejbRemove);

return messageDrivenBean;

7.4.2.9 Create of Entity Bean for Message-Driven Bean

The EJBEntityBean (EB) is created to contain reference to EJBRemoteInterfaces that are required by MDB to select the receiver of the message. The references are provided by EJBSessionBeans and set by setRemoteInterfaceRef method. The

getRemoteInterfaceMethod is used by MDB to acquire reference. The result of this

generation is shown on Figure 61.

133

Figure 61 - Basic result of the creation of Entity Bean for Message-Driven Bean

134

7.4.2.9.1 Specification of Entity Bean for Message -Driven Bean Creation

Model_Management::Subsystem createEntityBeanForMDB (){

pre: true query: body:

// entity - entity bean created for message-driven bean

Model_Management::Subsystem entity =

new Model_Management::Subsystem(); entity.name = "RemoteInterfaceEntity"; entity.addStereotypeByString("EJBEntityBean"); entity.visibility = Foundation::Data_Types::VisibilityKind.public; entity.setEJBPersistanceType("Container"); entity.setEJBReentrant("true");

//PRIMARY KEY CLASS

String name = “PrimaryKeyClass”

Foundation::Data_Types::VisibilityKind visibility =

Foundation::Data_Types::VisibilityKind.public; boolean isAbstract = false; boolean isStatic = true; boolean isFinal = false; boolean isStricfp = false; boolean isActive = false;

Foundation::Core::Class ejbPrimaryKeyClass = createJavaClass(name, visibility, isAbstract, isStatic, isFinal, isStricfp, isActive); ejbPrimaryKeyClass.setRealizeSerializableInterface();

// constructor method with no input

// parameters

Operation constMet = createJavaMethod(ejbPrimaryKeyClass.name,

Foundation::Data_Types::VisibilityKind.public, false, false,

false, false, false, null, null); ejbPrimaryKeyClass.ownedElement.add(constMet);

// equals method

Foundation::Core::Operation equals = createJavaMethod("equals",

Foundation::Data_Types::VisibilityKind.public, false, false,

false, false, false, getModel().getModelElement("boolean"),null);

Foundation::Core::Parameter inParam = createJParameter("o", false,

Foundation::Data_Types::ParameterDirectionKind.in, getModel().getModelElement("java::lang::Object")); equals.ownedElement.add(inParam); ejbPrimaryKeyClass.ownedElement.add(equals);

// hashCode(): int method

Operation hashCode = createJavaMethod("hashCode",

Foundation::Data_Types::VisibilityKind.public, false, false,

false, false, false, getModel().getModelElement("int"),

null); ejbPrimaryKeyClass.ownedElement.add(hashCode);

// primKeAtt - id attribute

Foundation::Core::Attribute primKeyAtt =

new Foundation::Core::Attribute(); primKeyAtt.name = "id"; primKeyAtt.ownerScope = Foundation::Data_Types::ScopeKind.instance; primKeyAtt.visibility =

Foundation::Data_Types::VisibilityKind.public;

Foundation::Data_Types::Multiplicity multip =

new Foundation::Data_Types::Multiplicity();

Foundation::Data_Types::MultiplicityRange mRange =

new Foundation::Data_Types::MultiplicityRange("1..1"); multip.range = mRange; primKeyAtt.multiplicity = multip; primKeyAtt.changeability =

Foundation::Data_Types::ChangeableKind.changeable;

135

primKeyAtt.setJavaVolatile("false"); primKeyAtt.type = getModel().getModelElement("java::lang::Integer"); ejbPrimaryKeyClass.ownedElement.add(primKeyAtt); entity.ownedElement.add(ejbPrimaryKeyClass);

//IMPLEMENTATION CLASS

Foundation::Core::Class impl = createJavaClass(entity.name +

"Bean", Foundation::Data_Types::VisibilityKind.public, false,

false, false, false, false); impl.addStereotypeByString("EJBImplementation"); impl.setPersistent("true");

//constructor method

Operation constMet = createJavaMethod(session.name,

Foundation::Data_Types::VisibilityKind.public, false, false,

false, false, false, null, null); impl.ownedElement.add(constMet);

// primary key field creation

Foundation::Core::Attribute primKey = createJavaField("id",

Foundation::Data_Types::VisibilityKind.public, false, false,

false, false, ejbPrimaryKeyClass); primKey.addStereotypeByString("EJBPrimaryKeyField");

// remIntRefField - cmp field with reference to remote interface

// creation

Foundation::Core::Attribute remIntRefField = createJavaField("remoteInterfaceRef",

Foundation::Data_Types::VisibilityKind.public, false, false,

false, false, getModel().getModelElement("javax::ejb::EJBObject")); remIntRefField.addStereotypeByString("EJBCmpField"); impl.ownedElement.add(primKey); impl.ownedElement.add(remIntRefField); impl.setRealizeEntityBeanInterface(); entity.ownedElement.add(impl);

//REMOTE INTERFACE

ModelClass remote = createJavaInterface(entity.name,

Foundation::Data_Types::VisibilityKind.public, false); remote.setSpecializeEJBObject(); remote.addStereotypeByString("EJBRemoteInterface");

List ejbFields = implementation.getEJBCmpFields();

for(int i=0;i<ejbFields.size();++i){

Foundation::Core::Attribute att = ejbFields.get(i);

//getters

List exceptions = new List(); exceptions.add("java.rmi.RemoteException");

Foundation::Core::Operation getterImp = createJavaMethod(("get" + att.name.substring(0,1).toUpperCase() + att.name.substring(1),

Foundation::Data_Types::VisibilityKind.public, false,

false, false, false, false, att.type, exceptions); getterImp.concurency =

Foudnation::Data_Types::CallConcurencyKind.sequential;

Foundation::Core::Operation getterRem = createJavaMethod(("get" + att.name.substring(0,1).toUpperCase() + att.name.substring(1),

Foundation::Data_Types::VisibilityKind.public, false,

false, false, false, false, att.type, exceptions); getterRem.concurency =

Foudnation::Data_Types::CallConcurencyKind.sequential; getterRem.addStereotypeByString("EJBRemoteMethod"); implementation.ownedElement.add(getterImp); remote.ownedElement.add(getterRem);

//setters

136

Foundation::Core::Operation setterImpl = createJavaMethod("set" + att.name.substring(0,1).toUpperCase() + att.name.substring(1),

Foundation::Data_Types::VisibilityKind.public, false,

false, false, false, false, getModel().getModelElement("void"), exceptions); setter.concurency =

Foundation::Data_Types::CallConcurencyKind.sequential;

Foundation::Core::Parameter input = createJParameter(att.name

+ "Value",false,

Foundation::Data_Types::ParameterDirectionKind.in, att.type); setterImpl.ownedElement.add(input);

Foundation::Core::Operation setterRem = createJavaMethod("set"

+ att.name.substring(0,1).toUpperCase() + att.name.substring(1),

Foundation::Data_Types::VisibilityKind.public, false,

false, false, false, false, getModel().getModelElement("void"), exceptions); setter.concurency =

Foundation::Data_Types::CallConcurencyKind.sequential;

}

}

Foundation::Core::Parameter input = createJParameter(att.name

+ "Value", false,

Foundation::Data_Types::ParameterDirectionKind.in, att.type); setterRem.ownedElement.add(input); remSetter.addStereotypeByString("EJBRemoteMethod"); implementation.addElement(setterImpl); remote.addElement(setterRem); ejbFields = implementation.getPrimKeyAttr();

for(int i=0; i<ejbFields.size();++i){

Foundation::Core::Attribute att = ejbFields.get(i);

//getters

List exceptions = new List(); exceptions.add("java.rmi.RemoteException");

Foundation::Core::Operation getterImp = createJavaMethod(("get" + att.name.substring(0,1).toUpperCase() + att.name.substring(1),

Foundation::Data_Types::VisibilityKind.public, false,

false, false, false, false, att.type, exceptions); getterImp.concurency =

Foudnation::Data_Types::CallConcurencyKind.sequential;

Foundation::Core::Operation getterRem = createJavaMethod(("get" + att.name.substring(0,1).toUpperCase() + att.name.substring(1),

Foundation::Data_Types::VisibilityKind.public, false,

false, false, false, false, att.type, exceptions); getterRem.concurency =

Foudnation::Data_Types::CallConcurencyKind.sequential; getterRem.addStereotypeByString("EJBRemoteMethod"); implementation.ownedElement.add(getterImp); remote.ownedElement.add(getterRem); entity.ownedElement.add(remote);

//HOME INTERFACE

Foundation::Core::Class home = createJavaInterface(entity.name +

"Home", Foundaiton::Data_Types::VisibilityKind.public, true); home.addStereotypeByString("EJBEntityHomeInterface"); home.setPersistent("true"); home.setSpecializeEJBHome();

137

// Create method

List exceptions = new List(); exceptions.add("java.rmi.RemoteException");

Foundation::Core::Operation ejbPostCreate = createJavaMethod("ejbPostCreate",

Foundation::Data_Types::VisibilityKind.public, false, false, false, false, false, getModel().getModelElement("void"), exceptions); ejbPostCreate.concurency =

Foundation::Data_Types::CallConcurencyKind.sequential;

Foundation::Core::Operation ejbCreate = createJavaMethod("ejbCreate",

Foundation::Data_Types::VisibilityKind.public, false, true,

false, false, false,primaryKeyClass, exceptions); ejbCreate.concurency =

Foundation::Data_Types::CallConcurencyKind.sequential; implementation.ownedElement.add(ejbPostCreate); implementation.ownedElement.add(ejbCreate); exceptions.add("javax.ejb.CreateException");

Foundation::Core::Operation create = createJavaMethod("create",

Foundation::Data_Types::VisibilityKind.public, false, true, false, false, false, remoteInterface, exceptions); create.concurency =

Foundation::Data_Types::CallConcurencyKind.sequential; create.addStereotypeByString("EJBCreateMethod"); home.ownedElement.add(create);

//findByPrimaryKey method

List exceptions = new List();

Foundation::Core::Operation findByPrimaryKey = createJavaMethod("findByPrimaryKey",

Foundation::Data_Types::VisibilityKind.public, false, true,

false, false, false, remoteInterface, exceptions); findByPrimaryKey.concurency =

Foundation::Data_Types::CallConcurencyKind.sequential; findByPrimaryKey.addStereotypeByString("EJBFinderMethod");

Foundation::Core::Parameter input = createJParameter("id", false,

Foundation::Data_Types::ParameterDirectionKind.in, ejbPrimaryKeyClass); findByPrimaryKey.ownedElement.add(input); home.ownedElement.add(findByPrimaryKey); entity.ownedElement.add(home);

// client - supplier implementation.setEJBRealizeHome(homeInterface);// UML Abstraction implementation.setEJBRealizeRemote(remoteInterface);// UML

Abstraction homeInterface.setEJBPrimaryKey(ejbPrimaryKeyClass);// UML Usage homeInterface.setInstantiate(remoteInterface);// UML Usage return entity;

}

7.4.2.10 Process Components transformation

This transformation maps ProcessComponents, and creates elements needed for performing asynchronous communication, i.e. MDB and EB, if any asynchronous port exists in the project. Further, it sets EJBReferences between EJBSessionBeans. The

EJBReferences are set as well in case of EJBSessionBeans that use asynchronous

communication. In this particular situation, EJBSessionBeans are set between the

MDB and those EJBSessionBeans, EJBSessionBeans and the EJBEntityBean.

The transformProcessComponents has following input parameters:

structPack – reference to package stereotyped <<EDOCStructure>>

138

transModPack – reference to Transitional Model package

7.4.2.10.1 Specification of ProcessComponents transformation

Model_Management::Subsystem transformProcessComponents(

Model_Management:: Package structPack,

Model_Management:: Package transModPack){

pre:

structPack.stereotype->exists(name=’EDOCStructure’)

query: body:

// ejbModelPack - package that will conatian Enterprise Beans and

// their inner classes

Model_Management::Package ejbModelPack =

new Model_Management::Package(); ejbModelPack.name = "EJBModelPackage";

// ///////////////////////////////////////////////

// Creating Message-Driven Beana and Entity for //

// asynchronous communication ----------------- //

// ///////////////////////////////////////////////

// messageDrivenBean – Message-Driven Bean

Foundation::Core::Class messageDrivenBean = null;

// if in EDOC project exists any asynchronous port,

// messageDrivenBean and entity bean will be created

Model_Management::Subsystem entityForMDB = null;

if (asynchMethodsExist()) { messageDrivenBean = createMessageDrivenBean(); ejbModelPack.ownedElement.add(messageDrivenBean);

}

// entityForMDB - entity that will be used to store remote

// interfaces with assynchronous methods entityForMDB = createEntityForMDB(); ejbModelPack.ownedElement.add(entityForMDB);

// ///////////////////////

// Creating SessionBeans//

// ///////////////////////

List procCompTransToSessionBean = transModPack.getProcessComponentsTransToSessionBean();

List beans = new List();

for(int i=0; i<procCompTransToSessionBean.size();++i) {

Foundation::Core::ModelElement elem = procCompTransToSessionBean.get(i);

Model_Management::Subsystem bean = transformPCToBean(elem, messageDrivenBean);

} ejbModelPack.ownedElement.add(bean); beans.add(bean);

// /////////////////////////

// Creating EJBReferences //

// /////////////////////////

List mdbTuples = new List();

for(int i=0;i<beans.size();++i) {

Model_Management::Subsystem session = beans.get(i);

List innerProcCompVect = session.getInnerClasses();

Model_Management::Subsystem inSession = session.getSuppOfMTrace();

List used = new List(); used = inSession.addSubsUsedBy(used); for(int i=0; i< innerProcCompVect.size();++i) {

}

Foundation::Core::ModelElement cl = innerProcCompVect.get(i); used = cl.addSubsUsedBy(used);

139

}

List refTuples = new List();

for(int i=0;i<used.size();++i){

Foundation::Core::ModelElement elem = used.get(i);

Model_Management::Subsystem subsSec = getClientOfMTrace(elem); session.addReference(subsSec); refTuples.add(subsSec.getRefTuple());

}

if (session.hasOnMessage()) { session.addReference(entityForMDB); refTuples.add(entityForMDB.getRefTuple()); messageDrivenBean.addReference(session);

}

} mdbTuples.add(session.getRefTuple()); session.setEJBReferenceTag(refTuples);

if{asynchMethodsExist()){ messageDrivenBean.addReference(entityForMDB);

} mdbTuples.add(entityForMDB.getRefTuple()); messageDrivenBean.setEJBReferenceTag(mdbTuples);

// /////////////////////////////////////////////////

// Transformation to session bean's inner classes //

// and setting up session beans references ------ //

// /////////////////////////////////////////////////

for(int i=0;i<beans.size();++i) {

Model_Management::Subsystem bean = beans.get(i); transformInnerClasses(bean);

}

return ejbModelPack;

7.4.2.11 EDOC to EJB transformation

This top-level transformation is responsible for all EDOC to EJB transformations.

7.4.2.11.1 Specification of Interfaces

Model_Management::Package EDOC2EJBTransformation

(Model_Management::Package inputPackage, Model_Management::Package returnPackage){

pre:

inputPackage.ownedElement->exists(elem| elem.stereotype->exists(name=’EDOCStructure’)) and inputPackage.ownedElement->exists(elem| elem.stereotype->exists(name=’EDOCProtocol’)) and inputPackage.ownedElement->exists(elem| elem.stereotype->exists(name=’EDOCComposition’)) and inputPackage.ownedElement->exists(elem| elem.stereotype->exists(name=’EDOCDataModel’))

query:

let composition :Foundation::Core::ModelElement =

Foundation::Core::ModelElement-> AllInstances->select(elem| elem.stereotype->exists(stereo|stereo.name=”EDOCComposition”)

let structPack :Model_Management::Package = Model_Management::Package->

AllInstances-> select(pack| pack.stereotype-> exists(stereo|stereo.name=”EDOCStructure”)

let protocolPack :odel_Management::Package = Model_Management::Package->

AllInstances-> select(pack| pack.stereotype-> exists(stereo|stereo.name=”EDOCProtocol”)

let documentModelPackage :Model_Management::Package =

Model_Management::Package->AllInstances->select(pack| pack.stereotype->exists(stereo|stereo.name=” EDOCDataModel”)

in body

// ///////////////////////////////////////////////////////////

// This part is responsible for transitional model creation //

// ///////////////////////////////////////////////////////////

// transModPackage - model package that will contain all model

// elements of transitional model

Model_Management::Package transModPackage =

140

} createTransitionalModelTransf(inputPackage, structPack, composition); returnPackage.ownedElement.add(transModPackage);

// //////////////////////////////////////////////////////

// This part is responsible for transformation of EDOC //

// types to Java types //

// //////////////////////////////////////////////////////

String dataTypesPackName = "DataTypes";

// dataTypesPack - package with java classes and interfaces

// that are acquired by transformation of data model package, and

// are used as types in EJB model.

Model_Management::Package dataTypesPack = createDataTypesPackage(documentModelPackage, dataTypesPackName);

// it creates interface that represents interfaces from the CCA

// model transformationOfProtocols(protocolPack,dataTypesPack); returnPackage.ownedElement.add(dataTypesPack);

// ///////////////////////////////////////////////////////////////

// This part is responsible for process component transformation//

// ///////////////////////////////////////////////////////////////

// ejbModelPack - this variable has reference to package that will

// conatian Enterprise Beans and their inner classes

Model_Management::Package ejbModelPack = transformProcessComponents(structPack, transModPackage); returnPackage.ownedElement.add(ejbModelPack);

// EDOC 2 EJB transformation is finished and result is returned

return returnPackage;

7.4.3 Document Model transformations

This group of transformation is responsible for mapping data types of the EDOC into data types used in the EJB.

7.4.3.1 Document Model to JavaClass

The aim of this transformation is to run the process of transformation from the

Document Model to Java classes. Firstly it creates the package within completely generated java classes will be stored.

Secondly, it generates IDataInvariant and IExternalDocument, whether necessary.

The EnumerationToJavaClass transformation is executed.

Next, the ExternalDocumentToJavaClass transformations are fired. This transformation is made in two steps, the Java classes hierarchy generation, i.e. this process creates empty classes connected each other by generalisation relation, and traces abstraction relation between transformed model document element and Java classes are added, and in the next step classes generated previously are filled by proper content.

Third step is the CompositeDataToJavaClass transformation, during which, similarly to the previous approach, transformation is made in two steps.

DocumentModelToJavaClass takes two input parameters:

documentModelPackage – this is a reference to document model package, which contains description of document model of transformed system,

dataTypesPackageName – name of data type package, i.e. package to which all result of performing of transformation

DocumentModelToJavaClass are stored.

7.4.3.1.1 Specification

Model_Management::Package DocumentModelToJavaClass(

141

} pre:

Model_Management::Package documentModelPackage, String dataTypesPackageName){

true query:

let compositeData : Sequence = documentModelPackage.ownedElement-> select(elem|elem.stereotype->exists(name=’CompositeData’))

let externalDocuments : Sequence = documentModelPackage.ownedElement-> select(elem|elem.stereotype->exists(name=’ExternalDocument’))

let enumerations : Sequence = documentModelPackage.ownedElement-> select(elem|elem.isOclType(Foundation::Core::Enumeration))

let invariantionControl : Boolean = documentModelPackage.ownedElement-> exists(elem|elem.stereotype->exists(name="CompositeData") and elem.constraint->exists(constraint| constraint-> exists(elem|elem stereotype->exists(name=’DataInvariant’)))) in

body:

Model_Management::Package iDataInavariant = null, iExternalDocument = null,

// it creates new package of name dataTypesPackageName

Model_Management::Package dataTypesPackage = dataTypesPackage.name = dataTypesPackageName;

// it creates proper IDataInvariant interface if necessary

// and adds it to the dataTypesPackage

if(invariantionControl){ iDataInavariant = GenerateIDataInvariant();

}

// it creates proper IDataInvariant interface if necessary

// and adds it to the dataTypesPackage

if(externalDocuments.size()>0){

}

// generates all enumeration interface

for(int i=0; i < enumerations.size(); i++){

}

}

new Model_Management::Package(); dataTypesPackage.ownedElement.add(iDataInavariant); iExternalDocument = GenerateIExternalDocument(); dataTypesPackage.ownedElement.add(iExternalDocument);

EnumerationToJavaClass(enumerations.get(i), dataTypesPackage, dataModelPackage);

// generates external documents generateGeneralizationHierarchy(externalDocuments, dataTypesPackage);

// generates all external documents

for(int i=0; i < externalDocuments.size(); i++){

ExternalDocumentToJavaClass (externalDocuments.get(i), getDataElementJavaClass (externalDocuments.get(i)),

} dataTypesPackage, dataModelPackage);

// generates composite data generateGeneralizationHierarchy(compositeData, dataTypesPackage);

// generates all composite data

for(int i=0; i < compositeData.size(); i++){

CompositeDataToJavaClass(compositeData.get(i), getDataElementJavaClass(compositeData.get(i)), dataTypesPackage, dataModelPackage);

return dataTypesPackage;

142

7.4.3.2 Generate Data Invariant interface

The intention of this transformation is to generate interface, which implementation is responsible for checking of data invariant. The interface contains an operation definition, i.e. isInvariantFulfilled, which shall perform proper invariant checking.

7.4.3.2.1 Specification

}

Foundation::Core::Class GenerateIDataInvariant(){

pre:

true

query:

body:

String isInvariantFulfilledName = ”isInvariantFulfilled”, returnParamName=”return”, iDataInvariantName = “IDataInvariant”;

Foundation::Core::Class iDataInvariant;

Foundation::Core::Operation oper;

Foundation::Core::Parameter arg1;

// set value of iDataInvariant iDataInvariant = createJavaInterface(iDataInvariantName,

Foundation::Data_Types::VisibilityKind.public,false);

// creates isInvariantFulfilled operation oper = createJavaMethod(isInvariantFulfilledName,

Foundation::Data_Types::VisibilityKind.public,

true, false, false, false, false, getModel().getModelElement("boolean"), null); oper.isQuery = true; iDataInvariant.feature.add(oper);

return iDataInvariant;

7.4.3.3 Generate External Document interface

This transformation does not take any arguments. It generates an

IExternalDocument JavaClass interface, with operations that give an access to values

stored in the definition of the external document, i.e. mimeType, specURL and

externalName. Moreover, this transformation adds also operations responsible for

setting or getting a content of document.

7.4.3.3.1 Specification

Foundation::Core::Class GenerateIExternalDocument(){

pre:

true

query: body:

String mimeTypeGetOperation = ”getMimeType”, specUrlGetOperation = ”getSpecUrl”, externalNameGetOperation = ”getExternalName”, externalNameSetOperation = “setExternalName”, externalName = “externalName”, contentSetOperation = “setContent”, contentGetOperation = “getOperation”, contentName = “content”, iExternalDocumentName = “IExternalDocument”;

Foundation::Core::Class iExternalDocument;

Foundation::Core::Operation oper;

Foundation::Core::Parameter arg1;

//set value of iExternalDocument iExternalDocument = createJavaInterface(iExternalDocumentName,

143

Foundation::Data_Types::VisibilityKind.public,false);

// creates getMimeType operation oper = createJavaMethod(mimeTypeGetOperation,

Foundation::Data_Types::VisibilityKind.public, true,

false, false, false, false, getModel().getModelElement("java::lang::String"),null); oper.isQuery = true; iExternalDocument.feature.add(oper);

// creates getSpecUrl operation oper = createJavaMethod(specUrlGetOperation,

Foundation::Data_Types::VisibilityKind.public, true,

false, false, false, false, getModel().getModelElement("java::lang::String"), null); oper.isQuery = true; iExternalDocument.feature.add(oper);

// creates externalName get operation oper = createJavaMethod(externalNameGetOperation,

Foundation::Data_Types::VisibilityKind.public, true,

false, false, false, false, getModel().getModelElement("java::lang::String"), null); oper.isQuery = true; iExternalDocument.feature.add(oper);

// creates externalName set operation oper = createJavaMethod(externalNameSetOperation,

Foundation::Data_Types::VisibilityKind.public, true,

false, false, false, false, getModel().getModelElement("void"), null); oper.isQuery = false;

// add arguments arg1 = createJParameter(externalName, false,

ParameterDirectionKind.IN, getModel().getModelElement("java::lang::String”)); oper.parameter.add(arg1); iExternalDocument.feature.add(oper);

// creates content get operation oper = createJavaMethod(externalNameSetOperation,

Foundation::Data_Types::VisibilityKind.public, true,

false, false, false, false, getModel().getModelElement("java::lang::Object”), null); oper.isQuery = true; iExternalDocument.feature.add(oper);

// creates content set operation oper = createJavaMethod(contentSetOperation,

Foundation::Data_Types::VisibilityKind.public, true,

false, false, false, false, getModel().getModelElement("void"), null); oper.isQuery = false;

// add arguments arg1 = createJParameter(contentName, false,

ParameterDirectionKind.in, getModel().getModelElement("java::lang::Object”)); oper.parameter.add(arg1); iExternalDocument.feature.add(oper);

return iExternalDocument;

144

}

7.4.3.4 Enumeration to JavaClass

The intention of transformation is to create a JavaClass that implements an

Enumeration. The class will contain two method set and get, which are responsible for

correct setting of value of the class. EnumerationLiterals are set in the resulting class, in form of public, no changeable attributes, to presents all possible values of

Enumeration type. The values of Enumeration type itself are stored in integer variable.

EnumerationToJavaClass takes three input parameters:

enumeration – transformed instance of an Enumeration,

dataTypePackage – data type package, i.e. package to which all result of performing of transformation EnumerationToJavaClass are stored,

documentModelPackage – this is a reference to document model package, which contains description of document model of transformed system.

7.4.3.4.1 Specification

EnumerationToJavaClass(

Foundation::Core::Enumeration enumeration,

Model_Management::Package dataTypePackage,

pre:

Model_Management::Package documentModelPackage){

true

query: body:

String enumPrefix = “Enum”, enumValueName=”enumValue”, trace=”trace”, javaLanguage="Java", get=”get”, set=”set”, javaClassName;

Foundation::Core::Class enumerationClass;

Foundation::Core::Attribute attribute;

Foundation::Core::Operation oper;

Foundatoin::Core::Parameter par;

Foundation::Data_Types::Expression expression=

new Foundation::Data_Types::Expression();

if(enumeration.name.length()>0)

else

javaClassName = enumPrefix+ enumeration.getFullName( documentModelPackage).substring(0,1).toUpperCase()+ enumeration.GetFullName( documentModelPackage).substring(

1,enumeration.GetFullName( enumeration, documentModelPackage).length()); javaClassName = enumPrefix; enumerationClass = createJavaClass

(javaClassName,

Foundation::Data_Types::VisibilityKind.public,

false, false, false, false, false);

// set owner of enumeration type dataTypePackage.ownedElement.add(enumerationClass);

// adds trace abstraction addStereotypedAbstraction(enumeration, enumerationClass, dataTypePackage, trace); attribute = createJavaField(enumValueName,

Foundation::Data_Types::VisibilityKind.private, false, false,

145

}

false, true, GetModel()->GetModelElement(“int”)); attribute.multiplicity = GetMultiplicity(1,1); attribute.ordering = Foundation::Data_Types::OrderingKind.ordered; enumerationClass.getFeatures().add(attribute); oper = createJavaMethod(get,

Foundation::Data_Types::VisibilityKind.public,

false, false, false,

false, false, attribute.type,

null); oper.query = true; enumerationClass.feature.add(oper); oper = createJavaMethod(set,

Foundation::Data_Types::VisibilityKind.public,

false, false, false,

false, false,

GetModel()->GetModelElement(“void”),

null); oper.query = false;

} par = createJParameter(enumValueName, false,

Foundation::Data_Types::ParameterDirectionKind.in, attribute.type); oper.parameter.add(par); enumerationClass.feature.add(oper);

for(int i=0; i<enumeration.getLiterals().size(); i++){ attribute = createJavaField( enumeration.literals.getElement(i).name,

Foundation::Data_Types::VisibilityKind.public, false, true, false, true,

GetModel()->GetModelElement(“int”)); attribute.multiplicity = GetMultiplicity(1,1); attribute.ordering =

Foundation::Data_Types::OrderingKind.ordered; expression.language = ‘Java’; expression.body = i.asString(); attribute.initialValue = expression; enumerationClass.feature.add(attribute);

7.4.3.5 Generate Generalization Hierarchy

This transformation is realized within two transformations , i.e.

GenerateGeneralizationHierarchy and GeneralizationHierarchyForDataElement. The

aim of this transformation is to create a generalization hierarchy of given List of

GeneralizableElements. This transformation preserves Java restrictions on

generalization, thereby converts multi-inheritance to single -inheritance relationship.

GenerateGeneralizationHierarchy takes two input parameters:

list – is a list of all used DataElements,

dataTypePackage – is a data type package, i.e. package to which all result of performing of transformation the transformation is stored.

7.4.3.5.1 Specification – GenerateGeneralizationHierarchy

GenerateGeneralizationHierarchy(List list,

Core::Package dataTypePackage){

pre:

list->forAll(elem-> oclIsKindOf(Foundation::Core::GeneralizableElement) and

(elem->isOclType(Foundation::Core::Enumeration) or elem.stereotype->exists(name=’CompositeData’) or

146

query:

elem.stereotype->exists(name=’ExternalDocument’)) or elem->isOclType(Foundation::Core::DataType)))

-- select all elements on top of generalization hierarchy

let trees:Sequence(Foundation::Core::Generalization) = list-> select(elem|elem.generalization-> size()=0) in

body:

String trace=”trace”;

Foundation::Core::Class clazz;

// for each model element creates a class that corresponds

// to represented data element and adds trace abstraction between

// these elements

for( int i=0; i<trees.size(); i++){ clazz = new Foundation::Core::Class(); dataTypePackage.ownedElement.add(clazz); trees.get(i).addStereotypedAbstraction(clazz, trace);

}

// do the same for all subclasses

GeneralizationHierarchyForDataElement( trees.get(i), clazz, dataTypePackage);

}

7.4.3.5.2 Specification – GeneralizationHierarchyForDataElement

GeneralizationHierarchyForDataElement(

Foundation::Core::Generalizable dataElement,

Foundation::Core::Generalizable parentClass

Foundation::Core::Package dataTypePackage){

pre:

dataElement->isOclType(Foundation::Core::Enumeration) or dataElement.stereotype->exists(name=’CompositeData’) or dataElement.stereotype->exists(name=’ExternalDocument’) or dataElement->isOclType(Foundation::Core::DataType))

query:

-- select all elements on top of generalization hierarchy

body:

let children:Sequence = dataElement.specialization.child in

String trace=”trace”;

Foundation::Core::Class clazz, prevParent;

// for each model element creates a class that corresponds

// to represented data element and adds trace abstraction between

// these elements

for( int i=0; i< children.size(); i++){

// checks whether there is a correspond to particular dataElement

if(!children.get(i).doesDataElementJavaClassExist()){

// create new class

}

else{

} clazz = new Foundation::Core::Class(); dataTypePackage.ownedElement.add(clazz);

// set the trace children.get(i).addStereotypedAbstraction(clazz, trace); clazz = children.get(i).getDataElementJavaClass();

//now one have a situation where

//mulitsub-classing has been made

//it is forbidden in Java,

//thus one has to insert parentClass

//between prevParent, and

//clazz in hierarchy, nevertheless

// the problems of covered

//attributes, still remains prevParent =clazz.generalization. getElementsIterator().next(); removeGeneralization(prevParent,clazz); addGeneralization(prevParent, parentClass); addGeneralization(parentClass,clazz,dataTypePackage);

147

}

}

// do the same for all subclasses generalizationHierarchyForDataElement( children.get(i), clazz, dataTypePackage);

7.4.3.6 ExternalDocument to JavaClass

The intention of this transformation is to fill the class that represents an

externalDocument. The tagged values added to ExternalDocument, are transformed to

frozen attributes accessed by methods, which are implemented according

IExternalDocument, generated by different transformation. Moreover, the attribute

content is added. The attribute represent the content of the ExternalDocument.

The transformation takes four input parameters:

externalDocument – represents externalDocument,

externalDocumentClass – class that represents externalDocument,

dataTypePackage – data type package, i.e. package to which all result of performing of transformation the transformation are stored,

documentModelPackage – this is a reference to document model package, which contains description of document model of transformed system.

7.4.3.6.1 Specification

ExternalDocumentToJavaClass(

Foundation::Core::DataType externalDocument,

Foundation::Core::Class externalDocumentClass,

pre:

Model_Management::Package dataTypePackage,

Model_Management::Package documentModelPackage){ externalDocument.stereotype->exists(name=’ExternalDocument’);

query:

let mimeType:String = externalDocument.taggedValues-> select(taggedValue|taggedValue.type.name=’mimeType’)->first()-> oclAsType(Foundation::Extension_Mechanisms::TaggedValue). dataValue->first()->oclAsType(String)

let specUrl:String = externalDocument.taggedValues-> select(taggedValue|taggedValue.type.name= ‘specUrl’)->first()-> oclAsType(Foundation::Extension_Mechanisms::TaggedValue). dataValue->first()->oclAsType(String)

let externalName:String = externalDocument.taggedValues-> select(taggedValue|taggedValue.type.name=‘externalName’)->first()-> oclAsType(Foundation::Extension_Mechanisms::TaggedValue). dataValue->first()->oclAsType(String) in

body:

String mimeTypeAttribute = ”mimeType”, specUrlAttribute = ”specURL”, externalNameAttribute = ”externalName”, iExternalDocumentName = “IExternalDocument”, realize=”realize”;

String javaLanguage="Java";

Foundation::Core::Class externalDocumentInterface;

Foundation::Core::Attribute attribute;

Foundation::Data_Type::Expression initialValue;

// set value of class’ attributes makeJavaClass(externalDocumentClass, externalDocument.GetFullName(documentModelPackage),

Foundation::Data_Types::VisibilityKind.public,

false, false,

false, false, false);

148

}

// set inheritance to interface externalDocumentInterface = dataTypePackage.getModelElement(iExternalDocumentName);

// adds realize abstraction externalDocumentInterface.addStereotypedAbstraction( externalDocumentClass, realize);

ImplementJavaInterface(externalDocumentClass, externalDocumentInterface,”JavaInterface”);

// create new attribute that holds mimeAttribute attribute = createJavaField(mimeTypeAttribute,

Foundation::Data_Types::VisibilityKind.private,

false, true,

false, true); initialValue = new Foundation::Data_Type::Expression(); initialValue.language = javaLanguage; initialValue.body = “\””+mimeType+”\””; attribute.multiplicity = getMultiplicity(1,1); attribute.ordering = Foundation::Data_Types::OrderingKind.ordered; attribute.initialValue = initialValue attribute.type = getModel().getModelElement(“java::lang::String”); externalDocumentClass.feature.add(attribute);

// create new attribute that holds specUrlAttribute attribute = createJavaField(specUrlAttribute,

Foundation::Data_Types::VisibilityKind.private,

false, true,

false, true, getModel().getModelElement(“java::lang::String”)); initialValue = new Foundation::Data_Type::Expression(); initialValue.language = javaLanguage; initialValue.body = “\””+specUrl+”\””; attribute.multiplicity = getMultiplicity(1,1); attribute.ordering = Foundation::Data_Types::OrderingKind.ordered; attribute.initialValue = initialValue; externalDocumentClass.feature.add(attribute);

// create new attribute that holds externalNameAttribute attribute = createJavaField(externalNameAttribute,

Foundation::Data_Types::VisibilityKind.private,

false, true,

false, true, getModel().getModelElement(“java::lang::String”)); initialValue = new Foundation::Data_Type::Expression(); initialValue.language = javaLanguage; initialValue.body = “\””+externalName+”\””; attribute.multiplicity = getMultiplicity(1,1); attribute.ordering = Foundation::Data_Types::OrderingKind.ordered; attribute.initialValue = initialValue; externalDocumentClass.feature.add(attribute);

7.4.3.7 Compos iteData to JavaClass

The intention of this transformation is to generate the class that represents the composite data. The task of this transformation is go trough all attributes embedded in that class and, if necessary, invoke proper transformation method.

The transformation ignores tagged value, isByValue, and transform or attributes as references to particular instances of Java classes.

The transformation takes four input parameters:

149

compositeData – represents compositeData,

compositeType – class that represents compositeType,

dataTypePackage – data type package, i.e. package to which all result of performing of transformation the transformation are stored,

documentModelPackage – this is a reference to document model package, which contains description of document model of transformed system.

7.4.3.7.1 Specification

CompositeDataToJavaClass (

Foundation::Core::Class compositeData,

Foundation::Core::Class compositeType,

Model_Management::Package dataTypePackage,

pre:

Model_Management::Package documentModelPackage){ compositeData.stereotype->exists(name=’CompositeData’);

query:

let compositions:Sequence = composideData.feature-> select(elem :Foundation::Core::Attribute| elem.type.stereotype->exists(name=’CompositeData’))

let externalDocuments:Sequence = composideData.feature-> select(elem:Foundation::Core::Attribute| elem.type.stereotype->exists(name=’ExternalDocument’))

let enumerations:Sequence = compositeData.feature-> select(elem :Foundation::Core::Attribute| elem->isOclType(Foundation::Core::Enumeration))

let dataTypes:Sequence = compositeData.feature-> select(elem :Foundation::Core::Attribute|

not (elem.type->isOclType(Foundation::Core::Enumeration) or elem.type.stereotype->exists(name=’CompositeData’) or elem.type.stereotype->exists(name=’ExternalDocument’)) and elem.type->isOclType(Foundation::Core::DataType))

let invariantionControl:Boolean = compositeData.constraint-> exists(elem :Foundation::Core::Attribute| elem.type.stereotype->exists(name=’DataInvariant’)) in

body:

String iDataInvariantName = “IDataInvariant”, realize=”realize”;

Foundation::Core::Attribute attribute;

Foundation::Core::Class type;

Foundation::Core::Constraint constraint;

Foundation::Core::Class dataInvariantInterface;

Foundation::Core::Operation oper;

Foundation::Core::Parameter arg1; makeJavaClass(compositeType, compositeData.GetFullName(documentModelPackage),

Foundation::Data_Types::VisibilityKind.public,

false, false,

false, false, false);

for(int i=0; i<compositions.size();i++){ type = getDataElementJavaClass(compositions.get(i)).type; attribute = createJavaField( compositions.get(i).name,

Foundation::Data_Types::VisibilityKind.public,

false, true,

false, true, type); attribute.multiplicity = compositions.get(i).multiplicity; attribute.initalValue = compositions.get(i).initialValue; attribute.ordering = Foundation::Data_Types::OrderingKind.ordered; compositeType.feature.add(attribute);

150

}

// add proper access method to the compositeType addAccessJavaMethods(attribute, compositeType);

}

for(int i=0; i< enumerations.size();i++){ type = getDataElementJavaClass(enumerations.get(i)).type; attribute = createJavaField(enumerations.get(i).name,

Foundation::Data_Types::VisibilityKind.public,

false, false,

false, true, type);

} attribute.multiplicity = enumerations.get(i).multiplicity; attribute.ordering =

Foundation::Data_Types::OrderingKind.ordered; compositeType.feature.add(attribute);

// add proper access method to the compositeType addAccessJavaMethods(attribute, compositeType);

for(int i=0; i< externalDocuments.size();i++){ type = getDataElementJavaClass( externalDocuments.get(i)).type;; attribute = createJavaField(externalDocuments.get(i).name,

Foundation::Data_Types::VisibilityKind.public,

false, false,

false, true, type); attribute.multiplicity = externalDocuments.get(i).multiplicity; attribute.ordering =

Foundation::Data_Types::OrderingKind.ordered; compositeType.feature.add(attribute);

// add proper access method to the compositeType addAccessJavaMethods(attribute, compositeType);

for(int i=0; i< dataTypes.size();i++){ type = dataTypes.get(i).type; attribute = createJavaField(dataTypes.get(i).name,

Foundation::Data_Types::VisibilityKind.public,

false, false,

false, true, type);

} attribute.multiplicity = dataTypes.get(i).multiplicity; attribute.ordering =

Foundation::Data_Types::OrderingKind.ordered; compositeType.feature.add(attribute);

// add proper access method to the compositeType addAccessJavaMethods(attribute, compositeType);

// if invariantion control is added,

//make this class an implementation of

// IDataInvariant

if(invariantionControl){

// set inheritance to class IDataInvariant dataInvariantInterface = dataTypePackage.getModelElement(iDataInvariantName);

// adds realize abstraction dataInvariantInterface.addStereotypedAbstraction( compositeType, realize);

}

ImplementInterface( compositeType, dataInvariantInterface,”JavaInterface”);

151

}

7.4.3.8 Add Access JavaMethods

The transformation generates access operations to the public attribute within a class, which are given as transformation parameter. The transformation does not return any value. The transformation has two main different behaviours with respect to type of attribute given as input.

If attribute is given with multiplicity 0..1, 1, then operations getAttributeName and

setAttributeName are created and attributed to the given class.

The getAttributeName operations shall return a reference to an instance of the proper attribute.

The setAttributeName returns a reference to an instance of the attribute. The last one is generated only in case attributes which changeability is different then frozen.

Finally, the visibility of the attribute is changed to private.

If attribute is given with multiplicity n..m, where n > 1, then the type of the attribute is changed to java::util::List, and new name of the attribute is set as a primary name of the attribute concatenated with “s”.

Further, proper access operation is made, i.e.

addAttributeName,

setAttributeNameAt, getAttributeNameAt, removeAttributeNameAt,

getAttributeNameCount and they are attributed to the given class.

The addAttributeName, is an operation that adds a reference to an instance of the primary type of the attribute at the end of the list.

The setAttributeNameAt sets a reference to a new instance of the type in the list at given position, which is in between zero and length – 1 of the list of the attributes.

The getAttributeNameAt returns a reference to an instance of the type in the list at given position, which is in between zero and length – 1 of the list of the attributes.

The removeAttributeNameAt removes a reference to an instance of the type in the list at given position, which is in between zero and length – 1 of the list of the attributes. Indexes of all references in the list of positions’ index bigger than index of the position are decremented. The length of the list is decremented.

The getAttributeNamesCount returns a length’s value of the list of the attributes.

The operations addAttributeName, setAttributeNameAt, removeAttributeNameAt are generated only in case attributes which changeability is different then frozen.

Finally, the visibility of the attribute is changed to private.

The transformation takes two input parameters:

attribute – processed attribute

clazz – is a class that contains an attribute.

7.4.3.8.1 Specification

AddAccessJavaMethods(Foundation::Core::Attribute attribute,

Foundation::Core::Class clazz){

pre:

attribute.visibility =

Foundation::Data_Types::VisibilityKind.public

query:

let sequence:Boolean = attribute.multiplicity.upper > 1

let readOnly:Boolean = attribute.changeability =

Foundation::Data_Types.frozen in

body:

Foundation::Core::Operation oper;

Foundation::Core::Parameter arg1, arg2, arg3;

String getPrefix = “get”, setPrefix=”set”, addPrefix=”add”, atPostfix=”At”, removePrefix=”remove”, indexName=”index”, countPostfix=”count”, operationName;

152

if(!sequence){

// creates get operation

if(attribute.name.length() > 0) operationName = getPrefix + attribute.name.substring(0,1).toUpperCase() + attribute.name.substring(

else

1,attribute.name.length()); operationName = getPrefix; oper = createJavaMethod(operationName,

Foundation::Data_Types::VisibilityKind.public,

false, false, false, false, false, attribute.type, null); oper.isQuery = true; clazz.feature.add(oper);

// if not readOnly add the set operation

if(!readOnly){

// creates set operation

if(attribute.name.length() > 0) oper.name = getPrefix + attribute.name.substring(0,1).toUpperCase() +

else

attribute.name.substring(

1,attribute.name.length()) + atPostfix; oper.name = getPrefix; oper = createJavaMethod(operationName,

Foundation::Data_Types::VisibilityKind.public,

false, false, false, false, false, getModel().getModelElement(“void”), null); oper.isQuery = false;

// add arguments arg1 = createJParameter(attribute.name, false,

Foundation::Data_Types::ParameterDirectionKind.in, attribute.type); oper.parameter.add(arg1);

// add operation to class clazz.feature.add(oper);

}

}

else{

// list type is provided

// creates getAt operation

if(attribute.name.length() > 0) operationName = getPrefix + attribute.name.substring(0,1).toUpperCase() +

else

attribute.name.substring(1,attribute.name.length()) + atPostfix; operationName = getPrefix+atPostfix; oper = createJavaMethod(operationName,

Foundation::Data_Types::VisibilityKind.public, false, false, false, false, false, attribute.type, null); oper.isQuery = true;

// add arguments arg1 = createJParameter(indexName, false,

Foundation::Data_Types::ParameterDirectionKind.in,

153

getModel().getModelElement(“int”)); oper.parameter.add(arg1);

// add operation to class clazz.feature.add(oper);

// creates getCount operation

if(attribute.name.length() > 0) operationName = getPrefix + attribute.name.substring(0,1).toUpperCase() +

else

attribute.name.substring(1,attribute.name.length()) + countPostfix; operationName = getPrefix+atPostfix; oper = createJavaMethod(operationName,

Foundation::Data_Types::VisibilityKind.public,

false, false, false, false, false, getModel().getModelElement(“int”), null); oper.isQuery = true;

// add operation to class clazz.feature.add(oper);

// if not readOnly add the set operation

if(!readOnly){

// creates add operation

if(attribute.name.length() > 0)

else else

operationName = addPrefix + attribute.name.substring(0,1).toUpperCase() + attribute.name.substring(1,attribute.name.length()); operationName = addPrefix; oper = createJavaMethod(operationName, oper.isQuery = false;

// add arguments arg1 = createJParameter(attribute.name, false, oper.parameter.add(arg1);

Foundation::Data_Types::VisibilityKind.public,

false, false, false, false, false, getModel().getModelElement(“void”), null);

Foundation::Data_Types::ParameterDirectionKind.in, attribute.type);

// add operation to class clazz.feature.add(oper);

// creates setAt operation

if(attribute.name.length() > 0) operationName = setPrefix + attribute.name.substring(0,1).toUpperCase() + attribute.name.substring(1,attribute.name.length()) + atPostfix; operationName = setPrefix +atPostfix; oper = createJavaMethod(operationName,

Foundation::Data_Types::VisibilityKind.public,

false, false, false, false, false, getModel().getModelElement(“void”), null); oper.isQuery = false;

// add arguments arg1 = createJParameter(attribute.name, false,

Foundation::Data_Types::ParameterDirectionKind.in, attribute.type); arg2 = createJParameter(indexName, false,

154

Foundation::Data_Types::ParameterDirectionKind.in, getModel().getModelElement(“int”)); oper.parameter.add(arg1); oper.parameter.add(arg2);

// add operation to class clazz.feature.add(oper);

// creates removeAt operation

if(attribute.name.length() > 0)

else

operationName = removePrefix + attribute.name.substring(0,1).toUpperCase() + attribute.name.substring(1,attribute.name.length()) + atPostfix; operationName = removePrefix +atPostfix; oper = createJavaMethod(operationName,

Foundation::Data_Types::VisibilityKind.public, false, false, false, false, false, getModel().getModelElement(“void”), null); oper.isQuery = false;

// add arguments arg1 = createJParameter(indexName, false,

Foundation::Data_Types::ParameterDirectionKind.in, getModel().getModelElement(“int”)); oper.parameter.add(arg1);

}

// add operation to class clazz.feature.add(oper);

// change types and name of the attribute attribute.name = attribute.name; attribute.type = getModel().getModelElement(“java::util::List”);

}

// change attribute visibility to protected attribute.visibility = Foundation::Data_Types::VisibilityKind.protected;

}

7.4.4 OCL Function Specifications

The functions used in the specification of the transformations are presented below.

7.4.4.1 Add Generalization

-- it adds a generalization relationship beetwen self and child

context Foundation::Core::GeneralizableElement::removeGeneralization

(child:Foundation::Core::GeneralizableElement)

pre:

-- generalization between parent and child must exist

post:

not self.specialization->exists(spec | spec.child=child)

self.specialization->exists(spec| spec.child=child)

7.4.4.2 Add Stereotype by String

-- it sets a stereotype of name stereotypeName

context

Foundation::Core::ModelElement::addStereotypeByString(stereotypeName :

String)

pre:

-- the stereotype is not yet set for the model element

self->stereotype->exists(name <> stereotypeName)

155

post:

self.stereotype->exists(name=stereotypeName)

7.4.4.3 Add Stereotyped Abstraction

-- this method add an abstraction relationship, and stereotypes of name -

-- as stereotypeName

context Foundation::Core::ModelElement::addStereotypedAbstraction ( client:Foundation::Core::ModelElement, stereotypeName:String)

pre:

true

post:

self.supplierDependency->exists(supp| spec.client=client

and supp->addStereotypeByString(stereotypeName)

and supp.oclIsType(Foundation::Core::Abstraction))

7.4.4.4 Add Subsystems by UML Usage

-- this method adds to List all Subsystems that

-- are connected by UML Usage with –

-- self and have a supplier role in this UML Usage

context Model_Management::Subsystem ::addSubsUsedBy( used:Sequence(Model_Management::Subsystem)) :

Sequence(Model_Management::Subsystem)

pre:

post:

true

let newU: Sequence(Model_Management::Subsystem) =

Model_Management::Subsystem->allInstances()-> select(subs|subs.supplierDependency->exists( usage:Foundation::Core:Usage| usage.client->exists(self)))

in

result = used->union(newU)

7.4.4.5 Add Usage

-- this method add an usage relationship,

context Foundation::Core::ModelElement::addUsage ( client:Foundation::Core::ModelElement, stereotypeName:String)

pre:

true

post:

self.supplierDependency->exists(supp| spec.client=client

and supp->addStereotypeByString(stereotypeName)

and supp.owner= package_

and supp.oclIsType(Foundation::Core::Abstraction))

7.4.4.6 Create Bean Subsystem

-- this operation returns sequence of Subsystems. Each of subsystems are

-- connected by <<Mtrace>> dependency with propper ModelElements> that

-- are given in the input sequence.

context Sequence(Foundation::Core::ModelElement)::createBeanSubs() :

Sequence(Model_Management::Subsystem)

pre: self->flatten()->forAll(e | e.stereotype.name = ‘ProcessComponent’)

post: result->forAll(elem: Model_Management::Subsystem |

self->includes(proComp: Foundation::Core::ModelElement| procComp.name=elem.name->getFullName() and procComp.supplierDependency->includes

(dep:Foundation::Core::Dependency | dep.client=elem and dep.Stereotype.name=’MTrace’)))

7.4.4.7 Create Java Class

-- result of the operation is an instance of Foundation::Core::Class

156

-- that fulfills constraints for JavaClass

context createJavaClass(name : String, visibility :

Foundation::Data_Types::VisibilityKind, isAbstract : Boolean, isStatic :

Boolean, isFinal : Boolean, isStricfp : Boolean, isActive : Boolean):

Foundation::Core:Class

pre:

post:

true

result.name = name and

result.visibility = visibility and

result.isAbstract = isAbstract and

result.isLeaf = isFinal and

result.ownerScope = if isStatic

then Foundation::Data_Types::ScopeKind.classifier

else Foundation::Data_Types::ScopeKind.instance endif and result.taggedValue-> exists(tagVal| tagVal.type.name = ‘JavaStatic’ and dataValue->first()->oclAsType(String) =

if isStatic then ‘true’ else ‘false’ endif) and result.taggedValue-> exists(tagVal| tagVal.type.name = ‘JavaStrictfp’ and dataValue->first()->oclAsType(String) =

if isStricfp then ‘true’ else ‘false’ endif)

and true

-- the other constraints are presented in the paper [31]

7.4.4.8 Create Java Field

-- result of the operation is an instance of Foundation::Core::Attribute

-- that fulfills constraints for JavaField

context createJavaField(name : String, visibility :

Foundation::Data_Types::VisibilityKind, isStatic : Boolean, isFinal :

Boolean, isVolatile : Boolean, isTransient : Boolean, jType :

Foundation::Core::Classifier): Foundation::Core:Attribute

pre:

true

post:

result.name = name and

result.visibility = visibility and

result.ownerScope = if isStatic

then Foundation::Data_Types::ScopeKind.classifier

else Foundation::Data_Types::ScopeKind.instance endif and result.changeability = if isFinal

then Foundation::Data_Types::ChangeableKind.frozen

else Foundation::Data_Types::ChangeableKind.changeable

endif and result.taggedValue-> exists(tagVal| tagVal.type.name = ‘JavaVolatile’ and dataValue->first()->oclAsType(String) =

if isVolatile then ‘true’ else ‘false’ endif) and result.taggedValue-> exists(tagVal| tagVal.type.name = ‘persistence’ and dataValue->first()->oclAsType(String) =

if isTransient then ‘true’ else ‘false’ endif) and tru

-- the other constraints are presented in the paper [31]

7.4.4.9 Create Java Interface

-- result of the operation is an instance of Foundation::Core::Class

-- that fulfills constraints for JavaInterface

context createJavaClass(name : String, visibility :

Foundation::Data_Types::VisibilityKind, isStatic : Boolean):

Foundation::Core:Class

pre:

true

157

post:

result.name = name and

result.ElementOwnership.visibility = visibility and

result.isAbstract = true and

result.isLeaf = isFinal and result.taggedValue-> exists(tagVal| tagVal.type.name = ‘JavaStatic’ and dataValue->first()->oclAsType(String) =

if isStatic then ‘true’ else ‘false’ endif)

and true

-- the other constraints are presented in the paper [31]

7.4.4.10 Create Java Method

-- result of the operation is an instance of Foundation::Core::Operation

-- that fulfills

-- constraints for JavaMethod and if type is not null it contians

-- return paramter

-- with type set on type argument of the function

context createJavaMethod(name : String, visibility :

Foundation::Data_Types::VisibilityKind, isAbstract : Boolean, isStatic :

Boolean, isFinal : Boolean, isNative : Boolean, isSynchronized : Boolean, returnType : Foundation::Core::Classifier, exceptions :

Sequence(String)): Foundation::Core:Operation

pre:

post:

true

result.name = name and

result.visibility = visibility and

result.isAbstract = isAbstract and

result.ownerScope = if isStatic

then Foundation::Data_Types::ScopeKind.classifier

else Foundation::Data_Types::ScopeKind.instance endif and result.isLeaf = isFinal and result.taggedValue-> exists(tagVal| tagVal.type.name = ‘JavaNative’ and dataValue->first()->oclAsType(String) =

if isNative then ‘true’ else ‘false’ endif) and

if isSynchronized then result.concurrency =

Foundation::Data_Types::ConcurrencyKind.guarded endif and

if not type = null

then return.parameter->exists(param| param.kind =

Foundation::Data_Types::ParameterDirectionKind.return and param.type = type and param.name = ‘’ and param.taggedValue->exists(tagVal| tagVal.type->exists(name = ‘JavaFinal’) and tagVal.dataValue-> first()->oclAsType(String) = ‘false’) and

if return.parameter.contains(par2)

then par2=param else true endif)

else true endif and

result.taggedValue-> forAll(tagVal| if tagVal.type.name=’JavaThrows’ then exceptions.contains(tagVal.dataValue-> first()->oclAsType(String)) else true endif) and exceptions->forAll(elem| result.taggedValue->exists(tagVal| tagVal.type.name=’JavaThrows’and tagVal.dataValue->first()->oclAsType(String)=elem) and true

-- the other constraints are presented in the paper [31]

7.4.4.11 Create Java Parameter

-- result of the operation is an instance of Foundation::Core::Parameter

-- that fulfulls contraints for Parameters for JavaMethod

158

context createJParameter(name : String, isFinal : Boolean,paramDirect:

Foundation::data_Types::ParameterDirectionKind, paramType :

Foundation::Core::Classifier): Foundation::Core:Parameter

pre:

true

post:

result.name = name and

result.type = paramType and

result.taggedValue->exists(tagVal| tagVal.type.name = ‘JavaFinal’

and tagVal.dataValue->first()oclAsType(String) = if isFinal

then ‘true’ else ‘false’ endif) and

result.kind = paramDirect) and true

-- the other constraints are presented in the paper [31]

7.4.4.12 Create MultiPort Class

-- result of the operation is an instance of Foundation::Core::Class

-- that represents multiport in the EJB

context createMultiPortClass(multip : Foundation::Core::Class, impl : Foundation::Core::Class): Foundation::Core:Class

pre: multip.stereotype->exists(name=’MultiPort’) and

post:

impl.stereotype->exist(name=’EJBImplementation’)

result.name = multip.name and

result.visibility =

Foundation::Data_Types::VisibilityKind.private and

result.isAbstract = false and

result.isLeaf = false and

result.isActive = false and

result.ownerScope = if isStatic

then Foundation::Data_Types::ScopeKind.classifier

else Foundation::Data_Types::ScopeKind.instance endif and

result.taggedValue-> exists(tagVal| tagVal.type.name = ‘JavaStatic’ and dataValue->first()->oclAsType(String) = ‘false’) and result.taggedValue-> exists(tagVal| tagVal.type.name = ‘JavaStrictfp’ and dataValue->first()->oclAsType(String) = ‘false’) and impl.feature->exists(creatJavaField(

) and

) multip.name->concat(‘Arg’),

Foundation::Data_Types::VisibilityKind.private,

result.feature->exists(createJavaMethod( ‘isBufferFull’,

))

false, false, false, true, result)

Foundation::Data_Types::VisibilityKind.public,

false, false, false, false, false, getModel()->getModelElement(‘boolean’), Sequence({}))

-- it fulfills other constraints on JavaClass that

-- are presented in the paper [31]

7.4.4.13 Does DataElement-JavaClass Trace Exist

-- it returns a true whether type class that corresponds dataElement exists

context Foundation::Core::ModelElement:: doesDataElementJavaClassExist(dataElement :

Foundation::Core::ModelElement) : Boolean

pre:

-- elements are of one of type or are stereotyped as

self.isOclType(Foundation::Core::Enumeration) or

self.stereotype->exists(name=’CompositeData’) or

self.stereotype->exists(name=’ExternalDocument’) or

self.isOclType(Foundation::Core::DataType)

159

post: result =

-- checks whether there is abstract dependency stereotyped by <<trace>>

self.supplierDependency->exists

(abstr:Foundation::Core::Abstraction|abstr.stereotype-

>exists(name=’trace’)

and abstr.client->first()->oclIsTypeOf(Foundation::Core::Class)

and abstr.client->size()=1)

7.4.4.14 Flatten package

-- it returns a sequence of all model document’s elements

context Model_Management::Package::flattenPackage() :

Sequence(Foundation::Core::ModelElement)

pre: true post:

let seq:Sequence(Foundation::Core::ModelElement)=Sequence({}) in

result = self.ownedElement->select(elem|not elem.isOclType(Model_Management:: Package))

->includesAll(

self.ownedElement->forAll( elem:Model_Management::Package| seq.includesAll(elem->flattenPackage())

)

)

7.4.4.15 Get all ProcessComponents used in a CommunityProcess

-- result of the operation is a sequence of ProcessComponents used

-- in a communityProcess

context Foundation::Model_Management::Package:: getAllComponentsUsedInCP

(communityProcess : Foundation::Model Management::Subsystem) :

Sequence(Foundation::Core::ModelElement)

pre:

communityProcess.stereotype->exists(name=‘CommunityProcess’)

post:

result = self-> flattenPackage()->

select(elem | elem->isComponentUsedBy(communityProcess))

7.4.4.16 Get Client of MTrace UML

-- this method returns Classifier that plays a client role in MTrace UML

-- Usage with self, where self plays a supplier role.

context Foundation::Core::Classifier:: getClientOfMTrace():Foundation::Core::Classifier

pre:

self.supplierDependency->select(dep|

post:

dep.stereotype->exists(stereo|stereo.name=’MTrace’))

result.clientDependency->exists(dep| dep.stereotpe->exists(stereo|stereo.name=’MTrace’) and dep.supplier->first()=self)

7.4.4.17 Get DataElement-JavaClass

-- it returns a data type class that corresponds to DocumentModel

-- DataElement

context Foundation::Core::ModelElement::getDataElementJavaClass() :

Foundation::Core::ModelElement

pre:

-- elements are of one of type or are stereotyped as

((self.isOclType(Foundation::Core::Enumeration) or

self.stereotype->exists(name=’CompositeData’) or

self.stereotype->exists(name=’ExternalDocument’))) and

-- checks whether there is abstract dependency

self.supplierDependency->exists

(abstr:Foundation::Core::Abstraction|abstr.stereotype-

>exists(name=’trace’)

160

and abstr.client->first()->oclIsTypeOf(Foundation::Core::Class)

and abstr.client->size()=1) or

self.isOclType(Foundation::Core::DataType)

post: result = if(self.isOclType(Foundation::Core::Enumeration) or

self.stereotype->exists(name=’CompositeData’) or

self.stereotype->exists(name=’ExternalDocument’))

then self.supplierDependency

->select (abstr:Foundation::Core::Abstraction|abstr.stereotype-

>exists(name=’trace’)

and abstr.client->oclIsTypeOf(Foundation::Core::Class))

->first()->oclAsType(Foundation::Core::Abstraction).client

->oclAsType(Foundation::Core::Class)

else self endif

7.4.4.18 Get EJBCmpFields

-- this method returns Attributes with <<EJBCmpField>>

context Foundation::Core::Class:: getEJBCmpFields():Sequence(Foundation::Core::Attribute)

pre:

post:

true

result.forAll(att:Foundation::Core::Attribute| att.stereotype->exists(stereo|stereo.name=’EJBCmpField’) and

self.feature->contains(att))

7.4.4.19 Get EJBPrimaryKeyField

-- this method returns Attributes with <<EJBPrimaryKeyField>>

context Foundation::Core::Class

:getPrimKeyAttr()::Sequence(Foundation::Core::Attribute)

pre:

true

post:

result.forAll(att:Foundation::Core::Attribute| att.stereotype->exists(stereo|stereo.name=’EJBPrimaryKeyField’) and

self.feature->contains(att))

7.4.4.20 Get Exceptions

-- this method returns exceptions related operationPort

context Foundation::Core::Class::getExceptions

(flowPorts:Sequence(Foundation::Core::Class))

:Sequence(String)

pre:

post:

true

result->first()=’java.rmi.RemoteException’

7.4.4.21 Get FlowPort Type

-- this method returns Classifier that is a type of the FlowPort

context Foundation::Core::Class:: getFlowTypeValue():Foundation::Core::Classifier

pre:

self.stereotype->exists(stereo| stereo.name = ‘FlowPort’)

post:

result = Foundation::Core::Classifier->allInstances()->select( clf|(cl.stereotype->exists(stereo| stereo.name = ‘ExternalDocument’ or stereo.name = ‘CompositeData’) or cl.oclIsKindOf(Foundation::Core::DataType) or cl.oclIsKindOf(Foundation::Core::Enumeration)) and cl.association.exists(assocEnd| assocEnd.association->exists(assoc| assoc.connection->exists(assocEnd2| assocEnd2.participant = self))))

161

7.4.4.22 Get FlowPorts

-- Get FlowPorts used by ProcessComponent

context Foundation::Core::Classifier:: getFlowPorts():Sequence(Foundation::Core::Class)

pre:

post:

self.stereotype->exists(stereo| stereo.name = ‘ProcessComponent’)

result = Foundation::Core::Class->allInstances->select(port | port.stereotype->exists(stereo|stereo.name=’FlowPort’) and port.association->exists(assEnd| assEnd.association.connection-> exists(assEnd|assEnd.participant = self)))

7.4.4.23 Get Full Name

--it returns the text is the concatenation of names of packages on

--the path between mainPackage and self element with self elements’s name

context Foundation::Core::ModelElement::getFullName

(mainPackage:Model_Management::Package):String

pre: self.stereotype->exists(name=’ProcessComponent’) and mainPackage->includesRec(self)

post: result = self.name.concat(if self.namespace <> mainPackage

then self.namespace->getFullName(mainPackage) else ‘’ endif)

7.4.4.24 Get Index of

-- This operation returns index of first occurrence of given string in

-- self string

context String ::indexOf(String str): Integer

pre: true post:

let a:Set(Integer) = Set(Integer)-

>forAll(int|self.substring(int,int+str.size())=str)

in

if a.size()>0 then a.forAll(i| result<=i and a.includes(result)) else

result = -1 endif

7.4.4.25 Get InnerClasses

-- This method acquires process components that will be transformed to

-- inner

-- classes for given session bean

context Model_Management::Subsystem::getInnerClasses():

Sequence(Foundation::Core::Classifier)

pre:

self.stereotype->exists(stereo| stereo.name = ‘EJBSessionBean’)

post:

result->forAll(procComp : Foundation::Core::Classifier| procComp->getClientOfMTraceBySupplier().namespace-> getClientOfMTraceBySupplier() = self)

7.4.4.26 Get In Parameters

-- This method returns in parameters of operation

context Foundation::Core::Operation:: getParameters():Sequence(Foundaiton::Core::Parameter)

pre: post: true

result = self.parameters->select(param| param.kind = Foundation::Data_Types::

ParameterDirectionKind.in)

7.4.4.27 Get Interfaces

-- Get Interfaces used by ProcessComponent

context Foundation::Core::Classifier:: getInterfaces():Sequence(Foundation::Core::Class)

162

pre:

self.stereotype->exists(stereo| stereo.name = ‘ProcessComponent’)

post:

result = Foundation::Core::Class->allInstances->select(port| port.stereotype->size()=0 and port.association->exists(assEnd| assEnd.association.connection->exists(assEnd| self.getProtocolPorts.includes(assEnd.participant))))

7.4.4.28 Get JavaThrows

-- This method checks returns dataValue of JavaThrows TaggedValue

context Foundation::Core::Operation::getThrows(): Sequence(String)

pre: post: true

result = self->getTaggedValue(‘JavaThrows’).dataValue

7.4.4.29 Get Model

-- it returns a model, that contains all model elements

context getModel() :: Model_Management::Model

pre: true

post: result = Model_Management::Model->allInstances()->first()

7.4.4.30 Get ModelElement

-- it returns a true whether type class that corresponds dataElement exists

context Model_Management::Package::getModelElement(modelElementName :

String) : Foundation::Core::ModelElement

pre:

if modelElementName.indexOf(‘::’) <> -1

then

self.ownedElement->exists(pack:

Model_Management::Package|pack.name= modelElementName.substr(1, modelElementName.indexOf(‘::’)))

->first()->oclAsType(Model_Management::Package)

else

self.ownedElement->exists(pack:

endif first()->oclAsType(Model_Management::Package)

Model_Management::Package|pack.name= modelElementName.substr(1, modelElementName.size()))->

post:

let package_:Model_Management::Package =

if modelElementName.indexOf(‘::’) <> -1

then

self.ownedElement->select(pack:

Model_Management::Package|pack.name= modelElementName.substr(1, modelElementName.indexOf(‘::’)))

->first()->oclAsType(Model_Management::Package))

else nil endif in

result =

-- checks whether modelElementName contains ‘::’

if modelElementName.indexOf(‘::’) <> -1

then

package_->getModelElement( modelElementName.substr(modelElementName.indexOf(‘::’)+1, modelElementName.size()), package_)

else

self.ownedElement->select(pack:

Model_Management::Package|pack.name= modelElementName.substr(1, modelElementName.size()))

->first()->oclAsType(Model_Management::Package)

endif

163

7.4.4.31 Get Model Element by Stereotyped Abstraction

-- it returns a model element that at the client side

-- of the abstraction. The supplier of the abstraction is

-- self ModelElement

context Foundation::Core::ModelElement:: getModelElementByStereAbstract(stere:String) :

Foundation::Core::ModelElement

pre:

-- checks whether there is abstract dependency and

-- is stereotyped by stere

self.supplierDependency->exists

(abstr:Foundation::Core::Abstraction| abstr.stereotype->exists(name=stere))

and abstr.client->first()->oclIsTypeOf(Foundation::Core::Class)

and abstr.client->size()=1

post: result = self.supplierDependency

->select (abstr:Foundation::Core::Abstraction| abstr.stereotype->exists(name=stere)

7.4.4.32 Get Multiplicity

--this return an object of Multiplicity class, which has a multiplicity -

- range from lower to upper

context getMultiplicity (lower:Integer, upper:UnlimitedInteger):

Foundation::Data Types::Multiplicity

pre:

lower <= upper

post:

result.range->forAll(range|range.lower=lower and range.upper=upper)

7.4.4.33 Get MultiPorts

-- Get MultiPorts used by ProcessComponent

context Foundation::Core::Classifier:: getMultiPorts():Sequence(Foundation::Core::Class)

pre:

self.stereotype->exists(stereo| stereo.name = ‘ProcessComponent’)

post:

result = Foundation::Core::Class->allInstances->select(port| port.stereotype.name=’MultiPort’ and port.association->exists(assEnd| assEnd.association.connection-> exists(assEnd|assEnd.participant = self)))

7.4.4.34 Get OperationPorts

-- Get OperationPorts used by ProcessComponent

context Foundation::Core::Classifier:: getOperationPorts():Sequence(Foundation::Core::Class)

pre:

self.stereotype->exists(stereo| stereo.name = ‘ProcessComponent’)

post:

result = Foundation::Core::Class->allInstances->select(port| port.stereotype->exists(stereo| stereo.name=’OperationPort’) and port->isSynchronous() and port->isResponds() and port.association->exists(assEnd| assEnd.association.connection-> exists(assEnd|assEnd.participant = self)))

7.4.4.35 Get ProcessComponents transformed to EJBSessionBeans

-- result of this operation is a sequence of the ProcessComponents

-- that have to be transformed to EJBSessionBeans

context Foundation::Model_Management::Package:: getProcessComponentsToSessionBeans(

164

compositionPackage: Foundation::Model_Management::Package) :

Sequence(Foundation::Core::ModelElement)

pre:

self->flatten()->forAll(e | e.stereotype.name = ‘ProcessComponent’) and compositionPackage-> select(e | e.stereotype.name = ‘CommunityProcess’)->size()=1

post:

let usedInCP : Sequence(Foundation::Core::ModelElement) =

self->getAllComponentsUsedInCP( compositionPackage-> select( e | e.stereotype.name = ‘CommunityProcess’)

->first()->oclAsType(Foundation::Core::ModelElement)) in

result = self->

findPCTranToSessBean(usedInCP, self->flatten()->excludes(usedInCP))

-- this function takes from the sequence of the suspected

-- ProcessComponents all that are transformed to the EJBSessionBean

-- and invoke itself again

context Foundation::Model_Management::Package:: findPCTranToSessBean( transfToBean : Sequence(Foundation::Core::ModelElement), suspected : Sequence(Foundation::Core::ModelElement))

: Sequence(Foundation::Core::ModelElement)

pre:

transfToBean ->forAll(e | e.stereotype.name = ‘ProcessComponent’) and suspected -> forAll (e | e.stereotype.name = ‘ProcessComponent’)

post: let usedInTranToBean :

Sequence(Foundation::Core::ModelElement) = suspected->getAllUsedBy(transfToBean) in

result = if (usedInTranToBean->size()=0) then transfToBean

else

self->findPCTranToSessBean

(transfToBean->includes(transfToBean),suspected->excludes(transfToBean))

endif

-- a result of this operation is a sequence of components that are

-- used by at least one component contained by containers

context Sequence(Foundation::Core::ModelElement)::getAllUsedBy

(containers : Sequence(Foundation::Core::ModelElement)) :

Sequence(Foundation::Core::ModelElement)

pre: self->forAll(elem | elem.stereotype.name=’ProcessComponent’) and containers ->forAll(elem | elem.stereotype.name=’ProcessComponent’)

post: result=self->select(elem | containers->exists(cont|elem-

>isComponentUsedBy(cont)))

7.4.4.36 Get Protocol

-- this method returns a protocol assigned to protocol port

context Foundation::Core::Class::getProtocol():

Foundation::Core::Class

pre:

self.stereotype->exists(stereo| stereo.name=’ProtocolPort’)

post:

self.generalization->exists(gen.parent=result and protocol.stereotype->exists(name=’Protocol’))

7.4.4.37 Get Protocol Interfaces

-- this method returns a sequence of JavaInterfaces that

-- corresponds to protocol by protocol port

context Foundation::Core::Class::getProtocolInterfaces( interfaces : Sequence(Foundation::Core::Class),

165

pre: direction : CCA::DirectionKind):Sequence(Foundation::Core::Class)

self.stereotype->exists(stereo| stereo.name=’ProtocolPort’)

post:

let innerProtocolPort:Sequence(Foundation::Core::Class) =

self->getProtocol()->getProtocolPorts()

let stereName:String =

if direction=CCA::DirectionKind.Responds then

traceInitiatesInterface’

else endif

traceRespondsInterface’

let protocolInterface : Foundation::Core::Class =

self->getProtocol()-

>getModelElementByStereAbstract(stereName)

in

if interfaces->includes(protocolInterface) then true

else result->includes(interfaces) and

result->forAll(elem|

)

(getProtocolInterfaces(innerProtocolPort, interfaces,

if self->isResponds()

then CCA::DirectionKind.Initiates

else CCA::DirectionKind.Responds

)->includes(elem) and direction=CCA::DirectionKind.Responds)

or

(getProtocolInterfaces(innerProtocolPort, interfaces,

if self->isResponds()

then CCA::DirectionKind.Responds

else CCA::DirectionKind.Initiates

)->includes(elem) and direction=CCA::DirectionKind.Initiates)

7.4.4.38 Get ProtocolPorts

-- Get ProtocolPorts used by ProcessComponent

context Foundation::Core::Classifier:: getProtocolPorts():Sequence(Foundation::Core::Class)

pre: self.stereotype->exists(stereo| stereo.name = ‘ProcessComponent’)

post:

result = Foundation::Core::Class->AllInstances->select(port | port.stereotype->exists(stereo| stereo.name=’ProtocolPort’) and port.association->exists(assEnd| assEnd.association.connection-> exists(assEnd|assEnd.participant = self)))

7.4.4.39 Get Return Type

-- Method acquires return type of Operation

context Foundation::Core::Operation:: getReturnType(): Foundation::Core::Classifier

pre: post: true

result = self.parameter->select(param| param.kind = Foundation::Data_Types::

ParameterDirectionKind.return)->first()-> oclAsType(Foundation::Core::Classifier)

7.4.4.40 Get Subsystem used by Subs

context

Model_Management::Subsystem::getSubsystemUsedBySubs(currSubs:Model_Manage ment::Subsystem, beanProCompVec:Sequence(Foundation::Core::Classifier)) :

Sequence(

pre:currSubs.stereotype->exists(name=’EJBSessionBean’)

post:

let procComp : Foundation::Core::Classifier = getSuppOfMTrace(currSubs)

166

let usedVect : Sequence(Foundation::Core::Classifier) =

(getComponentUsedBy(procComp)->asSet()->intersect(beanProCompVect-> asSet()))->asSequence() in usedVect->forAll(pc| if pc->oclIsType(Model_Management::Subsystem)

and beanProCompVec->includes(pc) then result-> includes(pc) else not result->includes endif) and usedVect->asSet()->intersect(result->asSet())=result->asSet()

7.4.4.41 Get Supplier of MTrace UML

-- this method returns Classifier that has a supplier role in MTrace UML

-- Usage with self, where self has a client role.

context Foundation::Core::Classifier:: getSuppOfMTrace():Foundation::Core::Classifier

pre:

self.clientDependency->select(dep|

post:

dep.stereotype->exists(stereo|stereo.name=’MTrace’))

result.supplierDependency->exists(dep| dep.stereotpe->exists(stereo|stereo.name=’MTrace’) and dep.client->first()=self)

7.4.4.42 Get TaggedValue

-- This method finds TaggedValue in ModelElement by name

context Foundation::Core::ModelElement:: getTaggedValue(name: String):Foundation::Core::TaggedValue

pre: true

post:

result = self.taggedValue->select(tagVal| tagVal.type.name=name)->first()-> oclAsType(Foundation::Core::TaggedValue))

7.4.4.43 Get Tuple for EJBReferences tag

-- this method creates a tuple for EJBReferences tag

context Model_Management::Subsystem::getRefTuple()

pre:

self.stereotype->exists(stereo| stereo.name = ‘EJBSessionBean’ or stereo.name = ‘EJBEntityBean’)

post:

let remName :String = self.ownedElement->select(elem| elem.stereotype->exists(stereo| stereo.name = ‘EJBRemoteInterface’))->first()-> oclAsType(Foundation::Core::Class).name

let homeName :String = self.ownedElement->select(elem| elem.stereotype->exists(stereo| stereo.name = ‘EJBSessionHomeInterface’ or stereo.name = ‘EJBEntityHomeInterface’))->first()-> oclAsType(Foundation::Core::Class).name

let type :String =

if self.stereotype->exists(stereo| stereo.name = ‘EJBSessionBean’)

then ‘Session’ else ‘Entity’ endif

in

result = self.name->concat(‘;’)->concat(type)->concat(‘;’)-> concat(homeName)->concat(‘;’)->concat(remName)

7.4.4.44 Has Asynchronous FlowPorts

-- This method checks if Session Bean or any of his inner classes will

-- have asynchronous methods

context asynchMethodsExist():Boolean

pre:

true

post:

let flowPorts:Sequence(Foundation::Core::Class)=

Foundation::Core::Classes->allInstances()->select(port| port.stereotype->exists(name=’FlowPort’) and port.taggedValues->exists(tagVal|

167

in

tagVal.type.name = ‘isSynchronous’ and tagVal.dataValue->first()-> oclAsType(String)=’false’))

result = flowPorts->size()>0

7.4.4.45 Has Asynchronous Methods

-- This method checks if Session Bean or any of his inner classes

-- will have asynchronous methods

context Model_Management::Subsystem::hasAsynchMethods():Boolean

pre:

self.stereotype->exists(stereo| stereo.name = ‘EJBSessionBean’)

post:

let procCompSec: Sequence(Foundation::Core::Classifier) = self->getInerClasses()->add(self->

in

getSupplierOfMTrace()->getSupplierOfMTrace())

result = procCompSec->exists( procComp:Foundation::Core::Classifier|

Foundation::Core::Class->allInstances->select( port |(port.stereotype->exists(ster.name=’FlowPort’))

and

-- ports are connected directly to the procComp port.association->exists(assEnd| assEnd.association.connection-> exists(assEnd| assEnd.participant = procComp or

-- ports are connected via multiport assEnd.participant.association-> exists(assEnd| assEnd.association.connection-> exists(assEnd| assEnd.participant = procComp or

-- ports are connected via protocol

(assEnd.participant.steretype->exist(name=’Protocol’) and assEnd.participant.specialization->exists(

))

)and child.stereotype->exists(name=’ProtocolPort’) and child.association->exists(assEnd| assEnd.association.connection-> exists(assEnd|assEnd.participant = procComp ) port.taggedValues->exists(tagVal|

>size()>0) tagVal.type.name = ‘isSynchronous’ and tagVal.dataValue->first->oclAsType(String)=’false’)-

7.4.4.46 Has onMessage Operation

-- This method checks if Session Bean has onMessage Operation

context Model_Management::Subsystem::hasOnMessage():Boolean

pre:

self.stereotype->exists(stereo| stereo.name = ‘EJBSessionBean’)

post:

let rem :Foundation::Core::Class = bean.ownedElement->select(elem| elem.stereotype->exists(stereo|

in

stereo.name = ‘EJBRemoteInterface’))

result = rem.feature->exists(oper: Foundation::Core::Operation| oper.name = ‘onMessage’)

7.4.4.47 Includes Recursivly

-- this operation check whether the elem is contained by self package or packages

-- that are contained by self package recursively

context Model_Management::Package::includesRec(elem :

Foundation::Core::ModelElement):Boolean

168

post: self.ownedElement->includes(elem) or

self.ownedElement->exists(pack : Model_Management::Package| pack-

>includesRec(elem))

7.4.4.48 Is Component Used By

-- this operation result is true if processComponent as self is used

-- by the container, i.e it exists such component usage owned by

-- the container that is

-- related with the processComponent

context Foundation::Core::ModelElement::isComponentUsedBy

(container : Foundation::Core::ModelElement) : Boolean

pre: self.stereotype.name=’ProcessComponent’ and container.stereotype.name=’Composition’

post: result=container.ownedElement->exists(compUsage | compUsage.stereotype->exists(name=’ComponentUsage’) and compUsage.clientDependency->exists(clD|clD.supplier = self))

7.4.4.49 Is Java Final

-- This method checks value of JavaFinal taggedValue

context Foundation::Core::Parameter::isJavaFinal():Boolean

pre: true post:

result = self.getTaggedValue(‘JavaFinal’). dataValue->first()=’true’

7.4.4.50 Is Responds

-- this method checks if port has direction tag set on responds

context Foundation::Core::Class::isResponds ():Boolean

pre: post:

self.stereotype->exists(stereo| stereo.name = ‘FlowPort’ or stereo.name = ‘OperationPort’ or stereo.name=‘ProtocolPort’) and self.taggedValue->exists(tagVal|tagVal.type.name=’direction’ and tagVal.dataValue->size()>0)

result = self.taggedValue->exists(tagVal| tagVal.type.name = ‘direction’ and tagVal.referenceValue->first()-> oclAsType(DirectionKind) = DirectionKind.responds)

7.4.4.51 Is Synchronous

-- this method checks if port has isSynchronous tag set on true

context Foundation::Core::Class::isSynchronous():Boolean

pre: post:

self.stereotype->exists(stereo| stereo.name = ‘FlowPort’ or stereo.name = ‘OperationPort’) and self.taggedValue->exists(tagVal| tagVal.type.name=’isSynchronous’ and tagVal.dataValue->size()>0)

result = self.taggedValue->exists(tagVal| tagVal.type.name = ‘isSynchronous’ and tagVal.dataValue->first()-> oclAsType(String) = ‘true’)

7.4.4.52 Is Transactional

-- this method checks if port has direction tag set on responds

context Foundation::Core::Class::isTransactional():Boolean

pre:

self.stereotype->exists(stereo| stereo.name = ‘FlowPort’ or stereo.name = ‘OperationPort’ or stereo.name=‘ProtocolPort’) and

169

self.taggedValue->exists(tagVal| tagVal.type.name=’isTransactional’ and tagVal.dataValue->size()>0)

post:

result = self.taggedValue->exists(tagVal| tagVal.type.name = ‘isTransactional’ and tagVal.dataValue->first()-> oclAsType(String) = ‘true’)

7.4.4.53 Make Java Class

-- result of the operation is an instance of Foundation::Core::Class

-- that fulfills constraints for JavaClass

context makeJavaClass(clazz Foundation::Core:Class, name : String, visibility : Foundation::Data_Types::VisibilityKind, isAbstract :

Boolean, isStatic : Boolean, isFinal : Boolean, isStricfp : Boolean, isActive : Boolean)

pre:

post:

true clazz.name = name and clazz.visibility = visibility and clazz.isAbstract = isAbstract and clazz.isLeaf = isFinal and clazz.ownerScope = if isStatic

then Foundation::Data_Types::ScopeKind.classifier

else Foundation::Data_Types::ScopeKind.instance endif and clazz.taggedValue-> exists(tagVal| tagVal.type.name = ‘JavaStatic’ and dataValue->first()->oclAsType(String) =

if isStatic then ‘true’ else ‘false’ endif) and clazz.taggedValue-> exists(tagVal| tagVal.type.name = ‘JavaStrictfp’ and dataValue->first()->oclAsType(String) =

if isStricfp then ‘true’ else ‘false’ endif)

and true

-- the other constraints are presented in the paper [31]

7.4.4.54 Realize java.io.Serializable

-- This method implements java.io.Serializable in

-- JavaClass

context Foundation::Core::Class::setRealizeSerializableInterface()

pre: post: true

let cl:Foundation::Core::Class = ImplementJavaInterface(self, getModel()->getModelElement(‘java::io::Serializable‘), ‘JavaClass’)

self.feature = cl.ownedElement and

self.clientDependency = cl.clientDependency

7.4.4.55 Realize javax.ejb.EJBHome

-- This method implements javax.ejb.EJBHome in

-- Home Interface

context Foundation::Core::Class::setSpecializeEJBHome()

pre:

self.stereotype->exists(stereo| stereo.name = ‘EJBSessionHomeInterface’ or stereo.name = ‘EJBEntityHomeInterface’)

post:

let cl:Foundation::Core::Class = ImplementJavaInterface(self, getModel()->getModelElement(

‘javax::ejb::EJBHome‘), ‘HomeInterface’)

self.feature = cl.ownedElement and

self.clientDependency = cl.clientDependency

170

7.4.4.56 Realize javax.ejb.EJBObject

-- This method implements javax.ejb.EJBObject in

-- Remote Interface

context Foundation::Core::Class::setSpecializeEJBObject()

pre:

post:

self.stereotype->exists(stereo| stereo.name = ‘EJBRemoteInterface’)

let cl:Foundation::Core::Class = ImplementJavaInterface(self, getModel()->getModelElement(

‘javax::ejb::EJBObject‘),‘ImplementationClass’)

self.feature = cl.ownedElement and

self.clientDependency = cl.clientDependency

7.4.4.57 Realize javax.ejb.EntityBean

-- This method implements javax.ejb.EntityBean in

-- Home Interface

context Foundation::Core::Class::setRealizeEntityBeanInterface()

pre:

post:

self.stereotype->exists(stereo| stereo.name = ‘EJBImplementation’)

let cl:Foundation::Core::Class = ImplementJavaInterface(self, getModel()->getModelElement(

‘javax::ejb::EntityBean‘),‘HomeInterface’)

self.feature = cl.ownedElement and

self.clientDependency = cl.clientDependency

7.4.4.58 Realize javax.ejb.MessageDrivenBean

-- This method implements javax.ejb.MessageDrivenBeaninterface in

-- Message-Driven Bean

context Foundation::Core::Class::setRealizeMessageDrivenBeanInterface()

pre:

post:

self.stereotype->exists(stereo| stereo.name = ‘EJBMessageDrivenBean’)

let cl:Foundation::Core::Class = ImplementJavaInterface(self, getModel()->getModelElement(

‘javax::ejb::MessageDrivenBean‘),‘ImplementationClass’)

self.feature = cl.ownedElement and

self.clientDependency = cl.clientDependency

7.4.4.59 Realize javax::ejb::SessionBean

-- This method implements javax.ejb.SessionBean interface

-- in implementation class

context Foundation::Core::Class::setRealizeEJBSessionBean()

pre:

post:

self.stereotype->exists(stereo| stereo.name = ‘EJBImplementation’)

let cl:Foundation::Core::Class = ImplementJavaInterface(self, getModel()->getModelElement(

‘javax::ejb::SessionBean‘),‘ImplementationClass’)

self.feature = cl.ownedElement and

self.clientDependency = cl.clientDependency

7.4.4.60 Realize javax.ejb.SessionSynchronization

-- This method implements javax.ejb.SessionSynchronization interface in

-- implementation class

context Foundation::Core::Class::setRealizeSessionSynchronization()

pre:

post:

self.stereotype->exists(stereo| stereo.name = ‘EJBImplementation’)

let cl:Foundation::Core::Class = ImplementJavaInterface(self, getModel()->getModelElement(

‘javax::ejb::SessionSynchronization‘), ‘ImplementationClass’)

self.feature = cl.ownedElement and

self.clientDependency = cl.clientDependency

171

7.4.4.61 Realize javax.jms.MessageListener

-- This method implements javax.jms.MessageListener in

-- Message-Driven Bean

context Foundation::Core::Class::setRealizeMessageListenerInterface()

pre:

self.stereotype->exists(stereo| stereo.name = ‘EJBMessageDrivenBean’)

post:

let cl:Foundation::Core::Class = ImplementJavaInterface(self, getModel()->getModelElement(

‘javax::jms::MessageListener‘),‘ImplementationClass’)

self.feature = cl.ownedElement and

self.clientDependency = cl.clientDependency

7.4.4.62 Realize Port Interface

-- This method implements interface in Session Bean

context Model_Management::Subsystem:: realizePortInterface(interf : Foundation::Core::Classifier, impl : Foundation::Core::Class, rem : Foundation::Core::Class)

pre: post:

self.stereotype->exists(stereo| stereo.name = ‘EJBSessionBean’)

let newImpl: Foundation::Core::Class = ImplementJavaInterface(impl, interf.getDataElementJavaClass(),

‘ImplementationClass’)

let newRem: Foundation::Core::Class = ImplementJavaInterface(rem, interf.getDataElementJavaClass(), ‘RemoteInterface’)

in

self.select(cl:Foundation::Core::Class|cl.stereotype-> exists(name=’EJBImplementation’))->size()=1 and

self.select(cl:Foundation::Core::Class|cl.stereotype-

>exists(name=’EJBRemoteInterface’))->size()=1 and

self.ownedElement->contains(newImpl) and

self.ownedElement->contans(newRem)

7.4.4.63 Realize Protocol Interface

-- This method realize protocol interface in Session Bean

context Model_Management::Subsystem:: realizeProtocolInterface (interf : Foundation::Core::Classifier, impl : Foundation::Core::Class, rem : Foundation::Core::Class)

pre: post:

self.stereotype->exists(stereo| stereo.name = ‘EJBSessionBean’)

let newImpl: Foundation::Core::Class = ImplementJavaInterface(impl,

in

interf,

‘ImplementationClass’)

let newRem: Foundation::Core::Class = ImplementJavaInterface(rem, interf, ‘RemoteInterface’)

self.select(cl:Foundation::Core::Class|cl.stereotype-> exists(name=’EJBImplementation’))->size()=1 and

self.select(cl:Foundation::Core::Class|cl.stereotype-

>exists(name=’EJBRemoteInterface’))->size()=1 and

self.ownedElement->contains(newImpl) and

self.ownedElement->contans(newRem)

7.4.4.64 Remove Generalization

-- it removes a generalization relationship beetwen self and child

context Foundation::Core::GeneralizableElement::removeGeneralization

(child:Foundation::Core::GeneralizableElement)

pre:

-- generalization between parent and child must exist

post:

self.specialization->exists(gene| gene.child=child)

not self.specialization->exists(gene| gene.child=child)

7.4.4.65 Set EJBEnvEntries TaggedValue

-- this method sets EJBEnvEntires TaggedValue for Enterprise Bean

172

context Foundation::Core::Classifier::setEJBEnvEntries(val:

Sequence(String))

pre:

self.stereotype->exists(stereo| stereo.name = ‘EJBSessionBean’ or stereo.name = ‘EJBEntityBean’ or stereo.name = ‘EJBMessageDrivenBean’)

post:

self.taggedValue->exists(tagVal| tagVal.type.name =

‘EJBEnvEntires’ and tagVal.dataValue->forAll( elem| val->contains(elem)) and tagVal.dataValue->size() = val->size())

7.4.4.66 Set EJBPersistanceType

-- this method sets EJBPersistanceType TaggedValue for Entity Bean

context Model_Management::Subsystem::setEJBPersistanceType(val:String)

pre:

self.stereotype->exists(stereo|stereo.name = ‘EJBEntityBean’) and

(val = ‘Bean’ or

post:

val = ‘Container’)

self.taggedValue->exists(tagVal| tagVal.type.name = ‘EJBPersistanceType’ and tagVal.dataValue->first()-> oclAsType(String)=val and tagVal.dataValue->size() = 1)

7.4.4.67 Set EJBPrimaryKey Usage

-- this method creates UML Usage stereotyped <<EJBPrimaryKey>> where self

-- plays a client role and supp plays a supplier role

context Foundaton::Core::ModelElement::setEJBPrimaryKey( supp : Foundation::Core::ModelElement) : Foundation::Core::Usage

post:

result.client->size() = 1 and

result.supplier->size() = 1 and

result.client->includes(self) and

result.supplier->includes(supp) and

result.stereotypes->exists(stereo|stereo.name=’EJBPrimaryKey’)

7.4.4.68 Set EJBRealizeHome Abstraction

-- this method creates UML Abstraction

-- stereotyped <<EJBRealizeHome>> where self

-- has a client role and supp has a supplier role

context Foundaton::Core::ModelElement::setEJBRealizeHome( supp:Foundation::Core::ModelElement):Foundation::Core::Abstraction

post:

result.client->size() = 1 and

result.supplier->size() = 1 and

result.client->includes(self) and

result.supplier->includes(supp) and

result.stereotypes->exists(stereo|stereo.name=’EJBRealizeHome’)

7.4.4.69 Set EJBReentrant

-- this method sets setEJBReentrant TaggedValue for Entity Bean

context Model_Management::Subsystem::setEJBReentrant(val: String)

pre:

self.stereotype->exists(stereo|stereo.name = ‘EJBEntityBean’) and

(val = ‘true’ or

post:

val = ‘false’)

self.taggedValue->exists(tagVal| tagVal.type.name = ‘EJBReentrant’ and tagVal.dataValue->first()-> oclAsType(String)=val and tagVal.dataValue->size() = 1)

173

7.4.4.70 Set EJBReferences Tagged Value

-- this method sets EJBReferences TaggedValue for Enterprise Bean

context Foundaton::Core::Classifier::setEJBReferenceTag(val:

Sequence(String))

pre: post:

self.stereotype->exists(stereo| stereo.name = ‘EJBSessionBean’ or stereo.name = ‘EJBEntityBean’ or stereo.name = ‘EJBMessageDrivenBean’)

self.taggedValue->exists(tagVal| tagVal.type.name = ‘EJBReferences’ and tagVal.dataValue-> forAll(elem| val->contains(elem)) and tagVal.dataValue-> size() = val->size())

7.4.4.71 Set EJBSessionType TaggedValue

-- this method sets EJBSessionType TaggedValue for Home Interface in

Session Bean

context Foundation::Core::Class::setEJBSessionType(val: String)

pre:

self.stereotype->exists(stereo|stereo.name =

‘EJBSessionHomeInterface’) and

(val = ‘Stateful’ or

post:

val = ‘Stateless’)

self.taggedValue->exists(tagVal| tagVal.type.name = ‘EJBSessionType’ and tagVal.dataValue->first()-> oclAsType(String)=val and tagVal.dataValue->size() = 1)

7.4.4.72 Set EJBTransAttribute TaggedValue

-- this method sets EJBTransAttribute TaggedVallue for Parameter for Java

Method

context Foundation::Core::Parameter::setEJBTransAttribute(val: String)

pre:

val = ‘Bean’ or val = ‘Container’ or val = ‘Required’ or val = ‘RequiresNew’ or val = ‘Mandatory’ or val = ‘Never’

post:

self.taggedValue->exists(tagVal| tagVal.type.name = ‘EJBTransAttribute’ and tagVal.dataValue->first()-> oclAsType(String) = val and tagVal.dataValue->size()=1)

7.4.4.73 Set EJBTransType TaggedValue

-- this method sets EJBEnvEntires TaggedValue for Session Bean

context Foundation::Core::Classifier::setEJBTransType(val:

Sequence(String))

pre:

val = ‘Bean’ or val = ‘Container’

post:

self.taggedValue->exists(tagVal| tagVal.type.name = ‘EJBTransType’ and tagVal.dataValue->first()-> oclAsType(String)=val and tagVal.dataValue->size() = 1)

7.4.4.74 Set Instantiate Usage

-- this method creates UML Usage stereotyped <<Instantiate>> where self

-- has a

-- client role and supp has a supplier role

174

context Foundaton::Core::ModelElement::setInstantiate ( supp : Foundation::Core::ModelElement) : Foundation::Core::Usage

pre: post: true

result.client->size() = 1 and

result.supplier->size() = 1 and

result.client->includes(self) and

result.supplier->includes(supp) and

result.stereotypes->exists(stereo|stereo.name=’Instantiate’)

7.4.4.75 Set InterBean Usages

-- this method creates UML Usage for inner model beans

-- beanSubsVect - vector with beans subsystems

context setInterBeanUsages(beanSubsVect:Sequence(Model_Management::Subsystem), beanProCompVec:Sequence)

pre: beanSubsVect->forAll( bean->oclIsTypeOf(Model Management::Subsystem) and bean. clientDependency-> exists(dep.stereotype->exists(name=’MTrace’))

post: beanSubsVect->forAll(currSubs| getSubsystemsUsedBySubs(currSubs, beanProCompVec)->forAll

(subs|subs->setUsage(currSubs)))

7.4.4.76 Set JavaFinal TaggedValues

-- this method sets JavaFinal TaggedValue for Paramter for JavaMethod

context Foundation::Core::Classifier::setJavaFinalTaggedValue( val :String)

pre:

val = ‘true’ or

val = ‘false’

post:

self.taggedValue->exists(tagVal| tagVal.type.name = ‘JavaFinal’ and tagVal.dataValue->first()-> oclAsType(String)=val and tagVal.dataValue->size() = 1)

7.4.4.77 Set JavaThrows Tagged Value

-- this method sets JavaThrows TaggedValue for Java Operation

context Foundaton::Core::Operation::setJavaThrows (exceptions:

Sequence(String))

pre: post:

true

result.taggedValue-> forAll(tagVal| if tagVal.type.name=’JavaThrows’ then exceptions.contains(tagVal.dataValue-> first()->oclAsType(String)) else true endif) and exceptions->forAll(elem| result.taggedValue->exists(tagVal| tagVal.type.name=’JavaThrows’and tagVal.dataValue->first()->oclAsType(String)=elem)

7.4.4.78 Set JavaVolatile Tagged Value

-- this method sets JavaVolatile TaggedValue for Java Field

context Foundaton::Core::Attribute::setJavaVolatile (val:

Sequence(String))

pre:

val = ‘true’ or val = ‘false’

post:

self.taggedValue->exists(tagVal| tagVal.type.name = ‘JavaVolatile’ and tagVal.dataValue->first()-> oclAsType(String)=val and

175

tagVal.dataValue->size() = 1)

7.4.4.79 Set MTrace Dependency

-- this method creates Dependency stereotyped <<MTrace>>

-- where self has a client

-- role and supp has a supplier role

context Foundaton::Core::ModelElement::setMTrace

(supp : Foundation::Core::ModelElement) : Foundation::Core::Dependency

pre:

true post:

result.client->size() = 1 and

result.supplier->size() = 1 and

result.client->includes(self) and

result.supplier->includes(supp) and

result.stereotypes->exists(stereo|stereo.name=’MTrace’)

7.4.4.80 Set persistence TaggedValue

-- this method sets persistence TaggedValue for Classifier

context Foundation::Core::Classifier::setPersistent(val: String)

pre:

val = ‘true’ or

val = ‘false’

post:

self.taggedValue->exists( tagVal| tagVal.type.name = ‘persistence’ and tagVal.dataValue->first()-> oclAsType(String)=val and tagVal.dataValue->size() = 1)

7.4.4.81 Set Port Direction

-- this method checks if port has direction tag set on responds

context Foundation::Core::Class::setDirection( direction:CCA::DirectionKind)

pre: post:

self.stereotype->exists(stereo| stereo.name = ‘FlowPort’ or stereo.name = ‘OperationPort’ or stereo.name=‘ProtocolPort’) and

self.taggedValue->exists(tagVal|tagVal.type.name=’direction’ and tagVal.dataValue->size()>0)

result = self.taggedValue->exists(tagVal| tagVal.type.name = ‘direction’ and tagVal.referenceValue->first()-> oclAsType(CCA::DirectionKind) = direction)

7.4.4.82 Set Reference Dependency

-- this method creates UML Abstraction

-- stereotyped <<EJBReference>> where self

-- has a client role and bean has

-- a supplier role and sets EJBRefType Tagged

-- Value, EJBRefName Tagged Value, EJBComponentInterface Tagged Value and

-- EJBHomeInterface Tagged Value

context Model_Management::Subsystem::addReference

(bean:Model_Management::Subsystem):Foundation::Core::Abstraction

pre:

self.stereotype->exists(stereo| stereo.name = ‘EJBSessionBean’ or stereo.name = ‘EJBEntityBean’ or stereo.name = ‘EJBMessageDrivenBean’) and

post:

bean.stereotype->exists(stereo| stereo.name = ‘EJBSessionBean’ or stereo.name = ‘EJBEntityBean’)

let refType:String =

if bean.stereotype->exists(stereo| stereo.name = ’EJBSessionBean’)

then ‘Session’ else ‘Entity’ endif

let refName:String = self.name.concat(‘Ref’).concat(bean.name)

176

let remName:String = bean.ownedElement->select( rem|rem.stereotype->exists( stereo|stereo.name=’EJBRemoteInterface’))

->first()->oclAsType(Foundation::Core::Class).name

let homeName:String = bean.ownedElement->select( rem|rem.stereotype->exists( stereo|stereo.name = if refType = ‘Session’

then ’EJBSessionHomeInterface’ else

‘EJBEntityHomeInterface’ endif))->first()-> oclAsType(Foundation::Core::Class).name

in

result.client->size() = 1 and

result.supplier->size() = 1 and

result.client->includes(self) and

result.supplier->includes(bean) and

result.stereotypes->exists(stereo|stereo.name = ’EJBReference’) and

result.taggedValue->exists( tagVal| tagVal.type.name = ‘EJBRefType’ and tagVal.dataValue = refType) and

result.taggedValue->exists( tagVal| tagVal.type.name = ‘EJBRefName’ and tagVal.dataValue = refName) and

result.taggedValue->exists( tagVal| tagVal.type.name = ‘EJBComponentInterface’ and tagVal.dataValue = remName) and

result.taggedValue->exists( tagVal| tagVal.type.name = ‘EJBHomeInterface’ and tagVal.dataValue = homeName)

177

8 I

MPLEMENTATION OF

T

HE

T

RANSFORMATIONS

In this chapter, the authors focus on the implementation of the transformations’ specification provided in the previous chapter. In particular, the authors describe the chosen implementation approach in the first part of the chapter. The second part is devoted to discussion about implementation’s verification against the specifications.

8.1 Introduction

The specification presented in the chapter above, now has to be implemented in order to perform the transformation expressed within them. The basic issue is to choose the proper approach that is able to execute the specification.

In the chapter Transformations in the MDA, several approaches for transformation performing are presented. From the set of possible solutions, the authors have decided to use the direct-manipulation approach, although this technique has some disadvantages. The used technique gives an easiness, performance, and power of expressivity [79].

In addition, the direct-manipulation approaches are mostly realized using the extension of the modelling tools, i.e. the API to an internal modelling repository. This has following characteristics. Firstly, the specification is made within the generalpurpose languages as C++, Java, and offered supporting tools, as translators, debuggers, editors, etc. Such support is required in order to make the process of the transformation specification less cumbersome. Moreover, the example languages are modern solutions that provide additionally features as object-oriented programming paradigm. Further, it gives developers a possibility to build a transformation approach tailored to particular transformation task.

Obviously, one can ask why not to use the frameworks, or transformation approaches, specially prepared to this kind of task.

During the work related with the thesis, the authors considered the transformation specific approaches, in particular, freely available BasicMTL [83]. However, the probe had failed and the authors were forced to choose the currently used solution. There were two basic reasons of that, the lack of documentation, and poor quality of the transformation approach itself.

The BasicMTL approach provides the language, and its trans lator. The language allows for model manipulation in terms of the concepts of particular meta-model. In other words, it allows for creation and modification of the elements of a particular model, using meta-classes, meta-associations, etc. utilized for the meta-model specification.

Nevertheless, the first disadvantage of the approach was lack of specification, or documentation of the language, tool, or libraries that might facilitate the transformation specification. Further, the level of maturity of the tool itself was very poor, e.g. low performance, low reliability, etc. which practically , eliminated this approach from farther investigation.

The situation presented above describes in some manner why the transformation approaches, that are available freely, are not capable for developing of larger transformation projects. As a poor documentation and quality of the approaches are provided, it forces the users of such approaches to deal with the tool’s implementation problems rather than focus on the transformation issues, although the approach may provide facilities for transformation specification at higher level of abstraction, which theoretically release developers from implementation of some general transformation actions.

Thus, the authors provide the implementation of the transformation using the direct-manipulation approach, which details are described in the following part.

178

8.2 The tool

To implement the transformation, authors decide to use a modelling approach, the

MagicDraw UML 9.0. MagicDraw is a visual UML modelling and CASE, developed using the Java language. It supports the UML meta-model in the version 1.4, which fulfils the author’s requirements against modelling languages, since the models used in the transformations are expressed as the UML profiles. The tool is implemented using the plug-in technology, which indeed gives a possibility to its users to enhance the tool facilities. In the thesis, the authors use this tool’s capabilities to develop own transformation plug-in.

The plug-in is an example of the white-box framework, i.e. set of classes, and interfaces that are gathered together in order to make the task of the transformation implementation easier. The basic concepts of the tool are presented in Appendix 1, as well as the implementation of the transformation presented in the previous chapter. For further details, see the proper appendix.

8.3 Testing of the transformations

In the previous chapter, the transformation specifications are defined. The verification has to be done. The extensive test are not provided in the thesis, however to prove that transformations are at least partially correct; the serious of test are executed. The serious is divided into three categories, which are derived from the three main groups of transformation, i.e. composition transformation tests, component transformation tests, DocumentModel tests. From these groups, particular transformations are selected for testing. The test input examples try to represent attractive examples of the test input.

8.3.1.1 ProcessComponent to EJBSessionBean – Test

In this test, the transformation of the ProcessComponent, shown on Figure 62, is made. ProcessComponent is transformed to EJBSessionBean. The ProcessComponent has only one port attached – Mult1, which is a MultiPort. The MultiPort has four

FlowPorts: fSI2 (synchronous and initiates), fSR2(synchronous and responds),

fAR2 (asynchronous and responds), fAI2(asynchronous and initiates).

The result EJBSessionBean has to have onMessage method to handle asynchronous communication with fAR2, it should also have tuple in EJBReferences

TaggedValue indicating that it has reference to RemoteInterfaceEntity. The

ProcessComponent has isPersistent TaggedValue set on true, the transformation

should map this to EJBSessionTag set on Stateful in EJBProcCompTestHome. All of the flow ports, besides fSI2, should be transformed to JavaMethods (sendFAI2,

executeFAR2 , sfFSR2 ) in Implementation Class; fSR2 should also have representation

of his method in RemoteInterface. The Transformation should also create

performActionForMult1method and argument Mult1Arg with Mult1 as its type.

JavaClassMult1 should have four arguments (one for each FlowPort) with the

same types as input parameters types for methods created for these FlowPorts. Each of these arguments has to have setter and getter method. Mult1 JavaClass has also to contain isBufferFull method that takes no arguments and returns boolean.

Created EJBSessionBean and all elements it contains have to fulfil constraints from EJB UML Profile [72]. As one can see on

the result model fulfils these requirements.

179

Figure 62 - ProcessComponent to EJBSessionBean – Test - Input Model

180

Figure 63 - ProcessComponent to EJBSessionBean – Test – ResultComponent Transformation

181

8.3.1.2 Composition to Transitional Model

In this test, transformation from composition to Transitional Model is made. The input model contains five ProcessComponent with theirs ComponentUsages. The result of the transformation should contain two UML Subsystems with <<MTrace>> to ProcCompTest2 and ProcCompTest5 . UML Subsystem should contain three UML

Classes with that will have <<MTrace>> Dependency to ProcCompTest1,

ProcCompTest2 and PRocCompTest3 . UML Subsystem with name

“struktura.ProcCompTest2” should have <<use>> Dependency to all of its

innerClasses and to the second UML Subsystem. There should be only two other

<<use>> Dependencies and they should be between UML Class with name

“struktura.ProcCompTest4” and two other elements of result model:

struktura.ProcCompTest1 and struktura.ProcCompTest5 .

As one can see on Figure 65, the result model fulfils these requirements.

Figure 64 - Composition to Transitional Model – Test – Input Model

182

Figure 65 - Composition to Transitional Model - Test - Result

8.3.2 DocumentModel

8.3.2.1 Enumeration to JavaClass – Test

In this test, the transformation of an enumeration type Colour is made. The enumeration contains five possible values of colours, thus the result class shall contain all this values as the frozen attributes, which in fact one can see on a result model of the transformation. Additionally , the transformation shall generate also two methods that are responsible for getting, and setting the value of the enumeration class, which is also made in the result model.

Figure 66 - Enumeration to JavaClass - Test - Input Model

183

Figure 67 - Enumeration to JavaClass - Test - Result

8.3.2.2 CompositeData to JavaClass - Test

The aim of this test is to show a correctness of the CompositeData to JavaClass transformation. In particular, the example model shown below. It contains from two

<<CompositeData>> classes, where one is a generalization of another. Additionally,

the class CompositeData, contains a specification of DataInvariant.

The result of the transformation should be a set of two classes of the same name, which are related by the generalization relationship. Further, each attribute visibility shall be protected, and each attribute shall have access JavaMethod, i.e. setter and getter functions. In addition, the CompositeData’s invariant shall be transformed to

isInvariantFullfiled() function. All this requirements are fulfilled by the result model

of this test of CompositeData to JavaClass transformation.

Figure 68 – CompositeData to JavaClass - Test - Input Model

184

Figure 69 – CompositeData to JavaClass - Test - Result

185

9 C

ONCLUSIONS

9.1 Summary

This paper contains of several parts. At first, the author has introduced to the reader the concept of the model driven development, and the MDA in particular. The authors described also the traditional software development model and juxtaposed it with the development process related to the MDA approach. At the end of this part, a description of the basic MDA framework is provided; in order to give to user understand of relation between basic elements in the MDA.

The following two chapters focus more on the artefacts of the MDA as models and transformation. In particular, the third chapter is devoted to issues related with the model in the MDA. The authors present in this chapter the structure of the models of the MDA, and further they investigate the relations between these models in more details than it is made in previous chapter. Another important part of this chapter is the discussion about the way the specification of the languages might be made. The authors focus on two general approaches used for languages definition, i.e. extension of already existing languages, as for instance dialecting the UML using its profile mechanism, and so-called heavyweight extension i.e., extension, and modification of the meta-model itself. The la st part of the chapter is focused on general-purpose modelling languages that seem to be important candidates for modelling approaches for the MDA. In particular, the UML 1.x, Executable UML, and UML 2.0 are presented.

The transformations are in the main scope of the paper, and the theoretical fundaments and practical aspects of transformation specification, implementation and execution are the content of the chapter 4. The authors in the chapter, at first place, presents and discuss several definitions of transformation, and organise transformations into basic categories.

In the second part of this chapter, the focus is concentrated on the implementation issues of the transformations. Thereby, the authors present the process of transformation’s development. Further, the basic requirements on the transformation approaches are elaborated. Finally, the review of transformation’s approach is given.

As the general description of the elements of the MDA is given, next the concrete approaches and solutions used for the transforming EDOC’s to EJB’s models are presented. It is on the focus of the following chapters.

In the chapters five and six, the platform independent and platform specific languages are introduced. The authors describe the EDOC in the chapter five, focusing on parts utilized in the thesis, in particular the CCA. Obviously, the authors put also the description of the UML profile used for expressing the input models. In similar way, the platform-specific modelling language is presented.

The transformation specifications are in concern of the chapter Transformations

EDOC-EJB. First, the description of the specification approach is made and in next step, using the approach, transformations are specified.

In order to perform the specifications, the experimental tool is developed.

Moreover, the partially verification of the transformation is made within the same chapter, providing testing for some transformations.

9.2 Conclusions

The transformations described in the paper cover only part of all transformations required for making a fully automated process of an application generation possible.

One of the reasons of that is a high complexity of this type of solutions. Although, the scope of developed transformation is narrowed only to transformations of structural

186

aspects of a system models, it still requires a big amount of work to prepare transformation of some of structural aspects of the system.

The next issue is to develop the authors’ own transformation tool, since they have to prepare, not only the tool but also a specification of the transformation language.

Further, the specification made within the language has to be translated to the target implementation language, which is Java, what not always is straightforward.

In general, lack of reliable tool support and standardised approach to transformation specification causes that every attempt of system development within

MDA will have to start from scratch (from creating the transformations); what will remove any gains that MDA can provide. The authors predict that proper tools play the key role in developing the transformations on the bigger scale.

The next issue is an approach that assumes full automation of transformation.

Though the full automation of transformations is possible, it comes with some issues.

It is caused by lack of information in PIM that has to be abstract enough to remain platform independent. Most of this information can be omitted and the transformation will proceed, but as in case of decision about strict-FP attribute for Java platform this decision will have to be chosen for whole transformation, not for specific element.

This issue can be fixed or by excess PIM, or by marking the model and giving up the automatic transformation.

The MDA seems to be the next step in evolution from machine code to platform independent software development. However, just as it is when we one uses high-level languages (e.g. C or Java); the code created on higher level of abstraction might have lower performance. That is why MDA will probably be used only for systems that need faster development, but with not necessarily optimal final architecture.

9.3 Future work

The first extension is to prepare transformations that will cover all structural aspects of the EDOC model, like Entities, Events, etc.

Another extension of the transformation set is to add to this set a collection of transformations of behavioural aspects of the system.

Moreover, the PIM of the system might be enriched by information about other aspects of the system, e.g. security or graphical interface aspects.

The transformation tool used in the thesis might be enhanced by additional features, as interpretation of the transformation language presented in the thesis.

Further, the language itself might be extended by other features that would help in developing and organising the transformations.

At the end, the work in this area might be focused on enhancing the transformation tool model checking ability, e.g. syntax and semantics checking, or ensuring consistency between transformed models.

187

10 R

EFERENCES

[1] Agrawal, A., G. Karsai and F. Shi. “Graph Transformations on Domain-

Specific Models”, Journal on Software and Systems Modeling, 2003

[2] Akehurst, D.H., “Transformations based on Relations”, ECOOP 2004

Workshop Reader, Workshop on Model Driven Development (WMDD 2004),

2004

[3] Akehurst, D. H., Kent S., and Patrascoiu O., "A relational approach to defining and implementing transformations between meta-models," Journal on

Software and Systems Modeling, vol. 2, pp. 215, November 2003.

[4] Alcatel, Softeam, Thales, TNI-Valiosys, Codagen Corporation, et al. MOF

Query/Views/Transformations, Revised Submission. OMG Document: ad/03-

08-05

[5] Andries, M. G. Engels, A. Habel, B. Hoffmann, H.-J. Kreowski, S. Kuske, D.

Pump, A. Schurr, and G. Taentzer. Graph transformation for specification and programming. Science of Computer Programming, 34(1):1–54, Apr. 1999.

[6] ArcStyler, http://www.arcstyler.com/

[7] ATOM: A Tool for Multi-Paradigm modeling, http://atom3.cs.mcgill.ca/

[8] b+m ArchitectureWare, Generator Framework, http://www.architectureware.de

[9] Bassett, P.G. Framing Software Reuse: Lessons from the Real World. Prentice

Hall, Inc., 1997

[10] Belaunde, M. J. Bezvin, and Thanh Ha Pham, “Implementing EDOC business components on top of a CCM platform”, EDOC 2003, 2003, p. 208-219 .

[11] Belaunde, M. and M. Peltier, “From EDOC Components to CCM

Components: A Precise Mapping Specification”, FASE 2002, 2002, p. 1-16.

[12] Bézivin, J., G. Dupé, F. Jouault, and J. E. Rougui. First experiments with the

ATL model transformation language: Transforming XSLT into XQuery. In the online proceedings of the OOPSLA’03 Workshop on Generative Techniques in the Context of the MDA, http://www.softmetaware.com/oopsla2003/mdaworkshop.html

[13] Booch G., Rumbaugh J., Jacobson I., “UML przewodnik uzytkownika”,

Wydawnictwa Naukowo-Techniczne, Warszawa, 2000

[14] Born, M. A.Blazarenas, M. Funabashi, C. Hirai

,

O. Kath, T.Ritter

and

M.

Soden, “An Open Modeling Infrastructure integrating EDOC and CCM”,

IEEE, 2001

[15] Bracha, G., J. Gosling, B. Joy and G. Steele, “The Java Language

Specification, Third Edition”, http://java.sun.com/docs/books/jls/third_edition/html/j3TOC.html

188

[16] Braun, P. and F. Marschall. The Bi-directional Object-Oriented

Transformation Language. Technical Report, Technische Universität

München, TUM-I0307, May 2003

[17] CBOP, DSTC, and IBM. MOF Query/Views/Transformations, Revised

Submission. OMG Document: ad/03-08-03

[18] CCM, http://www.omg.org/docs/ptc/04-03-04.pdf

[19] Czarnecki, K. “Generative Programming: Principles and Techniques of

Software Engineering Based on Automated Configuration and Fragment-

Based Component Models”, Technical University of Ilmenau, Germany,

October 1998

[20] Czarnecki, K., Eisenecker W. U., Generative Programming: Methods, Tools

and Applications, Adison-Wesley, 2000

[21] Czarnecki K., and S. Helsen, “Classification of Model Transformation

Approaches”, OOPSLA’03 Workshop, 2003, p. 1-17.

[22] Duddy, K., A. Gerber, M. Lawley, K. Raymond and J. Steel, “Model

Transformation: A declarative, reusable patterns approach”, Proceedings of the Seventh IEEE International Enterprise Distributed Object Computing

Conference (EDOC’03), IEEE, Location, 2003.

[23] EBXML, http://www.ebxml.org/

[24] Eckel B., “Thinking in Enterprise Java”, http://www.Mindview.net

, 05-06-

2003

[25] Frankel, D.S., Model Driven Architecture: Applying MDA to Enterprise

Computing, Wiley Publishing, 2003.

[26] Gardner, T., C. Griffin, J. Koehle r, 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

[27] Gerber, A., Lawley, M., Raymond, K., Steel, J., and Wood, A.,

”Transformation: The Missing Link of MDA”, Proc. Graph Transformation -

First International Conference, ICGT 2002, citeseer.ist.psu.edu/gerber02transformation.html, 2002

[28] Hearnden, D., Raymond K., and Steel J., “MQL: a Powerful Extension to

OCL for MOF Queries”, Enterprise Distributed Object Computing

Conference2003. Proceedings Seventh IEEE International, IEEE Computer

Society, 2003, p.264 – 276

[29] Interactive Objects and Project Technology, MOF

Query/Views/Transformations, Revised Submission. OMG Document: ad/03-

08-11, ad/03-08-12, ad/03-08-13

[30] Jamda, Jamda: The Java Model Driven Architecture 0.2, May 2003, http://sourceforge.net/projects/jamda

189

[31] JCP, UML profile for EJB http://www.jcp.org/aboutJava/communityprocess/review/jsr026/

[32] Jezequel, J.M., Pollet, D., and Vojtisek, D., “OCL as a Core UML

Transformation Language” Workshop on Integration and Transformation of

UML models, 2002

[33] Kent, S., and R. Smith, “The bidirectional mapping problem.”, ENTCS, 82(7),

2003.

[34] Kleppe, A., J. Warmer, and W. Bast, MDA Explained: the Practice and

Promise of Model-Driven Architecture, Addison-Wesley, 2003.

[35] Mantell K., "From UML to BPEL," 2003, http://www-

106.ibm.com/developerworks/webservices/library/ws-uml2bpel/

[36] Mashkoor, A., “Investigating Model Driven Architecture”, Master Thesis,

Department of Computing Science, Umeå University, Sweden, 2004

[37] MDR, “Metadata Repository (MDR)” http://mdr.netbeans.org/

[38] Mellor, S.J, and Balcer, M.J., Executable UML: A Foundation for Model-

Driven Architecture, Addison Wesley, 2002

[39] Mellor, S.J., Scott, K., Uhl, A. and Weise, D. MDA Distilled, Addison-

Wesley Professional, 2004.

[40]Microsoft, .NET site, http://www.microsoft.com/net/

[41] Miller, J. and J.Mukerji, “MDA Guide Version 1.0.1”, http://www.omg.org/docs/omg/03-06-01.pdf

.

[42] Miller, J. and J.Mukerji, “Model Driven Architecture – A Technical

Perspective”, http://www.omg.org/docs/ormsc/01-07-01.pdf

.

[43] Morrison, M., HTML and XML for beginners, Microsoft Press, Redmond,

2001

[44] No Magic, MagicDrawUML, http://www.magicdraw.com

[45] OMG, Action semantics for UML, Action semantics specification document, www.omg.org/docs/ptc/02-01-09.pdf, Object Management Group, August

2002

[46] OMG, CWM site, http://www.omg.org/technology/cwm/

[47] OMG, Common Object Request Broker Architecture, http://www.omg.org/technology/documents/formal/corba_iiop.htm

[48] OMG, Enterprise Collaboration Architecture (ECA) Specification, http://www.omg.org/cgi-bin/doc?formal/2004-02-01, 2004

[49] OMG, CORBA Component Model. http://www.omg.org/technology/documents/formal/components.htm

190

[50] OMG, “Enterprise Collaboration Architecture Specification”, February 2004 http://www.omg.org/docs/formal/04-02-01.pdf

[51] OMG, “Meta-Object Facility (MOF) Specification”, OMG document 02-04-

03, April 2002.

[52] OMG, “Request for Proposal: MOF 2.0 Query / Views / Transformations

RFP”, http://www.omg.org/cgi-bin/apps/do_doc?ad/02-04-10.pdf

[53] OMG, The Common Warehouse Model 1.1., OMG Document: formal/2003-

02-03

[54] OMG, The Object Constraint Language Specification 2.0, OMG Document: ad/03-01-07

[55] OMG, "The Unified Modeling Language Version 1.5," Object Management

Group, formal/03-03-01, March 2003.

[56] OMG. „UML Profile for Enterprise Distributed Object Computing”. OMG

Document: ad/01-08-20 http://www.omg.org/technology/documents/formal/edoc.htm

.

[57] OMG, “UML Profile for Enterprise Collaboration Architecture Specification”,

February 2004 http://www.omg.org/docs/formal/04-02-05.pdf

[58] OptimalJ 3.0, User's Guide, http://www.compuware.com/products/optimalj

[59] Otegem van, M., XSLT – Uniwersalny jezyk przeksztalcenia dokumentów

XML, Helion, Gliwice, 2003

[60] Patrascoiu, O., “Mapping EDOC to Web Services using YATL”, Enterprise

Distributed Object Computing Conference, 2004. EDOC 2004. Proceedings.

Eighth IEEE International,

IEEE

,

2004

, 286-297

[61] Poole, J. D., Model-Driven Architecture: Vision, Standards And Emerging

Technologies, April 2001

[62] QVT-Partners, “Revised submission for MOF 2.0 Query / Views /

Transformations RFP”, http://qvtp.org/ , 2003

[63] Rational Rose Web Site, Rational Software Corporation, 2003. http://www.rational.com/products/rose/index.jsp

[64] Rational XDE Web Site, Rational Software Corporation, 2003. http://www.rational.com/products/xde/index.jsp

[65] Rensink, A., (Ed.) Proceedings of the Workshop on Model Driven

Architecture: Foundations and Applications, University of Twente, Enschede,

The Netherlands, June 26-27, 2003, CTIT Technical Report TR–CTIT–03–27,

University of Twente, 2003, http://trese.cs.utwente.nl/mdafa2003

[66] Rozenberg, G. (ed.); “Handbook of graph grammars and computing by graph transformation: Volume I Foundations”. World Scientific Publishing, 1997.

191

[67] Schürr, A., A. Winter and A.Zündorf; “The Progress Approach: Language and environment”. In Chapter13 of G. Rozenberg (eds), Handbook of graph grammars and computing by graph transformation: Volume II Applications,

Languages and Tools, World Scientific Publishing, 1997.

[68] Sendall, S. “Combining Generative and Graph Transformation Techniques for

Model Transformation: An Effective Alliance?”, http://cui.unige.ch/~sendall/files/sendall-mda-workshop-OOPSLA03.pdf

[69] Sendall S., and W. Kozaczynski, “Model Transformation – the Heart and Soul of Model-Driven Software Development”, IEEE Software, 2003, p. 42-45.

[70] Sendall, S., Perrouin, G., Guelfi, N., and Biberstein, O., “Supporting Modelto-Model Transformations: The VMT Approach” Workshop on Model Driven

Architecture: Foundations and Applications, Technical Report TR-CTIT-03-

27, University of Twente, 2003

[71] Sun, Enterprise JavaBeans Technology, http://java.sun.com/products/ejb/ ,

[72] Sun, EJB 1.0 Specification, http://www.sun.com

[73] Sun, EJB 2.0 Specific ation http://java.sun.com/products/ejb/docs.html

[74] Sun, “Java Metadata Interface(JMI) ”, http://java.sun.com/products/jmi/index.jsp

[75] Sun, Java Syntax, http://java.sun.com/docs/books/jls/second_edition/html/syntax.doc.html

[76] Sun, JavaTM 2 Platform, Standard Edition, v 1.4.2 API Specification, http://java.sun.com/j2se/1.4.2/docs/api/index.html

[77] Sun Microsystems, Java 2 Enterprise Edition (J2EE). http://java.sun.com/j2ee/

[78] Sunyé, G., F. Pennaneach, W-M. Ho, A. Le Guennec and J-M. Jézéquel;

“Using UML Action Semantics for Executable Modeling and Beyond”.

Proceedings of 13 th

International Conference, CAiSE 2001, Switzerland.

LNCS (Lecture Notes in Computer Science), no. 2068, pp. 433-447, Springer

Verlag, 2001.

[79] Staron, M. and L. Kuzniarz, “Implementing UML model transformation for

MDA”, NWPER'2004 Workshop, 2004, p. 1-15.

[80] Tau Telelogic, http://www.telelogic.com/

[81] Unified Modelling Language, The official homepage of UML, www.uml.org

,

Object Management Group, Lastly accessed: May 17, 2004

[82] Varro, D., G. Varro and A. Pataricza. “Designing the automatic transformation of visual languages”, Science of Computer Programming, vol. 44(2):pp. 205--

227, 2002

[83] Vojtisek, D., “MOTOR PROJECT BasicMTL realization Guide”, modelware.inria.fr/IMG/pdf/MOTOR-F3. 2-

BasicMTLRealisationGuide_V0.4.pdf, 2004

192

[84] Wahler, M., “Formalizing Relational Model Transformation Approaches”,

2004

[85] Warmer, J. and A. Kleppe; “The Object Constraint Language: Precise

Modeling With UML”. Addison-Wesley 1998.

[86] Wolfram Research, “Mathworld”, http://mathworld.wolfram.com/

[87] W3C, XML Path Language Version 1.0, November 1999, http://www.w3.org/TR/xpath

[88] W3C, XSL Transformations (XSLT) Version 1.0, November 1999, http://www.w3.org/TR/xslt

[89] XMI, http://www.omg.org/technology/documents/formal/xmi.htm

193

A

PPENDIX

1 – D

ESIGN OF THE TOOL

Figure 70 - Basic Elements of the transformation tool

194

Figure 71- Interfaces and Classes of the Transformation Tool

195

Figure 72 – Examples of the specification of queries. Basic element of the framework

196

A

PPENDIX

2 OCL F

UNCTIONS

I

NDEX

7.4.4.1

A

DD

G

ENERALIZATION

...................................................................................................................155

7.4.4.2

A

DD

S

TEREOTYPE BY

S

TRING

........................................................................................................155

7.4.4.3

A

DD

S

TEREOTYPED

A

BSTRACTION

...............................................................................................156

7.4.4.4

A

DD

S

UBSYSTEMS BY

UML U

SAGE

.............................................................................................156

7.4.4.5

A

DD

U

SAGE

......................................................................................................................................156

7.4.4.6

C

REATE

B

EAN

S

UBSYSTEM

............................................................................................................156

7.4.4.7

C

REATE

J

AVA

C

LASS

.......................................................................................................................156

7.4.4.8

C

REATE

J

AVA

F

IELD

........................................................................................................................157

7.4.4.9

C

REATE

J

AVA

I

NTERFACE

..............................................................................................................157

7.4.4.10

C

REATE

J

AVA

M

ETHOD

..............................................................................................................158

7.4.4.11

C

REATE

J

AVA

P

ARAMETER

........................................................................................................158

7.4.4.12

C

REATE

M

ULTI

P

ORT

C

LASS

......................................................................................................159

7.4.4.13

D

OES

D

ATA

E

LEMENT

-J

AVA

C

LASS

T

RACE

E

XIST

..................................................................159

7.4.4.14

F

LATTEN PACKAGE

.....................................................................................................................160

7.4.4.15

G

ET ALL

P

ROCESS

C

OMPONENTS USED IN A

C

OMMUNITY

P

ROCESS

....................................160

7.4.4.16

G

ET

C

LIENT OF

MT

RACE

UML ................................................................................................160

7.4.4.17

G

ET

D

ATA

E

LEMENT

-J

AVA

C

LASS

.............................................................................................160

7.4.4.18

G

ET

EJBC

MP

F

IELDS

...................................................................................................................161

7.4.4.19

G

ET

EJBP

RIMARY

K

EY

F

IELD

....................................................................................................161

7.4.4.20

G

ET

E

XCEPTIONS

.........................................................................................................................161

7.4.4.21

G

ET

F

LOW

P

ORT

T

YPE

................................................................................................................161

7.4.4.22

G

ET

F

LOW

P

ORTS

.........................................................................................................................162

7.4.4.23

G

ET

F

ULL

N

AME

.........................................................................................................................162

7.4.4.24

G

ET

I

NDEX OF

..............................................................................................................................162

7.4.4.25

G

ET

I

NNER

C

LASSES

....................................................................................................................162

7.4.4.26

G

ET

I

N

P

ARAMETERS

..................................................................................................................162

7.4.4.27

G

ET

I

NTERFACES

.........................................................................................................................162

7.4.4.28

G

ET

J

AVA

T

HROWS

......................................................................................................................163

7.4.4.29

G

ET

M

ODEL

.................................................................................................................................163

7.4.4.30

G

ET

M

ODEL

E

LEMENT

................................................................................................................163

7.4.4.31

G

ET

M

ODEL

E

LEMENT BY

S

TEREOTYPED

A

BSTRACTION

.....................................................164

7.4.4.32

G

ET

M

ULTIPLICITY

.....................................................................................................................164

7.4.4.33

G

ET

M

ULTI

P

ORTS

.......................................................................................................................164

7.4.4.34

G

ET

O

PERATION

P

ORTS

...............................................................................................................164

7.4.4.35

G

ET

P

ROCESS

C

OMPONENTS TRANSFORMED TO

EJBS

ESSION

B

EANS

..................................164

7.4.4.36

G

ET

P

ROTOCOL

............................................................................................................................165

7.4.4.37

G

ET

P

ROTOCOL

I

NTERFACES

.....................................................................................................165

7.4.4.38

G

ET

P

ROTOCOL

P

ORTS

................................................................................................................166

7.4.4.39

G

ET

R

ETURN

T

YPE

......................................................................................................................166

7.4.4.40

G

ET

S

UBSYSTEM USED BY

S

UBS

...............................................................................................166

7.4.4.41

G

ET

S

UPPLIER OF

MT

RACE

UML.............................................................................................167

7.4.4.42

G

ET

T

AGGED

V

ALUE

...................................................................................................................167

7.4.4.43

G

ET

T

UPLE FOR

EJBR

EFERENCES TAG

....................................................................................167

7.4.4.44

H

AS

A

SYNCHRONOUS

F

LOW

P

ORTS

..........................................................................................167

7.4.4.45

H

AS

A

SYNCHRONOUS

M

ETHODS

..............................................................................................168

7.4.4.46

H

AS ON

M

ESSAGE

O

PERATION

..................................................................................................168

7.4.4.47

I

NCLUDES

R

ECURSIVLY

..............................................................................................................168

7.4.4.48

I

S

C

OMPONENT

U

SED

B

Y

...........................................................................................................169

7.4.4.49

I

S

J

AVA

F

INAL

..............................................................................................................................169

7.4.4.50

I

S

R

ESPONDS

................................................................................................................................169

7.4.4.51

I

S

S

YNCHRONOUS

........................................................................................................................169

7.4.4.52

I

S

T

RANSACTIONAL

.....................................................................................................................169

7.4.4.53

M

AKE

J

AVA

C

LASS

.....................................................................................................................170

7.4.4.54

R

EALIZE JAVA

.

IO

.S

ERIALIZABLE

..............................................................................................170

7.4.4.55

R

EALIZE JAVAX

.

EJB

.EJBH

OME

.................................................................................................170

7.4.4.56

R

EALIZE JAVAX

.

EJB

.EJBO

BJECT

..............................................................................................171

7.4.4.57

R

EALIZE JAVAX

.

EJB

.E

NTITY

B

EAN

............................................................................................171

197

7.4.4.58

R

EALIZE JAVAX

.

EJB

.M

ESSAGE

D

RIVEN

B

EAN

.........................................................................171

7.4.4.59

R

EALIZE JAVAX

::

EJB

::S

ESSION

B

EAN

.......................................................................................171

7.4.4.60

R

EALIZE JAVAX

.

EJB

.S

ESSION

S

YNCHRONIZATION

..................................................................171

7.4.4.61

R

EALIZE JAVAX

.

JMS

.M

ESSAGE

L

ISTENER

................................................................................172

7.4.4.62

R

EALIZE

P

ORT

I

NTERFACE

.........................................................................................................172

7.4.4.63

R

EALIZE

P

ROTOCOL

I

NTERFACE

...............................................................................................172

7.4.4.64

R

EMOVE

G

ENERALIZATION

.......................................................................................................172

7.4.4.65

S

ET

EJBE

N V

E

NTRIES

T

AGGED

V

ALUE

....................................................................................172

7.4.4.66

S

ET

EJBP

ERSISTANCE

T

YPE

.......................................................................................................173

7.4.4.67

S

ET

EJBP

RIMARY

K

EY

U

SAGE

..................................................................................................173

7.4.4.68

S

ET

EJBR

EALIZE

H

OME

A

BSTRACTION

...................................................................................173

7.4.4.69

S

ET

EJBR

EENTRANT

..................................................................................................................173

7.4.4.70

S

ET

EJBR

EFERENCES

T

AGGED

V

ALUE

....................................................................................174

7.4.4.71

S

ET

EJBS

ESSION

T

YPE

T

AGGED

V

ALUE

...................................................................................174

7.4.4.72

S

ET

EJBT

RANS

A

TTRIBUTE

T

AGGED

V

ALUE

...........................................................................174

7.4.4.73

S

ET

EJBT

RANS

T

YPE

T

AGGED

V

ALUE

......................................................................................174

7.4.4.74

S

ET

I

NSTANTIATE

U

SAGE

...........................................................................................................174

7.4.4.75

S

ET

I

NTER

B

EAN

U

SAGES

...........................................................................................................175

7.4.4.76

S

ET

J

AVA

F

INAL

T

AGGED

V

ALUES

............................................................................................175

7.4.4.77

S

ET

J

AVA

T

HROWS

T

AGGED

V

ALUE

.........................................................................................175

7.4.4.78

S

ET

J

AVA

V

OLATILE

T

AGGED

V

ALUE

......................................................................................175

7.4.4.79

S

ET

MT

RACE

D

EPENDENCY

......................................................................................................176

7.4.4.80

S

ET PERSISTENCE

T

AGGED

V

ALUE

............................................................................................176

7.4.4.81

S

ET

P

ORT

D

IRECTION

.................................................................................................................176

7.4.4.82

S

ET

R

EFERENCE

D

EPENDENCY

.................................................................................................176

198

A

PPENDIX

3 – L

IST OF

F

IGURES

F

IGURE

1 T

HE INCREASE OF LANGUAGE ABSTRACTION LEVELS WITHIN THE SPACE OF YEARS

[39] ........7

F

IGURE

2 T

RADITIONAL SOFTWARE DEVELOPMENT LIFE CYCLE

[34].........................................................10

F

IGURE

3 MDA

SOFTWARE DEVELOPMENT LIFE CYCLE

[34].......................................................................11

F

IGURE

4 T

HE BASIC ELEMENTS OF THE

MDA

FRAMEWORK

.......................................................................12

F

IGURE

5 M

ODEL

R

ELATIONSHIPS IN THE

MDA [42]....................................................................................17

F

IGURE

6 T

HE ARCHITECTURE OF T HE MODELS IN THE

MDA [42]..............................................................17

F

IGURE

7E

XAMPLE OF

PIM.

A

N EXAMPLE CLASS DIAGRAM OF LIBRARIAN SYSTEM AT DOMAIN

ABSTRACTION LEVEL

...................................................................................................................................19

F

IGURE

8 S

PECIFICATION AND ABSTRACTION LEVELS OF LANGUAGES

.......................................................21

F

IGURE

9 E

XAMPLE OF

PSM.

A

N EXAMPLE CLASS DIAGRAM OF LIBRARIAN SYSTEM AT DESIGN

ABSTRACTION LEVEL

...................................................................................................................................22

F

IGURE

10 E

XAMPLE OF STEREOTYPED MODEL ELEMENT

............................................................................25

F

IGURE

11 E

XAMPLE OF TAGGED VALUE

........................................................................................................26

F

IGURE

12 E

XAMPLE OF THE PROFILE SPECIFICATION

...................................................................................26

F

IGURE

13 E

XAMPLE OF A CONSTRAINT OF THE SAMPLE PROFILE

. .............................................................27

F

IGURE

14 P

ART OF THE

UML

META

-

MODEL

[55].........................................................................................28

F

IGURE

15 R

ELATIONS BETWEEN MODEL

,

LANGUAGE AND META

-

LANGUAGE

[34].................................29

F

IGURE

16 – B

ASIC TRANSFORMATION

S SIGNATURE

......................................................................................36

F

IGURE

17 – F

IRST EXTENDED SIGNAT URE OF TRANSFORMATIONS

...............................................................37

F

IGURE

18 – S

ECOND EXTENDED SIGNATURE OF TRANSFORMATIONS

..........................................................38

F

IGURE

19 – V

ERTICAL TRANSFORMATIONS

(

FORWARD REFINEMENTS

)......................................................40

F

IGURE

20 – V

ERTICAL

,

HORIZONTAL

,

AND OBLIQUE TRANSFORMATIONS

..................................................41

F

IGURE

21 S

CHEMA OF MERGING TRANSFORMATION

....................................................................................43

F

IGURE

22 – R

ELATION BETWEEN TRANSFORMATION DEFINITION LANGUAGE AND METALANGUAGE

....47

F

IGURE

23M

AIN TASKS OF TRANSFORMATION TOOLS

[20,

P

.334]...............................................................48

F

IGURE

24 D

IAGRAM OF THE MODEL TRANSFORMATION TOP

-

LEVEL FEATURES

[21]..............................49

F

IGURE

25 F

EATURES OF

T

RANSFORMATION

R

ULES

[21].............................................................................51

F

IGURE

26 F

EATURES OF RULE SCHEDULING

[21]..........................................................................................52

F

IGURE

27 S

CHEMA OF DIRECT MANIPULATION MODEL TRANSFORMATION APPROACH

[79]..................58

F

IGURE

28 C

LASSIFICATION OF LANGUAGES WITH RESPECT TO THEM SPECIALIZATION AND

ABSTRACTION LEVEL

[19]...........................................................................................................................60

F

IGURE

29 D

EFINITION OF RELATION IN THE RELATIONAL APPROACHES

...................................................61

F

IGURE

30 A

PAIR

XY

OF OBJECTS

X

AND

Y

[3] ..............................................................................................61

F

IGURE

31 R

ELATION IN

O

BJECT

O

RIENTED

M

ODELLING CONTEXT

[3] ....................................................61

F

IGURE

32 C

ONSTRAINTS ON A RELATION

,

MATCHING CONDITION

.............................................................61

F

IGURE

33 E

XAMPLE OF HIERARCHICAL RELATION

[2].................................................................................62

F

IGURE

34 G

RAPHICAL ICON AND CLASS WITH A

<<

RELATION

>>

STEREOTYPE TO REPRESENT

RELATION PATTERN OF CLASSES

[2]..........................................................................................................63

F

IGURE

35 S

EGMENT OF A METAMODEL FOR THE

BPEL

LANGUAGE

..........................................................63

F

IGURE

36 E

XAMPLE TRANSFORMATIONS BETWEEN

UML

AND

BPEL [2]................................................63

F

IGURE

37 OCL

DEFINITION OF RELAT IONS SPECIFIED IN

F

IGURE

36.........................................................64

F

IGURE

38 I

MPLEMENTATION OF MODEL TRANSFORMATION BASED ON

XSLT [79] ................................72

F

IGURE

39T

HE

ECA

MODELS RELATED TO VIEWPOINTS FROM

RM-ODP [50] .........................................76

F

IGURE

40 S

TRUCTURE AND DEPENDENCES OF

CCA

META

-

MODEL

[50] ...................................................77

F

IGURE

41 M

ETAMODEL FOR

S

TRUCTURAL

S

PECIFICATION

[50]................................................................79

F

IGURE

42 M

ETAMODEL FOR

C

HOREOGRAPHY

[50] .....................................................................................81

F

IGURE

43 M

ETAMODEL FOR

C

OMPOSITION

[50] ..........................................................................................82

F

IGURE

44 M

ETAMODEL FOR

D

OCUMENT

M

ODEL

[50] .................................................................................83

F

IGURE

45 M

ETAMODEL FOR

M

ODEL

M

ANAGEMENT

[50] ..........................................................................85

F

IGURE

46 P

ROTOCOL STRUCTURE

...................................................................................................................85

F

IGURE

47 – E

XAMPLE OF

C

OMPONENT STRUCTURE DIAGRAM

.....................................................................86

F

IGURE

48 – E

XAMPLE OF

C

OMPOSITION DIAGRAM

.........................................................................................86

F

IGURE

49 C

LIENT VIEW OF

M

ESSAGE

-D

RIVEN

B

EAN

D

EPLOYED IN A

C

ONTAINER

[73].......................93

F

IGURE

50 – E

XAMPLE OF STATELESS

EJBS

ESSION

B

EAN

..............................................................................99

F

IGURE

51 V

ARIABLES DEFINITION WITHIN THE QUERY PART OF THE SPECIFICATION

............................102

F

IGURE

52 V

ARIABLES DEFINITION WITHIN THE BODY PART OF THE SPECIFICATION

..............................103

F

IGURE

53 T

HE TRANSFORMATION SPECIFICATION SCHEMA

......................................................................103

199

F

IGURE

54 A

N EXAMPLE HEADER OF A TRANSFORMATION SPECIFICATION

.............................................103

F

IGURE

55 E

XAMPLE OF THE PRE BLOCK OF THE TRANSFORMATION SPECIFICATION

.............................104

F

IGURE

56 E

XAMPLE OF THE QUERY BLOCK OF THE TRANSFORMATION SPECIFICATION

.......................104

F

IGURE

57 E

XAMPLE OF THE BODY BLOCK OF THE TRANSFORMATION SPECIFICATION

.........................106

F

IGURE

58 T

OP

-

DOWN STRUCTURE OF

EDOC

TO

EJB T

RANSFORMATIONS

............................................107

F

IGURE

59 I

NPUT AND RESULT OF T RANSFORMATION FROM

EDOC

MODEL TO

T

RANSITIONAL MODEL

......................................................................................................................................................................110

F

IGURE

60 B

ASIC RESULT OF THE CREATION OF

M

ESSAGE

-D

RIVEN

B

EAN

..............................................132

F

IGURE

61 B

ASIC RESULT OF THE CREATION OF

E

NTITY

B

EAN FOR

M

ESSAGE

-D

RIVEN

B

EAN

.............134

F

IGURE

62 P

ROCESS

C

OMPONENT TO

EJBS

ESSION

B

EAN

– T

EST

I

NPUT

M

ODEL

...................................180

F

IGURE

63 P

ROCESS

C

OMPONENT TO

EJBS

ESSION

B

EAN

– T

EST

– R

ESULT

C

OMPONENT

T

RANSFORMATION

.....................................................................................................................................181

F

IGURE

64 C

OMPOSITION TO

T

RANSITIONAL

M

ODEL

– T

EST

– I

NPUT

M

ODEL

.......................................182

F

IGURE

65 C

OMPOSITION TO

T

RANSITIONAL

M

ODEL

T

EST

R

ESULT

....................................................183

F

IGURE

66 E

NUMERATION TO

J

AVA

C

LASS

T

EST

I

NPUT

M

ODEL

...........................................................183

F

IGURE

67 E

NUMERATION TO

J

AVA

C

LASS

T

EST

R

ESULT

......................................................................184

F

IGURE

68 – C

OMPOSITE

D

ATA TO

J

AVA

C

LASS

T

EST

I

NPUT

M

ODEL

.....................................................184

F

IGURE

69 – C

OMPOSITE

D

ATA TO

J

AVA

C

LASS

T

EST

R

ESULT

................................................................185

F

IGURE

70 B

ASIC

E

LEMENTS OF THE TRANSFORMATION TOOL

.................................................................194

F

IGURE

71I

NTERFACES AND

C

LASSES OF THE

T

RANSFORMATION

T

OOL

.................................................195

F

IGURE

72 – E

XAMPLES OF THE SPECI FICATION OF QUERIES

.

B

ASIC ELEMENT OF THE FRAMEWORK

....196

200

Was this manual useful for you? yes no
Thank you for your participation!

* Your assessment is very important for improving the work of artificial intelligence, which forms the content of this project