Thesis Summary:

Thesis Title:
AUTOMATED TRANSFORMATION OF PLATFORM SPECIFIC MODEL TO MULTI-PLATFORM IMPLEMENTATION
This research is focusing on automating the transformation from Platform Specific Models (PSM) to multiple platform code. Multiple
platform in this context is referring to Java, .Net and PHP. The main contribution of this study is a method that realizing the Platform Model
(PM) to drive the transformation from PSM to multiple platforms environment. The OMG descripted the PM as a system manual that used to
complement the technical information in the PSM model during the transformation process. Normally, the PM model implicitly embedded in
the model transformation and it holds technical information about the targeted platform environment.
Abstract
The Model Driven Architecture (MDA) paradigm, aim to support multiple platforms software production. The transformation is the major
MDA activity used to transform a Platform Independent Model (PIM) to a Platform Specific Model (PSM) that transformed to platform
executable code given a Platform Model (PM). The Unified Modelling Language (UML) is a general-purpose languages commonly used to
design the PIM and PSM models. Profiles and stereotypes are common UML extensions that enrich UML diagrams by concrete platform
details. Upon a transformation of a PSM extension based model to platform code, these extensions dispose that PSM toward a specific
platform technology. Consequently, changes in platform necessitate for a new costly time consuming PSM and/or its upstream PIM redesign.
In contrast, current model transformations implicitly assume a target platform for the platform-specific models. Therefore, change of targeted
platform call for a creation of new model transformations. In general, embed of platform specific elements in designing PSM models, or in
model transformations, limit the chance of support multiple platforms. This research is motivating for explicit PM use to drive model
transformation from PSM to multiple platforms. An explicit PM model designed to accommodate multiple platform specification in different
abstraction levels. The PM design supported by a domain specific language developed to facilitate valid and easy population multiple
platforms elements. The explicit use of PM in model transformation, make the PSM and the model transformation independent from specific
technology elements. Hence, PSM and model transformation can be used for producing multiple platforms software. Two case studies
provided to evaluate and test the method developed to transform PSM models to multiple platforms. A third part focus group of MDA domain
experts involved as well to evaluate this method. The main contribution of this study is in realizing the PM for explicit use by model
transformation to transform PSM models to multiple platforms.
Problem Background
Transformation of a PSM to multiple platform under the MDA approach is incorporating three difference challenges in the development
process. The MDA development process incorporates three languages that syntactically and semantically different. These languages are the
modeling language, the transformation languages, and the platform languages.
1. The Modeling languages: The OMG specified the UML to design PIM and PSM models. The UML is a general-purpose language
that comes with different behavioral and structural diagrams. These diagrams used to provide a high-level view of the software
products, structurally and behaviorally. Beside the class diagram, some behavioral diagrams like sequence diagram, activity diagram
and state machine diagram used to define the runnable behavior of the system. Although these behavioral diagrams are quite useful
for analysis but are not part of the executable solution model, even though they may still considered as a part of "software
development". Some researches focused doing model transformation from behavioral diagrams to code, but their success was limited
in a platform dependent specific scenarios with a lot of manual hard coding in the transformation side. These limitations are because
there are differing fundamental views about UML before and after the MDE paradigm. These views looking to UML as a Sketching,
UML as blue print, or UML as a programming language. This diverse in UML views limited some of its diagrams to analysis not
implementation or programming part. The OMG specified UML extensions to support these diagrams and to minimize this
abstraction gap between models and platform environment. UML Profiles, Stereotypes, Tags and Notions are examples of these
extensions. Normally the UML profiles include many stereotypes that represent platform-specific elements. For example, in the EJB
platform, there are stereotypes for "Session Beans", "Entity Beans" and "Message Beans" - The PSM models may include classes
with these stereotypes. The PSM to platform code transformation takes the UML model and produces the corresponding code. These
stereotypes are quite similar to the "annotations" used in Java or the "attributes" used in .Net. For instance, in Java we can annotate a
class with annotations such as "@Entity" or "@Singleton". An application serve takes these annotated classes and produces
additional code in runtime to implement the expected behavior. A problem with the use of UML Profiles and stereotypes is that each
time the library changes at the platform side, most probably followed by a modification in the corresponding PSM profile. In
addition, the use of a UML profile is limited and dedicated the PSM to a specific platform technology. Change in the platform

