Metamodeling and the Model Driven Architecture
(MDA) Paolo Ciancarini
Agenda
Model Driven Engineering Metamodeling Metamodeling in UML Model Driven Architecture OMG technologies for MDA
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
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
Levels of abstractions
The history of software development is a history of raising the level of abstraction
• In Programming Languages • e.g., Assembler, C, C++, Visual C#, …
• In Software Architectures
• e.g., Client-Server, n-tier, SOA, …
• In Operative Systems
• e.g., Virtual Machines, Middleware, Grid
• In data representation
• e.g., File, Database, XML, …
A stack of Programming Languages
0s and 1s
3GL
Assembly Language
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
System isRepresentedBy the real world
the modeling space
MDE: Approaches
MDE concepts can be applied in different ways producing different approaches, each one relying on a specific set of tools
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
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
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
Models and Reality
A class diagram models a set of objects
Example with three levels
Discuss
A model which describes a model is called metamodel
Metamodels are descriptions of descriptions: why are they important to develop software?
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
Metamodeling
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
Multiple levels of abstractions
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
terminal model M
system S
conformsTo
repOf Representation of
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
Metadata architecture
Four Layered Architecture Layer Description Example
Meta-metamodel Defines metamodel metaClass, metaAttribute, metaOperation
Metamodel An instance of meta-Metamodel. Defines a model
Class, attribute operation, component
Model Language for describing an information domain. Defines a set of related objects that represent a concept
Employee
User object An instance of the model. An example information domain
:Sally
OMG Modeling Infrastructure
23
M3
M2
M1
M0
Meta-Object Facility (MOF)
UML Metamodel
Modeling concepts
User Data
Instance_of
Instance_of
Instance_of
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)
Example
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
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
28
MOF Model
MOF Key Abstract Classes
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
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
34
Component
0..1 0..1 0..1
ownedElement
Comment * Link
1..* 1..* 1..* EnumerationLiteral
ProgrammingLanguageType Enumeration Primitive
* * * * * *
1..*
* Object
Parameter defaultValue kind
Instance Namespace
specialization * parent
* child
GeneralizableElement isRoot isLeaf isAbstract
Package
Model Subsystem DataType Interface
deploymmentLocation * resident *
AssociationClass
Class Node
owner
{ordered}
participant * specification
* AssociationEnd
isNavigable aggregation multiplicity
connection 2..* 2..* 2..* Association
Method body
Operation isAbstract
0..1
qualifier * Attribute initialValue
{ordered} *
specification * * * * * *
* type Generalization
discriminator
Feature visibility
BehaviouralFeature StructuralFeature multiplicity
Classifier
ModelElement name
Element
Relationship *
*
type
importedElement *
*
UML Meta Model
Metaclasses used in class, package, component and deployment diagrams
A fragment of the UML Meta-Model
not self.isAbstract implies self.allOperations->forAll(op | self.allMethods->exists(m | m.specification includes (op)))
Model Elements • An element is an atomic
constituent of a model
• Element is the top metaclass in the metaclass hierarchy
• A model element is a named entity in a model
• It is the base for all modeling metaclasses in UML - All other modeling metaclasses are
either direct or indirect subclasses of ModelElement
ModelElement
name
Element
owner
{ordered}
Method body
Operation isAbstract
Attribute initialValue specification
* * * * * *
Feature visibility
BehaviouralFeature StructuralFeature multiplicity
Classifier
*
Features • Feature is an abstract class
that declares a behavioral or structural property of - an instance of a Classifier - the Classifier itself
• A behavioral feature refers to a dynamic feature of a model element - E.g. operation or method
• A structural feature refers to a static feature of a model element - E.g. attribute
38
• 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
Classifier
Component
Structure 1..* 1..* 1..*
EnumerationLiteral
ProgrammingLanguageType Enumeration Primitive
Subsystem DataType Interface deploymmentLocation * resident
* Class Node
Classifier {ordered}
Feature
visibility * Namespace
Classifier
*
1..*
*
Object
Parameter
defaultValue kind
Instance GeneralizableElement
isRoot isLeaf isAbstract
owner
{ordered}
participant *
specification *
AssociationEnd
isNavigable aggregation multiplicity
* type
Feature
visibility
Classifier
*
type
Namespace
• A classifier is a generalizable element and defines a namespace
• It can have - association ends - parameters - instances
AssociationClass
Class
Association
Generalization discriminator
Relationship
Relationship • A relationship is a connection
among model elements
• UML defines several relationships such as: - Association - Generalization
• UML defines other types of relationships that are not shown in this diagram, such as: - Dependency - Flow
Namespace
0..1 0..1 0..1
ownedElement
Namespace GeneralizableElement
isRoot isLeaf isAbstract
Package
Model Subsystem
Classifier
ModelElement name
* importedElement *
*
• A namespace is a part of a model that contains a set of other model elements - E.g. Associations and
Classifiers - the name of an owned
model element is unique within the namespace
• Namespace is an abstract metaclass and it subclasses are - Classifier - Package
42
Data Types
1..* 1..* 1..*
EnumerationLiteral
ProgrammingLanguageType Enumeration Primitive
DataType
• 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
Mapping of UML Models to Metamodel Elements (Example)
Customer Account accountNumber balance overdraftLimit
CreditCard expiryDate
*1..2
withdraw deposit
Saving Chequing
BankSystem
Generalization discriminator
Relationship
Association
Relationship AssociationEnd
isNavigable aggregation multiplicity Class
Classifier Namespace
Package
Attribute initialValue
StructuralFeature multiplicity
Method
BehaviouralFeature
Use Case Diagrams Metamodel
Mapping Use Cases Model to Metamodel
Generalization discriminator
Relationship
Include
Relationship
Actor
Classifier UseCase
Classifier
Extend
Relationship
Open file by typing name Open file by
browsing
Open file
System Administrator
Browse for file
Ordinary User
Attempt to open file that does not exist
«extend» «include»
State Machines (Main Metamodel)
Mapping State Machines to Metamodel
SimpleState
State
PseudoState
StateVertex
Event
Transition
0..1
*
Enter / run motor forwards
Enter / run motor in reverse
Enter / stop motor
Enter / stop motor
openingCompleted
closingCompleted
pressButton
pressButton
pressButton
Closing Open
Opening Closed
Procedure
State
0..1 +entry
0..1
Extension Mechanisms Metamodel
Example
LinearShape startPoint: Point
1..* edge <<geometry>
LineSegment
Path Line Polygon
RegularPolygon
endPoint: Point {startPoint <> endPoint}
{ordered}
{edge->size=1}
{edge->forAll(e1,e2 | e1.length = e2.length)}
length : int length
{length = edge.length->sum}
{edge->first.startPoint = edge->last.endPoint}
Stereotype
GeneralizableElement
Constraint
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
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
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
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
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
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
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
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
Models, metamodels and platforms
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)
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
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
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
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
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
The MOF Meta-metamodel
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)
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
UML 2.0 Infrastructure
Note: the Core package is the same of the MOF Meta-metamodel
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
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
4-Layers MDA: an Example
4-Layers Metamodelling Instance
UML 1.x Metamodel (1/2)
UML 1.x Metamodel (2/2)
UML 2.1 Use-Case MOF Metamodel
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
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)
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
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
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
Relational Data
Record Data
Multidimensional Data
XML Data
Data Transformations
OLAP
Data Mining
Info Visualization
Business Nomenclature
Warehouse Process
Warehouse Operation
CWM: Fragment of the Relational Metamodel
TableisTemporary : BooleantemporaryScope : String/ trigger : TriggerisSystem : Boolean
ViewisReadOnly : BooleancheckOption : BooleanqueryExpression : QueryExpression
QueryColumnSetquery : QueryExpression
NamedColumnSet/ optionScopeColumn : Column/ type : SQLStructuredType/ usingTrigger : Trigger
SQLSimpleTypecharacterMaximumLength : IntegercharacterOctetLength : IntegernumericPrecision : IntegernumericPrecisionRadix : IntegernumericScale : IntegerdateTimePrecision : Integer
SQLDistinctTypelength : Integerprecision : Integerscale : Integer/ sqlSimpleType : SQLSimpleType
1
*
sqlSimpleType
1
sqlDistinctType *
{ordered}
{ordered}
{ordered}
CheckConstraintdeferrability : DeferrabilityType
*
*
/constrainedElement
*
/constrant*
ColumnSet
SQLDataTypetypeNumber : Integer
Columnprecision : Integerscale : IntegerisNullable : NullableTypelength : IntegercollationName : StringcharacterSetName : String/ optionScopeColumnSet : NamedColumnSet/ referencedTableType : SQLStructuredType
**
/constrainedElement
*
/constraint
*
*
0..1 /feature
*/owner
0..11
*/type
1/structuralFeature*
Pairwise (9 connections)
CWM Tool
Source
Source
Source
Target
Target
Target
Hub (6 connections)
The CWM Metamodel
Extract Transform
Drill Down
Source
Source
Source
Operational Data Sources
Target
Target
Target
Data Warehouses
OMG Metamodel Architecture
Standard Components Modeling Notation: UML Metadata Interchange: XMI Metadata API:
MOF IDL Mapping JMI – MOF/Java Mapping
M I D D L E W A R E
A P P L I C A T I O N
User Data/Object Layer (M0)
Metadata/Model Layer(M1)
Metamodel Layer(M2)
Meta-metamodel Layer (M3)
<Stock name=“IBM” price=“112”/>
Stock: name, price
UML: Class, Attribute CWM: Table, Column ElementType, Attribute
MOF: Class, Attribute, Operation, Association
CWM is based on UML MOF XMI
The CWM Metamodel (1.0) Warehouse
Process Warehouse Operation
Transformation
XML Record Multi- Dimensional Relational
Business Information
Software Deployment
Core
Management
Resource
Analysis
Object (Core+Behavioral+
Relationships)
Foundation
OLAP Data Mining
Information Visualization
Business Nomenclature
Data Types Expressions Keys
Index Type
Mapping
Behavioral Relationships Instance Object Model
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
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
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?
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
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
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/
Questions?