Journal of Software Engineering and Applications, 2011, 4, 195-216
doi:10.4236/jsea.2011.44023 Published Online April 2011 (http://www.SciRP.org/journal/jsea)
195
End to End Development Engineering
Abdelga ffar Ha med1, Rob ert M. Colomb2
1College of Computer Science and Information Technology, Sudan University of Science and Technology, Khartoum, Sudan;
2Faculty of Computer Science and Information Systems, Universiti Technologi Malaysia, Skudai, Malaysia.
Received February 22nd, 2011; revised March 10th, 2011; accepted March 13th, 20 11.
ABSTRACT
Raising software abstraction and re-use levels are key success factors for producing quality software products. Model-
driven architecture (MDA) is an OMG initiative following this trend by mapping a conceptual model of application
specified in platform independent model (PIM), to one or more platform specific models (PSM) automatically. Because
there is little previous work tackling the development problem from specification through to implementation, this paper
proposes End to End Development engineering (E2EDE) method using MDA methodology. E2EDE is intended to fill
the mapping gap between PIM and PSM in MDA. The notion of variability is utilized from software product line and
used to model design decisions in PSM. PIM is equipped with Nonfunctional requirements which borrowed from Design
pattern to inform design decisions; thereby guiding the mapping process. In addition we have developed a strategic
PSM for messaging systems can be configured to produce different applications such as the helpdesk system which is
used as a case study.
Keywords: End to End Engineering, MDA, Metamodeling, Domain Engineering
1. Introduction
The complexity of producing large-scale software systems
is increasing due to the increased complexity of require-
ments. Technologies are volatile for many reasons but
enhancing the quality of services is among clear reasons
justified by software providers. For example, java plat-
form versions and Google chrome browser has adopted
new browsers technology. The functionality of browsers
is already crafted (i.e. Mozilla) but putting it into a new
fas hi on is because of security, performance, reliability,
and etc. On other hand, service-based system (SOA) has
emerged as new engineering discipline encourages orga-
nizations to integrate t heir s ystems i n a sea mless manner.
These highlight questions like 1) How to extend the tra-
ditional methods (Code-based) in a longlived architec-
ture to deliver these new businesses? 2) how to provide
an effectiv e integration with legac y systems? 3) If a deci-
sion is made to change technology (acquiring new qual-
ity such as security and performance) is the design easily
adaptable? The trend now is proposing model-based en-
gineering approach which means separating concerns
where software development is driven by a family of
high level languages [1]. To this end abstraction level is
raised above 3GLs which increases re-using
theme and put software artifact into a situation of core
asset. More i mportantly formalizin g of these artifacts (i.e.
metamodels) leads to realize the benefit of high degree of
automatio n. T his me a ns a mac hiner y of spe cifica tion (i.e .
UML), s ync hr o niz at i on a nd ma nagement of these models
are essential. Thus, software not a program became like
an information system itself. Thereby the crafting of code
is becoming a manufacturing process not a personal skill.
Model Driven Architecture (MDA) is a new software
development method following that trend. It raises ab-
straction level and maximizes re-use. Using MDA, we
will be able to work with software artifacts as assets
which from the software engineering perspective is a ma-
jor success factor for reliable and fast development. The
philosophy of MDA is to do more investment on soft-
ware artifacts (models) to increase their efficiency, lead-
ing to systematic and more powerful mechanisms for so-
ftware re-use.
MDA is an aspect of the more general discipline of
software reuse. The synergistic relationship among MDA
and the longer-established areas of Design pattern and
software product line engineering (SPL) [2] has been stu-
died as part of the present research [3,4].
The problem of producing a complete solution from
specification through to implementation is still a long

End to End Development Engineering
196
standing research aim, and because of the mapping gap
from PIM to PSM, E2EDE has emerged. Most of previ-
ous work i n MD A has bee n o n infra st ruct ure and compo-
nents. Therefore the major question in this paper is how
to write a pro gram in MDA?
End to End development engineering (E2EDE) is a
new trend to software engineering, proposed to answer
that question, which uses MDA methodology and explo-
its some experience from Software Product Line (SPL)
and lessons from Design Pattern (e.g. nonfunctional re-
quirements) to a uto mate the develop ment fro m specifica-
tion through to implementation. In doing so, we need to
investigate the relationships among MDA, SPL, and de-
sign patte rn and how MDA can fit on them. There fore t he
contributions of the paper are the following:
1) We present E2EDE to automate the mapping pro-
cess as realization to MDA which is intended to produce
prod ucts without entirely writing code.
2) We discuss the relationship between MDA, SPL,
and d esign p atter n and ho w MD A can fit in the both lo n-
ger established re-using approaches .
3) We share some lessons learned and challenges of
MDA software engineering in practice.
Domain engineering is the key concept utilized from
SPL which realizes breeding of a number of products that
have similarity and some sort of variability in features.
Desig n patter n in the hi stor y of so ftware e ngineer ing has
concerned with linking the design with nonfunctional
requirements. Therefore, Nonfunctional requirements is
borrowed as a concept.
The paper is organized as follows: Section 2 describes
MDA as a major method used in E2EDE. In Section 3 we
explain the problem through example of mappings from
QVT specification. The proposed E2EDE methodology
is discussed at Section 4. The concepts of E2EDE are
validated by case study at Section 5. Sections 6 and 7
describe the relationship among MDA, Design Pattern
and SPL. Section 8 draws on the principle of MDA and
shows a case of strategic PSM. In Sections 9 and 10 we
discuss MDA and E2EDE implementation aspects re-
spectively. In Section 11 the realistic value of our ap-
proach with existing platforms is investigated. A conclu-
sion is presented in Section 12.
2. Model Driven Architecture (MDA)
MDA is a new development paradigm initiated by the
OMG aimed at software development driven by model [1].
In this case, a Platform Independent Model (PIM) is used
to specify application behavior or logic by using MOF or
a MOF-complaint modeling language [3]. This step re-
presents a problem space in an application-oriented pers-
pective. A Platform Specific Model (PSM) is used to rea-
lize a PIM. It represents a solution space from an imple-
mentation-oriented point of view. Therefore, a transfor-
mation from the problem space to the solution space is
required. The automation of this process is the ultimate
goal of MDA. Thereby, when we need to change the ap-
plication, cha nges will be in onl y one par t (PIM) without
affecting implementatio n technolo gies (PSM). Converse-
ly, when the platform such as SQL Server is changed re-
targeting a new platform for example new version (has
enhanced feature), we need only to select the appropriate
PSM and then regenerate the code not only without mod-
ifying PIM but also this time re-using most of the trans-
formation. P roductivity becomes higher and c ost is redu-
ced due to the increased reuse of models. In addition,
maintenance becomes cheaper. It is worthwhile to obser-
ve here that MDA is working with models as assets that
can be reused once the initial investment is made. MDA
depends on a well established code-base.
2.1. MDA Transformation Process
The transformation from PIM to PSM is done by a ma p-
ing function, which is a collection of mapping rules. In
this case some or all of the content of the target model is
defined. It is expected that when MDA automates this
process, development efficiency and portability would
significantly increase. In addition, the mapping function
can be repeated many times (re-used) for different appli-
cations using the same PIM and PSM metamodels. MD A
also helps avoid risks of swamping the application with
implementation deta il which causes model divergence [5].
The steps of designing a system is to create a concept-
tual model by designers for application requirements and
developing anot her implementa tion model to map the fir-
st int o the sec ond. B ut this might in volve many sub a cti-
vities. Ho wever, we can divide MD A into two majo r pro-
cesses [1]:
1) Mode l to Model mappings
The mapping in this stage does not consider any speci-
fic characteristics or special cases that apply to technolo-
gy or platform (called M2M). The result of this phase is
still high level model but for code (P SM instances).
2) Bringing i n a Particular Platform
The goal of this mapping (sometimes called M2T) is
tailoring the conceptual model to specific technology.
Different platforms have different features and constrain-
ts so step 1 will be refined to conform to features of one
of the selected platform. The result in this phas e is expec-
ted to be context dependant code expressed in a platform
concrete syntax. In fact, we intended to use the word
bringing to denote applying the principle of MDA in de-
veloping standard PSM.
2.2. Met amodeling
The conceptual model of the design language such as