2.

3.

technology will lead to a new design with more cost and time. Another issue when adopting UML profiles and stereotypes is the
code generation composition. A PSM with a profile for EJB, may generate an EJB application. Similarly, a PSM with a security
profile may generate the corresponding code. However, in a case where an EJB application with security features a PSM with two
profiles for EJB and for security is required. There is no reason to assume that the model transformation used for generating an EJB
code is valid for generating a security code. Thus, a separate model transformation is required for each profile. Consequently, Profile
based PSM models does not support multiple platforms environment, and not easy to maintain upon a platform change or multiple
platform support.
The Transformation Languages: The MDA vision categorized by two schools of thoughts, the Translationist and the
Elaburationist. In the Translationist the code generated directly from the PIM model. Both, the PSM and the PM model implicitly
embedded in the transformation tools. Normally, the generated code using this school of thought is not readable or updatable and
fully dependent on the used transformation tools. This approach, best described as an MDE rather than MDA. xUML, and agile
MDA are examples of approaches that considered Translationist and it is normally supporting some UML behavioral diagrams
transformation. However, supporting multiple platform is limited by, what platforms tool vendors supports. The abstraction gap
between the generated code and the PIM is too high, making a reverse engineering from code to model impossible. Changes at
platform technology or to support multiple platforms require a complete new PIM design and code generation transformation
process. There are several embedded system developments using MDE researches are using this transformation approach and it is
focusing on a specific implementation platform environment.
The Elaborationist is the second school of thought that represents the main stream of MDA adopters that realizing the Separation of
Concern (SoC) concept. The PIM transformed to PSM through platform environment code. In this approach, there is an elaboration
room at the PSM and code level. The generated code is limited to the functions name. It is the developers task to manually updating
the functions body code; however, modifications made to the generated code not reflected in models unless done manually. Similar
to the Translationist school, the more specific platform elements exist in the PSM, the more quality code generated with less manual
elaboration. However, this is creating a dependency on a specific platform environment. On the other hand, the transformation tools
dealing with this approach normally equipped with concrete specific platform details. Hence, multiple platform support is limited,
and change in the platform will lead to new costly design and development process.

In general, both school of thought must deal with different levels of abstraction. Therefore, addition input required in the model
transformation upon the transformation from PIM to PSM and PSM to platform code. The MDA suggests that this extra input can be in the
form of a Platform Model (PM). In current MDA practice, the model transformation implicitly assumes the platform model. This makes it
much easier to write model transformations, since one only has to deal with the limited scope of targeting a single, assumed platform. It is
unclear, however, whether a model transformation can be used for other platforms than the one for which it was written. The only safe
assumption is that each targeted platform requires its own dedicated set of model transformations.
Problem Statement
As has become apparent in the above, the MDA approach offers support for platform diversity up to a certain extent. However, there is a
limitation concerning the transformation from PSM model to multiple platforms environment. Since the UML is a general-purpose language,
it is not enough to generate executable code at platforms environment. The current MDA development practice relying on UMLs profiles and
extensions to complement the UML diagrams in designing the PIM and PSM models. The class diagrams used to address the system structural
framework, but there is a gap in addressing systems behavioral aspects. Existing researches used some of the UML diagrams to generate
code. However, these researches are focusing on a specific platform technology for specific implementation scenarios. In response to this
issue, the OMG specified the UML extension to define systems behavior and to narrow the abstraction gap between the models and the
platform. However, Profile and extension based PSM models, are dedicated to a specific platform technology. For Multiple platform support,
a separate UML profiles and/or extensions used for each platform environment. Changes in the platform or to support multiple platforms will
lead to a costly time-consuming process of PSM models redesign. As there is no reason to assume that the model transformation used for
generating code out of a profile based PSM for one application context is reusable for generating a code of another profile based PSM with
different application context. Thus, a separate model transformation is required for each profile, which leads to a code generation
composition issue. Consequently, Profile based PSM models does not support transformation to multiple platforms environment, and not
easy to maintain upon a platform change.
On the other hand, the implicit use of the PSM and the PM in the model transformation and transformation tools make the development
process limited to a specific platform technology. On the other hand, the data interchange between dissimilar data resources like PSM model,
transformation tool, model transformation and targeted platforms, is triggering the necessity of having a source of information to fill any

