1. Metamodeling and the
Model Driven Architecture
(MDA)
Paolo Ciancarini

2. Agenda
 Model Driven Engineering
 Metamodeling
 Metamodeling in UML
 Model Driven Architecture
 OMG technologies for MDA

3. Enterprise Computing
 Software is a complex and expensive product
 Enterprise Computing adds further requirements:
 Rapid change in organizational assets
 Continuous evolving partnerships
 Heterogeneous end-user clients
 e.g., Fat clients, Web clients, Cellular Phone, iPod, DTT TV
 Need for information ubiquity
 e.g., in mobile/opportunistic networking, cross-network roaming
 The only thing we can predict with confidence
about the future of software platforms is that things
we cannot predict will happen

4. Motivations
 There is a strong pressure on the industry to
increase
 Quality
 Longevity
 Reusability
of software products, while reducing costs
 In order to fulfill this needs the productivity
of the software industry must be improved
 Most increments in software productivity are
obtained increasing the abstraction level

5. Levels of abstractions
 The history of software development is a
history of raising the level of abstraction
A stack of
• In Programming Languages
Programming Languages
• e.g., Assembler, C, C++, Visual C#, …
• In Software Architectures
3GL
• e.g., Client-Server, n-tier, SOA, …
Assembly • In Operative Systems
Language
• e.g., Virtual Machines, Middleware, Grid
0s and 1s • In data representation
• e.g., File, Database, XML, …

6. Model Driven Engineering (MDE)
 MDE is a software development method for handling the
complexity of software platforms and related problems
 Main feature: “Everything is a model”: the models are first-
class abstractions closer to domains than to algorithmic
ideas and concerns
 A model is a simplified representation of a part (i.e. a
system) of the real world
Model
the modeling space
the real world isRepresentedBy
System

7. MDE: Approaches
 MDE concepts can be applied in different
ways producing different approaches, each
one relying on a specific set of tools

8. Example: EMF
 The Eclipse Modeling Framework (EMF) is a modeling
framework and code generation facility for building
applications based on a structured data model
 From a model specification described in XMI, EMF
produces a set of Java classes for the model, a set of
adapter classes that enable viewing and editing the
model, and a basic editor
 Models can be specified using annotated Java, UML,
XML documents, or modeling tools, then imported into
EMF
 EMF itself provides the foundation for interoperability with
other EMF-based tools and applications

9. Approach
Requirement model:
defines the system in its
environment
Analysis and design
model: defines the
system architecture
Realization model: defines
how the system is built
Code of the system and
configuration artifacts

10. Models represent systems
 A model is a set of statements about some system
under study
 A system S is a delimited part of the world considered
as a set of elements in interaction
 A model M is a representation of a given system S
satisfying the principle of substitutability
 Principle of substitutability: A model M is said to be a
representation of a system S for a given set of questions
Q if, for each question q in Q, the model M will provide
exactly the same answer that the system S would have
provided in answering the same q
 The relation between a model and a system is called
representation of

11. Models and Reality

12. A class diagram
models a set of objects

13. Example with three levels

14. Discuss
 A model which describes a model is
called metamodel
 Metamodels are descriptions of
descriptions: why are they important to
develop software?

15. Genesi, 2:19
So out of the ground the Lord God
formed every beast of the field
and every bird of the air, and
brought them to the man to see
what he would call them; and
whatever the man called every
living creature, that was its name

16. Metamodeling

17. Meta-model
A meta-model defines concepts System
+name
and their relationships thanks to
a class diagram 1
* * *
A meta-model only defines +super
+participate
0..*
Actor Use Case
structure (no semantics) 0..1 +name +name
*
+extend
*
A model is an instance of a
* +include
meta-model if it respects the
structure defined by the meta-
model
PetStore
The relation between a model
Add Order
and its metamodel is called
conformance
Client Buy
The UML meta-model defines
the structure that all UML
models must have

18. Multiple levels of abstractions
b:CustomerOrder
Mike:Customer
c:CustomerOrder
Item=batter Objects (M0)
Id= 12345
Quantity=<5 tons>
Customer CustomerOrder
Model (M1)
id item
quantity
Class Association Meta-Model (M2)

19. System-Model-Metamodel Relations
 The extraction of an element from system S to build a