End to End Development Engineering
197
UML data model (i.e. class diagram) is called a me t a-
model, which has concept like a class. A particular design
in a desi gn language is called model instance like student
class in the student record system. This model instance
can be visualized by using UML model instance (i.e. ob-
ject diagram) but also MOF has similar model instances
metamodel. A metamodel defines a schema for database
called a repository. The population of this repository is
the model instance. Formation rules of the metamodel are
expressed as constraint on the repository [6]. A meta-
model represents syntax of a modeling language. If the
metamodel tells the designer how to create a model in-
stance, it is said to be concrete syntax [6]. If it does not,
it is said to be abstract syntax. Therefore, sometimes
rendering conventions augmented with abstract syntax to
generate concert syntax like MOF instance specification
[7].
Model-based design that relies on a repository (tables
or data structure) for storing a complex object (design), is
the key art behind the MDA app roach. For example QVT
mappings are specified as patterns on schemas, or meta-
model [8]. In this way, information contained in the mo-
dels is separated from the algorithms defining tool be-
havior, inste ad of b eing hard -code d into a tool. The algo-
rithmic part of tool communicates with models via an
abstract program interface (API), which affords the facil-
ity to create, modify and access the information in models
[9]. Further, MDA tools can transform model instances
into various forms. For example, the mappings from PIM
to PSM takes PIM metamodel instances from the instan-
ce repository and turns it into corresponding instances
updating the target repository, moving from proble m sp a-
ce to solution space.
Thi s mappin g ac tivit y is do ne us ing st anda rd lang uage
independent of the source and target. The metamodel of
the ma pping fro m end to a nothe r end c an also be r e-used
as an asset.
2.3. Query, Views, and Transformations (QVT)
Two kinds of transformation are recognized in MDA
community:
• Horizontal, that does not change the abstraction
level, for example from PIM to PIM which is used
when a model is enhanced, filtered or specialized
(mapping fro m anal ys is to desi gn),
• Vertical, that changes the abstraction level, for ex-
ample projection to the execution infrastructure.
Four types of these transformations are categorized
in [10].
There are tools to specify such mappings, such as
query-view-transfor m Q VT [8]. QVT is an OMG standard
which helps us to specify rules for the transformation
function. QVT uses the concept of predicate (expression
evaluated to true or false) and pattern (set of expressions)
in much similar way a s pro log programming language.
The intended scenario of writing a progra m using M DA
will be demonstrated first by an example then below in
our case study where the mapping task is the major activ-
ity. Generally the application development is a process
invol ves man y trans format ions so vertical and horizontal
or combination of them might be used.
3. MDA Example and Mapping Proble m
We will use the QVT specification [8] example of object
to relational mappings in order to understand where the
problem is in this context. For sake of simplicity we fo-
cus on part of the mappings between PIM (object model)
and PSM (relational model). This example shows the
mappings take place between simplified UML2 metamo -
del in Figure 1, the PIM, and the PSM in Figure 2.
The mapping between conceptual models and relatio-
nal schema is well established in the database. The gen-
eral idea is that classes map to tables, packages map to
schemas, attributes to columns, and associations to for-
eign keys. We will discuss p art o f this mappin g informal-
ly then we will show simple QVT rules for that.
In Figures 3 and 4 examples we have a relation (use
to specify rules of mapping source to target) named Pac-
kageToSchema, and ClassToTable. Both have two do-
mains that will match elements in uml (our PIM) and
rdb ms (our PSM).The relation ClassToTable specifies the
map of a class which has attr ibute na me wit h val ue e qua l
the variable “cn”. All classes instances in uml repository
will populate this variab le one by one. For example if the
model i nsta nce o f our P IM is stud ent re cord system, the se
will be person, lecturer, student, etc (M1). If the precon-
dition is satisfied by this way the enforce clause is very
similar to a checkonly clause. If there is an instance in
the rdbms repository satisfying the pattern expression,
then the enforce clause behaves as a predicate, with the
value true. If no such instance exists, then the QVT en-
gine will create one.
The mapping takes structural patterns in the M1 PIM
model (problem domain) instance into in some cases
quite different structural patterns in the M1 PSM model
(implementation domain). The patterns are described in
the M2 metamodel. Thereby that mapping is grasped as a
part of the process of specifying and implementing the
system. This process in most traditional software engi-
neering methods is done manually. The ultimate goal of
mapping is having a way to be able relate M0 instances
of the PIM to M0 instances of the PSM. But the standard-
document of MDA [1] does not s pe cify how to do th at.
MOF specification has described how to create instan-
ces from MOF-based metamodel. When we talk about
MOF we mean M2 level in the OMG hierarchy. Both

End to End Development Engineering
198
Figure 1 . Simplified UML2 metamodel from QVT [8].
Figure 2. Simplified relational database model from QVT
specification [8].
create and destroy methods for objects and links are spe-
cified as MOF standard operations for creating and de-
leting dynamic objects [7]. So the objects created and
destroyed by these methods are of kind M1 objects for
M2 metaclasses. By this way an instance model will be
created for M2 metamodel elements similar like having
student, lecturer, and course, etc., instances. UML stan-
dard also specifies methods for creating instance model
for M1 objects which are M0.Hence since like the in-
stance model of record system is UML instance model
then it should be able to create m0 objects using UML
model instance inherited capabilities: create and destroy
of objects and links.
The intended scenario for mapping is that an applica-
tion using application terms have a facility to create ob-
jects which is PIM instance model. On other hand the
implementation model that is PSM creates objects corre-
sponding to that objects using PSM concepts and terms
which repr esents a design voc abulary. To this end still i n
the MDA development (i.e. using MDA to solve prob-
lems) the question is how to do this process which re-
quires finding concrete technical mapping methods.
A general method to approach this problem is needed
whereby one could develop application without entirely

End to End Development Engineering
199
Figure 3 . Mapping package to schema QVT rul e.
Figure 4 . Mapping class to table QVT rule.
writing code. Here the task for developer/modeler is a
function of specificatio n where applica tion requirements,
implementation and mapping metamodels are presented
usin g desi gn la nguage s suc h as UML/MOF and mapping
language such as QVT. In this case mapping and syn-
chronization among models are performed by toolset.
4. Proposed E2EDE Design &
Implementation
This section demonstrates key points of E2EDE and ex-
plores most important aspects that should be addressed.
4.1. Introduction
End to End development engineering (E2EDE) is a novel
paradigm intended to automate software development
from the specification end (i.e. object model) to the im-
plementation end (i.e. relational model) using the MDA
approach. The central issue is filling the mapping gap
between PIM and PSM in MDA.
Theor etically E2EDE is inspir ed from an investigatio n
of the synergistic relationship among MDA, SPL, and de-
sign patterns as we will see in Sections 6 and 7.T he r atio-
nale behind establis hing this relations hip was from litera-
ture SPL and design patterns have long history of re-use
software development. So they are longer established re-
use methods. MDA is a more recent stream of re-use.
E2EDE engineering is going to exploit this relationship
to achieve its mapping goal. The key concept in SPL is
variability which gives customization or configuration
options. Variant feature is a place in the software artifact
can be populated by at least one variant at a time from a
set of variant. For example, if color is variant feature
then Red is one variant. We conceive design decisions a s
variation point s and the design choice s as variants popu-
lating these po ints. T his comes fro m the obser vation t hat
PSM as a design artifact has different structures most
properly lead to different architectural qualities. Therefore ,
to model design decisions we need to represent variabil-
ity exp lici tly in t he PSM . The stud y of the desi gn patte rn
approach highlights the importance of the relationship
between design and requirements, specifically nonfunc-
tional requirements, which is proposed to be modeled in
the PIM. Still there is a research gap in these areas on
how to map nonfunctional requirements with design de-
cisions systematically. The problem has been looked at
from one dimensio n, for exa mple SPL has concer ned o nly
with var ia b ili t y wi tho ut co ns i d e ri ng NF R s uc h a s [ 2 ,3,11,
12] while design pattern has recognized the impact of
NFR dimension without variability in an explicit way
[13-15].
However, the benefit here is PSM construction could
be automated effectively because of consideration of de-
sign quality and management of single PSM. Hence, do-
cumenting variability in architecture and modeling non-
functional requirements explicitly will become major ac-
tivities during the development process. This section de-
monstrates key issues arising when we tackle E2EDE.
Further, these issues have been applied to a selected case
study to evaluate the possibility of the proposed enginee-
ring approach.
The ultimate goa l of E2EDE is to p rovide a method o f
generating a solution from one specific source to a spe-
cific target like for example, from object-model to rela-
tional model. The advantages of E2EDE are reflected in
the modeling support for the concepts in the domain and
the ability to do more tha n genera l-purpose languages do,
in addition to r e duction of cost.
4.2. The Steps of E2EDE Process
In this section we will see the main steps of E2EDE. It
will be detailed step by step and finally summarized as
sho wn in Table 1.
4.2.1. Modeling Variation Points in PSM (Task A)
The key concept is to document variability in the PSM,
which can be thought of as an abstract data type similar
to the logical level in database systems. Usually, a solu-
tion is specified firstly at high abstraction level before
rendered into a database technology. Variability in this
PSM exposes different design decisions from the design
space. The design decisions we mean in this context are
architectural elements. Since it is possible to create diffe-
rent implementations from a generic specification, vari-
ability management concepts and techniques from SPL ex-

