A DISSERTATION SUBMITTED IN PARTIAL FULFILLMENT OF THE REQUIREMENTS FOR THE DEGREE OF DOCTOR OF PHILOSOPHY

BRNO UNIVERSITY OF TECHNOLOGY
FACULTY OF INFORMATION TECHNOLOGY
A DISSERTATION SUBMITTED IN PARTIAL
FULFILLMENT OF THE REQUIREMENTS FOR THE DEGREE OF
DOCTOR OF PHILOSOPHY
PETR C. SMOLÍK
Field of specialization: Information Systems
Supervised by: Prof. Ing. Tomáš Hruška, CSc.
State doctoral exam: June 2000
Submitted on: February 2006
Availability: Library of the Faculty of Information Technology,
Brno University of Technology, Czech Republic

Software systems are a critical component of the information age. They are used to
support or control business processes, production, communication, or even drive
products themselves. Software quality is becoming of utmost importance, since even
the smallest flaws may have huge impacts on success of organizations or even on
human lives. There are various approaches to increasing quality, like application of
formal methods or introduction of specific types of development processes. Focus of
this thesis is on an approach that attempts to increase quality of software systems
by means of clear specification of their essential properties. Systems are built for
different purposes in different problem domains. Domain experts know best how
their system should work and what is important about it. These experts need means
to express their requirements in a way that can ensure their fast and correct
realization in software.
Metamodeling environment is introduced that enables creation and operation of
domain;specific modeling environments based on explicitly defined metamodels.
These modeling environments not only allow for modeling of various aspects of
software systems, but also for automatic generation of their program code. This
results in high configurability of realized systems, good requirements traceability,
and independence on implementation technologies, because the essence of the
system is expressed cleanly in a model and not complexly encoded into programs of
a general purpose programming language. The metamodeling environment is based
on a metamodeling language that is formally grounded by its translation to Alloy
modeling language and allows for automatic semantic analysis of metamodels with
available tools.
Viability of the presented approach was demonstrated on several real;world
enterprise software development projects where large;scale software systems were
developed and are now being maintained and extended by means of modeling and
metamodeling.
Alloy Modeling Language, Domain Specific Languages, Metamodel, Metametamodel,
Metamodeling Environment, Metamodeling Language, Model Driven Engineering,
Software Product Lines.

This work had been a long journey from crazy thoughts that not many believed in, to
their successful real;world applications that are still unbelievable to many. Particular
thanks belong to all those who believed and therefore made this work possible and
without whom this work would not progress into something real and useful. My
special thanks belong to prof. Tomáš Hruška, the dean and my supervisor, who
trusted me from the beginning and who was convinced that I am up to something
significant.
I am very grateful to J=rgen Holland, Mikhail Sosnin, Pavel Polák, Rastislav Blažej,
Daniel Bohata, Milan Rubeš, Vítězslav Křivánek, Martin Charvát, Radek Pokorný,
Ondřej Jaroš, Jan Šudoma, David Škarka, Miroslav Benedík, Libor David, Lubomír
Pecko, Jaromír Šmerda, Miroslav Řehák and others, who took significant risks and
let my theories and hypotheses be tested on their projects and organizations,
betting their own careers on something so wild and unproven.
This work would be also impossible without those who helped to materialize and
perfect all these abstractions and ideas, my colleagues and friends, Michal Dvořák,
Pavel Vítkovský, Karel Miarka, Jan Tesáček, Martin Vít, Jakub Dadák, Pavel
Mikuláštík, Gabriel Szigeti, Ivan Kraner, Tomáš Kyjak, Tomáš Kašpar, Roman Mišoň,
Lubor Gajda, Jan Chura, Mojmír Adamec, Michal Diatka and many others.
I take this opportunity to thank my family and friends for their love, support, and
the right conditioning. I am very grateful to my loving American family, Dr. John and
Nancy Curtis, who equipped me with significant international experience. My thanks
also belong to my most dear teachers, Dr. David Boyd, Dr. George Meghabghab, Dr.
Roger Lamprey, and Dr. Jun Ji, who taught me how to play with and be excited
about ideas.
Finally, I thank David Lewington for kind proofreading of the presented texts.
Petr C. Smolík
2006;02;22

