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 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
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
17. Meta-model
A meta-model defines concepts
and their relationships thanks to
a class diagram
A meta-model only defines
structure (no semantics)
A model is an instance of a
meta-model if it respects the
structure defined by the meta-
model
The relation between a model
and its metamodel is called
conformance
The UML meta-model defines
the structure that all UML
models must have
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
22. 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. 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)
26. 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
27. 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 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
31. Main Concrete Classes
• The key concrete classes (or meta-metaclasses) of MOF:
- Class
- Association
- Exception (for defining abnormal behaviours)
- Attribute
- Constant
- Constraint
31
32. 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
33.
34. UML Metaclasses used in class, package,
Meta
Element
component and deployment diagrams
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
34
35. A fragment of the UML Meta-Model
not self.isAbstract implies
self.allOperations->forAll(op |
self.allMethods->exists(m |
m.specification includes (op)))
36. 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
37. 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
38. 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
38
39. 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
40. 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
41. 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
42. 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 42
43. 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)
45. 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
47. 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
49. Example GeneralizableElement
Stereotype
{ordered} edge
<<geometry>
LinearShape 1..*
LineSegment
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
50. 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
51. 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
52. 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
53. 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
54. 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
55. 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
56. 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
57. 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
59. 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)
60. 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
61. 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
62. 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
63. 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
64. 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
66. 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)
67. 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
69. 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
70. 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
76. 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
77. 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)
78. 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
79. 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
80. 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
81. 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
81
83. 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)
84. 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 Metamodel CWM: Table, Column
E
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”/>
85. 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
86. 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
87. 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
88. 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?
89. 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
