Post on 14-May-2015
1 FILENAMs.PPT/ 6-Feb-04 / PSeTampere University of Technology
Metamodeling and Meta-Object Facility (MOF)
Petri Selonen8109103 Software Engineering Theory
Spring 2004
2 FILENAMs.PPT/ 6-Feb-04 / PSeTampere University of Technology
Presentation Outline
1. Introduction to Metamodeling2. Introduction to MOF3. MOF in Detail4. MOF and Unified Modeling Language5. Concluding Remarks
3 FILENAMs.PPT/ 6-Feb-04 / PSeTampere University of Technology
Models and Metamodels• Merriam-Webster Online Dictionary defines a model roughly as
a “description or analogy used to help visualize something that cannot be directly observed”
• models are used for describing, visualizing, and observing• models describe a system from different viewpoints, for
different stakeholders, at different levels of abstraction• Models are, first and foremost, used for communication
• ability to convey unambiguous meaning is essential• need for an underlying model behind the model
metamodel• Metamodels describe models (i.e., metamodel instances)
• allowed metaelements, their properties and relationships• well-formedness rules for the instantiated models• in essence, an abstract syntax for models!
4 FILENAMs.PPT/ 6-Feb-04 / PSeTampere University of Technology
Models and Metamodels, cont’d• In addition, metamodel should describe the semantics for the
metaelements and thus the meaning of a metamodel instance• in practice, abstract syntaxes are given more emphasis…
• Conceptually, a class diagram can act as a metamodel for an object diagram:
1..*
Joni : Person Avensis : CaryearOfPurchase := 1999
owner
Personname : String
Car
name : StringyearOfPurchase: Integer
+owner
0..*
+ownedCar
"metalevel" boundary
Model instance
Application model
5 FILENAMs.PPT/ 6-Feb-04 / PSeTampere University of Technology
Models and Metamodels, cont’d• If metamodels are important, how should they be presented?
• a metamodel itself is an instance of a meta-metamodel• metacircular definitions lead to an infinite number of
metalevels!• There is a need for metalevel or metadata architectures
• they have been used in many application domains• artificial intelligence, operating systems, programming languages, etc.• with object-oriented systems, a metalevel is often considered as a “higher
sphere of control”
• However, metamodeling in the context of software modeling languages has only recently gained larger (non-academic) popularity
• Of course, MetaEdit has been around for ~15 years…• As the importance of modeling grows, so does the need for
well-defined techniques
6 FILENAMs.PPT/ 6-Feb-04 / PSeTampere University of Technology
Metadata Architectures• Metadata architectures should facilitate construction and
building of frameworks and systems supporting the usage of meta-level information
• in the context of this presentation, they should facilitate the building of metamodels
• Characteristics of metadata architectures include the ability• to support arbitrary kinds of models,• to support arbitrary kinds of modeling paradigms,• to relate different kinds of metadata,• to incrementally add new metamodels and new kinds of
metadata to existing metamodels,• to support interchange of arbitrary metadata and meta-
metadata• Next slide presents an example of a four-layer metadata
architecture conforming similar to the ones presented by ISO
7 FILENAMs.PPT/ 6-Feb-04 / PSeTampere University of Technology
Four-Layer Metadata Architecture
8 FILENAMs.PPT/ 6-Feb-04 / PSeTampere University of Technology
Presentation Outline
1. Introduction to Metamodeling
2. Introduction to MOF3. MOF in Detail4. MOF and Unified Modeling Language5. Concluding Remarks
9 FILENAMs.PPT/ 6-Feb-04 / PSeTampere University of Technology
Object Management Group (OMG)• An open membership, not-for-profit consortium with over 600
members (est. 1989)• originally promoted theory and practice of object-oriented
technology in software development• now aims at producing “industry specifications for
interoperable enterprise applications”• Adopted technologies include:
• Model Driven Architecture (MDA)• Meta-Object Facility (MOF)• Unified Modeling Language (UML)• XML Metadata Interchange (XMI)• Common Warehouse Metamodel (CWM)• Common Object Request Broker Architecture (CORBA)
• On-line at http://www.omg.org
10 FILENAMs.PPT/ 6-Feb-04 / PSeTampere University of Technology
Metamodeling and MOF• The advent of OMG’s Model Driven Architecture (MDA)
initiative places further weight on models• emphasis on automatic generation of models and model
(PIM to PSM) transformations• seamless transition from high-level business and domain
logic into executable code (also seen as a model)• The Meta-Object Facility (MOF) is OMG’s answer to support
the generation and representation of arbitrary metamodels• the MOF Model and associated MOF IDL provide a meta-
metamodel for describing metamodels• metamodels are instances of meta-metamodels• support for common repositories, distribution of data, etc.
• MOF offers a meta-metamodel, i.e., metadata architecture for constructing metamodels!
11 FILENAMs.PPT/ 6-Feb-04 / PSeTampere University of Technology
Overview on MOF• MOF defines an abstract language and a framework for
specifying, constructing, and managing technology neutral metamodels (e.g. UML, MOF itself)
• MOF specification 1.4 (April 2002) includes• A formal definition of MOF meta-metamodel
• Abstract language for specifying MOF metamodels• A mapping from arbitrary MOF metamodels to CORBA IDL
• Produces IDL interfaces for managing metadata• A set of reflective CORBA IDL interfaces
• For representing and managing MOF metamodels• An XMI format for MOF metamodel interchange
• Metamodels of MOF and UML are architecturally aligned• They share a common subset of core modeling concepts• MOF reuses UML notation for visualizing metamodels
12 FILENAMs.PPT/ 6-Feb-04 / PSeTampere University of Technology
MOF Metadata Architecture• MOF is a meta-metamodel for defining metamodels for various
domains and modeling languages• MOF offers a CORBA IDL for creating, accessing, and
modifying the information present in metamodel instances• MOF Model is object-oriented
• metamodeling constructs are aligned with UML’s object modeling constructs
• Even though MOF outlines a four-layer structure…• information layer (M0), model layer (M1), metamodel layer,
and meta-metamodel layer• …MOF metalevels are not fixed
13 FILENAMs.PPT/ 6-Feb-04 / PSeTampere University of Technology
MOF Metadata Architecture, cont’d• The MOF Model is self-describing
• it is defined by its own constructs• its interfaces and behavior can be defined applying MOF
IDL mappings to the MOF Model itself• architectural basis for extensions and modifications of MOF
models• As with the concept of metadata architectures, MOF offers
• support for arbitrary models and modeling paradigms• possibility of relating different kinds of metadata• possibility of incremental addition of new metamodels and
metadata• support for interchange of arbitrary metadata (models) and
meta-metadata (metamodels) that use the same meta-metamodel
14 FILENAMs.PPT/ 6-Feb-04 / PSeTampere University of Technology
Parallel Instances of MOF Layers
15 FILENAMs.PPT/ 6-Feb-04 / PSeTampere University of Technology
MOF Technology Mappings
16 FILENAMs.PPT/ 6-Feb-04 / PSeTampere University of Technology
Presentation Outline
1. Introduction to Metamodeling2. Introduction to MOF
3. MOF in Detail4. MOF and Unified Modeling Language5. Concluding Remarks
17 FILENAMs.PPT/ 6-Feb-04 / PSeTampere University of Technology
MOF Classes• Classes model MOF metaobjects
• classes defined at the Mi level have instances at M(i-1) level• instances have object identity, state, and behavior
• Classes can have Attributes and Operations• Attributes have normal interpretation• Operations are “hooks” for accessing behavior
• they simply specify the names and type signatures• both have scoping and multiplicities
• Classes can be generalized• “typical” interpretation• type substitutability at M(i-1) level• no name over-riding is allowed
• Abstract classes are allowed
18 FILENAMs.PPT/ 6-Feb-04 / PSeTampere University of Technology
MOF Associations and Data Types• Associations express relationships in a metamodel
• meta-associations at Mi level have instances (metalinks) at M(i-1) level
• they are binary and have multiplicities• they can have aggregation or composition semantics
• Data types present those types whose values do not have object identity
• primitive types include Boolean, Integer, and String• MOF defines in total six standard, “technology-neutral” data types
• data type constructors allow definition of more complex data types: Enumeration, Structure, Collection, Alias, etc.
19 FILENAMs.PPT/ 6-Feb-04 / PSeTampere University of Technology
Other MOF Elements• Packages group elements in a metamodel
• at Mi level they modularize the metamodel space• at M(i-1) level they act as “outermost” containers for
metadata• packages can relate to each other in several ways:
generalization, package nesting, package importing, and package clustering
• Miscellaneous MOF elements include constraints, constants, exceptions, tags, etc.
20 FILENAMs.PPT/ 6-Feb-04 / PSeTampere University of Technology
MOF Model Package Overview
21 FILENAMs.PPT/ 6-Feb-04 / PSeTampere University of Technology
Differences Between MOF and UML
No CORBA awarenessSubset of CORBA primitive data types and constructors
Template metaclassNo support for templates
Generalization and Dependency are metaclasses
Generalization and Dependency are Associations
Navigation through Associations
Direct References
AssociationClass, QualifierNo AssociationClasses or Qualifiers
N-ary associationsBinary associations
MOF UML
22 FILENAMs.PPT/ 6-Feb-04 / PSeTampere University of Technology
Presentation Outline
1. Introduction to Metamodeling2. Introduction to MOF3. MOF in Detail
4. MOF and Unified Modeling Language5. Concluding Remarks
23 FILENAMs.PPT/ 6-Feb-04 / PSeTampere University of Technology
Three-Layer Example
Classname : String
Association
AssociationEndname : Stringmultiplicity : Multiplicity
Attribute
2..* +connection
1
1
+participant 0..*
+association
+feature
0..1
0..*
+type1
1..*
Joni : Person Avensis : CaryearOfPurchase := 1999
owner
Personname : String
Car
name : StringyearOfPurchase: Integer
+owner
0..*
+ownedCar
M0. Instance
M1. Model
M2. Metamodel
24 FILENAMs.PPT/ 6-Feb-04 / PSeTampere University of Technology
Model vs. View
1..*
Person : Class Car : Class
feature
Personname : String
Car
name : StringyearOfPurchase: Integer
+owner
0..*
+ownedCar
M1-model as a M2-level instance
M1-model as a UML class diagram
yearOfPurchase: Attribute name : Attributename : Attribute
owner :AssociationEnd
multiplicity=[1,*]aggregationKind=none
ownedCar :AssociationEnd
multiplicity=[0,*]aggregationKind=none
: Association
feature feature
participant participant
connection connection
type=String type=Stringtype=Integer
25 FILENAMs.PPT/ 6-Feb-04 / PSeTampere University of Technology
Example: Defining a Metamodel• To exploit MOF, let us define a new, MOF compliant metamodel for our
own, proprietary modeling language• The language is called HeaVy which allows the user to introduce
1. participants with attributes,2. binary associations between participants (containing a name, end
role names, and end multiplicities), and3. actions connected to one or more participants (actions have
parameters, a guard, and method body)
c CaryearOfPurchase: Integernew_car_buyer
(name)
p(name) || own(p,c)
not exists p2:Person ::p2.name=name
Personname: String
owner 0..1
new p
own
context foo
inv: (self.name=“Joni” or self.name=“Reima”) implies self.car.name=“Avensis”
26 FILENAMs.PPT/ 6-Feb-04 / PSeTampere University of Technology
HeaVy Metamodel / Abstract Syntax
Classname : String
Associationname : String
AssociationEndname : Stringmultiplicity : Multiplicity
Attributename : Stringtype : String
2 +connection
1
1
+participant 0..*
+association
+feature
1
0..*
M2. HeaVy Metamodel
Activityname : String
Participantname : String
Parametername : Stringtype : String
+parameter
1
0..*
Guardexpression : String
+guard0..*
0..*
Actionexpression : String
+action0..*
0..*
c CaryearOfPurchase: Integernew_car_buyer
(name)
p(name) || own(p,c)
not exists p2:Person ::p2.name=name
Personname: String
owner 0..1
new p
own
27 FILENAMs.PPT/ 6-Feb-04 / PSeTampere University of Technology
HeaVy Metamodel / Rest of the Stuff• Example well-formedness rules
• all HeaVy models (i.e., HeaVy metamodel instances) must conform to the MOF structural constraints (i.e., stated by the association end multiplicities)
• Additional rule (using UML’s OCL) for Classes[1] Attributes must have unique names within a Class:
self.feature->select( a | a.oclIsKindOf(Attribute) )->forAll( p,q | p.name=q.name implies p=q)
• Detailed semantics: 42• Example notation rules
• classes are depicted as rectangles with two compartments, with their name centered in the upper rectangle, and their attributes left-justified in the lower rectangle (name ‘:’ type)
28 FILENAMs.PPT/ 6-Feb-04 / PSeTampere University of Technology
HeaVy Stuff cont’d• Now we have defined our proprietary metamodel using MOF
• MOF standard defines abstract mappings of HeaVy models• XMI standard defines concrete mapping of HeaVy
metamodel into a HeaVy DTD, and a mapping from HeaVymetamodel instances into XML/XMI files
• It is up to the implemented tools, transformation components, and users to read our HeaVy definition and interpret it correctly
• we only defined an abstract syntax (a very loose one)• We would probably like to reuse and exploit the existing
modeling tools and metamodels• fortunately, MOF and UML are very much aligned…• …as is HeaVy, surprisingly enough• UML profiles offer a lightweight extension mechanism
29 FILENAMs.PPT/ 6-Feb-04 / PSeTampere University of Technology
Using UML Profiles• Profiles have not been properly defined in UML
• just a few example figures with textual descriptions• only used for direct metaclass reuse, meta-associations are
not covered by the existing definitions• assumes that the existing UML metamodel remains in effect
• Fortunately, we are practical people, we are not formal people (adaptation of Gianna Reggio, UML’02)
• when in trouble, switch metalevels back and forth• “what do you mean it cannot be done, I just did it?”
• Our toolbox:• define new stereotypes to represent user-specified new
metaclasses, derive them from standard UML metaclasses• define new attributes using Tagged Values• when necessary, override existing meta-associations
(inclusive vs. exclusive)• introduce additional OCL constraints
30 FILENAMs.PPT/ 6-Feb-04 / PSeTampere University of Technology
Using UML Profiles, cont’d• Our goal is just to provide sufficient support for HeaVy in such
a manner that these extended models can be represented in existing UML CASE tools, and the models can be exchanged in standard format
• Both the metamodel extension, i.e., HeaVy profile and the actual HeaVy models are just plain UML models
• They can be represented in standard XMI• Most tools, while not capable of interpreting the profiles, still
support alternative visualizations• When available, tools aware of our (non-existent) semantics
can react to the models• For even further simplicity:
• only introduce the concept of HActivity (standing for HeaVyactivity)
31 FILENAMs.PPT/ 6-Feb-04 / PSeTampere University of Technology
Using UML Profiles, cont’d
<<metaclass>>Classifier
name : String
<<metaclass>>Parameter
name : String
<<metaclass>>Constraint
name : Stringbody : BooleanExpression
<<metaclass>>Method
body: ProcedureExpr
*+constraint <<metaclass>>
Operationname : String
*+parameter
0..1
+feature0..*0..1
1 +type 1 +specification
<<stereotype>>HActivity
<<stereotype>>HGuard
body : BooleanExpression1+constraint <<stereotype>>
HSignature+feature
111
*
<<stereotype>><<stereotype>> <<stereotype>>
UML Metamodel
HeaVy Profile
32 FILENAMs.PPT/ 6-Feb-04 / PSeTampere University of Technology
A UML Metamodel Instance of HeaVy Model
new pPerson
id: Integername: String
add_owner(id, name)
p(id, name)
not exists b2:Book :: b2.id=id
<<HActivity>>add_owner :
ClassifierPerson : Class
id : Attribute
type=Integer
name : Attribute
type=String
: Association
new p :AssociationEnd: AssociationEnd
<<HGuard>>: Constraint
body="not existsb2:Book :: b2.id=id"
<<HSignature>>: Operation
id : Parameter
name : Parameter
: Method
body="p(id,name)"
33 FILENAMs.PPT/ 6-Feb-04 / PSeTampere University of Technology
UML Profiles vs. MOF Metamodels• Decision whether to design a metamodel as a MOF instance,
or whether to extend the UML metamodel depends on the domain and intent
• UML has wide-spread CASE tools support• but the tools are usually weak and not metamodel aware
• UML already includes an extensive portion of necessary software modeling constructs
• but some constructs are ambiguous and even inconsistent• UML specification is very large and complex• MOF specification is compact but restrictive
• UML defines a well-established notation• but MOF re-uses the same notation
• UML profile mechanism is very loosely defined• gives flexibility but enforcement requires conventions or proprietary tools• MOF metamodeling is harder to grasp but quite powerful
• How much does one want to reuse the UML semantics?
34 FILENAMs.PPT/ 6-Feb-04 / PSeTampere University of Technology
UML Metamodel Excerpt (Core::Structure)
Classifiername : String
Association
AssociationEndname : Stringmultiplicity : Multiplicity
Attribute
2..*
1
1
+participant 0..*
+association
+feature
0..1
0..*
+type1
Parametername : String
Constraintname : Stringbody : BooleanExpression
Methodbody:ProcedureExpression
*
+constraint
Operationname : String
*
+parameter 0..1
+feature0..*
0..11+type
1
+specification *
35 FILENAMs.PPT/ 6-Feb-04 / PSeTampere University of Technology
Presentation Outline
1. Introduction to Metamodeling2. Introduction to MOF3. MOF in Detail4. MOF and Unified Modeling Language
5. Concluding Remarks
36 FILENAMs.PPT/ 6-Feb-04 / PSeTampere University of Technology
Concluding Remarks• Metadata architectures are good and metamodeling is good,
m’kay?• support for common repositories and exchange formats• support for defining series of metamodels sharing the same
meta-metamodel• support for arbitrary(?) modeling languages and paradigms• support for relating metalevel elements
• MOF offers metamodeling and a metadata architecture implementation
• an industry standard• support for existing and upcoming technologies• aligned with UML• “a single reference point throughout the enterprise”
37 FILENAMs.PPT/ 6-Feb-04 / PSeTampere University of Technology
Questions?[see if I care]
“When you can’t beat them, move
one metalevelhigher. “ -Authoryou puny instances….
38 FILENAMs.PPT/ 6-Feb-04 / PSeTampere University of Technology
Alignment with CWM• MOF has been adopted as a part of OMG’s Common
Warehouse Metamodel (CWM) technology• Motivation for CWM
• systems are complex and interdependent• there is a need to trace data flows between systems• there is a need to understand meaning and context of data elements
• new information systems• unlike with data driven systems, where metadata was local• need to trace information• need to implement and enforce standards• need to provide reference points
• industry standard• “reflects the real world”
• single reference point throughout the enterprise• very much in line with the MDA approach!