End to End Development Engineering
200
Table 1. The steps of E2EDE process.
Tasks Technique Specific Solution
A- Modeling Variation Points in PSM variability from SPL Profile For PSM
B- Analyzing Variability and categorized based on
PSM /map ping, and functiona l/non-functional variability concepts + MD A conce p ts + design co ncepts Guidelines and informal steps help categorizing different sorts.
C- Developing Profiles for variability &NFRs UML-based extension mechanisms MOF language
D-Modeling of Non-functional Requirements in PIM
and c lassified in to package/cla ss level nonfunctional require ments c o nc epts Profile for PIM + guid elines for classifying N FRs
E- Developing model-model mapping rules. QVT language QVT rules
F- Packaging mappings variability rules opaque rule QVT meta ru les
G- Implement t he system met amodels UML Package, Profile and relationship
program m etamodel s .
periences are utilized to document design decision vari-
ants explicitly in the architecture. For example we will see
in Section 5 two types of connection: Topic (indirect) and
Queue (direct) for a messaging system. The variability
difference is that in topic multiple subscribers receive a
message while in queue only one subscriber is allowed to
receive. This variability can be modeled as two different
structures at PSM or formally as variants populating the
connectionType variation point.
Since standard UML does not have a variability conce-
pt, modeling vari ability in a PSM we need to use a profile
to allow us to specify the varia bility ontology. A profile is
a special domain language used as an extension mechan-
ism to UML model elements while keeping their syntax
and se mantic intact.Proposed metamodels and profiles in
the literature such as [2,12]can allo w an archite ct to id en-
tify specific variation points, constraints and dependen-
cies that indicate different relationships between varia-
tion point s (VP ) and variants (V), VP and VP, etc.
Because we are using design model (i.e. class diagra m)
the proposed profile here is different from these because
there is no need for dependency and constraints concepts.
They are built-in mechanisms whose semantics is speci-
fied with the mapping process and NFRs. Also, there is
no need for open and closed concepts which gives the
ability to add new variant or variation points because all
are closed in this situation (M DA works above 3 GLs).
Therefore, developing a suitable variability MOF-pro-
file is an essential part for the solution presented by
E2EDE.In fact there are alternative ways to model vari-
ability and nonfunctional requirements concepts using a
profile. The method we have chosen will help produce a
working syste m.
The variability ontology needed includes the concepts
variant indicated by <<V>> stereotype, variation point
indicated by <<VP>>, and an ID tag attribute to identify
each VP.
In Figure 5 the UML metaclass class is extended to
represent variant and variation point. A tagged value ex-
tension mechanism is used to model identifier and type
meta-attributes. Tagged values are additional meta-att-
ributes assigned to a stereotype, specified as name-value
pairs. They have a name and a type and can be used to
attach arbitrary information to model elements.For in-
stance, if we need to model ConnectionType (the two
kinds of connections in messaging system) variation
point we use the stereotype <<VP>> and for its variants
Queue and To pic we use two <<V>> at class level. Then
the tag for ConnectionType will be VPID =1and default
can take the value Direct. The effect tag of va riant sp eci-
fies design decision consequences like resource consump-
tion.
4.2.2. Variability Analysis (Task B)
A taxonomy for variability has emerged from our analy-
sis of variability in software architecture artifacts. They
could be called Nonfunctional variability, Functional
variability and Mapping variability. SPL has been focu-
sed mainly on functional variability. An exte nsive anal y-
sis of this can be found in [16]. Although our proposed
method includes this sort of variability, it highlights the
influence of Nonfunctio nal variability in the de sign. Most
of the issues discussed in Section 6.3 are of this kind.
Mapping variability can be seen in the problem of map-
ping superclass/subclass structures from object model in-
to relational model. It is not like the others because the
variation point s are in the tran sformation, not i n the PSM
(i.e. the mappings are parameterized). In this case the
mapping is from an object model as a source to the rela-
tional model as the target. The former specifies objects
and relationships between them which may includes su-
perclass-subclass relationship in a class diagram, while
the latter spe c ifies relations a nd their structure. The meta-
models and mapping using QVT of these are well descri-
bed in [8].The target does not include a structure corre-
sponding to superclass-subclass in the source. To solve

End to End Development Engineering
201
Figure 5 . Variability MOF-profiles.
this deficiency four options are suggested for this map-
ping in the standard database literature [17].
Generally these options can be classified into single-
relation and multiple-relation approaches named SR and
MR respectively. In the SR approach a table for super-
class attributes will be created with subclass attributes
included as optional while in MR approach table for each
subclass wil l be created. Two implementa tion techniques
are available for both. SR can be implemented by intro-
ducing one type at trib ute ind icating the subclass to which
each tuple belongs (null values will i ntroduced), or multi-
ple boolean type attributes can be used (allowing over-
lapping subclasses). MR has as one option with super
class attributes duplicated in each subclass table and ano-
ther o ptio n to sha re a ke y am ong sup ercla ss and subclass
tables.
For example, the option of one table for the superclass
with subclass attribu tes inc lud ed as optio nal is a good d e-
sign in terms of performance for SQL navigation, at a cost
of increased table space and increased integrity checking.
4.2.3. Modeling of Non-Functional Requirements
(Task D)
The E2EDE methodology considers NFRs as first class
objects which allow a PIM metamodel to be more infor-
mative. The separation of concerns (i.e. PIM-PSM) of
MDA effectively supports their representation.
Functional requirements are functions that the devel-
oped software must be capable of performing, while non-
functional requirements (NFRs) inform the design choi-
ces as to how functional requirements are going to be
realized in software products [16]. T here is no one agreed
defini tion because of the extr emel y d i ve r se nat ur e of N F R.
In fact, practices like in design pattern shows a single
NFR can have different semantic interpretations (impact
on implementation) within the same application. These
can be called impact factors. For example in our case stu-
dy, connection types, session types, and message types are
impact factors affecting performance positively or nega-
tively. There is confusion in term usage where a term so-
metimes refers to the nature of the requirement and so-
metimes refers to the design decisions. We will be using
the term NFR to denote the nature of the require ment so
a PIM metamodel is the place where we can define spe-
cific NFR types.
The difficulty of modeling and integrating explicitly
NFRs (addit ional co nstraint s) withi n the cont ext o f func-
tional requirements is the fact that NFR affects the system
as whole [18]. Non-functional requirements especially
related to architecture are called quality attributes [4].
They affect design decisions where different quality of
products can be distinguished. These are the decisions
that drive the system architecture. The representation and
categorization of non-functional requirements are still
under research. More than one piece of information con-

End to End Development Engineering
202
tributes negat ively or positive ly to one NFR. Pre liminary
resul ts sho w dive rsit y in ter minol ogy and orie ntation [4].
In addition, there are dependency relationship among
non-functional require ments. Fo r example, in some cases
maintainability requires portability. More importantly
conflicts are fo und such as be tween performance a nd re-
liability as shown in our case s tudy below.
The field of nonfunctional requirements as a compo-
nent in requirements engineering is less developed than
functional requirements[19], so there are only a few con-
tributions such as [14,20,21].We are going to follow a
simple approach that would be compatible with E2EDE.
For example, Zuh and Ian [22] proposed a generic UML
NFR Profile, but it is not suitable to work under MDA
because the assumption was to treat NFR and design de-
cision in one place. These are different (separate abstract-
tion levels) according to E2EDE’s principles. The 6-ele-
ments framework from SEI [21] follows a scenario-based
approach that presents a good way to resolve the over-
lapping problem between NFRs. Our approach simply
prioritizes NFRs to judge on design decisions, promoting
automation.
Since the types of NFRs differ greatly among classes
of application, a NFR Profile is needed as a domain spe-
cific language to allow system architecture to specify
NFRs easily in a PIM metamodel. According to investi-
gation in this track we have seen there is a need to priori-
tize NFRs so the toolset can tradeoff between NFRs or
resolve conflicts. Most of the current contribution to NFR
considers the human factor and does not take account of
tool support. For example Zhu and Ian [22] proposed for
the relationship between design decision and NFR: sup-
port, break, he lp a nd hurt. Daniel and Eric [14] follow the
same trend. In order to reach our goal we need to identity
NFRs so the identifier concept is used to discriminate
NFR instances. The 6-elements framework suggested by
[21] could be a useful tool for Non-functional analysis at
earlier development phases.
Fi g u re 6 shows the e lement s of the NFR pr ofile (Task
C) used by an architect to specify NFRs which is spe-
cializing a metaclass class with two tag attributes. Below
in the anchor is an example of an instance model. It also
shows NFRs can be at Package level, which represents
global NFRs such as Application Type, while delivery
mode is at class level. It also shows that NFRs can act as
Packagelevel, which r epre sents gl obal N FRs such a s Ap-
plication T ype, while deli very mode is at class level.
4.2.4. Transformation of informative PIM to PSM
(Task E)
The notion of transformation is hardly a new concept in
software engineering. Traditionally, most software engi-
neering work is conceived of as mapping, like the trans-
formation from software specification to software design.
Figure 6 . NFR UML profile.

End to End Development Engineering
203
But what makes MDA different is considering mappings
as first class objects in the effort to formalize this process
by using standard la nguages such as QVT where mapping
is from one metamodel to another metamodel. This appr-
oach is a prerequisite for the automation that MDA is
seeking to achieve.
The key concept of MDA mapping is to resolve a stru-
cture pattern instance from PIM into a PSM correspond-
ing structure pattern(s) instance. For example, in case of
mapping fro m object model (P IM) to the relational mod-
el (PSM), a cla ss instance will map to a table instance.
Our work proposes NFRs as major design drivers fee-
ding the mapping process. This feature facilitates the ma-
pping task where it becomes easier to select the corre-
sponding PSM structure. NFRs make the difference be-
tween two PSM configurations. For instance, as we will
see later there are two types of messages, persistent and
nonpersistent, in the messaging system. If performance
impact factor(s) are most important, the nonpersistent
variant is suitable while i f reli ab ilit y is a design issue, t he
persistent varia nt i s the b est o p tion. T he for mer architect-
ture will expose performance quality while the latter will
expose rel iability based on the additio nal computation the
application needs to maintain the message storing process.
4.2.5. Mappings of Class Operations
The c lass str ucture in UML includes methods or behavior.
Because maintaining different views in one model is
com-plex, UML supports capturing dynamic behavior of
the system separately by a set of behavioral diagrams
such as the activity diagram. This subsection is about
highli ght ing mapp ing p ro ble m fro m PI M ins tanc es o f the
process model to PSM instances of its process model. In
this case a metamodel does not have user-defined opera-
tions, the MOF specification has defined default methods:
create object, destroy object, and create link in each MOF
metaclass [7] . Firstl y, these method s are abstract methods.
Secondly, mappings of structural patterns are somehow
straightforward but the relationship between PIM be-
have- ioral model and PSM behavior is nonlinear. So
when mappings for example occurred for attributes
which are going to be columns in the relational model,
there might be a set of corresponding operations (1 to M
relationship) in the PSM behavioral metamodel for a
corresponding class’ methods in PIM behavioral model.
However, there is no uniquely determined method to do
that. Recent attempt for example in this case was sug-
gested by [6], one possible MDA program written for
medium-sized problem involving organizing a swimming
meet according to FINA rules (insert and update native
call) utilizin g OCL capability to construct SQL PSM.
However, we can use the hierarchy structure of UML
activity diagra m to show the implementat ion of PIM me-
thod s in P SM as work flo w as in our case stud y in F igure
7: Sendcase mapped to SendingProcess where it is ex-
tended into five operations as described in 5.3.
We notice here future work is needed to find a method
that realizes the operations mapping so we can see how
to incorporate variability and N FR concepts.
Generally the tasks co mprise E 2EDE pr ocess are sho wn
in Table 1.
5. Case Study
A set of applications has been analyzed to produce the
PSM architecture used by this case study as an imple-
mentation end. This family of products which are men-
tioned in Table 2 has exposed commonality in most as-
pec ts unde r me ssa ging s yste m d omai n. T his ana lysis ste p
is in line with the principle o f domain engine erin g where
at least three products should expose commonalities to
justify the investment in core asset architecture [23]. A
Help desk system is one example from this set of produ-
cts which is a major component in most c urrent b usiness
web-based systems. The idea is to allow a user to raise a
case for some aspect which needs a reply from some or-
ganization web site party. An employee should consult
thro ugh the same web site a list of cases or a specific case
that has been presented as a request in order to update it.
Then the update is sent back to user, who may be offline,
as response. A broker is an intermediate module used to
exchange messages between the system and users. Users
contacting the system are durable customers. The non-
functional requirement for system performance is higher
than reliability.
5.1. The Proble m Specificati on
The helpdesk software system is needed to service cus-
tomer(s) and employee(s) at the same time. A customer
will be required to insert identification information such
as user name and password after registration—both of
which will be sent for validation to the web site system
which is located remotely somewhere on the internet. The
customer as well as the employee will then be able to
perform one or more operations.
The helpdesk must be able to provide the following
services to the customer:
1) A customer must be able to login using his account
information.
2) A customer must be able to submit a case to any
employee l i nked to o rgani zati on, b y writing a text messa-
ge and submitting it to a broker.
3) A customer must be able to view their case history
(feedback), status, and details.
4) A broker needs to maintain a queue in order to sche-
dule cases and differentiate between different u s ers’ cases.
They also must be able to create a message.