model M is guided by a meta-model MM
 MM plays the role of “filter” in the selecting from the
system S the elements for building the model M
metamodel
MM
conformsTo
repOf terminal
system S Representation of
model M

20. Exercises
 Describe a metamodel for libraries
 Describe a metamodel for cars
 Describe a metamodel for TV sets
 Describe a metamodel for CRC cards
 Describe a metamodel for Petri Nets

23. Four Layered Architecture
Layer Description Example
Meta-metamodel Defines metamodel metaClass,
metaAttribute,
metaOperation
Metamodel An instance of meta- Class, attribute
Metamodel. Defines a operation, component
model
Model Language for describing an Employee
information domain. Defines
a set of related objects that
represent a concept
User object An instance of the model. :Sally
An example information
domain

24. Metadata architecture

25. OMG Modeling Infrastructure
Meta-Object Facility (MOF)
M3
Instance_of
UML Metamodel
M2
Instance_of
Modeling concepts
M1
Instance_of
User Data
M0
25

26. 4-Layers Metamodeling
 A model, or terminal model, (M1) is a
representation of a real object (in M0)
conforming to a metamodel (M2)
 A metamodel (M2) is a representation of
a set of modelling elements (in M1)
conforming to a meta-metamodel (M3)
 A meta-metamodel (M3) is a set of
modeling elements used to define
metamodels (M2 ed M3) conforming to
itself
N.B. M2, M2 and M3 are all “models”. We could
represent them using the same modeling language
(e.g., UML)

27. Example

28. Meta-metamodel
• A metamodel describes information about models
• A meta-metamodel describes information about
metamodels
• Metamodels defined using the same meta-
metamodel
- can be compared for conformance
- can exchange information
- can be used by the same tools that understand
the meta-metamodel

29. Meta Object Facility (MOF)
• Enables meta-metamodeling of UML level
metamodels
• It defines a small set of concepts (such as
package, class, method, attribute…) that allow to
define and manipulate models of metadata (data
about data)
• All definitions are described using a subset UML
notation

30. MOF
Model
30

31. MOF Key
Abstract
Classes

32. MOF Key Abstract Classes
• ModelElement base Class of all M3-level Classes;
every ModelElement has a name
• Namespace base Class for all M3-level Classes that
need to act as containers
• GeneralizableElement base Class for all M3-level
Classes that support generalization (i.e. inheritance)
• TypedElement base Class for M3-level Classes such
as Attribute, Parameter, and Constant whose
definition requires a type specification
• Classifier base Class for all M3-level Classes that
(notionally) define types; examples of Classifier
include Class and DataType

33. Main Concrete Classes
• The key concrete classes (or meta-metaclasses) of MOF:
- Class
- Association
- Exception (for defining abnormal behaviours)
- Attribute
- Constant
- Constraint
33

34. Key associations
• Contains: relates a ModelElement to the Namespace that
contains it
• Generalizes: relates a GeneralizableElement to its
ancestors (superclass and subclass)
• IsOfType: relates a TypedElement to the Classifier that
defines its type
- An object is an instance of a class
• DependsOn : relates a ModelElement to others that its
definition depends on
- E.g. a package depends on another package

36. UML Metaclasses used in class, package,
Meta component and deployment diagrams
Element
Model
importedElement
ModelElement *
ownedElement
name
*
0..1
0..1
Relationship Feature
Link Comment Namespace Parameter Instance
visibility * GeneralizableElement
{ordered} defaultValue
* isRoot *
* kind
child isLeaf
Generalization * * * {ordered}
* isAbstract
specialization parent
discriminator
Object
type owner
AssociationEnd *
2..* type
connection participant specification Classifier
isNavigable
aggregation * * 1..*
Association multiplicity
0..1
StructuralFeature BehaviouralFeature
multiplicity
Package *
qualifier *
Attribute Operation Method
**
initialValue isAbstract specification body
Model
resident
Class Interface DataType Subsystem Node * Component
deploymmentLocation *
AssociationClass Primitive Enumeration ProgrammingLanguageType
1..*
EnumerationLiteral
36

37. A fragment of the UML Meta-Model
Meta-Class
GeneralizableElement
isRoot : Boolean Feature
isLeaf : Boolean
isAbstract : Boolean visibility : {public, private,
protected}
*
Classifier
Well-formedness constraint (OCL)
not self.isAbstract implies
self.allOperations->forAll(op |
Class self.allMethods->exists(m |
isActive : Boolean
m.specification includes (op)))

