Metamodeling and Meta-Object
Facility (MOF)
Petri Selonen
8109103 Software Engineering Theory
Spring 2004

1 FILENAMs.PPT/...
Presentation Outline
1. Introduction to Metamodeling
2. Introduction to MOF
3. MOF in Detail
4. MOF and Unified Modeling L...
Models and Metamodels
• Merriam-Webster Online Dictionary defines a model roughly as
a “description or analogy used to hel...
Models and Metamodels, cont’d
• In addition, metamodel should describe the semantics for the
metaelements and thus the mea...
Models and Metamodels, cont’d
• If metamodels are important, how should they be presented?
• a metamodel itself is an inst...
Metadata Architectures
• Metadata architectures should facilitate construction and
building of frameworks and systems supp...
Four-Layer Metadata Architecture

7 FILENAMs.PPT/ 6-Feb-04 / PSe

Tampere University of Technology
Presentation Outline
1. Introduction to Metamodeling

2. Introduction to MOF
3. MOF in Detail
4. MOF and Unified Modeling ...
Object Management Group (OMG)
• An open membership, not-for-profit consortium with over 600
members (est. 1989)
• original...
Metamodeling and MOF
• The advent of OMG’s Model Driven Architecture (MDA)
initiative places further weight on models
• em...
Overview on MOF
• MOF defines an abstract language and a framework for
specifying, constructing, and managing technology n...
MOF Metadata Architecture
• MOF is a meta-metamodel for defining metamodels for various
domains and modeling languages
• M...
MOF Metadata Architecture, cont’d
• The MOF Model is self-describing
• it is defined by its own constructs
• its interface...
Parallel Instances of MOF Layers

14 FILENAMs.PPT/ 6-Feb-04 / PSe

Tampere University of Technology
MOF Technology Mappings

15 FILENAMs.PPT/ 6-Feb-04 / PSe

Tampere University of Technology
Presentation Outline
1. Introduction to Metamodeling
2. Introduction to MOF

3. MOF in Detail
4. MOF and Unified Modeling ...
MOF Classes
• Classes model MOF metaobjects
• classes defined at the Mi level have instances at M(i-1) level
• instances h...
MOF Associations and Data Types
• Associations express relationships in a metamodel
• meta-associations at Mi level have i...
Other MOF Elements
• Packages group elements in a metamodel
• at Mi level they modularize the metamodel space
• at M(i-1) ...
MOF Model Package Overview

20 FILENAMs.PPT/ 6-Feb-04 / PSe

Tampere University of Technology
Differences Between MOF and UML
MOF

UML

Binary associations

N-ary associations

No AssociationClasses or
Qualifiers

As...
Presentation Outline
1. Introduction to Metamodeling
2. Introduction to MOF
3. MOF in Detail

4. MOF and Unified Modeling ...
Three-Layer Example
M2. Metamodel
+participant

Class

1

0..*

+association

name : String

1

+type

AssociationEnd
name...
Model vs. View
M1-model as a UML class diagram

Person

+owner

+ownedCar

1..*

name : String

Car

0..*

name : String
y...
Example: Defining a Metamodel
•

To exploit MOF, let us define a new, MOF compliant metamodel for our
own, proprietary mod...
HeaVy Metamodel / Abstract Syntax
M2. HeaVy Metamodel
+participant

Participant

1

0..*

+association

name : String

Ass...
HeaVy Metamodel / Rest of the Stuff
• Example well-formedness rules
• all HeaVy models (i.e., HeaVy metamodel instances) m...
HeaVy Stuff cont’d
• Now we have defined our proprietary metamodel using MOF
• MOF standard defines abstract mappings of H...
Using UML Profiles
• Profiles have not been properly defined in UML
• just a few example figures with textual descriptions...
Using UML Profiles, cont’d
• Our goal is just to provide sufficient support for HeaVy in such
a manner that these extended...
Using UML Profiles, cont’d
<<metaclass>>

Parameter
name : String

1
<<metaclass>>

Constraint

*