End to End Development Engineering
204
Figure 7. Behavioral mappings activity f or helpde sk PIM to messaging system PSM.
Table 2. Configuratio n for a set of product s from PSM metamodel with pr o file.
Appliction domains NFR Profile Prio rity Variation point(Design Decisions)
<Message,connection,session,Ack>
1-Email Sys tem App-size = normal Iscritical = yes
Delivery = notUrgent
P1
P2 +P3 > P1
P3 <per sist en ce,queue,transacted, AutoAck>
2-Chat App -s ize = normal Iscritical = no
Delivery = medium
P1 >P2 + P3
P2
P3
<NonPersist ence,
Topic,nontransacted, DupAck>
3-Forum App -s ize = normal Iscritical = no
Delivery = medium
P1 >P2 + P3
P2
P3
<NonPersistence,Topic,nontransacted,
AutoAck, >
4-Mobile application R el iability = high Iscritical = yes
Delivery = high
P1=
P2=
P3=
<p er s istence,queue,
transacted,
FastAck>
5) An employee should be able view cases by individ-
ual case or list of cases and look for details.
6) An employee should be able to update a case.
This is the functio nality needed to d evelop an applica-
tion conceptual model (PIM) as we will see in Figure 8.
Figure 8 shows a class diagram for the helpdesk sys-
tem. The basic structure of the class diagram includes six
major classes: customer, login, broker, case, manager, and
Que ue with t he ir r esp onsibiliti es and r elationship s a mong
them. I n the ca se o f the ma nager, one o f the re spons ibili-
ties is to provide access to a case in the response queue
that has received a message from a broker and send the
updated version back to broker; thus, Case, Queue, and
broker have associations to manager. Case has associa-
tion t o t he que ue c la ss. Cas e wil l b e give n uniq ue ID and
created so each case will represent uniquely an individual
customer case which is stored in a queue either as a re-
quest if it ca me from the customer or response if it came
from the sys tem. The UI is specified in this PIM but we
are not considering this part. It could be possible to cap-
ture an entire UI specification from this PIM that could
be rendered by an outsourced third-party platform such
as a browser.
We are using <<NFR>> stereotype to indicate non-

End to End Development Engineering
205
Cas eKind
< <enum >>
StatKind
< <enum >>
Reques ts
A ddRespons e( )
Res ponses
A ddReques t()
DeptKind
A dm in UsrName : s tr
A dmi n Pass word : s t r
Dept : Cas eK ind
Login
Us rName : String
LogID : in t
P assword
submi t()
Cus tomer
Us rName : String
A ddres s : s t ri ng
Em ail : St ring
< < NFR> > Cus t omerType : int = {NFRId= 1, P=medui m}11. .*
1+ Loged
1. .*
Manager
Claasific ation : CaseKind
Cas Det ail s : string
< < NFR> > A ppType : st ri ng {NFRId = 2, P = l ow}
< < NFR> > S ens i t i vi t y : str ing {NFRId = 3, P = m edium }
send()
rec eive ()
updat e()
+ Connected
B roker
P rocessID : i nt
Cas es t ate : S t at K ind
P roCont ent : s t ri ng
rec ieve ()
send()
1. .*1. .*
Cas e Msg
1+ rec i ver
+ sender
1
Queue
ContentID
c ont ent : s t ri ng
length : int
listCases()
1. .*
1
+case
1. .*
1
1. .*
+ archive
Case
ID : Int eger
c ont ent : S t ring
Dat e : dat e
< < NFR> > Deli very M ode : S tr ing {Id = 4, P=normal}
< < NFR> > A ppk i nd = {NFRId=5, P = hi gh}
create case()
createID()
S et Status()
1. .*
1
+ theCas e
1. .*
1
1. .*
1
+ pool
1. .*
1
+ owned
1. .*
Figure 8. PIM: Helpde sk sys tem wit h NFR documented.
functional requirements according to the NFR profile.
Tag values are used to denote two pieces of information:
ID to identify a NFR and priority (P) which assigns an
integer number to indicate a prio rity level of NFR. T hese
are the elements of the NFR specific-language used to
model NFRs as described in 4.2.3 (Task D).
In the PIM shown in Figure 8 there are the following
NFRs: Applic ation sens itivity {Hi gh, low, medium}, App-
Kind{transactional,nontransactional}, CustomerType {nor-
mal, durable}, AppType {normal, critical}, and delivery
Mode{normal,guaranteed}. (Task D). The interpretation
of these NFRs will make sense when we link to design
decisions as we will see later.
We now have a helpdesk system conceptual model de-
scribing functionality as well as nonfunctional require-
ment s .
The PSM in Figure 9 s hows a messa ging s yste m which
can be a realization of a PIM such as in Figure 8. It de-
scribes how data can communicate between two software
entities: Producer instance and Consumer instance. A
Session instance must be created between the two ends
but to do that a Connection instance must be created first
with suitable parameters. Session has two types as does
Connection, while Transact means the under lying s ystem
should treat the data send as a transaction in database so
the system should guarantee correct update, consistency,
and can rollback a NonTransactional is to treat data not
as a transaction. Consumer and data instances can be
synchronous (Synch) or Asynchronous (Asynch) which
refers to whether it is necessary or not for the consume r

End to End Development Engineering
206
Figure 9. PSM of messaging system with variability in design decision.
to attend at the time of connection. Connection is Direct
type or Indirect type transaction in ca se of failure.
We can call Queue for the former which allows one
recei ver per se nd action and Topic for the later that allo ws
multiple receivers per send. Data can be Persistence type
which means using backing store, preserving it in the
case of any failure, or it can be NonPersistence. (Task B)
We notice this abstraction deals with concepts that are
from implementation space not like the PIM concepts that
are from an application domain.
Figure 9 shows the capability to deal with different
design decisions configuration that are represented by va-
riabilit y (Task A, C). For example Connection is denoted
by <<VP>> stereotype which can take Direct or Indirect
variants. Likewise session denoted by <<VP>> with its
two different variant kinds. The focus on the discussion
will be onl y on varia bilit y that is no n-functional wi th re s-
pect to the PIM.
5.2. Mappings (Task E)
In order to explain how to apply this principle we will
describe mappings of this case manually, while it should
be automated. The NFR in the PIM of Figure 8 will guide
the mapping process to configure a suitable PSM from
Figure 9 automatically. For instance, the two data vari-
ants: persistence or NonPersistence is selected according
to the application need for reliability or performance so
delivery mod e will deter mine that. The current case study
says Application Sensitivity is not high and a delivery
mode is normal hence these two NFRs are not reliability
factors which require maximizing performance. The de-
livery would use NonPersistence option which does not
necessarily insure message delivery by for example stor-
ing message until a receiver becomes available.
Similarly, the Session variatio n point has t wo var iants:
Transacted and Nontransacted. Because the AppType (i.e.
size) NFR is normal application in the help desk PIM
Nontransacted variant is the most suitable.
This factor affects performance directly for example
when transacted variant is used performance is impacted
negatively compared with the Nontransacted mode. This
is because there is additional overhead for resource ma-
nipulation needed in the system for transaction mode.
Connection variation point has two connection varian-
ts: Direct and Indirect which means s ingle r eceiver versus
multiple receivers per message. They are selected based
on AppKind and CustomerType Non-functional require-
ments. A Transactional application, for example banking
transactions, requires usually direct connection such as
for doing funds transfer. The same is true in our case
study where direct connection is selected for request and
response messa ges because CustomerType is single user.
In contrast, mobile applications such as advertisements
prefer broadcasting a message to group of receivers so
indirect connection is the most suitable variant. In that
case customer Type can be multiple users.