knowledge gap between these heterogeneous components. Considering the fact that, any MDA based system must have the ability to store,
manage and publish both application- and system-level information (including descriptions of the environment itself).
There is a need for a method to design an explicit platform model that describe computer platforms, and have a degree of flexibility to
accommodate multiple platform specifications in different level of abstraction for multiple computer platform. It is also important to consider
the MDA specifications and principles to facilitate information exchange between the transformation tool and the UML models from one side
and the targeted platforms environments from the other, with less technology dependency.

Research Questions:
How to develop a method to address computer platform diversity in MDA model transformation context?
How to automate transformation from Platform Specific Model to multiple platforms?

Objectives:
The main objectives of this study is:
o To develop a method to address computer platform diversity in MDA model transformation context.
o To automate transformation from Platform Specific Model to multiple platforms based on the above method.
o To evaluate the proposed method.

Research Method
A case studies research method adopted for this study. The use of case studies as a research method is widely used in MDE
Researches, since it allows for detailed exploratory investigations, both prospectively and retrospectively, that attempt to understand
and explain phenomenon or test theories, using primarily qualitative analysis. Case studies provide detailed answers for how and why
questions. It gaining deep insights into chains of cause and effect. Testing theories in complex settings where there is little control
over the variables. Therefore, drive model transformation method from an initial prototypical set of interrelated source and target
models, which describe critical cases of the model transformation problem in a purely declarative way, make the case studies
research method most suitable for this study context.
The study investigates the existing researches concerning the transformation from PSM to code. Below are the gap and limitations
observed:
- The main stream of these studies is focusing on transforming software structure parts. Class diagrams used to design the
PSM. UML profiles and extensions used to describe some application behavioral parts.
- Few attempts managed to generate executable code out of PSM behavioral model (State Machine, Activity Diagram).
However, they either incorporate other approaches like DSL or they hard code platforms speciation in the model
transformation. Therefore, they approaches are limited to specific platform implementation scenario. Translationist
transformation school of thought dominates this research segment.
- Having concrete platform elements in the PSM model side or the model transformation make the development process
disposable for specific platforms.
- Concerning the transformation from PSM to executable code, existing researches paying less attention to the platform side.
Consequently, these approaches dedicated to specific platform technologies.
- Implicit use of Platform Model PM is common among existing researches. As a result, model transformations are not
reusable for platforms other than the one they initially designed for.
- Research that explicitly used the PM model are focusing on PIM to PSM transformation. Ontology used to describe the
platform element. However, the approach is limited to a single platform. The ontology platform high-level abstract
description is not enough for producing platform executable code.
From the above limitations and gaps, the objectives of this research is:
- To address platform diversity in model transformation context by focusing on explicit use of a platform model. The platform
model design should have a flexibility to accommodate multiple platforms specifications. It also required to conform with
the MDA specifications and compatible with other MDA components and tools.
- Use the PM to drive a PSM transformation to multiple platform environment.
To evaluate the proposed method, two case studies provided to test the transformation method to multiple platforms. The case studies

scenario focusing on the proposed method completeness, correctness, flexibility and reliability concerning the transformation from
PSM to multiple platforms code.
A third party focus group of domain expert to evaluate the overall proposed method.