38. Model Elements
• An element is an atomic
constituent of a model
Element
• Element is the top metaclass in
the metaclass hierarchy
ModelElement
• A model element is a named
entity in a model name
• It is the base for all modeling
metaclasses in UML
- All other modeling metaclasses are
either direct or indirect subclasses
of ModelElement

39. Features
• Feature is an abstract class Feature
that declares a behavioral or visibility *
{ordered}
structural property of
- an instance of a Classifier
- the Classifier itself owner
Classifier
• A behavioral feature refers to
a dynamic feature of a model StructuralFeature BehaviouralFeature
multiplicity
element
- E.g. operation or method Attribute Operation
**
Method
initialValue isAbstract specification body
• A structural feature refers to a
static feature of a model
element
- E.g. attribute

40. Classifier
• A classifier is an element that describes behavioral and
structural features
- E.g. class, data type, interface, component
• Classifier is an abstract class that
- declares a collection of Features, such as Attributes, Methods…
- has a name, which is unique in the Namespace enclosing the
Classifier
Feature
* Namespace
Classifier
visibility {ordered}
resident
Class Interface DataType Subsystem Node * Component
deploymmentLocation *
Primitive Structure Enumeration ProgrammingLanguageType
1..*
EnumerationLiteral
40

41. Classifier
• A classifier is a generalizable element and defines a
namespace
• It can have
- association ends
- parameters
- instances
Feature
Namespace Parameter Instance
visibility * GeneralizableElement
{ordered} defaultValue
isRoot *
kind
isLeaf
*
isAbstract
Object
* type owner
AssociationEnd
Classifier type
isNavigable participant specification
aggregation * * 1..*
multiplicity

42. Relationship
Relationship
• A relationship is a connection
among model elements Generalization
discriminator
• UML defines several relationships
such as: Association
- Association
- Generalization
• UML defines other types of
relationships that are not shown in
this diagram, such as: Class
- Dependency
- Flow
AssociationClass

43. Namespace
importedElement
• A namespace is a part of a ModelElement
name
*
ownedElement
model that contains a set of *
0..1
0..1
other model elements GeneralizableElement
Namespace
- E.g. Associations and isRoot
isLeaf
Classifiers isAbstract
- the name of an owned
model element is unique Classifier
within the namespace
• Namespace is an abstract Package *
metaclass and it subclasses
are Subsystem Model
- Classifier
- Package

44. Data Types
• UML data types include
- primitive built-in types (such as integer and string)
- definable enumeration types (such as Boolean whose literals are false
and true); enumerations are a user-defined data types whose instances
are literals (specified by the user)
• Programming languages data types
- are specified according to the semantics of a particular programming
language
- are not portable among languages (except by agreement among the
languages)
- do not map into other UML classifiers
DataType
Primitive Enumeration ProgrammingLanguageType
1..
*
EnumerationLiteral 44

45. Namespace
Classifier
Relationship
AssociationEnd
isNavigable
Package aggregation Class
Association multiplicity
BankSystem
Customer 1..2 * Account
accountNumber
StructuralFeature
balance Relationship
multiplicity overdraftLimit
withdraw
Attribute deposit Generalization
initialValue discriminator
BehaviouralFeature
Chequing Saving CreditCard
expiryDate
Method
Mapping of UML Models to
Metamodel Elements (Example)

46. Use Case Diagrams Metamodel

47. Mapping Use Cases Model
to Metamodel Classifier
Classifier
UseCase
Actor
Relationship
Open file Generalization
discriminator
Ordinary User
Open file by Open file by
typing name browsing
Relationship
«extend» «include»
Include
Browse for file
System
Attempt to open file
Administrator
that does not exist
Relationship
Extend

48. State Machines
(Main Metamodel)

49. Mapping State Machines
to Metamodel
State
State
StateVertex
SimpleState 0..1
PseudoState 0..1 +entry
Procedure
Closed Opening
Enter / pressButton Enter /
stop motor run motor forwards
closingCompleted Transition
*
openingCompleted
pressButton
0..1
Closing pressButton Open Event
Enter / Enter /
run motor in reverse stop motor