End to End Development Engineering
207
Generally in terms of performance indirect connection
is contributing positively while direct connection is con-
tributing negatively. The same message is forwarded to
different subscribers which mean lower resource con-
sumption.
Note that we need one of the variants to be set as de-
fault because the PIM and PSM are independent so that
the default will be selected in case there is no correspon-
ding NFR(s). For instance Figure 10 shows that the de-
fault variant is se lected ([2 ]) fo r Conne ctio nV P if there i s
no corresponding NFR addressed. We notice also two or
more design decisions d ete rmi ned b y singl e NF R suc h as
Appkind can be used to decide both connection and ses-
sion va riants.
Table 2 shows informally part of mappings from Help-
desk system PIM to messaging system PSM with NFRs
guidance. I t also sho ws how a pplicatio n concepts turn in-
to design concepts. For instance the Case from PIM me ta -
model which is a unit of work between customers and
company holding the necessary infor mation will be map-
ped into three objects: Message, Connection and Session.
Because we have two kinds of messages and so two
different bodies of computations, we need to judge on
suitable design by looking into NFRs presented in the
PIM according to for example performance or reliability.
NFRs can be extracted from system specification by
different formats and meaning. For simplicity Iscritical
(such as OCL style) is used instead of AppType. The
mapping rules that can be used to implement the map-
pings specified in Table 1 are shown below.
PSMR= PSM repository holding instances
Pi=Priority
[1] CaseToData
IF (Iscritical=Yes) and (delivery=guaranteed)
th en
If (P1[Is criti cal]>P2[delivery])
Then store in PSMR ([Data,type=Persistence)])
IF (Iscritical = N O ) and (delivery=guran teed)
Then store in PSMR ([Data,t yp e=Non Persistence)])
IF (Iscritical = No) and (delivery=normal)
Then st o r e in P SMR ([D ata,type=Persis tence])
[2] CaseToConnection
Select connection.default-V [Queue in this case]
Store in PSMR ([Connecti o n.type=connection. defau lt-V])
[3] CaseToSession
IF (AppKin d.value=transactional)
Then store in PSMR ([session,type=transacted])
Figure 10. Part of informal mappings rules from helpdesk
PIM to messaging system PSM.
Figure 10 like pseudo-code shows a sample of map-
pings rules to transform PIM instances with existence of
priority consideration into PSM instances. For example,
[1] describes a conflict situation where if the application
Iscritical and at the same time the delivery is guaranteed,
the selection of design decision will depends on the hi-
ghest priority. In this case persistence (factor of reliabil-
ity) is chosen because P1 is greater than P2. Note here
pri ority is use d only in t he cas e of NFR va lues cau sing a
conflict.
We notice by this way an application could be config-
ured at the two extremes: reliability and performance
using suitable design decisions represented in the design
artifact with NFRs guidance. It is also possible to con-
figure an application in between these two extremes.
Thus our method affords different products with archi-
tecture designs at different levels of quality-attributes.
Inputs for mappings will be PIM metamodel (holds appli-
cation instance s), NFRsrepository (NFR in stances), PSM
metamodel, and Variability (d e sig n d e c isio n instances).
5.3. Class Methods Mapping
This activity is intend ed to realize the abstrac t operations
expressed by one kind of behavior diagram for the help-
desk PIM metamodel. We can use an activity diagram to
show the control flow and instances creation during the
execution of the mappings fro m PIM to P SM a t this stage.
For example in the behavior i ns t ances mo del of Figure 8,
the sendcase method in broker needs to map into the fol-
lowing sequence: createObject (connection), createOb-
ject (session), createObject (producer) as in the behavior
instances model shown in Figure 7. It sho ws the control
flow of mapping activity and relationship occurrences
between source (helpdesk behavior model) and target
(messaging system model). For example, raise case will
be mapped to initialize Connection and sendcase will be
mapped to sending process. We can determine PIM
(source) and PSM (target) actions from this activity dia-
gram. For example PSM activity are, initalizeConnetion,
SendingProcess, ReceivingProcess, CreateUniqueRecord,
lookupcase, UpdateRecord and createResponse (from 1.1
to 1.7) . But still as we mentioned previously more inves-
tigation is needed in this place to map a PIM process
model to PSM process model and understand this map-
ping completely.
6. MDA in the Context of Design Pattern
and SPL
It is a claim in this paper that MDA i s a re-use approach.
In this section we see how MDA can fit in with other
common re-use approaches such as design pattern and
software product line (SPL).The investigation of this
relationship is the reason behind approaching E2 EDE.

End to End Development Engineering
208
Varibility and Nonfunctional requirement concepts are
borrowed as we have seen in section. MDA is a special
case of design pattern techniques as we will argue in Se-
ction 6.1, while MDA and SPL have a synergistic rela-
tionship according to observations described in Section
6.2.
6.1. MDA and Design Pattern
The design pattern concept goes back to Christopher Al-
exander [24]. His definition identified a relationship be-
tween three parts constituting a pattern: problem, solu-
tion and context. In software engineering, a design pat-
tern is a general reusable solution to a commonly occur-
ring problem in software design [25].
6.1.1. Limited to Domains with a Well-Established
Code Base
The nature of solution provided by MDA is more specific
to the problem domain than the design pattern which is
more general because there are many kinds of design pat-
terns [26]. A general purpose pattern perspective in solv-
ing problems is more expensive in terms of the estab-
lishment of working environment than in MDA, which is
characterized by its well-established specific backend.
Typically, MD A is used to target platform(s) that have al-
ready been crafted. For instance, large scale software
RDBMS (a complex proven solution) can be utilized
automatically by tools which transform PSM relational
model after mappi ng to the SQL language. In contrast, for
a pattern to be executed generally involves establishing
new tools. For instance, Yacoub, Xue and Ammar [27]
proposed their own visual systematic tool.
6.1.2. Separating Concerns Allows Application Logic
and Platform to be Variable and Encourages
Re-Use
It is observed that design pattern tends to integrate the
behavior aspects with implementation aspects which re-
sult in risks of platform changing or volatility. Further,
some implementation details become suppressed as con-
sequence of behavioral variation as in the publish-sub-
scribe pattern which does not say anything about remote
objects design [15]. If this pattern is used in a d istributed
environment it becomes necessary to distinguish local
from remote objects which is not available as a design
decision at de sig n time.
6.1.3. End of Pattern Life Cycle
Design Pattern follows a life-cycle as patterns become
more mature and quality increases [28]. MDA produces
high quality patterns because PSMs are end of the pattern
life cycle. Altho ugh the nonfunctio nal requirement e mer-
ged first in the design pattern approach, MDA gives a
wide opportunity to represent NFR explicitly. It is the
critical requirement that discriminates between pattern
architecture designs. In fact, it is still a research question
how to graft design pattern with recognit ion of NFRs. In
Buschmann [15] we can observe the role of NFRs in ba-
lancing design forces.
6.2. MDA and Software Product Line (SPL)
Software product line engineering is a paradigm to deve-
lop software applications (software-intensive systems and
software products) using common platforms and mass
customizatio n [2]. The intended goal is to avoid re inven-
ting the same solution for different applications in order
to achieve shorter development time and high quality
products (i.e. Nokia mobile applications). There are two
distinct development processes adopted by SPL: domain
engineering and application engineering. The former is
concerned with design for reuse by seeking c ommu nal -
ties and variability in the software product line. As a re-
sult a reference architecture called product line architect-
ture (PLA) is established . The aim of the latter is to drive
applications by exploiting the variability of the software
prod uct line.
6.2.1. Defining Variation Points and Variants
The central concept in SPL is the explicit representation
of variability. Variability is a variable item of the real
world or a variable property of such an item [16].A vari-
ant identifies a single option of a variation point and can
be associated with other artifacts corresponding to a par-
ticular option (dependency relationship). For example,
payment method as a variation point can be realized by
variants: payment by credit card or payment by cash, etc.
It is necessary in SPL to identify variability by defining
variation points and var ia nts, which is used by a selectio n
process to produce different products.
There are two types of variability: Variability in time,
which is different versions of the artifact at different
ti mes (i.e. performance), while variability in space refers
to an artifact in different shapes at same time. For exam-
ple “syste m access b y” var iation p oint in a home sec urit y
system can have two variants: web browser and mobile
phone. Variability in space is the central challenge faced
by SPL, so management of variabilit y is the main issue in
this engineering approach [16].
A set of closely related objects, packaged together with
a set of defined interfaces, forms a component [28]. Usu-
ally a component-based approach is used to realize SPL
concepts.
SPL tightly couples application and implementation
mod els together.MD A a s an approach reduces the SPL to
abstract computational processes. It separates the appli-
cation from implementation by creating PIM and PSM
abstractio n levels.