Approach
Platform Modeling:
o We propose an explicit design for the Platform Model (PM) that used as a basis to express multiple platforms instances and
dependencies. This platform model designed inspired by the Entity-Attribute-Value (EAV). EAV employed as a knowledge
representation means for computer platform based on the computer platform metamodels (See Appendix A). Its open spiral
structure allow for expressing multiple platform structure in different levels of abstraction. Database views used to address
particular platform instances and/or dependencies. EAV table and the views built on top of it can be expresses in XML format. This is
because both described as an attribute value pair. More discussion about EAV concerning it is capabilities in knowledge
representation, integration between static and dynamic models and accommodation of metamodels with their instance models in one
repository are available in our published work:
http://www.jatit.org/volumes/Vol57No3/15Vol57No3.pdf
And
http://www.jatit.org/volumes/Vol68No1/14Vol68No1.pdf
The XML Model Interchange (XMI) is a languages specified by the OMG to facilitate information exchange between the MDA models,
transformation tools and platforms environment. By explicitly specifying the platform dependencies for each reusable model transformation,
each transformation can be guaranteed as valid for a well-defined class of platforms. Because platform instances use the same platform model
description, the platform model enables us to determine which platforms satisfy which platform dependencies. It is capability of hosting
multiple platform architecture in different level of abstraction (Up to a precompile libraries/APIs) is making the PSM model and the model
transformation more independent from any specific technology. Thus, multiple platform transformation is possible with no or minor change in
model transformation since most of the platform information populated in the PM side. The PM designed based on computer platform
metamodel (Appendix A). Each platforms component can be expressed in EAV structure. An attribute associated to a particular platform
component can be represented as an Entity for another platform component.
o Upon multiple platform population, EAV-PM grown more complex and fault tolerance. For that reason, a Domain Specific Language
(DSL) developed to ensure accurate and easy population of EAV-PM model. This DSL language called EAV-PM Language (EAVPML). Besides assuring the validity of the data entered to EAV-PM, EAV-PML developed to keep EAV-PM updatable during time.
Future platform change or new platforms can be entered through EAV-PML editor. (Appendix B) show a fragment of EAV-PML
grammar. While the whole concept discussed in our published work:
http://www.jatit.org/volumes/Vol79No1/15Vol79No1.pdf
Transformation on PSM to Code
o To automate the transformation from a PSM model to multiple platform code. The model transformation query the targeted platform
information, constrains and dependencies from the EAV-PM. These queries created in views to save particular platform specifications
for future productions. The views represented in XMI format to conform in order to be readable by the transformation tool during
model transformation. The targeted platforms in this study are Java, .Net and PHP.
o Accelo is an OMG MDA specified tool that support model to text transformation. It support template base transformation, where
predefined templates used to accommodate the generated code. These Templates divided to public and private modules. The
developers can elaborate the public modules, while the private modules dedicated for transformation tools to elaborate. However, the
private module can be customized in the transformation tool manifest. It is normally, concerned with the target languages file
specifications, e.g. file extension, header, linked library and classes, etc. A batch script used to order the generated code at the
template side, based on a refined PSM state diagram version.

Since, targeted platforms specifications resides at EAV-PM and it is up-to-date, the above transformation scenario implied for new
platforms or upon a change in existing one.
Accelo transformation tool provide a Using Accelo, case studies with different scales provided to formulate and test the transformation
method. The design science principle applied to select the case studies concerning its scale, completeness and relevancy to the subject matter.
o

Case Study I (Website Factory):