1.1 Context of the Presented Work .............................................................................5
1.2 Fundamentals of Metamodeling............................................................................6
1.3 The Process of Metamodeling................................................................................8
1.4 Analogies to Metamodeling....................................................................................9
1.5 Software Quality ................................................................................................... 10
1.6 Chapters Overview................................................................................................ 13
!"# ! !$!# % # " $ &
2.1 Megamodel ............................................................................................................ 14
2.2 Model Driven Engineering ................................................................................... 16
2.3 OMG Model Driven Architecture......................................................................... 24
2.4 Microsoft Tools for Domain Specific Languages.............................................. 28
2.5 Atlas Model Management Architecture............................................................. 30
2.6 Model;Integrated Computing.............................................................................. 34
2.7 Alloy Modeling Language..................................................................................... 36
' #"$ ( %! ) !$! ! * &
3.1 Initial Goals Statement ........................................................................................ 45
3.2 Goals Stated in the Current Terminology ......................................................... 45
& # + #+! ,! ( # &-
4.1 Introduction........................................................................................................... 47
4.2 Mambo by Example.............................................................................................. 48
4.3 Relation to Alloy.................................................................................................... 56
4.4 Grammar ................................................................................................................ 57
4.5 Semantics............................................................................................................... 58
! #.! #. !" / " 0'
5.1 Mambo 1.0............................................................................................................. 63
5.2 Mambo 2.0............................................................................................................. 67
5.3 Mambo 3.0............................................................................................................. 70
0 ! #. !" + / .! -'
6.1 Aspects Overview.................................................................................................. 73
6.2 Model Manipulation ............................................................................................. 76
6.3 Model Storage ....................................................................................................... 78
6.4 Model Validation................................................................................................... 82
6.5 Model Transformation.......................................................................................... 83
- ! #. !" + ,," ! 11
7.1 University Information System Development................................................... 88
7.2 Enterprise Application Integration..................................................................... 91
7.3 Enterprise Front;End Development.................................................................. 100
1 " $ $ 21
8.1 Comparison to Similar Approaches ................................................................. 108
8.2 Main Contributions............................................................................................. 112
8.3 Directions for Further Research ....................................................................... 113
$ ( + !$ &
!(! ! !$ 0

Mambo Metamodeling Environment 5
Daniel N. Jackson, MIT
Chapter summary:
• Introduces context of the presented work.
• Uncovers the philosophy of metamodeling, explains why metamodeling is
useful and powerful, and offers two analogies to metamodeling.
• Provides overview of the subsequent chapters.
!3 ( %! ) !$! ! *
Since the beginning, software has been created to satisfy requirements. First
software was very computation oriented and the requirements were pure
mathematical formulas. The formulas were easily mapped to languages used to
program the software. Nevertheless, during time, computers were used increasingly
to accomplish more complex tasks. Software is now used to obtain, process, and
provide information, interact with human users, or control machinery. There are still
requirements that software has to satisfy. The difference is that it is more and more
difficult to map requirements to software itself. Requirements are specified by
problem domain experts in their own language and the task of programmers is to
map these requirements to programs in appropriate programming languages.
Problem domain experts are professionals or specialists in a specific field or
industry, i.e. experts in banking, telecommunications, logistics, or marketing. The
domain experts know best what the required software should do and they are often
its future users.
For large software systems it may take quite a lot of human time and energy to
gather requirements and translate them into fully functional software. Lots of time
may be also wasted, because wrong requirements might have been realized, or
because some requirements might have been misunderstood. Successful software
projects manage to implement the required software functionality in a reasonable
time. Nevertheless, the duration from requirements to running software may be one
of the main reasons why many software projects fail.
Moreover, the situation is even worse since requirements are not static. As
companies evolve their businesses and as people have increasing demands on
technology, requirements keep changing. Software systems need to be flexibly
adaptable to changing requirements. But again, due to the gap between
requirements and running software, it takes a lot of human effort to keep the
software up;to date with the most recent needs of its users.

The software industry always looked for means to narrow the gap on the way from
requirements to software. Many programming languages have been created and
many programming paradigms were invented. The general trend could be sensed
from all the individual developments. High;level general purpose programming
languages were created so that applications of any kind would be easy to build.
Specific purpose languages were designed so that some very specific applications
may be built yet quicker and simpler. The object paradigm was invented to move
software closer to the reality that is assumed to be object;oriented. Software
components were expected to enable composing software from reusable parts. It is
the trend of raising the level of abstraction.
The requirements gap was also tackled by various attempts for requirements
traceability, where each requirement had linkage all the way down to the parts that
realize it. Analysis and modeling techniques were created to enable better and more
exact ways of specifying requirements. Finally, there were many attempts to define
the best suitable way of software development. Development processes were
designed to ensure that the right software was created quickly. The current
development approaches range from heavy weight (RUP) to light weight (agile). The
light weight approaches, where the development is more incremental and less
formal, suit better in cases where is high level of uncertainty and requirements
change faster.
All the mentioned trends are integral part of software industry evolution. It could
not be said that any one is wrong or outdated. Other industries have come through
their own evolution too. A good analogy may be the automobile industry. Cars were
first manufactured, later assembled from components, then built on assembly lines,
and now they may start to be massively customized as customer demands increase.
Importantly, none of the evolutional advances is outdated. It is just that some
special parts may be manufactured, many components are still reused, and the
variability of the assembly line keeps growing.
The future developments in the software industry may be similar. General purpose
languages are like increasingly more efficient tools in a manufacture. Domain
specific languages may become increasingly better assembly lines. Components and
libraries will be extensively reused as parts of assembled applications. Nevertheless,
the same as with the automobile industry, what has the real power to speed;up the
production process and move requirements closer to the product are the assembly
lines. Domain specific languages are languages that speak in terms of the real
problems that should be solved by the software. With domain specific language it is
the closest requirements definition may get to software. At best, the program in the
domain specific language is the requirements definition itself. What is now missing
is a clear way of integrating all the approaches and languages into a coherent and
effective development environment.
#.! #"$ ( ! #. !" +
Metamodeling is powerful, because it targets important aspects of software. It
primarily focuses on the purpose of software itself and forces time to be invested
into defining what the essence of a system being implemented is. Metamodeling
means identification of general concepts that exist in a given problem domain and
their relations. It is a search for sufficient yet simple enough language that may be
used to define the domain’s requirements.

Metamodeling forces clear distinction between what is modeled and what is the
framework where the model lives. This distinction is needed, because without it, it
would not be possible to apply metamodeling to real software development.
Definitions of the primary terms follow:
• 3! #4"! .# !"
Any software implements requirements of some problem domain (i.e. traffic
lights control). Metamodeling allows for models to be able to talk directly in
terms of specific problem domains. Executable domain model is a model that
fully describes functional requirements on the system in a given domain and
may be directly executed as software that implements these requirements.
This model is kept as simple as possible while sufficiently expressing
everything needed.
• 3! #.!5 *
Executable domain model must abstract both from implementation
technology details and from general rules inherent in the given domain. The
execution framework provides an environment in which the executable
domain model may live and which provides concrete implementation of all
the general rules of the domain that are not part of the model. The framework
may be realized in a specific technology into which transformed models are
integrated, or a model interpreter may directly interpret the executable
model.
• ! #. !"
For models to fit requirements of specific domains, it is necessary that for
each domain a specific modeling language (domain specific language) could
be designed. General purpose modeling language would not suffice, since it
does not talk in terms of any specific domain’s concepts. Metamodel defines
concepts of a given domain, their relations, and forms a modeling language
used to create executable domain models.
The executable model must talk directly in terms of the target domain concepts
where the software system is to be used. This enables the domain experts to directly
understand the system definition. Furthermore, domain experts may be able not
only to validate satisfaction of their requirements, but they may also learn to model
the system themselves. In an ideal case a system should be modeled purely by the
domain experts that need it.
The scope of what may be defined in a model is specified by a metamodel.
Metamodel specifies what elements may be contained in the model and how they
relate among one another. In reality, metamodel is a specification of a domain;
specific modeling language, a language used to express the requirements on the
system and define how exactly it should realize them. No distinction is made
between domain;specific language and domain;specific modeling language, the same
way there is no distinction made between a program and a model. The word model
just helps to abstract from the concrete representation of the program. This work
strongly stresses the importance of metamodel flexibility. During development of a
software system it is necessary to develop a well fitting metamodel, and thus decide
what should be or should not be modeled about the system.
Flexibility of modeling abilities is needed, because as system develops, it adopts to a
domain environment that may also be changing. Domain concepts may be added or
changed. To enable this level of flexibility, the metamodel has to be also flexible. It
needs to be very easy to add and change the concepts manipulated by models and
change their possible relations.

Metamodel needs to offer enough power for models to be able to describe most of
the domain’s requirements while it needs to abstract from anything that is not
related directly to the domain or anything that is a general rule in the domain. In
any domain it is possible to distinguish what is variable and what is the rule. The
variable aspects need to be captured in models, the rules to rely on need to be
implemented by the framework. The role of a metamodel is to narrow down the
number of concepts manipulated by models to a sufficient minimum. This means
that models should be as simple as possible, while enable full definition of all the
required functionalities.
' %! ) !$$ ( ! #. !" +
Metamodeling is the process of:
• .," ( # ; For functionalities in a system to be easily defined, there has
to be little to define about them. Simplification is provided by lowering the
number of parameters that may be set and increasing the number of facts
that are taken as a rule.
• 4$ # ; Metamodel abstracts from specifics of implementation
technologies, because it focuses on defining purely the important aspects of a
domain.
• !,# # ( %! ., # ( . %! $! # 6 ; Important is the domain,
secondary are the implementation technologies (implementation details).
The parts of the metamodeling process may be the following:
• Using metametamodel to create metamodels.
• Looking for the important concepts in the target domain.
• Finding degrees of freedom or potential variabilities of the system.
• Setting rules of the game, which means looking for things that are in the
framework and not in the model.
• Ensuring that metamodels are kept as simple as possible and yet describe all
necessary about the domain.
• Deciding about environment where the models would live (framework) – and
how it will live (compilation vs. interpretation).
There are the following expected impacts of metamodeling:
• Systems traceability and auditability (norms, regulations, legislation).
• Faster from analysis to system realization.
• Higher flexibility and maintainability of the system.
• Higher system quality.
• Lower price of system ownership.

& #" + !$ ! #. !" +
This section provides two useful analogies that help to capture some aspects of
metamodeling in different light.
& #.!$ ! .$ ( ! #. !" +
The game analogy is as follows:
• Game has rules. Rules are constant and are seldom changed. The rules form
the ( #.!5 * of the game.
• Game has a theme. The theme has some concepts that are manipulated when
the game is played. The theme of the game is the problem .# and its
definition is a .! #. !".
• Game is played. Each particular play of the game manipulates the theme
concepts and takes advantage of choices available. The choices are limited by
the rules. Instance of a game is instance of a . !".
Implications of the game analogy:
• If there were too many choices, the game would be hard to play. This implies
that model would be hard to create if there were too many things to say in
the model. Therefore metamodel must be kept simple.
• There has to be enough choices for the game to satisfy the player. This
implies that model has to be able to express requirements that satisfy the
user. Therefore metamodel, must sufficiently cover the given domain.
The game of building a software system:
• Goal of the game is to build a software system.
• Rules of the game specify how such system may be build (what can be used
to build it, in what order, and what are the limitations).
• Playing the game means building the new functionalities into the system.
& ) !$ ! .$ ( ! #. !" +
The production line analogy is as follows:
• Production line produces products of some sort ( .# )
• Production line is able to produce different instances of a product based on
product parameters defined (. !")
• Production line has to enable the variability offered in the product definition
(.! #. !")

• Implementation of the production line is the ( #.!5 *
Implications of the production line analogy:
• It is very easy to change production within the variability offered by the given
production line. This implies that model changes must be the simplest and
most effective to accomplish.
• If too little variability is offered then the production line is not able to
produce required products. This implies that to satisfy customers, the
metamodel should anticipate wide enough range of choices.
• If too much variability is offered, then the production line gets more complex.
This implies that not only models get complicated, but also the framework.
• Metamodeling is about constantly weighing what model flexibilities should be
allowed and what should not. Thus there may never exist a perfect
metamodel usable in a whole range of situations. There may only be a
perfectly matching metamodel for a given situation at a given time.
Software system as a production line:
• Production line to offer functionalities of a software system.
• Production line may be parameterized to produce different functionalities of
the system.
• Flexibility of the production line is limited, which ensures that the
parameterization is simple.
• Flexibility of the production line is big enough so most of the potential
functionalities needed may be produced.
• There may be something left for manual finishing (special functionalities).
( 5# ! 7 #" 6
The world business is more and more powered by software and thus software is
being created to satisfy business requirements. This section presents the full notion
of software quality based on the international standard focused on software quality
ISO/IEC 9126 [ISO91] and argues that software quality is essential for reaching the
universal business goals. [Nor04] defines the following universal business goals: high
quality, quick time to market, effective use of limited resources, product alignment,
low;cost production, low;cost maintenance, mass customization, mind share.
The following extract from the ISO standard shows that most of the universal
business goals are targeted exactly by software quality. Furthermore, it should be
noted that metamodeling of software systems has its goals also well aligned with
software quality, because it aims for more flexible and easier to maintain systems
that implement large amounts of functionalities. This section focuses on quality
characteristics that may be used to evaluate software quality and will look at them
in the light of metamodeling. The quality characteristics based on ISO/IEC 9126
[ISO91] are the following:

• #" 6 A set of attributes that bear on the existence of a set of
functions and their specified properties. The functions are those that satisfy
stated or implied needs.
o #4 " 6 Attribute of software that bears on the presence and
appropriateness of a set of functions for specified tasks.
o # 6 ; Attributes of software that bear on the provision of right or
agreed results or effects.
o ! ,! #4 " 6 ; Attributes of software that bear on its ability to
interact with specified systems.
o .," # ! ; Attributes of software that make the software adhere to
application related standards or conventions or regulations in laws and
similar prescriptions.
o ! 6 ; Attributes of software that bear on its ability to prevent
unauthorized access, whether accidental or deliberate, to programs
and data.
A software system model focuses on the exact definition of functionality and
a metamodel defines what types of functionalities may be defined and how.
Functionality characteristic of software quality thus relates mainly to the
ability of a modeling language to express all needed requirements cleanly in a
model. Quality of software is increased because the model is kept as simple as
possible and abstracts from implementation technologies. Furthermore, to
simplify models, general rule functionalities may be abstracted from models
into the execution framework.
• !" #4 " 6 ; A set of attributes that bear on the capability of software to
maintain its level of performance under stated conditions for a stated period
of time.
o # 6 ; Attributes of software that bear on the frequency of failure
by faults in the software.
o # " "! # ! ; Attributes of software that bear on its ability to
maintain a specified level of performance in cases of software faults or
of infringement of its specified interface.
o ! /! #4 " 6 ; Attributes of software that bear on the capability to re;
establish its level of performance and recover the data directly affected
in case of a failure and on the time and effort needed for it.
With metamodeling, reliability is split into two parts. Both reliability of the
execution framework and executable model may be measured. The advantage
is that during time, reliability of the framework increases. Framework matures
quickly, because any fault is corrected only once and forever. Model faults, on
the other hand, are very local and easy to locate and fight.
• 8$#4 " 6 ; A set of attributes that bear on the effort needed for use, and on
the individual assessment of such use, by a stated or implied set of users.
o 8 ! $ # #4 " 6 ; Attributes of software that bear on the users'
effort for recognizing the logical concept and its applicability.
o !# #4 " 6 ; Attributes of software that bear on the users' effort for
learning its application (for example, operation control, input, output).
o ,! #4 " 6 ; Attributes of software that bear on the users' effort for
operation and operation control.
Usability is something that may be strongly enforced by a metamodel and
metamodeling – it is because the process of metamodeling is about deciding

how complex or how simple the system should be, and that decides its
usability.
• (( ! 6 ; A set of attributes that bear on the relationship between the level
of performance of the software and the amount of resources used, under
stated conditions.
o .! 4!%#/ ; Attributes of software that bear on response and
processing times and on throughput rates in performing its function.
o !$ ! 4!%#/ ; Attributes of software that bear on the amount of
resources used and the duration of such use in performing its function.
Speed of a system relates almost to implementation technologies used. Speed
of user operation relates to ergonomics of the GUI, which depends on the
execution framework. Number of people needed to accomplish a task
depends on complexity of the task’s execution, which depends on the model.
• # # #4 " 6 ; A set of attributes that bear on the effort needed to make
specified modifications.
o #"69#4 " 6 ; Attributes of software that bear on the effort needed for
diagnosis of deficiencies or causes of failures, or for identification of
parts to be modified.
o %# +!#4 " 6 ; Attributes of software that bear on the effort needed
for modification, fault removal or for environmental change.
o #4 " 6 ; Attributes of software that bear on the risk of unexpected
effect of modifications.
o !$ #4 " 6 ; Attributes of software that bear on the effort needed for
validating the modified software.
This characteristic of quality is the one hardest to reach, because it is always
easier to just somehow implement the system and not care about the future.
Nevertheless, the future always brings unexpected changes and software has
to be ready to be flexibly changed. Maintainability is the primary
characteristic targeted by this work.
Significant effort needs to be invested in designing a software system in order
for it to be maintainable in the future. Metamodeling serves here as a strategy
that forces a clear distinction between the real problem that the system
should solve and the technology that is to support it.
Analyzability is increased, because care is given to separation of various
aspects of the software. Metamodeling focuses on defining the degrees of
freedom available in the realized system and therefore it offers an extreme
changeability within well defined boundaries.
In case of execution framework, stability goes against changeability. The
framework implements the general rules of the system and sets the bounds
for model flexibility. The implemented general rules affect execution of all
functionalities defined in models. Therefore, on one side, very effective
changes may be made that instantly modify vast amounts of functionalities,
but there is the risk of unexpected effects. Stability of framework changes has
to be therefore increased by application of automated tests that yield
problems when they occur.
• ) #4 " 6 ; A set of attributes that bear on the ability of software to be
transferred from one environment to another.

o #, #4 " 6 ; Attributes of software that bear on the opportunity for
its adaptation to different specified environments without applying
other actions or means than those provided for this purpose for the
software considered.
o $ #""#4 " 6 ; Attributes of software that bear on the effort needed to
install the software in a specified environment.
o ( .# ! ; Attributes of software that make the software adhere to
standards or conventions relating to portability.
o !,"# !#4 " 6 ; Attributes of software that bear on the opportunity
and effort of using it in the place of specified other software in the
environment of that software.
Portability is highly increased by separation of the model from the framework.
Implementation technology may be changed with no change in the model.
Only framework may need to be rewritten into the new technology. Operating
system portability is strictly related to the implementation technology used
for the framework.
0 %#, ! $ /! / !5
• Chapter 2, Related Research and Solutions, overviews the current approaches
to metamodeling software systems and provides contextual basis for the
notions introduced in subsequent chapters.
• Chapter 3, Goals of the Presented Work, evaluates the current state;of;the;art,
identifies potential areas where research and experience is needed, and
presents goals of this work.
• Chapter 4, Language Specification, provides specification of the
metamodeling language for definition of domain;specific modeling languages
and their modeling environments.
• Chapter 5, Metametamodel Evolution, overviews how the metametamodel of
the metamodeling language has evolved and what were its major shaping
factors.
• Chapter 6, Metamodeling Environment, introduces a metamodeling
environment that may be used to flexibly define metamodels based on the
needs of a problem domain and to assemble corresponding domain specific
modeling environments.
• Chapter 7, Metamodeling Applied, presents three cases where metamodeling
and the metamodeling environment were applied in development of real;
world software systems.
• Chapter 8, Conclusions, overviews contributions of this work and suggests
directions for further research.
• Appendices include list of references used in this work, list of figures, and a
glossary of used terms and abbreviations.
Chapter 2 was compiled from cited sources with the addition of author’s remarks,
while chapters 3 to 8 represent author’s original contribution.

!"# ! !$!# % # " $
Chapter summary:
• Overviews current approaches to metamodeling software systems.
• Presents similar solutions to the presented software development issues.
• Provides contextual basis for the notions introduced in subsequent chapters.
!+#. !"
The notion of megamodel was first introduced in [BJV04] and it is defined as “a
model of which at least some elements represent and/or refer to models or
metamodels.” Megamodeling is then considered to be an activity of “modeling in
large” which is meant to be relating and managing models where global
relationships are considered among artifacts and not their contents. On the opposite
“modeling in the small” is concerned with the contents of models and their
transformations. The concept of megamodel is seen to be an essential part of any
future model;driven software development platform.
The core hypothesis of megamodeling based on Favre [Fav04, Fav04a, Fav04b,
FN04, Fav05] is that “everything is a system”. Based on Bertalanffy (1968), a system
may be defined as “a set of elements standing in interrelations”. Systems may be of
various kinds. Their basic classification is to physical systems, digital system, and
abstract systems. Orthogonally, also dynamic and static systems are recognized. For
example a language may be seen as an abstract system, its specification in a pdf file
is seen as a digital system, and in a printed form it is already a physical system.
Figure 2.1 The Megamodel Metamodel
Megamodels are models where elements represent systems that may play the role of
subsystems, elements of sets, models, or metamodels. Megamodel is itself a model
and therefore it also has its metamodel (Figure 2.1). Megamodel recognizes four
fundamental relations among systems:
• δ: ! ., $! : ., $ !;,# – relation that represents decomposition
of systems into subsystems and parts.
• : !, !$! # (: . !";$ $ – represents relation between model and a
system under study (sus) that it either describes or specifies [Fav04].
δ
System
model
sus
χ
ε
set
element
composite part
metamodel
cmodel
*
*
*
*
* *
* *

• ε: !"!.! (: !"!.! ;$! < represents relation between set and its elements
(i.e.: language is a set; program in the language is an element of the set).
• χ: ( .$ : .! #. !"; . !" < represents relation between metamodel
and its conformant model. This relation is derived from a pattern of and ε
relations [Fav04a].
Megamodel puts strong emphasis on the fact that being a model is just a role:
“Nothing is a model, but everything could serve as a model” [Fav05]. For example a
map may be a model for a human trying to find the right way, but it is a regular
system to play with.
%# $ # . !"=
The term model has many various definitions of the term model in the literature.
Megamodel offers convenient level of abstraction at which reasoning about terms
model, metamodel, or even meta;metamodel is possible. Megamodel provides for the
following definition of model:
“Model is a representation of a system”
Deeper definition of model is provided by [BG01] and supported by [Fav05]:
“A model is a simplification of a system built with an intended goal in mind.
The model should be able to answer questions in place of the actual system.”
Several orthogonal types and roles of models may be considered:
• !$ , /! /$ , !$ , /!
Descriptive models describe an existing system and help to understand it (i.e.
model of a solar system or model created to understand a legacy software
system). Prescriptive models are used as specifications for building new
systems, they are their construction plans. During time prescriptive models
may become descriptive and vice versa.
• # /$ 6 #. . !"$
Static models capture structure of systems, whereas dynamic models capture
their behavior.
• 3! #4"! /$ >!3! #4"!
Software models are executable when it is possible to use them to fully
interpret the behavior of the system they represent.
• #" /$ >( #"
Functional models capture functional aspects of a system, whereas non;
functional are interested in the general parameters or conditions that a
system should satisfy.
Based on their purpose, there may be also different kinds of models: mathematical,
biological, economical, meteorological, etc.
%# $ # .! #. !"=
Based on the megamodel, the following fundamental statements may be made:
“Modeling language is a set of models”

“Metamodel is a model of a modeling language”
By the megamodel, a modeling language is really seen as a “language of models”
which in the sense of formal language theory is seen as a set of all its possible
sentences. Deeper definition of metamodel is provided again by [BG01]:
“A meta;model is the explicit specification of an abstraction (a simplification).
In order to define the abstraction, the meta;model identifies a list of relevant
concepts and a list of relevant relationships between these concepts.”
It is important to note, that a model of a model is not a metamodel the same way as
a photo of a painting of a house is not a metamodel, but just another
representation.
%# $ # .! #.! #. !"=
The megamodel enables any model to have a metamodel. In case that some system
already plays the role of a metamodel with respect to some other system, its
metamodel may be considered a metametamodel with respect to that other system.
Number of possible meta;levels is unlimited, nevertheless there always exists some
system that is its own metamodel, and the chain of meta;levels stops with it.
Software systems used as metametamodels include the OMG MOF [MOF04], ECORE
[EMF], MS/DSL [MSDSL], KM3 [KM3], or Mambo metamodeling language presented
in this thesis.
!" /! + !! +
In 2001 Bézivin and Gerbé stated that “Model engineering has significant potential
as an avenue of research. It consists of bestowing first;class status on models and
model elements, similarly to the first;class status given to objects and classes in the
1980’s, the beginning of object technology era.” [BG01].
Later, in 2004, Bézivin refined the idea with Breton and stated that “A new
information system landscape is emerging that will probably be more model;
centered than object;oriented, characterized by many models of low granularity and
high abstraction. These models may describe various aspects of a system such as
software product properties, static and dynamic business organization, non;
functional requirements, middleware platforms, software processes, and many more.
Each model represents some particular point of view of a given system, existing or in
construction, and this model conforms to a precise metamodel or DSL (Domain
Specific Language).” [BB04]
The term Model Driven Engineering (MDE) is now used for a field of research that
encompasses research trends related to generative and transformational techniques
in software engineering, system engineering, and data engineering. The key ideas of
MDE are relevant also to other areas such as domain specific languages, model;
driven software development (MDSD), model management, or language;oriented
programming. Among major MDE approaches are counted Model;Integrated
Computing (MIC), Model Driven Architecture (MDA), and Software Factories. Some of
the areas and approaches are further discussed in subsequent sections.
Considering any software artifact to be a model or a model element is the basic
principle of MDE. In [DBJ05a] it is argued that “it has not only the advantage of

conceptual simplicity; it also leads to clear architecture, efficient implementation,
high scalability and good flexibility, allowing to operate directly on the mapping
elements and to attach semantics to them.” In MDE a model is an artifact that
conforms to a metamodel and that represents a given aspect of a system. These
relations of conformance and representation are central to MDE and are based on
the notion of megamodel.
Favre [Fav05] argues that the research hypothesis of MDE is that models and model
transformations will help to bridge the gap between requirements and their
realization in a running system. Further, Favre sees MDE to be in a position to meet
some of challenges to which object;oriented technology was not able to find a
solution (i.e.: aspect separation, homogenous handling of functional and non;
functional attributes, integration of different paradigms such as rules, services,
processes, or architectures).
The promise of MDE comes from the profound unification principle that “everything
is a model”, which is more broadly applicable than the “everything is an object” that
was used in object;oriented technology. MDE sees even the following non;objects as
models: design patterns, use cases, aspects, platforms, correspondences, methods,
programs, traces, legacy, transformations, model elements, metamodels, verification,
components, etc. [BHA04] argues that model engineering principles are realistic, but
that many open research problems may be related to a loose or strict application of
the “everything is a model” principle.
The following subsections focus in more detail on specific MDE attributes and also
discuss other approaches that are related to MDE.
.# ,! ( # + #+!$ ? $@
Domain specific languages are computer languages dedicated to a particular kind of
problem. DSLs are usually small and declarative. DSLs and DSMLs (Domain Specific
Modeling Languages) are considered to be the same and the terms are usually used
interchangeably. DSL is always represented by a metamodel and its models conform
to that metamodel.
An agile MDE environment needs to enable existence of a large number of small
DSLs defined by well focused metamodels and provide many tools, each based on
one of several metamodels, where interoperability is provided via model
transformations.
! #. !" +
In the context of MDE [DBJ05a] presents metamodeling nicely as “a convenient way
for isolating concerns of a system. Metamodel acts as a filter. It specifies the set of
concerns that should be taken into account while creating a model. Separate
metamodels may address distinct domains (information, processes, organization) or
different levels of abstraction. Once these concerns have been separately expressed,
they may have to be reassembled. This may be fulfilled by an ad hoc mapping,
specific for each couple of metamodels.”
! #. !"$ /$ " + !$
Domain ontology defines “general concepts and categories originating in a domain
of knowledge.” [Hru05] Ontological categories correspond to metaclasses of the
system’s objects. Nevertheless, ontologies are not the same as metamodels of
systems: A metamodel may be focused on allowing a specific system to be modeled.

It may capture general concepts of the domain in question, but it may also capture
other concepts related to the requirements placed on the system by its users.
Whereas domain ontology is interested only in the minimal, but yet complete, set of
concepts that apply to all the possible systems realized in the given domain.
Ontologies are not extended and modified based on changing system requirements,
but metamodels are.
! % " + #" ,# !$
The notion of Technological Spaces (TS) was initially proposed by Kurtev, Bézivin,
and Aksit in [KBA02]: “A technological space is a working context with a set of
associated concepts, body of knowledge, tools, required skills, and possibilities. It is
often associated to a given user community with shared know;how, educational
support, common literature and even workshop and conference regular meetings.”
Different meta;levels exist in all technological spaces and in each one the concepts
of model, metamodel, and transformation have different incarnations. Each
technological space is represented by a metametamodel. There is no best
technological space and MDE needs to deal with an arbitrary number of them and
their associated tools. The emphasis of MDE is on bridging technological spaces,
reuse and integration of various bodies of knowledge developed by different
research communities.
The following are seen as technological spaces: XML documentware, SVG graphware,
MDA modelware, RDBMS, OOBMS, CORBA, semantic web, Java grammarware, etc.
Figure 2.2 shows three sample technological spaces, MDA modelware, Java
grammarware and Mambo modelware, where similarity in the meta;levels is obvious.
EBNF, MOF and Mambo are metametamodels. UML, Java and integration metamodel
are metamodels. A specific UML model, Java programs and an integration model are
models. The bottom level represents running systems like message oriented
middleware.
Figure 2.2: Sample Technological Spaces
Technological spaces may be compared with regard to the following properties:
executability, support for aspects, formalization, specialization, modularity,
traceability, transformability. For example XML has excellent transformability, MDA
support for aspects, and grammarware formalization and executability. On the other
hand XML and MDA have poor formalization and executability. Collaborations
between different technological spaces exist. For example XML and MDA technology
UML MM
MOF MMM
UML Model
M
Particular
use of M
Java
Grammar
EBNF
Java
Program P
Execution
X of Java
Program P
Level M0
Level M1
Level M2
Level M3
Integration
Metamodel
Mambo
MMM
Integration
Model
Message
Oriented
Middleware

spaces are connected via XMI (XML Model Interchange), or MDA with Java through
JMI (Java Model Interchange).
)"# ( .$
The term MDE platform (short for MDE model management platform) was first
introduced in [BJV04] as means for tool integration within MDE that would allow for
many economies of scale and extends on the notion of Modelware Bus. The
following tools are expected to be integrated within an MDE platform:
• Repositories for model and metamodel access
• Transformation tools for transforming models and generation
• Megamodel support for modeling in large
• Various generic editing tools
• General browsing facilities
• Versioning and user authorization facilities
• etc.
MDE platforms may be either centralized or decentralized. The centralized ones exist
online and allow access to their models and in case that a model is not available
locally, another connected platform is interrogated. In the decentralized style MDE
artifacts, such as models, metamodels, transformations, etc. would be exchanged by
users as songs and videos are now exchanged on the web.
[BB04] argues that “the development of ambitious open source MDE platform
projects hosting simultaneously industrial tools and research prototypes may help to
explore still unsolved concrete problems and to improve the state of the art in this
field.”
Oren Novotny [Nov05] presents his thoughts on next generation development tools
and solutions that fit well the vision of MDE platforms and are relevant to this work.
The major extracted points are the following:
• !" ! $ +
Tools that support the creation of models should ideally allow for version
control on each individual model element. Each element should have the
ability to be checked in and out of a repository. A modeling tool should work
with the repository to provide branching and merging support at the element
level. At a later date, another developer might wish to reconcile differences
between branched elements in different models. If a bug in a model element
is fixed in one project, then other projects that are using the same model
element might wish to incorporate those changes; this should be an easy task
to accomplish.
• ! !
The source code should be available in many different languages
simultaneously (source code or UML classes are just different views). Ideally,
the code should not be stored in any single language, but it should be stored
as a model with additional language;independent CodeDOM (Code Document
Object Model) structures. In place of source files, an IDE would instead
connect directly to a project repository. The project would then list the
objects directly, bypassing the need for files.

• #,% #" !5
The tool would have a graphical view of the classes and their relationships in
addition to a code view. A diagram would be able to be created at any place
in the hierarchy, and the developer should be able to drag the classes onto
the designer surface.
( 5# ! ) !$ ? ) @
The notion of software product lines originates deeply in the history of software
engineering, but since 1995 significant work on its definition and application has
been done at the Software Engineering Institute of Carnegie Mellon University.
Primary definition of SPL comes from [Nor05] which sees software product line as “a
set of software;intensive systems that share a common, managed set of features that
satisfy the specific needs of a particular market segment or mission and that are
developed from a common set of core assets in a prescribed way.” The SPL web site
[SPL] includes a slightly modified definition, which uncovers the fact that SPLs are
not a particular technology, but a set of techniques: “Software product lines refers
to engineering techniques for creating a collection of similar software systems from
a shared set of software assets using a common means of production.” Remainder of
this section will present the major SPL thesis mostly compiled from [Nor05]. The
philosophy of SPLs well aligns with the thesis of this presented work.
SPLs exploit the fact that few systems are unique and most organizations produce
families of similar systems. They primarily focus on software reuse and address the
problems for which previous attempts for reuse had failed (that is 1960s
subroutines, 1970s modules, 1980s objects, 1990 components). Through its
development, reuse is becoming more and more systematic. SPL is trying to add
more thought and planning into reuse, and equals product lines to “strategic reuse”.
SPL proposes that products should be built from components, share a common
architecture, and pertain to a specific application domain or market strategy.
Architecture is seen as a core asset that satisfies requirements of the application
domain and is used to structure the components. Software product lines are not:
fortuitous small;grained reuse, single system developed with reuse, just component;
based development, just a configurable architecture, versions of single products, or
just a set of technical standards.
The core SPL assets are the following:
• % ! !
The right architecture paves the way for a system success and represents the
earliest design decisions. Architecture is hardest to change and uneasy to get
right. Architecture must support variation inherent in the product line.
Software components must be designed to be general without a loss of
performance and must build in support for variation points.
• ) ! ,!
Defines the scope of possible features of products that a given product line
could produce.
• ) )"#
Defines how the production of a product should proceed.

Three essential SPL activities are the following:
• ! $$! !/!" ,.!
Architecture, production plan and product line scope are created from
product constraints, production constraints and strategy, and pre;existing
assets.
• ) !/!" ,.!
Based on product requirements within the scope of the product line and via
the product plan, products are produced.
• # #+!.!
Management ensures the right organizational structure, allocates resources,
coordinates and supervises, manages external interface, etc.
The approaches to SPL introduction on projects are the following:
• ) # /!
Core assets are implemented, the whole SPL is built and products are then
produced. This approach requires upfront investment, significant amount of
knowledge and the ability to predict.
• !# /!
First product or two are realized and the core assets are extracted to form the
SPL that is then used to produce more products.
• !.! #"
The incremental approach may combine both of the previous approaches in
an incremental fashion.
It is argued that a “strategic software reuse through a well;managed product line
approach achieves business goals for: efficiency, time to market, productivity, and
quality.” [Nor05]
Northrop [Nor05] identifies the following remaining challenges that SPLs still face:
• Definition and implementation of appropriate variation mechanisms.
• Evolution of product line architectures and assets.
• Funding and business models to support strategic reuse decisions.
• Effective production plans that meet production constraints.
• Product line tool support.
• Ways to lower the initial cost of adoption.
' ( 5# ! # !$
Software factories is a new Micosoft Corporation’s cohesive approach to software
development which tries to synthesize ideas from domain specific languages,
software product lines, component specification and assembly, patterns, framework
completion, domain analysis and feature variability. Software factories are presented
as industrialization of software development. The first mention of software factories
appeared in [GS03]. The authors also published a book on software factories in
2004.
A software factory was primarily defined as “a model;driven product line – a product
line automated by metadata captured by models using domain specific modeling

languages.” [GS03] The approach builds on the notion of product lines presented in
the previous section and merges it with the ideas from model driven engineering.
The result of the merge now slowly materializes in real tools (DSL Tools presented in
a later section) becoming part of Microsoft’s Visual Studio. The idea is to enable
configuration of a development environment and make a software factory out of it.
Software factory works with three key concepts [GS04]:
• ( 5# ! # 6 %!.#
A schema describes the product line architecture and key relationships
between components and frameworks of which it is comprised. A schema
contains information about source code directories, SQL files, configuration
files, what DSLs should be used, how models can be transformed into code,
other artifacts or other models.
• ( 5# ! # 6 !.,"# !
A template provides patterns, guidance, templates, frameworks, samples,
custom tools such as DSL visual editing tools, scripts, XSDs, style;sheets, and
other ingredients used to build the product.
• 3 ! $ 4"! !/!" ,.! / .!
Environment such as Visual Studio Team System, which may be configured
with the software factory template, and which then becomes a software
factory for a given product family.
[GS04] also provides comparison of the software factories approach to OMG MDA
(Model Driven Architecture). Software factories have similar interest in models as
MDA, nevertheless they are less concerned with portability and platform
independence, and more concerned with productivity. Even though the software
factories approach differs from MDA it should be considered as one of the
realizations of MDE principles.
Experience with design and implementation of a software factory is presented in
[RG05] where a software factory was realized for producing healthcare systems
based on Health Level Seven (HL7) standard (HL7 is concerned with interoperability
among healthcare organizations). There was also an attempt to elaborate further on
software factories specialized on business process engineering, which introduces
notion of a business process factory [Fra05]. Similarly [BB04] proposes a method
that suggests using MDE principles to deal with process definitions.
& # + #+! *4! %!$
In [Fow05] Martin Fowler presents as his term for a class of
tools that viably realize . Language Oriented
Programming is then presented as “general style of development which operates
about the idea of building software around a set of domain specific languages
(DSLs).” As examples of Language Workbenches are mentioned Microsoft’s Software
Factories or JetBrains’ Meta Programming System. Only some ideas in MDA are seen
compatible with the notion of Language Workbenches, nevertheless the author does
not state which ones.
Language Workbenches are expected to “improve programmer productivity by giving
them better tools for the job” and “improving the productivity of development by
forging a closer relationship with domain experts by allowing domain experts more
opportunity to contribute directly to the development base.“ Properties of a
Language Workbench based on Fowler are the following:

• Users can freely define new languages which are fully integrated with each
other.
• The primary source of information is a persistent abstract representation.
• Language designers define a DSL in three main parts: schema, editor(s), and
generator(s).
• Language users manipulate a DSL through a projectional editor.
• A language workbench can persist incomplete or contradictory information in
its abstract representation.
There are three parts that need to be defined for a new DSL:
• 4$ # 6 #3 – basic structure of the language (schema of the abstract
representation).
• – that lets users manipulate the abstract syntax through a projection.
A DSL may have one abstract syntax and several editors (concrete syntaxes).
• ! ! # < that defines translation of the abstract representation into an
executable representation.
The key point of language workbenches is that they see the abstract representation
of a DSL as the primary representation of the “source” code as shown in Figure 2.3.
The abstract representation may be stored, generated into an executable
representation, or projected to one of possible editable representations. Editable
representations are purely transient and their purpose is only helping human users.
Figure 2.3: Manipulating Representations with a Language Workbench
Only one relevant part may be edited at a time and each projection may be focused
on different aspects. Graphical projection may focus on the structure and projection
into form;based editors may focus on details. The editable representation is no more
only textual.
Notion of MDE platform is very close to the notion of a language workbench, the
only difference is that in language workbenches models and metamodels are not
explicitly mentioned. Nevertheless, even there models and metamodels do exist.
store
generate
storage
representation
executable
representation
editable
representation
projection
abstract
representation

' !" /! % ! !
The latest definition of MDA was approved by ORMSC plenary session in 2004
[MDA04]:
“MDA is an OMG initiative that proposes to define a set of non;proprietary standards
that will specify interoperable technologies with which to realize model;driven
development with automated transformations. Not all of these technologies will
directly concern the transformations involved in MDA.
MDA does not necessarily rely on the UML, but, as a specialized kind of MDD (Model
Driven Development), MDA necessarily involves the use of model(s) in development,
which entails that at least one modeling language must be used. Any modeling
language used in MDA must be described in terms of the MOF language, to enable
the metadata to be understood in a standard manner, which is a precondition for
any ability to perform automated transformations.”
MDA was first presented within OMG by Richard Soley and the OMG Staff Strategy
group in the end of the year 2000 [Sol00]. OMG then formed a team to produce a
more formal statement on MDA, which resulted in a more formal but still incomplete
definition presented in [MDA01] and MDA was officially unveiled by OMG. Detailed
definition of the architecture was then presented in the mid;2003 in the MDA Guide
Version 1.0.1 [MDA03]. Final version is still being expected. In parallel, UML and
MOF were developed from initial version adopted in 1997 to version 2.0 adopted in
2003 and updated in 2004.
The MDA Manifesto [BBI04] declares the foundations of MDA in the following way:
“In essence, the foundations of MDA consist of three complementary ideas:
1. ! !, !$! # . Shift the focus of software development away from the
technology domain toward the ideas and concepts of the problem domain.
Reducing the semantic distance between problem domain and representation
allows a more direct coupling of solutions to problems, leading to more
accurate designs and increased productivity.
2. .# . Use computer;based tools to mechanize those facets of software
development that do not depend on human ingenuity. One of the primary
purposes of automation in MDA is to bridge the semantic gap between
domain concepts and implementation technology by explicitly modeling both
domain and technology choices in frameworks and then exploiting the
knowledge built into a particular application framework.
3. ,! $ # # $. Standards have been one of the most effective boosters of
progress throughout the history of technology. Industry standards not only
help eliminate gratuitous diversity but they also encourage an ecosystem of
vendors producing tools for general purposes as well as all kinds of
specialized niches, greatly increasing the attractiveness of the whole endeavor
to users. Open source development ensures that standards are implemented
consistently and encourages the adoption of standards by vendors.”
The MDA Manifesto [BBI04] acknowledges the complexity of UML and MDA, but
argues that complex tools are needed “to deal with the variability and complexity of
the real world”. UML incorporates best practices derived from several decades of
experience and it is expected that designers of domain specific languages “can

greatly benefit by building on top of such a rich base, rather than by recreating it
individually by trial and error.” Nevertheless, one may argue that one thing is
reusing the available knowledge and having to use a language with all that
knowledge is another.
MDA is OMG;specific realization of the broader MDE principles. OMG does not
recognize notion of MDE (Model Driven Engineering) and instead uses its own term,
MDD (Model Driven Development). Both MDA and MDD are OMG trademarks. OMG
realizes MDE principles around the following standards:
• MOF – metametamodel for definition of metamodels.
• UML – general purpose modeling language for modeling software systems.
• CWM – language to specify the design and use of a data warehouse.
• QVT – model transformation language.
• XMI – mapping to XML technological space.
• JMI – mapping to the Java technological space.
• CMI – mapping to CORBA technological space.
MDA is built around UML [UML04], [UML05] and MOF [MOF04], and targets reuse of
existing UML tools by means of UML profiles. UML profiles may be used in cases
when UML is not sufficient for representing a given problem. As presented in
[ABD05], a profile defines virtual UML subclass by associating stereotypes, tag
definitions, and constraints to provide some additional meaning to UML basic
elements. A stereotype provides a way of defining virtual subclasses of UML
metaclasses with additional semantics. It may define tags with additional properties
as well as additional constraints over its base metamodel class. A constraint is a
semantic restriction represented as a text expression. It can be specified using the
OCL [OCL05].
MDA recognizes three types of models: platform independent (PIM), platform
specific (PSM), and platform description (PDM). Platform is seen as a particular
implementation technology. System is always specified on the platform independent
level in a PIM and a PSM is generated from it by an automatic transformation. Each
platform is expected to have its PDM and a set of transformers that accomplish the
transformation from PIM to PSM. For each platform there is a direct mapping from
the PSM to the given platform’s program code and thus the PSM is used to
automatically generate the system implementation.
'
“The Meta Object Facility (MOF) is an adopted OMG standard that provides a
metadata management framework, and a set of metadata services to enable the
development and interoperability of model and metadata driven systems. Examples
of these systems that use MOF include modeling and development tools, data
warehouse systems, metadata repositories etc. A number of technologies
standardized by OMG, including UML, MOF, CWM, SPEM, XMI, and various UML
profiles, use MOF and MOF derived technologies (specifically XMI and more recently
JMI which are mappings of MOF to XML and Java respectively) for metadata;driven
interchange and metadata manipulation.” [MOF04]
Use of MOF is demonstrated on a four;layer metamodel architecture, but it is argued
that MOF as a fundamental concept may be used to handle any number of meta;
layers. The MOF metamodeling stack contains the following four layers:

• ' #6! < ! #.! #. !"
There is one unique metametamodel at the M3 layer and it is conformant to
itself. It means that here the layers stop and that no other metamodel is used
to define MOF.
• #6! < ! #. !"
This layer contains all metamodels used to define modeling languages (DSLs).
Metamodels defined at the M2 layer conform to the metametamodel at the
M3 layer. UML is located at this layer.
• #6! < !"
Each model is defined in the language of its unique metamodel and thus
models in M1 confirm to their respective metamodels in layer M2. UML
models are located at this layer.
• 2 #6! < !#" "
Systems located at this layer are represented by models at the M1 layer.
Figure 2.4: Simplified Version of the EMOF Metametamodel
MOF 2.0 comes with two flavors: EMOF (Essential MOF), shown in Figure 2.4 and
CMOF (Complete MOF). EMOF provides the minimal set of elements required to
model object;oriented systems, whereas CMOF is the metamodel used to specify
other metamodels such as UML 2.0.” [MOF04]

' ;
“EMF is a modeling framework and code generation facility for building tools and
other applications based on a structured data model. From a model specification
described in XMI, EMF provides tools and runtime support to produce a set of Java
classes for the model, a set of adapter classes that enable viewing and command;
based editing of the model, and a basic editor. Models can be specified using
annotated Java, XML documents, or modeling tools like Rational Rose, then
imported into EMF. Most important of all, EMF provides the foundation for
interoperability with other EMF;based tools and applications“. [EMF]
EMF framework is closely tied to UML and MOF and therefore it is presented here in
the MDA section. EMF framework includes its own metamodel, ECORE, which is used
for describing models and runtime support for models. The runtime support
includes notification, persistence, API for generic manipulation of EMF objects, and
XMI serialization. The ECORE metamodel shown in Figure 2.5 is self;describing and
is said to be compliant with MOF. ECORE is being used within EMF also as its
metametamodel.
Figure 2.5: Simplified Version of the ECORE Metametamodel

Apart from the core framework EMF also consists of EMF.Edit framework and
EMF.Codagen code generation facility [EMF]. The framework includes
generic reusable classes for building editors for EMF models. It provides [EMF]:
• “Content and label provider classes, property source support, and other
convenience classes that allow EMF models to be displayed using standard
desktop (JFace) viewers and property sheets.
• A command framework, including a set of generic command implementation
classes for building editors that support fully automatic undo and redo. “
“ !+! , the EMF code generation facility, is capable of generating everything
needed to build a complete editor for an EMF model. It includes a GUI from which
generation options can be specified, and generators can be invoked. The generation
facility leverages the JDT (Java Development Tooling) component of Eclipse. Three
levels of code generation are supported:
• !" ; provides Java interfaces and implementation classes for all the
classes in the model, plus a factory and package (metadata) implementation
class.
• #, ! $ ; generates implementation classes (called ItemProviders) that
adapt the model classes for editing and display.
• ; produces a properly structured editor that conforms to the
recommended style for Eclipse EMF model editors and serves as a starting
point from which to start customizing.
All generators support regeneration of code while preserving user modifications. The
generators can be invoked either through the GUI or from a command line.” [EMF]
EMF recognizes need for editors to be created for editing models compliant to
different metamodels. Editors are being assembled from reusable component,
nevertheless the metamodels are not used to dynamically configure the editors and
therefore much more time is needed to assemble an editor for a given metamodel.
& $ ( "$ ( .# ,! ( # + #+!$
“The Microsoft Tools for Domain;Specific Languages is a suite of tools for creating,
editing, visualizing, and using domain;specific data for automating the enterprise
software development process” [MSDSL]. Released in the late 2005, these tools were
inspired by the vision of software factories first introduced in [GS03] and extend on
the Microsoft’s notion of Domain Specific Modeling (DSM), which may be considered
as a specific realization of MDE principles. Comparison between OMG MDE and
Microsoft DSM is provided by Microsoft in [Coo04]. DSM is not based on UML and
promotes extensive use of small focused DSLs and aims to provide environment
where these languages may be created and their models maintained (a metaCASE
tool). Models are strongly tied to program code and support for reverse engineering
and synchronization is considered. The MS/DSL toolset relies on Microsoft
technologies.
Based on the introduction walkthrough provided with the tools [MSDSL], the suite of
tools is supported by a code framework that makes it easier to define domain
models and to construct a custom graphical designer hosted in Visual Studio.

The suite consists of:
• , A! 5 9# for creating a fully configured solution in which a domain
model may be defined that consists of a designer and a textual artifact
generator. Running a completed solution from within Visual Studio opens a
test solution in a separate instance of Visual Studio, allowing the designer
and artifact generator to be tested.
• + #,% #" !$ + ! for defining and editing domain models.
• B ( .# ( !# + !$ + ! !( $, from which the code for
implementing designers is generated (no manual coding needed).
• $! ( ! +! ! # $, which take a domain model definition and a
designer definition as input, and produce code that implements both of the
components as output. The code generators also validate the domain model
and designer definition, and raise errors and warnings accordingly.
• ( #.!5 * ( !( + !.,"# !>4#$! # (# +! ! # $, which takes
data (models) conforming to a domain model as input, and outputs text
based on the template. Parameters in the template are substituted using the
results of running a C# script embedded in the template.
Figure 2.6: Simplified Version of the MS/DSL Metametamodel
Figure 2.6 presents a simplified version of the MS/DSL metametamodel taken from
[BHJ05]. The FAQ provided with the MS/DSL toolset [MSDSL] highlights that a
family of related purpose;built metamodels, such as “Application Design DSL”, will
be used with well;defined mappings between them and other development artifacts.
The FAQ provides also the following recommendations [MSDSL]:
UML and UML;based tools are recommended for:
• Sketching
• White boarding
• Documentation
• Conceptual drawings that do not directly relate to code
Precisely defined DSLs and DSL;based tools are recommended for:
• Precise abstractions from which code is generated.

• Precise abstractions that map to variation points in frameworks and
components.
• Precise mappings between DSLs.
• Conceptual drawings that have precisely specifiable mappings to other DSLs
or to code artifacts.
"#$ !" # #+!.! % ! !
Atlas Model Management Architecture [AMMA] is a new generation model
engineering platform that was proposed as a conceptual architecture intended to
bridge the gap between MDE principles and their implementation. The AMMA
platform is implemented on top of the Eclipse/EMF framework [EMF]. AMMA
metamodels confirm to the ! !" ! # ! #> !" ? '@ [KM3]. Based on
[BJT05], AMMA is based on four blocks providing a set of model processing facilities:
• The "#$ # $( .# # + #+! ? @ is a model transformation
language [ATL] having its abstract syntax defined using a metamodel. An ATL
transformation accepts a source model Ma (conforming to a metamodel MMa)
and produces a target model Mb (conforming to MMb) by means of a
transformation Mt that conforms to ATL semantics.
• The "#$ !" !#/! ? @ [AMW] enables designers to perform model;
weaving operations between either models or metamodels. Weaving
operations aim to specify the links, and their associated semantics, between
elements of source and target models. AMW may enable creation of variable
mapping languages dedicated to specific application requirements. Model
weaving is described for example in [BJV04a, DBJ05, ABD05]. Common
weaving use cases are: data exchange, data integration, model merging,
model adaptation. A weaving model may be used as input or specification for
a transformation language.
• The "#$ !+# !" # #+!.! ? '@ [AM3] is an environment for
dealing with models and metamodels, together with tools, services and other
global entities, when considered as a whole. AM3 is related to the notion of
megamodel and provides practical support for modeling in large. The
megamodel may be seen as some kid of registry recording all available
resources (e.g. models, transformations, tools, services, etc.) and associated
metadata in a given scope.
• The "#$ ! % #" ) A! $ ? )$@ define a set of injectors and extractors,
which can be seen as import and export facilities between the model
engineering Technological Space (TS) [KBA02] and other TSs (Databases, Flat
files, XML, EBNF, etc).
!" !#/ +
This section presents model weaving in further detail, because it could be
considered as one of the most interesting attributes of AMMA and it will definitely
be an essential part of future MDE platforms. Model weaving is a generic model
management operation to create mappings between complex models. The mappings
are defined in a model called “weaving model” and generally define a set of links
(correspondences) between elements of two models that are being weaved. Since

the weaving model is a real model, it also has a metamodel, which is explicitly used.
This well corresponds with the MDE notion of everything being a model. Model
weaving expects use of different weaving metamodels in different situations.
Model weaving is a useful solution to various data or model mapping problems, such
as mapping metamodels of different metametamodels, mapping models of different
metamodels, or even providing flexible means for enabling data integration from
heterogeneous or legacy data sources.
Figure 2.7: Basic Weaving Metamodel
Figure 2.7 shows a weaving metamodel taken from [DBJ05a]. The metamodel is
basic because it offers only a minimal set of mapping abilities. The basic metamodel
may be extended as needed in a given situation and creation of a dedicated
mapping language is possible (i.e. concatenations, substring, mapping functions,
conditions, etc. may be added).
Model weaving is understood to be mostly non;automatic operation performed by a
human operator where experience and heuristics are being applied to solve the
particular mapping problem. The specific weaving models are created in a modeling
environment that offers the mapping capabilities based on a specific weaving
metamodel. The weaving metamodel should enable partial or full generation of the
corresponding modeling environment and it should be possible to generate useful
outputs from the weaving models, such as operational mappings in different
transformation languages.
With respect to transformation languages, model weaving means defining how to
transform one model to another. The difference is that the weaving model has a
metamodel dedicated to the particular mapping problem, whereas a transformation
language has a fixed metamodel. [DBJ05] provides more exact definition of what
model weaving really is and also nicely introduces its context. Figure 2.8
demonstrates the following definitions graphically.
• !" is a directed graph ! " #$ %&. The set of vertices $ denotes model
elements. A model element from $ has an identifier and a value. The set of
labeled edges % denotes associations between model elements.

• ! #. !" is a special kind of model that specifies the structure of a model.
A model conforms to a metamodel. Given a model ' " #$ %& and a
metamodel '' " #$( %(&, for every model element ∈$, there is an outgoing
edge to an element ∈$(, labeled as Meta edge. We denote it by
' # &.
• ! #.! #. !" is a metamodel defining the base structure for all
metamodels and models within a specified context. A metametamodel
confirms to itself.
• !" # $( .# ) is an operation that given a set of input models
#'* + ' &, evaluates them and returns a set of output models # '* +
' &. A transformation may be denoted by ' , called a transformation
model. Transformation model confirms to a transformation metamodel.
• !#/ + . !" represents correspondences in terms of its model elements.
Let '* " #$ %& and ', " #$( %(& be distinct models. Given elements *∈$
and ,∈$(, the correspondence # * ,& is denoted by a triple # * ' ,&,
where ' " #$ % & is a weaving model. The structure of a weaving model
is defined in a weaving metamodel.
• !" 5!#/ + is a generic operation that takes as input a set of models
#'* + ' &, a weaving metamodel '' and returns a weaving model ' .
Model weaving may be defined in terms of model transformations. After the
operation execution, the models #'* + ' & are woven models.
Figure 2.8: Model Weaving Example
[ABD05] provides several examples of using model weaving to bridge different
domain;specific modeling languages. The author argues that the problem is very
complex and hard but solutions need to be sought, because support for migration of
different models conformant to different metamodels is essential in MDE. The need
for sound model weaving will be further multiplied by the growing number of DSLs,
the small and well focused modeling languages. Further, model weaving will be
needed also for dealing with the legacy of models produced in different versions of
modeling languages such as UML and its various profiles.
MMM
MMa MMb
MMw
Ma1
Man
Mb1
Mbn
T1
Tn
Mw conforms to
model
weaving
transforms
conforms to

' < ! !" ! # ! # !"
KM3, the Kernel MetaMetaModel [KM3], provides a simple textual concrete syntax
that eases the coding of metamodels. KM3 notation has some similarities to the Java
notation and its files (.km3) may be transformed into XMI [XMI03] and used in MOF;
based environments, such as EMF [EMF] or AMMA [AMMA]. This is possible mainly
because KM3 is very close to ECORE and EMOF 2.0. Figure 2.9 presents the KM3
metametamodel taken from [KM3].
Figure 2.9: KM3 Metametamodel
To demonstrate KM3, a sample metamodel was selected from samples provided at
GMT [GMT]. The following sample shows a simple metamodel defined in KM3 for a
subset of XML (Extensible Markup Language). Author of the sample is Peter
Rosendal.
package XML {
abstract class Node {
attribute startLine[0;1] : Integer;
attribute startColumn[0;1] : Integer;
attribute endLine[0;1] : Integer;
attribute endColumn[0;1] : Integer;
attribute name : String;
attribute value : String;
reference parent[0;1] : Element oppositeOf children;
}
class Attribute extends Node {}

class Text extends Node {}
class Element extends Node {
reference children[*] ordered container : Node oppositeOf parent;
}
class Root extends Element {}
}
package PrimitiveTypes {
datatype Boolean;
datatype Integer;
datatype String;
}
KM3 is only a notation and its meaning is presented very vaguely and shortly. KM3
includes only limited modeling capabilities and includes no mechanism for
constraining the models.
0 !"> !+ # ! ., +
“Model;Integrated Computing (MIC) has been developed over two decades at ISIS,
Vanderbilt University for building a wide range of software systems. MIC focuses on
the formal representation, composition, analysis and manipulation of models during
the design process. It places models in the center of the entire life;cycle of systems,
including specification, design, development, verification, integration, and
maintenance.” [MIC]
MIC is one of the earlier realizations of the more general concept of MDE (Model
Driven Engineering) and it was fully introduced in [Nor99]. MIC uses domain specific
models to represent system, its environment, and their relationships. The models are
then used to automatically synthesize the embedded applications and generate
inputs to common analysis tools such as model checkers or simulators [LBM05]. The
authors argue that the MIC approach “speeds up the design cycle, facilitates the
evolution of the application and helps system maintenance, dramatically reducing
costs during the entire lifecycle of the system.”
MIC recognizes the need for a configurable modeling environment with support for
many widely different domain;specific modeling languages. Configurability is needed
mainly because it would be cost;prohibitive to fully re;implement model editors,
checkers, and synthesis components for each of the languages separately. MIC
allows for configurability of the modeling environment through metamodels
specifying the modeling paradigm of the application domain. Metamodels are then
used to automatically generate the MIC modeling environment for the given domain.
The same mechanism is also being used to generate the modeling facilities for
defining the metamodel itself.
Models are stored in model databases and are used as inputs to automatic
generation of applications or to synthesize inputs to different analysis tools. The
approach has been used to create and deploy large;scale systems.
The ! ! !" + / .! ? @ is a configurable toolkit for creating
domain;specific modeling and program synthesis environments. GME is configurable
by metamodels and it is the primary MIC development tool. GME supports its own
metamodeling language based on UML class diagrams with class stereotypes and
OCL constraints called MetaGME [ES04]. MetaGME metametamodel based on
[LBM05] is shown in Figure 2.10.

Figure 2.10: Simplified version of the MetaGME metametamodel
The meanings of the stereotypes used in MetaGME are [ES04]:
• !"$ are compound objects which are visualized in GME as containing
other model elements.
• .$ are elementary objects which are not visualized in GME as containing
other model elements.
• >$ are first;class objects which must be abstract but can serve as the base
type of an element of any other stereotype.
• !(! ! !$ correspond to pointers in an object;oriented programming
language.
• ! $ are analogous to UML Association Classes.
• $,! $ provide logical visibility partitioning to present different views of a
model.
“The GME modeling paradigm contains all the syntactic, semantic, and presentation
information regarding the domain; which concepts will be used to construct models,
what relationships may exist among those concepts, how the concepts may be
organized and viewed by the modeler, and rules governing the construction of
models. The modeling paradigm defines the family of models that can be created
using the resultant modeling environment." [GME]
GME is being extended to support also other metamodeling languages, such as MOF;
nevertheless, the MetaGME remains the language of choice for most of the current
GME users.
Based on [LBM05] the further development of MIC must focus on improving support
for management of large and complex models and support for large;scale
development projects. [LBM05] identifies two key features that are lacking in
available tools: “(1) distributed, simultaneous multi;user access to the models and

(2) model versioning.” The author offers a solution to the problem, which is based
on using a regular version control system to store models at relatively fine
granularity in XML files. Advantages of such an approach are: support for multiple
users; good access control; past versions are available; and there are only minor
model builder tool changes needed. The biggest challenge remains the impact of
changes in one model on other models.
- "" 6 !" + # + #+!
Alloy is a first;order relational logic for describing structural properties of systems
and their invariants that was developed by MIT Software Design Group and was
formally introduced in [Jac02]. It is a lightweight modeling language with simple
and uniform mathematical semantics, easy syntax, and importantly, it is amenable
to efficient and fully automated semantic analysis. Alloy is a relational logic, because
its values and expressions denote relations and are composed together using
relational operators. Relations consist of tuples whose elements are atoms, but
never relations, which makes the logic first;order and analyzable. In fact, Alloy is very
close to standard first;order logic. Alloy is also an executable declarative language,
because it may be used to express behavior of systems by describing the
relationship between the states before and after execution of a procedure.
This section has been compiled from various diversely focused sources and presents
fundamental concepts behind the Alloy modeling language. [Jac02] presents Alloy as
lightweight modeling notation, provides syntax, type rules, and semantics for its
kernel, and relates it to UML and Z. [Jac04] provides complete language reference of
Alloy 3.0 modeling language. [Jac05] overviews Alloy, its history and the key ideas
behind it. [JSS01] shows how signatures enabling a simple mechanism for
structuring specifications were introduced to Alloy. [EJT04] presents Alloy syntax
and semantics with full description of Alloy type system including inference rules for
bounding types and relevance types. [Tor04] provides formal description of Alloy
including semantics of expressions and formulas, type inference rules, and type
reduction rules. [GMB04] presents basic laws that state properties about Alloy
signatures, relations, facts, and formulae, and provide axiomatic semantics for Alloy
that clarify the meaning of its constructs, with the aim to provide powerful guidance
on the derivation of complex transformations, such as refactorings and
optimizations.
Significant amount of work has been done in the area of software quality, where
Alloy has been used as the target language that enabled analysis of software
designs. [BA05] is concerned with quality of mission critical enterprise and uses
Alloy to analyze translated UML class diagram refined from an implementation
technology independent model of web application. [Vaz04] shows how structural
specifications may be used as an invaluable tool for finding bugs in software
systems and presents technique based on Alloy modeling language. [Sch03] uses
Alloy in his framework to model organizational control principles. [MGB04] shows
how UML class diagrams translated into Alloy may be analyzed by Alloy Analyzer.
[MGB05] provides semantics for UML class diagrams by translation to correspondent
Alloy models.
With its elegance and clear focus on the problem of describing structure of systems
and constraints placed on them, Alloy is very suitable language for pragmatic
exploration of software requirements. It has been suggested by [Hut04] and others
that Alloy is highly suitable for educational purposes in place of more heavy;weight

and unfocused modeling languages. Key Ideas behind Alloy modeling language
follow:
• /! 6 % + $ # !"#
All values are represented as relations and Alloy does not differentiate
between scalars, tuples, and sets, but treats them the same:
{(A),(B)} sets of atoms are unary relations
{(A)} scalars are singleton unary relations
{(A,B)} tuples are n;ary relations
Where atom A, tuple containing it (A), and a set containing it {(A)}, are all
considered identical.
• ) ! " +
Alloy has no special syntax or semantics for state machines and uses
constraints for describing:
o Subtypes and classification
o Declarations and multiplicity
o Invariants, operations, and traces
o Assertions, including temporal
o Equivalence under refactoring
• ! !3#.,"!$ # $ ,!
Alloy models may be analyzed in a defined scope, where each basic type is
limited to a certain number of instances to be used in test instances. Within
the defined scope, all possible instances are analyzed. Most bugs are expected
to be caught based on the “small scope hypothesis”, which assumes that
many bugs have small counterexamples. It is suggested that this approach
discovers much larger amount of bugs than regular testing that covers only
few possible cases.
• #"6$ $ 46
Satisfiability (SAT) solvers are universal constraint solvers. When a problem
could be reduced to SAT it can be analysed. Alloy modeling language was
designed to be translatable to SAT and thus SAT solvers may be used to
analyze Alloy models.
- "!.! $ ( # "" 6 . !"
An Alloy model may be structured into simple modules that split specifications into
reusable pieces. Each module contains a sequence of paragraphs that are used to
define basic types, constrains, or commands. The running example provided with
explanations of the respective paragraphs was originally created by Daniel Jackson
as a toy model of genealogical relationships and is being distributed with Alloy
Analyzer.
• + # !$
Signatures define the “universe of discourse” and describe the data values
that one wants to reason about. A signature paragraph defines a basic type
and a collection of relations called fields. Relations represent sets of tuples of
atoms of basic types and no distinction is made between relations and
attributes. Relation declarations constrain the values that are related. An
atom is a typed entity that is indivisible, immutable, and uninterpreted (has
no meaning associated with it). Atoms represent real world entities or system
properties.

Signatures may be abstract and extend existing signatures. The extension
feature allows structures to be developed incrementally, but does not rely on
subtyping nor textual inclusion. Limits may be placed on the resulting set of
instances of a basic type:
; lone: zero or one
; one: exactly one
; some: one or more
Signatures are declared using the keyword $ +:
$ + S { f: E }
where S is name of the basic type and f relation to type E. If there is some x
that has type S, then the expression x.f will have the type E. It is possible
because interpreting fields of structures as relations allows relational
operators to be used for dereferencing.
#4$ # $ + Person {spouse: lone Person, parents: set Person}
$ + Man, Woman !3 ! $ Person {}
! $ + Eve extends Woman {}
! $ + Adam extends Man {}
The above statements show introduction of abstract basic type Person that
may or may not have one spouse and set of other people as parents. Man and
Woman are basic types that extend Person, such that each person is either
Man or Woman. There is also one particular woman, Eve, and one particular
man, Adam.
• # $
A fact may explicitly restrict relationships and limit the possible values that
they may contain. Facts must hold for all instances of a model, which means
that no instance will violate a fact. Conflicting facts may result in over;
constrained model, which has no possible instances of affected basic types.
Following are the sample facts provided with the genealogy example:
(# Biology {
;; nobody is his or her own ancestor
p: Person | p p.^parents
}
(# Bible {
;; every person except Adam and Eve has a mother and father
#"" p: Person ; (Adam + Eve) | ! mother: Woman, father: Man |
p.parents = mother + father
;; Adam and Eve have no parents
(Adam + Eve).parents
;; Adam's spouse is Eve
Adam.spouse = Eve
}
(# SocialNorms {
;; nobody is his or her own spouse
p: Person | p.spouse = p
;; spouse is symmetric
spouse = ~spouse

;; a man's spouse is a woman and vice versa
Man.spouse Woman && Woman.spouse Man
}
(# NoIncest {
;; can't marry a sibling
p: Person | $ .! p.spouse.parents & p.parents
;; can't marry a parent
p: Person | $ .! p.spouse & p.parents
}
• $$! $
Assertions check whether a model satisfies specific constraints, but do not
restrict its possible instances. They are statements (conjectures, hypotheses)
that are intended to follow from the facts and are expected to hold in a well
behaved system. Analyzer may be used to generate counterexamples of
unsatisfied assertions. Nevertheless, if assertion has no counterexamples
doesn’t mean that it holds. It only means that it cannot be falsified within the
given scope. The idea of explicit assertion is taken from Larch, where special
formulas are added purely for checkable redundancy.
#$$! IndirectIncestPossible {
;; a parent may be second parent's child
p: Person | $ .! p.parents.parents & p.parents
}
The above assertion expects that there would be no person who’s parent is
also its grandparent. This assertion will produce a counterexample shown
below since the NoIncest fact prohibits only direct incest.
• ) ! # !$ # ( $
Predicates are reusable constrains, where the body is a formula and the
return type is true or false. Functions are reusable expressions with a specific
return type. Both functions and predicates can by applied with a set of typed
parameters.
, ! Show() {
$ .! p: Person ; (Adam + Eve) | $ .! p.spouse
}
The above predicate requires there to be some person p, but not Adam or Eve
that has some spouse. This predicate is useful to visualize a sample instance
of the model. The instance shown will satisfy the predicate. If the constraint
would not be possible within the model, no instance would be provided.
• ..# $
Run command may be used to generate sample instances of a given
predicate. Check command may be used to generate counterexamples of an
assertion.
Show ( 6
%! * IndirectIncestPossible ( 6
The above run command executes the Show() predicate and produces a
sample instance if possible (i.e. if there is some that satisfies the predicate
within the given scope of six initial instances of each basic type). In this case

Alloy Analyzer created sample instance shown in Figure 2.11. The check
command produced a counterexample to the IndirectIncestPossible assertion.
The counterexample is shown in Figure 2.12.
Figure 2.11: Sample Example Generated by Alloy Analyzer
Figure 2.12: Sample Counterexample Generated by Alloy Analyzer
The Alloy modeling language takes most operators from standard first;order logic,
extends the possible quantifiers, and introduces its own relational operators. Only a

short overview of Alloy operators and quantifiers is shown here. Full Alloy reference
manual is available from [Jac04]. Formal semantics of constructs that are part of the
Alloy kernel are shown in the following section. Meaning of constructs that are
extensions of the kernel are presented in [Jac02] or elsewhere.
• ! ,! # $
union p + q {t | t∈p ∨ t∈q}
difference p – q {t | t∈p ∧ t∉q}
intersection p & q {t | t∈p ∧ t∈q}
subset p in q {(p1, … pn)∈p} ⊆ {(q1, … qn)∈q}
equality p = q {(p1, … pn)∈p} = {(q1, … qn)∈q}
cardinality #p number of elements of set p
• !"# #" ,! # $
product p ;> q
join p.q
transpose ~p
transitive closure ^p
reflexive t. c. *p
override p ++ q
domain restriction q <: p
range restriction p :> q
identity relation iden
• + ,! # $
negation !F not F
conjunction F && G F and G
disjunction F || G F or G
implication F => G F implies G
bi;implication F <=> G F when G
• 7 # ( ! $
universal all x: e | F F is true for every x in e
existential some x: e | F F is true for some x in e
non;existential no x: e | F F is true for no x in e
at most one lone x: e | F F is true for at most one x in e
exactly one one x: e | F F is true for exactly one x in e
- "" 6 6 #3 # !.# $
Alloy is based on a tiny kernel language that is given formal semantics. Semantics of
the full language is then defined by translation to the kernel [Jac02]. The semantics
were influenced by the architecture of the Alloy Analyzer tool, which required every
expression and formula to have a formal meaning (denotation).
Alloy expresses statements using only ASCII characters, which makes it usable in
plain text editors and makes it significantly differ from other specification languages,
often heavily reliant on special mathematical characters. Authors of Alloy argue that
if something is mathematical it is not about Greek symbols but rather about
simplicity and analyzability. Thus even formal modeling language, like Alloy, may be
crated simple, easy to use. The real perceived challenge, nevertheless, is the
abstraction.

A DISSERTATION SUBMITTED IN PARTIAL FULFILLMENT OF THE REQUIREMENTS FOR THE DEGREE OF DOCTOR OF PHILOSOPHY

A DISSERTATION SUBMITTED IN PARTIAL FULFILLMENT OF THE REQUIREMENTS FOR THE DEGREE OF DOCTOR OF PHILOSOPHY

Recommended

Recommended

More Related Content

Similar to A DISSERTATION SUBMITTED IN PARTIAL FULFILLMENT OF THE REQUIREMENTS FOR THE DEGREE OF DOCTOR OF PHILOSOPHY

Similar to A DISSERTATION SUBMITTED IN PARTIAL FULFILLMENT OF THE REQUIREMENTS FOR THE DEGREE OF DOCTOR OF PHILOSOPHY (20)

More from Jim Jimenez

More from Jim Jimenez (20)

Recently uploaded

Recently uploaded (20)

A DISSERTATION SUBMITTED IN PARTIAL FULFILLMENT OF THE REQUIREMENTS FOR THE DEGREE OF DOCTOR OF PHILOSOPHY