End to End Development Engineering
209
6.3. MDA in the Context o f the Software Product
Line
Both software product line e ngineeri ng (SP L) and model
driven architecture (MDA) are emerging as effective
paradigms for developing a family of applications in a
cost effective way [3]. SPL through its feature-based mo-
dels provides a capability to capture variability in inten-
sive systems, while the effectiveness of MDA is primar-
ily due to p otential for a uto mation it offers for variability
in technology. Generally MDA can fit into SPL as an ef-
fective software development method. For instance MDA
can tackle implementation variability within a specific
plat form. So the synergistic re lationship be tween the two
approaches has been studied recently [4,20,29]. The basic
differences between the two approaches are as follows:
6.3.1. MDA Decouples Implementation Model from
Application Model
The PSM is constructed as an API to specify the imple-
mentation aspects for an intended target such as rela-
tional database model. Similarly a PIM model is built
whic h sp ec if ie s t he bus i nes s logi c. T hi s will a d d va lue b y
enabling MDA to tackle technology variability which
allows the same PIM to be rendered into different plat-
for ms or PSMs.
Although components raise the reuse level a little bit,
they still su ffer from the software e volution pr oblem. For
example, any small interface changes will entail finding
ever ywhere the interfac e is used, changing it to reflect the
new interface, testing new code, reintegrating and retest-
ing the s yste m as who le . Ther e for e, a s mall c ha nge i n t he
interface can cause enormous changes by following each
code part that refers to this component interface. In con-
trast, the PSM, an intermediate subsystem, abstracts this
tedious task by concentrating the changes in one place.
Also, MDA a voids the problem of features explosion that
tends to complicate maintenance [9]. In addition, keeping
a mapp ing functio n separate avoids swamping the source
model (application) with implementation details and re-
duces the problem of model divergence because the tar-
get (implement ation) is generated [2 9].
Furthermore, MDA increases architecture longevity
(ageing) compared to the fact that sometimes PLE suffers
from architecture lifespan which may reach end of life
[22]. In this case evolving architecture will be expensive
or risky. MDA’s potentiality comes where evolving the
architecture becomes much cheaper because each of
PSMs and PIMs are adapted separately and they do not
carry any volatility risks (technology variability).
6.3.2. MDA is Intended to Automate the Craft of
Code
The po tential of MDA is due to the cap abilit y of automa-
tion it offers. It is recognized that if we will be able to
forma li ze the mo d el to t he e x t ent t hat it has no a mb i gui t y
and the model is machine readable (executable) then the
code in principle can be mechanically generated. MOF is
a powerful metamodeling language that realizes this trend
by allowing tools to interoperate and accurately modeling
the conceptual model of a design language such as UML.
Crafting code becomes a model driven process wherein a
transformation from source model (PIM) to a target mo-
del (PSM) can be automated by for example QVT tools.
Eventually the PSM can automatically mapped into text
(code). MDA works best if the scale of PSM objects is
the same as that of PIM. The mapping function is kept
separate so that it can generalize some concepts and it can
be repeated many times (repeated design decisions) sho-
wing a big picture of reuse. The mapping fu nctio n ca n be
automated at the instance level because it is an algo-
rithmic pro cess in which generic tra nsformation rules are
established at the type level. The general feature of auto-
mation is the synchronization between the two e nds.
6.3.3. Higher Abstracti on and Systematic
Development Methodology
The main goal of MDA is to raise the abstraction level
higher than traditional middleware and 3 GL/4 GLs pro-
gramming languages. This means taking advantage of
sof tware-platform independence that enables a specifica-
tion to execute on a variety of software platform with a
stable software architecture design. The granularity of
code re-use will increase to the level of a PSM (ADT) in-
stead of compo nent s as in SPL. The PSM is scoped to this
level of code reuse. For example relational database PSM
is an abstraction for the family of relational databases
above any specific technolo gy. Also, there is a difference
between MDA and SPL in defining interfaces to compo-
nents and fr ame works vi a an API. I n MDA, t he int erfa ce
is not concre te but it is meta -interface exported by mark-
ing mod els [ 29]. The mappings are externalized and gen-
eralized, which ca n be reused in simil ar problems.
MDA is standards-based development method which
is specified entirely by a nonprofit organization, OMG,
since 2001 [1] . It invol ves algorithmic mapping proc esses
from model to model (PIM-PSM) and from model to text
(PSM-code). The mapping process is rule-driven i n which
transformation rules are expressed by a standard language
(e.g. QVT). However, different viewpoints could be con-
structed for different abstraction levels. Formal mapping
functions will often fill the gap between any two differ-
ent abstraction levels (consider compilers). Further, hav-
ing MOF as metalanguage and other well-established
OMG standards (i.e. XMI), it promises industrial-scale
systematic re-use and integrat ion capability.

End to End Development Engineering
210
7. How Design Pattern and SPL Contribute
to E2E2D Engineering
The survey of the relationship among MDA, SPL, and
Design Patterns has shown a synergistic relationship.
MDA improves each approach by supporting these quail-
ties: automation, proper management of technology
changes or volatility, high granularity of reuse and more
important a cap a bility of integration.
Design Pattern is not an end to end concept because it
is an abstraction for software implementation.
Design pattern could be used to construct the architect-
ture in E2EDE. It adds value by acting as a proven solu-
tion and a documented experience.
SPL is an end to end concept but in addition to the pro-
blem of coupling application and implementation toge-
ther, it does not tackle the variability in the implement a-
tion part. In contrast, E2EDE is mainly addressing this cha -
llenge. In addition, there is no concrete link as in E2EDE
between higher level models and lower detailed models.
SPL engineering gives anothe r insight for E2EDE: the
concept of explicit variability representation and mana-
gement. Introducing variability explicitly in the PSM
helps mainly in its construction. This means a PIM can
become informed about variation points that are docu-
mented explicitly therefore it becomes possible to auto-
mate the design decision process. A UML profile for spe-
cifying PLA [3] can fill the gap between PSM and the
PLA core assets artifact.
Metamodeling and MDA are an alternative technique
successfully used to organize SPL and feature model
concepts as demonstrated by Muthig and Atkinson [11].
Furthermore, unlike orthogonal models, the variability
model and original model would not be separated, which
increases readability.
8. Strategi c Mess agi n g Syst e m P S M
The philosophy of MDA is to do more investment on me-
tamodels so as to hopefully obtain payoff at production
time by producing larger number of products. It can be
conceived as the same scale as where database systems
an d X 11 [20] are considered viable.
We have looked at PSM in Figure 9 in the previous
section as a spe ci fic imple men tation for helpd esk s yste m.
In fact this PSM was built from a general messaging sys-
tem perspective. The concepts in this PSM form an on-
tology. There are many messaging systems which com-
mit to that ontolo gy.
Examples are: Chat system, Email system, instant me -
ssaging syste m, media str eaming s ystem, mobile app lica-
tions, etc.
As we argued before re-use is a major trend in the soft-
ware development community. Important are not only re-
usable components but also strategic reusable assets like
models and transforms.
Table 2 shows a simple configuration for four prod-
ucts as a picture of the benefits of re-usi ng the me ssa ging
system PSM. Further, it is obvious that the rationale of
this specific architecture design does not exhaust the
E2EDE approach. An architect can reason about different
architecture designs.
In Table 3 we see there are number of NFRs common
to this set of applications, which are re-used to make a
design decisions. The y are App-size (i.e. Application size),
Iscritical and De livery. Both App-size and Iscritical are a
kind of Package level NFRs while Delivery is a class
level NFR because it is about an object class inside the
system. Design decisions are: message (data), connection
and session, and Acknowledgement mechanisms. In the
example of email system two reliability factors are high-
er than the other; App-size has lower value than for de-
livery and apply-size, therefore message (data) delivery
is persistence with Queue type connection and transacted
sessio n. T he Ack nowledge ment will be given nor mal va-
lue which is AutoAck. All these values makes reliability
higher than performance because of the overhead proce-
ssing (i.e. store ) which what is said by NFRs. The inverse
Table 3. Part of map pings from helpdesk system to messaging system.
PIM Relevant NFR PSM Variation Points
1- Case Data needed between producer and consumer and let the system works so it is functional. But there is a quality on its processing based on
prior ity and type.
1.1 Message
1.2 connection
1.1 Data [messa g e] Apptype{normal,critical}or sensitivity {low, high} and
delivery mo de 1.1.1 persist ence or 1.1.2 nonpersistence
1.2 connectio n customerType and AppKind{transactional, nontrnsact} 1.2.1 queue or
1.2.2 topic
1.2.x.1 session A p pKind an d de liv e ry mo de 1.2.3 transact ed
1.2.4 Nontransa cted
1.3 br oker User or customerType 1.3.1 Consumer::Asynch Or
1.3 .2 c ons u mer : : Synch