The website factory is a common case study in the MDA domain with known input and output. Similar like content management systems, the
website factory nature can be described as a meta-metamodel that generates website instance metamodels. Therefore, the generated code is a
website metamodels as well that can provide instance websites. The EAV-PM prepopulated by mobile and desktop computer elements for Java
and .Net platforms. The UML class based PSM metamodel with one stereotype element provided as a source model to the transformation
tools. Accelo is an OMG specified transformation tool for M2T transformation. The tool support template based model transformation. The
model transformation take the Website factory PSM metamodel as a source model, query the chosen platform environment technical
information, and generate the code for the targeted platform. The web factory PSM metamodel in .ecore format transformed to executable
code for Java desktop platform. The model transformation query the Java desktop libraries, constrains and dependencies from EAV-PM. A
transformation table used to compare and validate the correctness of the generated code verses the PSM class diagram and the expected results
for Java desktop platform. The results was complete and pretty matching the expected output. Similarly, the PSM transformed to Java mobile
platform producing mobile Java code, where the model transformation updated by reload the .genmodel with Java mobile elements from
EAV-PM and a mobile java code regenerated. The same steps followed in producing .Net code from the same PSM metamodels. It worth to
mentioned that there are four different libraries generated from the Calendar stereotype presented in the PSM metamodels class. The
java.util.Calendar is a common Java class that exist in J2SE and J2ME. However, they Serializable implemented interface not supported
by the later. For that reason, each platforms type or version iteratively populated in EAV-PM as a separate new platform, regardless the
commonality between the platforms types and/or versions. For the .Net C# generated code, the Calendar stereotype represented by the C#
class named System.Web.UI.WebControls.Calendar. Nevertheless, in the mobile version of code, the calendar stereotype represented by
System.Web.UI.MobileControls.Calendar class.
A general modularity support platform template populated by the generated code. A minor change done in the Accelo transformation manifest
during each transformation to adjust the output file extensions, headers and targeted language tags. The full project of this case study can be
downloaded from (https://www.dropbox.com/l/RtjY1X7AwYbc6FjLhAs24a?).
Case study results and observations:
- EAV-PM shown great flexibility in accommodating multiple platforms specifications and elements in different levels of
abstractions.
- Java, .Net C# accommodated in EAV-PM up to libraries level.
- Although the PSM is a Java platform specific the model transformation was capable to transform it to multiple platforms.
- A transformation table used to compare the generated code verses a pre-validated code for each targeted languages from one
side and PSM class element on the other side.
- The explicit use of EAV-PM eliminated the model transformation and the model design from the platform dependencies.
- No change required at the PSM model concerning the use of the calendar stereotype. Instead, the stereotype replaced by the
EAV-PM equivalent targeted platform library.
- The PSM class diagram in this case study restricted the generated code to represent the structural static elements of the PSM
model. In other word, there is no representation of behavioral elements in the generated code.
Successful transformation of a website factory PSM metametamodel instance metamodel code for multiple platforms technology is
increasing software productivity with less cost and time.
Case Study II Java Messaging System (JMS):
The Java Message Service (JMS) API is a subset of the Java Message Oriented Middleware (MOM) API. The JMS used for exchanging
messages between two or more nodes. It is under the J2EE, that standardized by Sun Corporation. Normally, Applications use JMS abstractly
and exchange asynchronous messages through a diverse platform environment. The JMS provide four basic operations, which are: Create,
Send, receive, and read messages. This case study show how the MDA principles applied to develop a model based messaging system. By
explicitly using EAV-PM, a JMS PSM metamodel transformed to a multiple platform concrete Java and PHP code. Likewise the website
factory case study, given the EAV-PM the Accelo transformation tool used to drive the model transformation from the JMS PSM metamodel
to Java and PHP code.

Beside the transformation from PSM metamodel to multiple platforms code, EAV-PM employed in this case study to provide user defined
precompiled APIs. These APIs used to embed a new PHP platform application to function on top of the JMS generated instance Java JMS
model. This platform is a WhatsApp instant messaging system. The WhatsApp treated on this case study as a new platform that host
applications working on top of it. In addition, a Customer Relational Management (CRM) PHP application run on top of the JMS system. It
worth to mentioned that the WhatsApp platform is abstractly used through a third party API. The code behavior at the platform side started
with establishing connection and initiate session at the JMS client side. The buffered data message sent from producer process to the
consumer process. The consumed process at the consumer side identify the MsgId and forward the tagged message to WhatsApp platform.
Noted that the WhatsApp designed on a PHP platform that generated from another PSM JMS version that for routine processing purpose
designed based on STM diagram. The JMS client consumer deliver the message to the WhatsApp API that process the pass the message to
The WhatsApp corporation platform. In reverse the messages received from WhatsApp corporation platform processed by the WhatsApp API
and forwarded to the JMS Client using platform. The WhatsApp API incorporated a simple PHP CRM application menu with 5 options that
generated from an activity diagram PSM Model. The start and exit feature of the activity diagram allow for executing specific functions
triggered by other processes. The EAV-PM prepopulated with the PHP and JAVA platforms information along with a precompiled concrete
conversion API that convert PHP code to JAVA and vice versa. In order to fulfill the structural and behavioral aspect this multiple platforms
systems, three versions of PSM provided in this case as per below:
o A class diagram PSM: This PSM provide the JMS application structural components. Other PSM versions derived from it through
chain of refinement transformation given EAV-PM.
o The State Diagram PSM: This PSM derived from the class diagram based PSM to represent processing routines. Each routine
represented by a state (e.g. connection, session, buffer, etc.). Events are state transitions. For instance, during the connection
establishment (SetConnect()), the "arrow" going from a connection class to the "session" class, indicating of session initiation. In
addition, there are some states to represent different types of operations (e.g. classification if the MsgId). In addition, the State
diagrams used to represent the WhatsApp composite processing routines, i.e. routines that combine CRUD simple operations and/or
other composite operations. The use of state diagrams based PSM allow for represent the system behavioral nature. Where routines
(states) can call other through (transitions). Alternatively, in the (Consumer) operation case the processing of the consumed message
may result to go to another routine (several transitions from the same state).
o The Activity diagram PSM: This PSM designed for a limited specific task. It serve as a flow chart to represent the CRM menu
selection.
Case study results and observations:
- The use of EAV-PM mode l offers great flexibility in combining several platforms elements in model transformation from
PSMs to platform.
- EAV-PM capability of accommodating multiple platforms with different abstract levels that include precompiled libraries,
make system integration during model transformation is possible.
- EAV-PM show flexibility in transformation of structural as well as behavioral PSM models t code.
- A template based M2T transformation targeted multiple platforms in diverse technology stream with unlike abstraction
levels.
- Relating the PSM extension elements to their targeted platform corresponding parts though EAV-PM model, provides more
flexibility in supporting multiple platforms.

R
Q
s

Research Gap

Findings

Conclusion

Contribution

automateRQ 2 -How to develop a methodRQ 1: -How to

R
Q
s

The class diagrams

Profile or
used to address the
extension
system structural
based PSM
framework, but there
models are
is a gap in
disposed for
addressing systems
specific
behavioral aspects
technology
Research Gap
PSM to multiple
platform
Transformation
under the MDA
incorporates three
difference
challenges in the

Findings

Technology is
volatile;
having
concrete
platform
elements at
the PSM
Conclusion

Theoretical:
Linking the PSM extension elements to their
targeted platform counterpart though EAV-PM
model, gives more flexibility in supporting
multiple platform.
The explicit employment of EAV-PM make the
model transformation reusable for multiple
Contribution

Theoretical:
Both
In both
transformation
transformatio Having targeted platforms information in EAV-PM
school of
n approaches,
instead of the model transformation or
thought must
implicit hard
transformation tools, make the model
deal with
coding of PM
transformation reusable for multiple platform
different levels
in model
with no or minor changes.
of abstraction.
transformatio Having Platform constrains and dependencies

Flexibilit
y

complete
Method correctness
ness

Method

Evaluation
How you describe the adequacy and completeness of this method
concerning:
o Automated transformation from PSM models to multiple
platforms?

Is the method correct?

Yes

No

Is the transformation from PSM to multiple platform code

correct?
Is the overall method of the PM design correct?

Yes

No

Yes

No

Is the method capable to transform behavioral and structural

PSM model to code?
Is the PSM behavioral aspect reflected correctly in the
generated code?
Is the PSM structural aspect reflected correctly in the
generated code?
Is research method adopted to achieve the research results
is correct?
Does the method support multiple platform transformation?

Yes

No

Yes

No

Yes

No

Yes

No

Yes

No

Does the EAV-PM have the flexibility to adopt multiple

platform specifications?
Does the EAV-PM can integrate with the transformation and
modelling tools?

Yes

No

Yes

No

AbstractionLevel of

be
Not
Supp
ort

Conformance with omg

MDA principles

Quality evaluation framework

Quef is considered as the MDWE methodologies evaluation framework, but generally, it can
used to evaluate other kind of methodologies given the below check list questionnaire.
- The method can defines a metamodel for the
Supp
Partial
Platform Specific Model where the model may not be
ort
ly
executed, although it contains all enquired
Suppo
information regarding a specific platform that
rt
developers may use to implement the executable
code.
- The method support with different levels of
Supp
Partial
abstraction?
ort
ly
Suppo
rt
- Is the PSM model based on to the OMG UML
Supp
Partial
specifications?
ort
ly
Suppo
rt
- Is Transformation tools conform to OMG M2T
Supp
Partial
Transformation?
ort
ly
Suppo
rt
- Is the PM designed based on the OMG specification?
Supp
Partial
ort
ly
Suppo
rt

Not
Supp
ort

Not
Supp
ort

Not
Supp
ort
Not
Supp
ort

Transformation

Is the PM capable to exchange information with the

OMG transformation and modelling tools?

Supp
ort

It uses a standard language for defining

transformation rules (i.e. providing ATL, QVT or Graph
transformations)?

Supp
ort

It provides mapping functions or automatic

transformations such as PIM2PIM?

Supp
ort

It provides mapping functions or automatic

transformations such as PIM2PSM?

Supp
ort

It provides mapping functions or automatic

transformations such as PSM2PSM?

Supp
ort

It provides mapping functions or automatic

transformations such as PSM2Code?

Supp
ort

It provides a separate explicit platform model for

describing the transformation?

Supp
ort

It provides a metamodel based on the Meta Object

Facility (MOF) and XML-based interchange format for
UML and other MOF-based metamodels and models
(XMI)
The method support model and metamodel definition
for PSM?

Supp
ort

The method support model and metamodel definition

for PIM?

Supp
ort

The method support model and metamodel definition

for Platform?

Supp
ort

The method support model and metamodel definition

for model transformation?

Supp
ort

This method is described as a platform independent

method?

Supp
ort

Is the method support multiple platforms

transformation?

Supp
ort

Standard
defnition

Platform
depende
ncy

Supp
ort

Partial
ly
Suppo
rt
Partial
ly
Suppo
rt
Partial
ly
Suppo
rt
Partial
ly
Suppo
rt
Partial
ly
Suppo
rt
Partial
ly
Suppo
rt
Partial
ly
Suppo
rt
Partial
ly
Suppo
rt
Partial
ly
Suppo
rt
Partial
ly
Suppo
rt
Partial
ly
Suppo
rt
Partial
ly
Suppo
rt
Partial
ly
Suppo
rt
Partial
ly

Not
Supp
ort
Not
Supp
ort
Not
Supp
ort
Not
Supp
ort
Not
Supp
ort
Not
Supp
ort
Not
Supp
ort
Not
Supp
ort
Not
Supp
ort
Not
Supp
ort
Not
Supp
ort
Not
Supp
ort
Not
Supp
ort
Not
Supp

Suppo
rt

ort

APPENDIX A

10

APPENDIX B

11