50. Extension Mechanisms Metamodel

51. Example GeneralizableElement
Stereotype
{ordered} edge
<<geometry>
LinearShape LineSegment
1..*
startPoint: Point
endPoint: Point
length : int
Path Line Polygon {startPoint <> endPoint}
length {edge->size=1} {edge->first.startPoint =
{length = edge->last.endPoint}
edge.length->sum}
RegularPolygon
{edge->forAll(e1,e2 |
e1.length = e2.length)}
Constraint

52. Model Driven Architecture (MDA)
 MDA is a theory of software construction based on a set of
standards provided by the Object Management Group
 MDA is a kind of MDE, that is domain engineering based on
developing models of software systems
 The idea of MDA is to exploit a modeling language (such as
UML) as a programming language rather than just as a
support for design
 This is not a new approach, it has notable ancestors:
 Database schemas, generative programming, CASE
tools, WYSIWYG interfaces

53. MDA Base Components
 MDA is based on a set of technologies that
allow:
 Domain specification (domain specific
languages)
 Modeling and metamodeling
 Model transformations which support the
development of a system independently from:
 platforms
 platforms evolution
 application domains

54. MDA Dimensions
 Horizontal: different domains that are not more or less abstract
than others, like business or technology
 E.g., marketing, engineering, sales, etc.
 E.g., performance, security, fault tolerance etc.
 Vertical: different level of abstraction of the same domain of a
system
 From physical data, logical data models, middleware,
applications specifications, component assemblies, business
process models, business goals and strategies
 Evolutionary: different systems, legacy, ongoing and upcoming,
as-is, as-was and as-could-be
 This is technically similar to the horizontal dimension, but it is
more concerned with evolution-focused architectural rules
and modeling standards

55. MDA: the Big Picture
This picture gives
some insights
about the
technologies
constituting MDA
together with the
platforms, the
kinds of
application and
the domains of
application that it
addresses

56. Key Idea
 create a source model
 independent from platform implementation details
 transform it in a target model richer of details than the
source model
 Use of a proper transformation language

57. Basic Concepts
 Model: a simplified representation of
 a system
 a part of a system
 a set of system functionalities
 Point of view: an abstraction technique with
the goal of highlighting some features of the
system
 View: a representation of the system from the
perspective of a particular point of view

58. Basic Concepts
 Refinement: it is related to a model M1
derived from model M2, where M1 has a
number of details greater than M2
 M1 is a refinement of M2
 Zooming: when we move from a model with a
different level of abstraction than another one
 we have like a zoom-effect
 System architecture: the specification of
 Components
 Connectors
 Interaction rules of components by means of
connectors

59. Basic Concepts
 Model driven: the use of models through all
the phases of software development
 Platform independence: a property of a
model developed regardless of platform
details
 Model transformation: the process of
converting one model into another one
concerning the same system

60. Models, metamodels and platforms

61. MDA: Core Standards
 How do we can specify models, metamodels
and meta-metamodels?
 OMG provides a set of standards supporting
such activities:
 MOF 2.0
 UML 2.3
 XMI 2.0
 CWM 1.1
 QVT (Query View Transform)

62. MOF
 MOF is an OMG standard to write metamodels
 Can be used to model the abstract syntax of
Domain Specific Languages
 Two flavors: EMOF (Essential MOF), CMOF
(complete MOF)
 Kermeta is an extension to MOF allowing
executable actions to be attached to EMOF meta-
models, hence making it possible to also model a
DSL operational semantics and obtain an
interpreter for it

63. Metamodel
 The correspondence between a model and a system is
defined by a metamodel:
 Terminology: a collection of concepts with their properties
and relations
 Assertions: a collection of additional rules by which
terminology elements can be constrained

64. Metamodels in Software Engineering
 Currently, metamodels focus on:
 Software process modeling (PIF)
 Software product modeling (UML, CWM)
 Many new fields are involved:
 Model of cost
 Model of resource consumption
 Models of test, QoS, and software measurements
 Requirements modeling (e.g. Use Cases)
 Know-how modeling (e.g. Patterns)
 Model validation

65. Meta-metamodel
 A Meta-metamodel provides the language to define a
set of metamodels
 Definition of abstract syntax: concepts, relationships, and
wellformedness rules
 Definition of concrete syntax: shapes, layout, and physical