End to End Development Engineering
211
of this situation typically is in Chat and Forum applica-
tion where P 1 of app lication size put into highest priorit y
than data delivery and Iscritical so the configuretion of
parameters is set to increase performance. The mobile
application comes in the middle between performance
and reliability more oriented to reliability. Note that this
is an arbitrary configuration but any other scenarios are
possible. The point is by that we can see an example of
NFRs and variability reusing among products in mes-
sagi ng syst ems.
9. How MDA Works
MDA is new trend in software develop ment. This section
sketches key po i nts about MDA implementation.
The histor y of software engineering sho ws that a soft-
ware design model is a complex object that needs to be
maintained during a project life cycle and refined over a
long period. CASE tool (computer-aided software engi-
neering) is used to allow easy model creation, editing,
rendering etc. In this case, a tool designer utilizes infor-
mation system technology to keep this complex object in
a database called a repository. A repository consists of a
schema which stores model instances [6]. In fact this re-
pository does not need the complete commercial database
machinery. There are recently emerging MOF-standards
like XMI [30] used as a mechanism not only for persis-
tence purpose but also as a mechanism for exchanging
models between tools which it was difficult before in a
classic CASE tool (i. e. magic draw, rational rose). Many
recent MOF-based toolsets support in addition to effi-
cient access methods, both system and user- defined API
serialization mechanis ms in which develo pers can render
a model using an XMI concrete syntax for different pur-
poses. There are many tools with different features and
capabilities working in this context, extensively studied
in [31]. EMF [32] an open platform adopting MDA prin-
ciples provides a Java code-generation facility to ac hieve
interoperability between applications based on a MOF
meta-modeling framework.
10. E2EDE Implementation
The implementation of E2EDE need to be considered as
there is some limitation in current MDA tools. Our ap-
proach in this space is to separate working on the model
view from the implementation view the same way UML
gives a different views for different purposes such class
diagram and activity dia gram.
The proposed profiles are useful in terms of readability
and explicit showing of the NFRs and VPs but for im-
plementation it needs suitable representation to fit the
MD A computatio n environment.
There are three reasons underlying the solution sug-
gested in this section: source, target and mapping meta-
models. Firstly, current tools have a limitation of recog-
nizing a profile instances in a model annotated by a pro-
file elements such as MediniQVT [33]. (Tag values are
not visible to QVT pattern expressions.) Therefore we
suggest a representation for profiles to resolve this i ssue.
Secondly, if we look practically to the mapping the me-
talevels concept breaks down when we compare two sys-
tems. For instances, if we used UML as PIM metamodel
and MOF as PSM metamodel, the mapping is from in-
stances of M0 objects to instances of M1 objects. The
same is true more generally when we use Profile instan -
ces that a re at le ve l hi g her t han i nsta nc e s l evel o f t he me-
tamodel. In our specific case, pro file instances are at M1
level while the metamodel instances needed by QVT en-
gine are at M0 level. However, OWL-Full [34] can be
suggested as an alternative technology to UML which
could resolve this solution. OW L has an OW L metaclass
class which is itself a class, so we can build a profile
mechanism by declaring subclasses of OWL class.
Finally there is a need for linking a single VP with a
set of NFRs and mapping variability should be conside-
red. (Task G)
Figure 11 describes the relationship between VP, NFR
and a Design Decision. A design decision is one of two
kinds: selection which denote s the normal variabilit y exi-
sts on P SM, and co mpiled which represents the mapping
variability highlighted in the previous sections. This sort
of design decision groups related rules that have some
common property which is modeled by the attribute rank.
An instance of compiled design decision is associated
with an instance of NFR because NFR(s) is the reason
behind this grouping.
For example, consider how the mapping variability
discussed in Section 4.2.2 could be represented. Also,
more information details about design decisions can be
added, for instance to compiled subclasses, like the ef-
fects and cost of effect etc. Ho wever, an instance of a de-
sign decision is an opaque rule specifying the creation of
valid PSM i nstance s when its precondition is satisfied as
shown in the following. A program manipulating this
metamodel should differentiate between three modes: de-
fault, application of a rule, and conflict resolution. A
conflict mode needs to refer to NFR’s priority. Seduo-
code based in QVT relati on lang uage is s hown in F igure
12 .This part sho wing application of Task F.
Figure 12 demonstrates statements describe two dis-
joint types of connection that will only be created as
PSM instances when certain Preconditions are satisfied.
The funct i on of the Guard Predicate class is to collect VP
related NFRs which has multiplicity one to many. This
means a pattern structure in PIM will be linked with one
variant through one or more NFRs. For instance, in the
two examples we have two sets of NFR related to Direc t

End to End Development Engineering
212
Figure 11. PIM to PSM mapping metamodel.
Figure 12. Opaque rules for mapping variabilit y rules.
and Indirect variants respectively: {importa nt, transactio-
nal}, {normal, Nontransactional}. Note that variants in
PSM are disjoint and covering because they are alterna-
tive design elements. NFR and VP are imported from
correspond i ng packages.
The metamodel in Figure 13 is a lightweight UML2. 0
metamodel used as an example by the QVT specification.
We use this as a base for presentation purposes (Profile).
The full wo rk makes u se of UML.
The extension or ad aptation to this existing metamodel
was special NFR ( SNFR) metaclass, general NFR (GNFR)
metaclass and NFR metaclass. Working with this case
study shows that there are two kinds of NFR: package
level (general) and class level (special).
An extension to the same UML simple metamodel
could be done for variability model using an extension to
the metaclass class to represent variation point, variant
and Q uail it yA t tr ib ute . The s ame extension is found in t he
literature such as [2,3,12] but there are two problems
with this. Firstly, it does not model mapping variability
and for example the conflict cases that arise when we
link NFRs with varia nts. Seco nd ly, it is i mpossib le to u se
the UML toolset to do that modification because it is at
the level of UML metamodel. Here the proposed app-
roach generally involves Profiles, packages and model
manipulation.
The meaning of variability in PSM is somehow diffe-
rent from traditional variability in SPL. In E2EDE, vari-
ants are disjoint and covering which represents only al-
ternative design decisions. These decisions can be over-
lapp e d and no t c ove r ing in S P L. Va ri ant s in E 2E DE e xi st
on a PSM artifact to represent Nonfunctional while SPL
traditionally represents only functional variability. There
is no dependency such as between VP-VP because it is
already inherited from the UML design language.
10.1. Packa ges (Task G)
PSM variability needs to be represented in a way access-
ible and without ambiguity to the relationship programs.

End to End Development Engineering
213
Figure 1 3. Simple UML2.0 metamo d el extention from QVT specification as Profil e implementation.
The relationship program has end to end functionality. It
is intended to link a PSM variant with the relevant
NFR(s). The traditional mechanism in literature used to
model variability is through a subclass structure of the
UML class model like [12]. This is suitable for humans
but if the system is scaled up, it would be difficult for a
human to comprehe nd that system. The second problem is
that some times in these large system names of classes,
properties, and association etc, can be ambiguo us. T her e-
fore we need a representation mechanism that allows the
program to find model elements. MOF and UML support
a Package mechanism which has a capability to make
names of members unique within the package that owns
them. Further it is has a facility to disambiguate names
where necessary by adding the package name as prefix.
So both human and programs could easily access model
elements withou t a mbigui ty. Furt her a pa ckage may need
to import or merge another package.
Therefore, the semantic operations of incorporating a
subclass (variant) in the model will be throu gh le ga l st an-
dard package operations.
In UML2 infrastructure a package [35] is defined to
group elements, and provides a namespace for the grouped
elements. A package merge is used as basic re-use me-
chanism that allows extension by new features. For ins-
tance, UML2.1.2 superstructure builds on the Infrastruc-
ture library by re-use of the kernel package. It is defined
in UML2.1.2 infrastructure as a direct relationship be-
tween two packages that indicates the contents of the two
packages are to be combined. Conceptually this means
there is a resulting element combining the characteristics
of both source and target.
Since we modeled VP and V using the generalization
concept, a subclass is always an extension for superclass
i.e. by adding new structural features. A package merge
has these capabilities. Therefore, a PSM super-subclass
structure will be modeled using packages.
The second value of using a package is that it is a po-
werful mechanism for embedding an entire metamodel
(sub architecture) to represent a variant that could be re-
used in the main model (namespace). It is effective due
to its capability to represent PSM implementation varia-

End to End Development Engineering
214
bility that can scale up as practically used by OMG as a
basic building block to develop and reuse a variety of in-
frastructure and superstructure constructs. Further the
capability of package operations (i.e. import, merge, etc)
allows one to build complex structures by combining
simple constructs using a systematic rule. This feature in
the programming languages concepts is recognized as
orthogonality [36].
So now we have the representation of variability in
PSM using the p ac kage mec ha nism. In ad diti o n, we ha ve
NFRs represented in PIM metamodel which has repre-
sentation in Figure 13. They were two kinds: package
level NFRs and class level NFRs. To this end we need a
relationship program using NFRs to select the suitable
variant(s). This will be modeled using model manipula-
tion tools. But in order for this relationship program to
work we represented elements of the problem in way
easier for the programs to find and manipulate (Package).
11. Lessons & Realistic of E2EDE
The key point from the step toward strategic PSM like
the one presented in section 8 is since there are a group
of different products complaint with a standard interface,
they are sharing an abstract data type (ADT). It becomes
easy for example to replace one by another, for example
Dell laptops standard architecture is the reason behind a
wide set of products. Another example from our commu-
nity is the service-oriented architecture where its stan-
dard interface leads to proliferation of applications and
what is known as Agility. This scenario even could be
applied to situation where there is no standard specifica-
tion. Here we need a reengineering process to fill the gap
but this time with the lowest reengineering cost, with
assumption that the different products have largely simi-
lar functionality. T ypically any drift from common func-
tionality would be resolved as a mapping from the PIM
to the PSM. Any further changes made necessary by use
of a particular platform should be relatively minor.
Typically it is the case of messaging system PSM there
is no standard specification but E2EDE encourage rea-
ching agreements on messaging design vocabulary. Our
investigation shows us there is similarity even if some-
times there are differences in naming.
One could see the advantage of what we are taking
about if we look at Advanced Message Queuing Protocol
(AMQP) [37] practice when it standardized message
format (known as a wire-level protocol) which is pro-
prietary in JMS [38]. Any tool conforming to this data
format can interoperate with any other compliant tool
regardless of implementation language. Both JMS and
Microsoft's MSMQ [39] comprise alternative candidate
platforms for our messaging system PSM. Both have
similar capabilities but have differences in performance
and int egra tion fe atur es pl us othe rs. O ur messa ging P SM
is developed from the standard of JMS which is recog-
nized as the best-known standard in the asynchronous
messaging world [40]. As we mentioned, a complete
ontology of messaging systems needs to be established
by a standards body so one could take the advantage of
replacing one messaging platform by another. This stan-
dard will establish a vendor-neutral protocol by studying
different practices of messaging paradigms such publish/
subscribe, point-to-point, request-response, etc. The stan-
dard would specify message format, Brokers behaveior
scenarios, and others.
12. Conclusions
MDA is about mapping PIM instances to PSM instances
automatically using a standard mapping language such as
QVT as a new trend of developing applications. The
MDA standard specification does not show in details
how to do the mappings from PIM metamodel (applica-
tion-space) to PSM metamodel (implementation-space).
This situation raises a question: how to develop End to
End applic a tions which is the ulti mate goal of MD A.
In the view of that question we have proposed E2EDE,
a novel software development approach which bridges
the mapping gap between PIM (functional specification)
and PSM (implementation specification) using the MD A
method.
E2EDE approach is based on documenting variability
in architecture artifact design on the PSM by utiliz i ng t he
variability notion in the software product line approach.
Our variability analysis has shown taxonomy for vari-
ability including mapping varia bilit y.
NFRs is proposed to be documented in PIM to make
the PIM more informative thereby guiding the mapping
process to select from among design alternatives in order
to automatically produce a suitable implementation or
PSM instance model. In this scenario the mapping pro-
cess is modeled in a configurable way to drive an archi-
tecture that can lead to considerable cos t-saving. We have
shown that this study has contributed to NFRs knowle-
dge b y ident ifyi ng t wo ki nds of NFRs : P acka ge leve l and
class level. The former have more re-use potential.
E2EDE contributes to the MDA domain by finding
concrete mapping methods for generating high quality
applications within specific but big enough domains
through building explicit links between design decisions
and N F Rs.
E2EDE implementation models were developed and it
was discovered that a profile is good at presentation level
but not suitable for implementation level. Generally, we
followed Profiles, Packages, and model manipulation ap-
proach where metamodels were developed for source,
target and relationship program.