UML Metamodel
HeaVy Pro...
A UML Metamodel Instance of HeaVy Model
add_owner
(id, name)
not exists b2:Book :: b2.id=id

new p

Person
id: Integer
nam...
UML Profiles vs. MOF Metamodels
• Decision whether to design a metamodel as a MOF instance,
or whether to extend the UML m...
UML Metamodel Excerpt (Core::Structure)

Parameter

+parameter

0..1

Operation

*

name : String

+specification

*

1

n...
Presentation Outline
1. Introduction to Metamodeling
2. Introduction to MOF
3. MOF in Detail
4. MOF and Unified Modeling L...
Concluding Remarks
• Metadata architectures are good and metamodeling is good,
m’kay?
• support for common repositories an...
Questions?
[see if I care]

“When you can’t
beat them, move
one metalevel
higher. “ -Author
you puny instances….

37 FILEN...
Alignment with CWM
• MOF has been adopted as a part of OMG’s Common
Warehouse Metamodel (CWM) technology
• Motivation for ...
Upcoming SlideShare
Loading in...5
×

Mof kalvot

166

Published on

Published in: Education
0 Comments
0 Likes
Statistics
Notes
  • Be the first to comment

  • Be the first to like this

No Downloads
Views
Total Views
166
On Slideshare
0
From Embeds
0
Number of Embeds
0
Actions
Shares
0
Downloads
2
Comments
0
Likes
0
Embeds 0
No embeds

No notes for slide