interchange formats
 Definition of semantic domains: the abstract logical space in
which models find their meanings
 Definition of mappings between domains

66. A Metamodel Language: MOF 2.0
 The Meta-Object Facility (MOF) is an OMG
specification defining an abstract language and a
framework for specifying, constructing, managing,
and exchanging, technology-neutral metamodels
 MOF defines a framework for implementing
repositories holding the persistent representation of
the metamodels

67. The MOF Meta-metamodel

68. MOF: Features
 MOF belongs to the MDA architecture
 MOF meta-metamodel defined in itself
 MOF 2.0 reuses a part of the UML 2.0 metamodel
 MOF to XML mapping: OMG XMI (XML Metadata
Interchange) specification
 MOF to Java mapping: JMI (Java Metadata
Interchange)

69. UML 2.0
 UML is a language with a very broad scope covering a
large and diverse set of application domains
 It is structured in two main parts:
 Infrastructure
 Superstructure
 The UML 2.0 metamodel is aligned with the MOF 2.0
meta-metamodel for accomplishing the MDA-vision
 In MDA all the four-layer models are defined by means
of UML or its extensions

70. UML 2.0 Infrastructure
Note: the Core package is the same of the MOF
Meta-metamodel

71. The MDA 4-Layers Architecture (1/2)
 The alignment between UML 2.0 and MOF 2.0
enables to see every UML 2.0 construct like an
instance of a MOF 2.0 element
 In this way, we can see MOF 2.0 like the meta-
metamodel of UML2
 Every UML 2.0 model is an instance of the
UML 2.0 metamodel

72. The MDA 4-Layers Architecture (2/2)
 The UML metamodel stack is instantiated in
MDA by:
 M3: MOF 2.0
 M2: UML 2.0
 M1: An UML 2.0 model at the “class” level
 M0: A “real world” object represented by an UML 2.0
model at the “object” level
 This stack represents the four-layers architecture

73. 4-Layers MDA: an Example

74. 4-Layers Metamodelling Instance

75. UML 1.x Metamodel (1/2)

76. UML 1.x Metamodel (2/2)

77. UML 2.1 Use-Case MOF Metamodel

78. XMI
 XML Metadata Interchange (XMI) is the OMG
technology for interchanging models in a
serialized form
 XMI focuses on the interchange of MOF
metadata
 i.e., metadata conforming to a MOF-based
metamodel
 XMI can also be used for model representation
in model transformations

79. XMI
 XMI uses XML for the transfer syntax and interchange format
 XML Document Type Definitions (DTD) or Schema are specified
to enable the transfer and verification of:
 UML-based models (e.g. mymodel.xmi, using uml.dtd or
uml.xsd)
 MOF-based metamodels (e.g. uml.xmi, using mof.dtd or
mof.xsd)
 Models based on other MOF-based meta-models (e.g.
mymodel.xmi using cwm.dtd or cwm.xsd)

80. CWM
 The Common Warehouse Metamodel (CWM)
is the OMG standard for data warehouse
 CWM is a specification for modeling metadata
for relational, non-relational, multi-dimensional,
and other objects found in a data warehouse
 CWM can be used to extend UML for
 supporting data warehouse environments
 modeling transformations
 structuring transformation specifications
 The goal is to integrate development tools with
data deployment solutions

81. The Metadata Problem
CWM addresses the problems facing any company:
 Many databases
 Many repositories
 Different schemas describing the “same” data
 Moving data requires manual schema
transformation

82. CWM Integrates Data
 CWM integrates existing data models
 Maps to existing schemas
 Supports automated schema generation
 Supports automated database loading
 The basis for data mining and OLAP (OnLine
Analytical Processing) across an enterprise

83. CWM Defines Metamodels
 CWM Foundation  OLAP
 Relational Data  Data Mining
 Record Data  Info Visualization
 Multidimensional Data  Business Nomenclature
 XML Data  Warehouse Process
 Data Transformations  Warehouse Operation
83