End to End Development Engineering
215
We have invest igated the realistic a pplication of E2EDE
and found that there different examples of messaging
syste ms without a standard. For use of E2EDE, having a
standard PSM would be an advantage. It increases the re-
use theme (PIM with NFRs can be like variant feature)
and achieves interoperability. The best situation would
be gained if PSM is built by standards bodies such as
ISO or the OMG.
Finall y, thr o u gho ut t his p ap e r we ha ve seen ho w MDA
can fit in with SPL and Design pattern under the reuse
umbrella which helps explore the research issues that are
arose such as Non-functional requirements when we tac-
kle E2EDE engineering. A case study was presented to
show the possibility of success under this approach. A
strategic PSM for messaging systems is developed as an-
other potentially valuable product. In addition, the les-
sons and the realistic application of the approach are in-
vestigated.
REFERENCES
[1] “MDA Guide Version 1.0.1,” 2001.
http://www.omg.org/cgi-bin/doc?omg/03-06-01.
[2] K. Pohl, G.Böckle and F. J. van der Linden, “Software
Product Line Engineering: Foundations, Principles and
Techniques,” Springer, Berlin, 2005, pp. 53 -72.
[3] H. Min and S. D. Kim, “A Techniqu e to Represent Prod-
uct Line Core Assets in MDA/PIM for Automation,”
Proceedings Rapid Integration of Software Engineering
Techn iques Second International Workshop (RISE 2005),
Minneapolis, V ol. 39 43 , 2006, pp. 66-80.
[4] M. Matinlassi, “Quality-Driven Software Architecture
Model Transformation,” PhD Dissertation, VTT Techni-
cal Resear ch Centr e of Finland, 2006.
www.vtt.fi/inf/pdf/publications/2006/P608.pdf
[5] S. J. Mellor, K. Scott, A. Uhl and D. Weise, “MDA Dis-
tilled: Principles of Model-Driven Archi tectur e,” Addison
Wesley, New York, 2004.
[6] R. M, Colomb “Metamodelling and Model-Driven Ar-
chitect ure,” In Publ is hing.
[7] “MOF 2.0 Core Final Adopted Specification,” 2004.
http://www.omg.org/cgi-bin/doc?ptc/03-10-04.
[8] “OMG MOF QVT Final Adopted Specification,” 2005.
http://www.omg.or g/doc s/ptc /05 -11-01.pdf
[9] S. Jarzabek, “Effecti ve Software Mai ntenance and Evolu-
tion: A Reuse-Based Approach,” Auerbach Publications,
Boca Raton, 2007, p p. 68-106.
doi:10.1201/9781420013115
[10] D. Ramljak, J. Puksec, D. Huljenic, M. Koncar and D.
Simic, “Building Enterprise Information System Using
Model Driven Architecture on J2EE Platform,” Proceed-
ings IEEE the 7th International Cconference on Tele-
communications, Zagreb, June 2003, Vol. 2, pp. 521-526.
[11] D. Muthig and C. Atki nson, “Model -Driven Product Line
Architectures,” Second International Conference on Soft-
ware Product Lines, San Diego, Vol. 2379, August 2002,
pp. 79-90.
[12] B. Korherr, “A UML2 Profile for Variability Models and
Their Dependency to Business Processes,” Proceedings
of IEEE Conference Database and Expert Systems Ap-
plications, Regensburg, September 2007, pp. 829-834.
[13] L. Chung “Representing and Using Non-Functional Re-
quirements: A Process-Oriented Approach,” PhD Thesis.
University of Toronto, Toronto, 1993.
[14] D. Gross and E. Yu, “From Non-Functional Require-
ments to Design through Patterns,” Requirements Engi-
neerin g, Vol. 6, No. 1, 20 01, pp. 18-36.
doi:10.1007/s007660170013
[15] F. Buschmann, K. Henney and D. C. Schmidt, “Pattern
Oriented Software Architecture on Patterns and Pattern
Languages,” John Wiley & Sons, England, Vol. 5, 2007,
pp. 67-74.
[16] M. Svahnberg, J. Van Gurp and J. Bosch, “A Taxonomy
of Variability Realization Techniques,” ACM Software-
Practice & Experience, Vol. 35, No. 8, July 2005, pp.
705-754.
[17] R. Elmasri and S. B. Navathe, “Fu ndamentals of Database
Systems,” 5th Edito n , Addison-Wesley, Reading, 2007,
pp. 232-234.
[18] I. Dubielewicz, B. Hnatkowska, Z. Huzar and L. Tuz-
inkiewicz, “Feasibility Analysis of MDA-Based Database
Design,” IEEE International Conference on Dependabil-
ity of Computer Systems, Washington, May 2006, pp.
19-26. doi:10.1109/DEPCOS-RELCOMEX.2006.26
[19] M. Glinz, “On Non-Functional Requirements,” Proceed-
ings of the 15th IEEE International Requirements Engi-
neering Conference, Delhi, Octobe r 2007, pp . 21-26.
[20] Wikipedia, “X Window System (Computer Science),”
2008. http://en.wikipedia.org/wiki/X_window_system.
[21] L. Bass, P. Clements and R. Kazman, “Software Archi-
tecture in Practice,” 2nd Edition. Addison-Wesley, Mas-
sachusetts, 2003, pp. 75-88.
[22] L. Zhu and I. Gorton, “UML Profiles for Design Deci-
sions and Nonfunctional Requirements,” IEEE Second
Workshop on Sharing and Resuing Architectural Knowl-
edge, Minneapolis, May 2007, pp. 49- 54.
[23] F. J. V. Linden, K. Schmid and E. Rommes, “Software
Product Lines in Action: The Best Industrial Practice in
Product Line Engineering,” Springer, Berlin Heidelberg,
2007, pp. 43-45.
[24] C. Alexander, S. Ishikawa, M. Silverstein, M. Jacobson, I.
Fiksdahl-King and S. Angel, “A Pattern Language,” Ox-
ford University Pr ess, New York, 1977.
[25] Wikipedia, “Design Patterns (Computer Science),” 2008.
http://en.wikipedia.org/wiki/Design_pattern_%28comput
er_science%29
[26] E. Gamma, R. Helm, R. Johnson and J. Vlissides, “De-
sign Patterns: Elements of Reusable Object-Oriented
Software, ” Addison-Wesley, New York, 1995, pp. 79-
315.
[27] M. Yacoub, H. Xue and H. Ammar, “Automating the

End to End Development Engineering
216
Developmen t o f Pat tern -Oriented Designs for Application
Specific Software Systems,” Proceedings IEEE the 3rd
Symposium on Application-Specific Systems and Software
Engineering Technology, Washington DC, March 2000,
pp. 163-170.
[28] S. M. Yacoub, “Pattern-Oriented Analysis and Design
(POAD): A Methodology for Software Development,”
PhD Thesi s, West Virginia University, Morgantown, De-
cembe r 1999.
[29] S. J. Mellor, K. Scott, A. Uhl and D. Weise, “MDA Dis-
tilled: Principles of Model-Driven Architecture,” Addison
Wesley, New York, 2004.
[30] “OMG MOF XMI Final Adopted Specification,” July
2010.
http://www.omg.org/technology/documents/formal/xmi.ht
m.
[31] P. Konemann, “The Gap between Design Decisions and
Model Transformations,” September 2009.
http://www2.imm.dtu.dk/.../the_gap_between_design_dec
isions_and_model_transformations.pdf
[32] D. Steinberg, F. Budinsky, M. Paternostro and E. Merks,
“EMF: Eclipse Modeling Framework,” 2nd Edition, Ad-
dison-Wesley Professional, Singapore, December 26
2008.
[33] “IKV++ technologies ag.MediniQVT,” 2007.
http://projects.ikv.de/qvt/
[34] “W3C OWL Web Ontology Language,” August 2010.
http://www.w3.org/TR/owl-ref/
[35] “OMG (2007b) OMG Unified Modeling Language
(OMG UML), Superstructure, V2.1.2,” OMG Document
Number: Formal/2007-11-02.
[36] W. R. Sebesta “Concepts of Programming Languages,”
5th Edition, Addison Wesley, Boston, 2005.
[37] “Microsoft Mess agi ng Queue,” August 2010.
http://www.microsoft.com/windowsserver2008/en/us/
technologies.aspx.
[38] “Advanced Message Queuing Protocol (AMQP),” 2010.
http://www.amqp.org/confluence/display/AMQP/Advanc
ed+Message+Queuing+Protocol
[39] “Java Messaging System Standard,” 2010.
http://java.sun.com/products/jms/
[40] S. Vinoski, “Advanced Message Queuing Protocol,” IEEE
Internet Computing, Vol. 10, N o. 6, 2006, pp. 87-89.
doi:10.1109/MIC.2006.116