Model Driven Architecture
Meta Modeling
Prof. Dr. Peter Thiemann
Universität Freiburg
24.05.2006
Metamodeling
Intro
What?
meta = above
Define an ontology of concepts for a domain.
Define the vocabulary and grammatical rules of a modeling
language.
Define a domain specific language (DSL).
Why?
Concise means of specifying the set models for a domain.
Precise definition of modeling language.
How?
Grammars and attributions for textbased languages.
Metamodeling generalizes to arbitrary languages (e.g.,
graphical)
Metamodeling
Uses
Construction of DSLs
Validation of Models
(checking against metamodel)
Model-to-model transformation
(defined in terms of the metamodels)
Model-to-code transformation
Tool integration
Terms
Domain restricted area of interest
technical aspects
factual aspects
Syntax well-formedness rules
abstract syntax
just structure, how are the language concepts
composed
concrete syntax
defines specific notation
typical use:
parser maps concrete syntax to abstract
syntax
Terms/Abstract Syntax
Example: Arithmetic expressions
abstract syntax
Expr = Const String
| Var String
| Binop Op Expr Expr
Op = Add | Sub | Mul | Div
Binop Mul (Const "2")
(Binop Add (Var "x") (Const "3"))
concrete syntax
E ::= c | x | E B E | (E)
B ::= + | − | ∗ | /
2 * (x + 3)
Terms/Abstract Syntax
Example: UML class diagram
concrete syntax
Person
name
salary
raise()
abstract syntax
:Class
name = "Person"
:Attribute :Operation :Attribute
name = "name" name = "raise" name = "salary"
Terms/Static Semantics
Static semantics defines well-formedness rules beyond the
syntax
Examples
“Variables have to be defined before use”
Type system of a programming language
"hello" * 4 is syntactically correct Java, but rejected
UML: static semantics via OCL expressions
Use: detection of modeling/transformation errors
Terms/Domain Specific Language (DSL)
Purpose: formal expression of key aspects of a domain
Metamodel of DSL defines abstract syntax and static
semantics
Additionally:
concrete syntax (close to domain)
dynamic semantics
for understanding
for automatic tools
Different degrees of complexity possible
configuration options with validity check
graphical DSL with domain specific editor
Metamodel vs Model
Domain of discourse Model Metamodel
"real world" describes
model elements
describes metamodel
elements elements
Insight: Every model is an instance of a metamodel.
Essential: instance-of relationship
Model:Metamodel is like Object:Class
Definition of Metamodel by Meta-metamodel
⇒ infinite tower of metamodels
⇒ “meta” relation always relative to a model
Every element must have a classifying metaelement which
contains the metadata and
is accessible from the element
Metamodeling a la OMG
OMG defines a standard (MOF) for metamodeling
MOF (Meta-Object Facility) used for defining UML
Attention, confusion:
MOF and UML share syntax (classifier and instance
diagrams)
MOF shares names of modeling elements with UML (e.g.,
Class)
Approach
Restrict infinite number of metalevels to four
Last level is deemed “self-describing”
OMG’s Four Metalevels
describes instanceof Typ: Classifier
ID: 5346456
M3: Meta−Metamodel Name: Classifier
describes instanceof
Typ: Classifier
ID: 764535
M2: Metamodel
Name: Klasse
Features: Attributes, Operations, Ass
describes instanceof
Typ: Klasse
ID: 21436456
M1: Model Name: Person
Attribute: Name, Firstn.
describes instanceof Operations: ...
Association: ...
M0: Instances Typ: Person
ID: 05034503
Name: Doe
Given name: John
Layer M0: Instances
Level of the running system
Contains actual objects, e.g., customers, seminars, bank
accounts, with filled slots for attributes etc
Corresponds to object diagram
Layer M1: Model
Level of system models
Example:
UML model of a software system
Class diagram contains modeling elements: classes,
attributes, operations, associations, generalizations, . . .
Concepts of M1 categorize (or classify) instances at layer
M0
Each element of M0 is an instance of M1 element
No other instances are allowed at layer M0
Relation between M0 and M1
M1: Model of a System
Customer Order
title : String number : String
name : String name : String
<<instance of>> <<instance of>> <<instance of>>
M0: System
Customer Customer Order
title = "Dr" title = "Mr" number = "200604"
name = "Joe Nobody" name = "Mark Everyman" name = "somename"
Layer M2: Metamodel
“Model of Model”
Level of modeling element definition
Concepts of M2 categorize instances at layer M1
Elements of M2 model categorize M1 elements: classes,
attributes, operations, associations, generalizations, . . .
Examples
Each class in M1 is an instance of some class-describing
element in layer M2 (in this case, a Metaclass)
Each association in M1 is an instance of some
association-describing element in layer M2 (a
Metaassociation)
and so on
Relation between M1 and M2
M2: Model of a Model
UML Class UML
UMLAttribute
Attribute
name: String name: String
<<instance of>> <<instance of>> <<instance of>>
M1: Model
UML Class UML Class UML Attribute
name = "Customer" name = "Order" name = "number"
Layer M3: Meta-Metamodel
Level for defining the definition of modeling elements
Elements of M3 model categorize M2 elements:
Metaclass, Metaassociation, Metaattribute, etc
Typical element of M3 model: MOF class
Examples
The metaclasses Class, Association, Attribute, etc are all
instances of MOF class
M3 layer is self-describing
Relation between M2 and M3
MOF Class M3: Model of a Model of a Model
name: String
<<instance of>> <<instance of>>
M2: Model of a Model
MOF Class MOF Class
name = "UML Class" name = "UML Attribute"
Overview of Layers
MOF Class M3: Model of a Model of a Model
name: String
<<instance of>> <<instance of>>
M2: Model of a Model
UML Class UML Attribute
name: String name: String
<<instance of>> <<instance of>> <<instance of>> <<instance of>>
M1: Model of a System
Customer Order
title: String number: String
name: String name: String
<<instance of>> <<instance of>>
<<instance of>>
M0: System
Customer Customer Order
title = "Dr" title = "Mr" number = "200604"
name = "Joe Nobody" name= "M. Everyman" name = "somename"
Excerpt from MOF/UML
Model
Element
Import Namespace Constraint Tag Feature
generalizes Generalizable Behavioral
Element Feature
Package Classifier Operation Exception
can throw
Association Class
Meta vs Abstract
M3
MOF
<<instanceof>>
M2
PIM− PSM−
Metamodel Metamodel
"meta" <<instanceof>> <<instanceof>>
"abstract" M1
PIM PSM
Transformation
Models on the same metalevel may have different degrees of abstraction
Transformations map between models of different abstraction levels
Source and target model of a transformation may be defined by different
metamodels
MOF vs UML
UML (M2) is an instance of MOF (M3)
UML is older than MOF
UML had to change to suit MOF
MOF reuses concrete syntax and some model elements
Designing a DSL
Definition of a new M2 language too involved
Typical approach: Extension of UML
Extension Mechanisms
Extension of the UML 2 metamodel
applicable to all MOF-defined metamodels
Extension using stereotypes (the UML 1.x way)
Extension using profiles (the UML 2 way)
Extending the UML Metamodel
Extended UML−Metamodel MOF
UML::Class
generalizes
<<instanceof>>
MOF::Classifier
<<instanceof>>
CM::Component
<<instanceof>>
MOF sanctions the derivation of a new metaclass
CM::Component from UML::Class
CM::Component is an instance of MOF::Classifier
the generalization is an instance of MOF’s generalizes
association
Extending the UML Metamodel/Concrete Syntax
(1) (2) (4)
<<CM::Component>> CustomAdmin::Person
<CM::Component>> CustomAdmin::Person {metaclass=CM::Component}
<<instanceof>>
(3) (5)
<<component>>
CustomAdmin::Person CustomAdmin::Person
CustomAdmin::Person
1 Explicit instance of metaclass
2 Name of metaclass as stereotype
3 Convention
4 Tagged value with metaclass
5 Own graphical representation (if supported)
Adding to a Class
UML::Class
<<CM::Component>>
CustomAdmin::Person
{transactional = true}
CM::Component
transactional: boolean
“just” inheriting from UML::Class leads to an identical copy
Adding an attribute to the CM::Component metaclass
leads to
an attribute value slot in each instance
notation: tagged value (typed in UML 2)
Meta vs Generalization
M3
MOF
"meta" <<instanceof>>
M2
Base metamodel
UML Metamodel
"base"
Metamodel Metamodel
Domain 1 Domain 2
<<instanceof>> <<instanceof>> M1
"meta" <<instanceof>>
Applicationsmodel Applicationsmodel
Domain 2 UML Model Domain 1
Extension Using Stereotypes (UML 1.x)
<<stereotye>>
<<metaclass>> <<stereotype>> CM::Component
{<<taggedValue>>
UML::Class transactional}
Simple specialization mechanism of UML
No recourse to MOF required
Tagged Values untyped
No new metaassociations possible
Extending Using Profiles (UML 2)
definition use
<<stereotype>> <<CM::Component>>
<<metaclass>>
UML::Class CM::Component CustomAdmin::Person
{transactional = true}
transactional: boolean
Extension of the stereotype mechanism
Requires “Extension arrow” as a new UML language construct
(generalization with filled arrowhead)
Not: generalization, implementation, stereotyped dependency, association, . . .
Attributes ⇒ typed tagged values
Multiple stereotypes possible
More on Profiles
Profiles make UML into a family of languages
Each member is defined by application of one or more
profiles to the base UML metamodel
Tools should be able to load profiles and corresponding
transformations
Profiles have three ingredients
stereotypes
tagges values
constraints
Profiles can only impose further restrictions
Profiles are formally defined through a metamodel
Profile Metamodel
PackageImport
appliedProfile
Package ProfileApplication
{subsets
1 importedPackage} n
n
imported Profile Association
Profile {subsets importedPackage}
1
1
/metaclass n
Extension Property
Class 1 /extension 1
{subsets ownedMember}
owned
Stereotype type
Stereotype ExtensionEnd
n
n 1
Example Profile for EJB
<<profile>>
EJB
<<stereotype>> context Bean:
Component inv: realization−>
Bean select( hasStereotype( "Remote" ))−>size()=1
&&
realization−>
select( hasStereotype( "Home" ))−>size()=1
<<stereotype>> <<stereotype>>
EntityBean SessionBean
<<stereotype>>
JAR
Artifact
<<enumeration>> <<stereotype>>
StateKind Remote
Interface
stateful
stateless <<stereotype>>
Home
Further Aspects of Profiles
Stereotypes can inherit from other stereotypes
Stereotypes may be abstract
Constraints of a stereotype are enforced for the
stereotyped classifier
Profiles are relative to a reference metamodel
e.g., the UML metamodel or an existing profile
Most tools today do not enforce profile-based modeling
restrictions, so why bother with profiles?
constraints for documentation
specialized UML tools
validation by transformer / program generator
Metamodeling and OCL
<<metaclass>>
UML::Attribute
name: String
type: Type
[...]
context Attribute:
<<metaclass>>
inv: Type.Name == "String"
CM::ConfigParam
OCL constraints are independent of the modeling
language and the metalevel
OCL on layer Mn + 1 restricts instances on layer Mn