Mof kalvot

  1. 1. Metamodeling and Meta-Object Facility (MOF) Petri Selonen 8109103 Software Engineering Theory Spring 2004 1 FILENAMs.PPT/ 6-Feb-04 / PSe Tampere University of Technology
  2. 2. Presentation Outline 1. Introduction to Metamodeling 2. Introduction to MOF 3. MOF in Detail 4. MOF and Unified Modeling Language 5. Concluding Remarks 2 FILENAMs.PPT/ 6-Feb-04 / PSe Tampere University of Technology
  3. 3. 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! 3 FILENAMs.PPT/ 6-Feb-04 / PSe Tampere University of Technology
  4. 4. 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: Person +owner 1..* name : String +ownedCar 0..* Car name : String yearOfPurchase: Integer Application model "metalevel" boundary Model instance Joni : Person owner Avensis : Car yearOfPurchase := 1999 4 FILENAMs.PPT/ 6-Feb-04 / PSe Tampere University of Technology
  5. 5. 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 5 FILENAMs.PPT/ 6-Feb-04 / PSe Tampere University of Technology
  6. 6. 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 metametadata • Next slide presents an example of a four-layer metadata architecture conforming similar to the ones presented by ISO 6 FILENAMs.PPT/ 6-Feb-04 / PSe Tampere University of Technology
  7. 7. Four-Layer Metadata Architecture 7 FILENAMs.PPT/ 6-Feb-04 / PSe Tampere University of Technology
  8. 8. Presentation Outline 1. Introduction to Metamodeling 2. Introduction to MOF 3. MOF in Detail 4. MOF and Unified Modeling Language 5. Concluding Remarks 8 FILENAMs.PPT/ 6-Feb-04 / PSe Tampere University of Technology
  9. 9. 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 9 FILENAMs.PPT/ 6-Feb-04 / PSe Tampere University of Technology
  10. 10. 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 metametamodel 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! 10 FILENAMs.PPT/ 6-Feb-04 / PSe Tampere University of Technology
  11. 11. 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 • • • • Produces IDL interfaces for managing metadata • • Abstract language for specifying MOF metamodels For representing and managing MOF metamodels A mapping from arbitrary MOF metamodels to CORBA IDL A set of reflective CORBA IDL interfaces 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 11 FILENAMs.PPT/ 6-Feb-04 / PSe Tampere University of Technology
  12. 12. 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 12 FILENAMs.PPT/ 6-Feb-04 / PSe Tampere University of Technology
  13. 13. 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 metametamodel 13 FILENAMs.PPT/ 6-Feb-04 / PSe Tampere University of Technology
  14. 14. Parallel Instances of MOF Layers 14 FILENAMs.PPT/ 6-Feb-04 / PSe Tampere University of Technology
  15. 15. MOF Technology Mappings 15 FILENAMs.PPT/ 6-Feb-04 / PSe Tampere University of Technology
  16. 16. Presentation Outline 1. Introduction to Metamodeling 2. Introduction to MOF 3. MOF in Detail 4. MOF and Unified Modeling Language 5. Concluding Remarks 16 FILENAMs.PPT/ 6-Feb-04 / PSe Tampere University of Technology
  17. 17. 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 17 FILENAMs.PPT/ 6-Feb-04 / PSe Tampere University of Technology
  18. 18. 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. 18 FILENAMs.PPT/ 6-Feb-04 / PSe Tampere University of Technology
  19. 19. 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. 19 FILENAMs.PPT/ 6-Feb-04 / PSe Tampere University of Technology
  20. 20. MOF Model Package Overview 20 FILENAMs.PPT/ 6-Feb-04 / PSe Tampere University of Technology
  21. 21. Differences Between MOF and UML MOF UML Binary associations N-ary associations No AssociationClasses or Qualifiers AssociationClass, Qualifier Direct References Navigation through Associations Generalization and Dependency are Associations Generalization and Dependency are metaclasses No support for templates Template metaclass Subset of CORBA primitive data types and constructors No CORBA awareness 21 FILENAMs.PPT/ 6-Feb-04 / PSe Tampere University of Technology
  22. 22. Presentation Outline 1. Introduction to Metamodeling 2. Introduction to MOF 3. MOF in Detail 4. MOF and Unified Modeling Language 5. Concluding Remarks 22 FILENAMs.PPT/ 6-Feb-04 / PSe Tampere University of Technology
  23. 23. Three-Layer Example M2. Metamodel +participant Class 1 0..* +association name : String 1 +type AssociationEnd name : String multiplicity : Multiplicity 0..1 2..* +connection 0..* +feature 1 Attribute Association M1. Model Person +owner 1..* name : String +ownedCar 0..* Car name : String yearOfPurchase: Integer M0. Instance Joni : Person owner Avensis : Car yearOfPurchase := 1999 23 FILENAMs.PPT/ 6-Feb-04 / PSe Tampere University of Technology
  24. 24. Model vs. View M1-model as a UML class diagram Person +owner +ownedCar 1..* name : String Car 0..* name : String yearOfPurchase: Integer M1-model as a M2-level instance owner : AssociationEnd multiplicity=[1,*] aggregationKind=none : Association connection ownedCar : AssociationEnd connection multiplicity=[0,*] aggregationKind=none participant participant Person : Class Car : Class feature feature feature name : Attribute yearOfPurchase : Attribute name : Attribute type=String type=Integer type=String 24 FILENAMs.PPT/ 6-Feb-04 / PSe Tampere University of Technology
  25. 25. 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), and 3. actions connected to one or more participants (actions have parameters, a guard, and method body) c Car yearOfPurchase: Integer new_car_buyer (name) context foo not exists p2:Person :: p2.name=name own owner 0..1 p(name) || own(p,c) new p inv: (self.name=“Joni” or self.name=“Reima”) implies self.car.name=“Avensis” Person name: String 25 FILENAMs.PPT/ 6-Feb-04 / PSe Tampere University of Technology
  26. 26. HeaVy Metamodel / Abstract Syntax M2. HeaVy Metamodel +participant Participant 1 0..* +association name : String AssociationEnd name : String multiplicity : Multiplicity 2 +connection 1 Class name : String Activity name : String 1 1 0..* 0..* c Association name : String +parameter 0..* yearOfPurchase: Integer new_car_buyer (name) not exists p2:Person :: p2.name=name own owner 0..1 p(name) || own(p,c) 0..* +feature Attribute name : String type : String 0..* +guard Parameter Guard new p Person name: String expression : String name : String type : String 0..* +action 26 FILENAMs.PPT/ 6-Feb-04 / PSe Car Action expression : String Tampere University of Technology
  27. 27. 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) 27 FILENAMs.PPT/ 6-Feb-04 / PSe Tampere University of Technology
  28. 28. 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 HeaVy metamodel 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 28 FILENAMs.PPT/ 6-Feb-04 / PSe Tampere University of Technology
  29. 29. 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 29 FILENAMs.PPT/ 6-Feb-04 / PSe Tampere University of Technology
  30. 30. 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 HeaVy activity) 30 FILENAMs.PPT/ 6-Feb-04 / PSe Tampere University of Technology
  31. 31. Using UML Profiles, cont’d <<metaclass>> Parameter name : String 1 <<metaclass>> Constraint * UML Metamodel HeaVy Profile HGuard body : BooleanExpression 31 FILENAMs.PPT/ 6-Feb-04 / PSe +type Classifier 1 +specification 0..1 0..1 <<metaclass>> Operation 0..* name : String +feature <<stereotype>> <<stereotype>> <<stereotype>> body: ProcedureExpr * name : String name : String body : BooleanExpression Method +parameter <<metaclass>> +constraint * <<metaclass>> <<stereotype>> +constraint 1 <<stereotype>> 1 HActivity +feature 1 <<stereotype>> 1 HSignature Tampere University of Technology
  32. 32. A UML Metamodel Instance of HeaVy Model add_owner (id, name) not exists b2:Book :: b2.id=id new p Person id: Integer name: String p(id, name) <<HGuard>> : Constraint body="not exists b2:Book :: b2.id=id" id : Attribute <<HActivity>> <<HSignature>> : Operation add_owner : Classifier Person : Class type=Integer name : Attribute type=String id : Parameter : AssociationEnd new p : AssociationEnd name : Parameter : Association : Method body="p(id,name)" 32 FILENAMs.PPT/ 6-Feb-04 / PSe Tampere University of Technology
  33. 33. 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 MOF re-uses the same notation • • • but some constructs are ambiguous and even inconsistent UML specification is very large and complex MOF specification is compact but restrictive • • but the tools are usually weak and not metamodel aware gives flexibility but enforcement requires conventions or proprietary tools MOF metamodeling is harder to grasp but quite powerful UML already includes an extensive portion of necessary software modeling constructs UML defines a well-established notation UML profile mechanism is very loosely defined How much does one want to reuse the UML semantics? 33 FILENAMs.PPT/ 6-Feb-04 / PSe Tampere University of Technology
  34. 34. UML Metamodel Excerpt (Core::Structure) Parameter +parameter 0..1 Operation * name : String +specification * 1 name : String body: ProcedureExpression 0..* +feature +type 1 Constraint name : String body : BooleanExpression +constraint * 0..1 Classifier +participant 1 name : String 1 Method +type 0..1 0..* +association AssociationEnd name : String multiplicity : Multiplicity 2..* 0..* +feature Attribute 34 FILENAMs.PPT/ 6-Feb-04 / PSe 1 Association Tampere University of Technology
  35. 35. Presentation Outline 1. Introduction to Metamodeling 2. Introduction to MOF 3. MOF in Detail 4. MOF and Unified Modeling Language 5. Concluding Remarks 35 FILENAMs.PPT/ 6-Feb-04 / PSe Tampere University of Technology
  36. 36. 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” 36 FILENAMs.PPT/ 6-Feb-04 / PSe Tampere University of Technology
  37. 37. Questions? [see if I care] “When you can’t beat them, move one metalevel higher. “ -Author you puny instances…. 37 FILENAMs.PPT/ 6-Feb-04 / PSe Tampere University of Technology
  38. 38. 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 • • • • • • • unlike with data driven systems, where metadata was local need to trace information need to implement and enforce standards need to provide reference points • • there is a need to trace data flows between systems there is a need to understand meaning and context of data elements “reflects the real world” new information systems industry standard • single reference point throughout the enterprise • very much in line with the MDA approach! 38 FILENAMs.PPT/ 6-Feb-04 / PSe Tampere University of Technology
  1. A particular slide catching your eye?

    Clipping is a handy way to collect important slides you want to go back to later.

×