84. CWM: Fragment of the Relational Metamodel
/constraint /constrainedElement
CheckConstraint
{ordered}
deferrability : DeferrabilityType * *
Column
/type SQLDataType
* /constrant precision : Integer *
typeNumber : Integer
scale : Integer /structuralFeature 1
0..1 /feature isNullable : NullableType
ColumnSet
length : Integer
/owner * collationName : String
{ordered} characterSetName : String
/ optionScopeColumnSet : NamedColumnSet
/ referencedTableType : SQLStructuredType
NamedColumnSet
/ optionScopeColumn : Column
/ type : SQLStructuredType
/ usingTrigger : Trigger
SQLDistinctType
length : Integer
/constrainedElement
QueryColumnSet precision : Integer
scale : Integer
query : QueryExpression
/ sqlSimpleType : SQLSimpleType
sqlDistinctType *
*
SQLSimpleType
{ordered}
characterMaximumLength : Integer
1 characterOctetLength : Integer
numericPrecision : Integer
sqlSimpleType numericPrecisionRadix : Integer
numericScale : Integer
Table dateTimePrecision : Integer
View
isTemporary : Boolean
isReadOnly : Boolean
temporaryScope : String
checkOption : Boolean
/ trigger : Trigger
queryExpression : QueryExpression
isSystem : Boolean

85. The CWM Metamodel
Operational Data
Warehouses
Extract Transform
Data Sources
Source Target Source Target
Source Target Source CWM Tool Target
Source Target Source Target
Pairwise Hub
(9 connections) Drill Down
(6 connections)

86. OMG Metamodel Architecture
M MOF: Class, Attribute,
I Meta-metamodel Operation,
D Layer (M3) Association
D
L
Standard Components E
W
 Modeling Notation: UML A UML: Class, Attribute
R
 Metadata Interchange: XMI E
Metamodel CWM: Table, Column
Layer(M2) ElementType, Attribute
 Metadata API:
MOF IDL Mapping
JMI – MOF/Java Mapping A
P
P Metadata/Model Stock: name, price
CWM is based on L
I
Layer(M1)
 UML C
A
 MOF T
 XMI I
O
User Data/Object
<Stock name=“IBM”
Layer (M0)
N price=“112”/>

87. The CWM Metamodel (1.0)
Management Warehouse Warehouse
Process Operation
Analysis Data Information Business
Transformation OLAP
Mining Visualization Nomenclature
Object Multi-
Resource (Core+Behavioral+ Relational Record XML
Relationships) Dimensional
Foundation Business Data Keys Type Software
Expressions
Information Types Index Mapping Deployment
Object Model Core Behavioral Relationships Instance

88. Metamodels, Syntaxes and Semantics
 The UML language has been defined by means
of a MOF metamodel
 In order to define a MOF metamodel we can use:
 MOF to (formally) define the abstract syntax of a set of
modelling constructs
 The natural language to (informally) describe some
parts of the semantics
 The concrete syntax can be expressed by a
graphical notation or not
 Example: a UML diagram can be represented in XML
by means of the XMI concrete syntax
 In this case, the XMI file represents the UML diagram

89. Conclusions
 MDA is a powerful family of technologies
 Its basis is metamodeling
 The technology of model transformations
(see next lecture) makes the approach
practical and powerful
 It is important because it allows to manage
automatically the design and maintenance
problems typical of large software systems

90. Self test questions
 What is a model?
 What is a metamodel?
 What is conformance to a metamodel?
 What is MOF?
 What is CWM?
 Which are the main differences between
UML1.x and UML2.x?

91. References
 Schmidt, Model-Driven Engineering. IEEE
Computer, 39:2(25-31), February 2006.
 Frankel, Model Driven Architecture: Applying
MDA to Enterprise Computing, Wiley, 2003
 Mellor, Scott, Uhl, Weise MDA Distilled:
Principles of Model-Driven Architecture,
Addison-Wesley, 2004
 Mellor & Balcer, Executable UML, a foundation
for MDA, Addison-Wesley 2002
 OMG, UML Infrastructure 2.3, 2010

92. Useful sites
 www.omg.org/mda!
 www.ibm.com/developerworks/rational/library/3100.html!
 www.agilemodeling.com/essays/mda.htm!
 martinfowler.com/bliki/ModelDrivenArchitecture.html

93. Interesting tools
 www.eclipse.org/modeling/emf/?project=emf
 www.andromda.org
 www.bluage.com/
 www.openarchitectureware.org
 www.openmdx.org
 www.ibm.com/developerworks/rational/products/rhapsody/

94. Questions?