Mof

Metamodeling and Meta-Object
Facility (MOF)

Petri Selonen
8109103 Software Engineering Theory
Spring 2004

Tampere University of Technology
1 FILENAMs.PPT/ 6-Feb-04 / PSe

Presentation Outline

1. Introduction to Metamodeling
2. Introduction to MOF
3. MOF in Detail
4. MOF and Unified Modeling Language
5. Concluding Remarks


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!


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:
+owner +ownedCar
Person Car
1..* 0..*
name : String name : String
yearOfPurchase: Integer

Application model
"metalevel" boundary
Model instance
owner
Joni : Person Avensis : Car
yearOfPurchase := 1999


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


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


Four-Layer Metadata Architecture



3. MOF in Detail


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


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!


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


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


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


Parallel Instances of MOF Layers


MOF Technology Mappings



3. MOF in Detail


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


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.


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.


MOF Model Package Overview


Differences Between MOF and UML

MOF UML
Binary associations N-ary associations

No AssociationClasses or AssociationClass, Qualifier
Qualifiers
Direct References Navigation through
Associations
Generalization and Generalization and
Dependency are Associations Dependency are metaclasses
No support for templates Template metaclass

Subset of CORBA primitive No CORBA awareness
data types and constructors



3. MOF in Detail


Three-Layer Example
M2. Metamodel
+participant 0..*
Class AssociationEnd
1 +association
1 +type 0..1 multiplicity : Multiplicity
2..* +connection

0..* +feature 1

Attribute Association

M1. Model

+owner +ownedCar
Person Car
1..* 0..*

M0. Instance
owner
Joni : Person Avensis : Car
yearOfPurchase := 1999


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

+owner +ownedCar
Person Car
1..* 0..*

M1-model as a M2-level instance

owner : : Association ownedCar :
AssociationEnd AssociationEnd
multiplicity=[1,*] connection connection multiplicity=[0,*]
aggregationKind=none aggregationKind=none

participant participant

Person : Class Car : Class

feature feature feature
yearOfPurchase
name : Attribute name : Attribute
: Attribute
type=String type=Integer type=String


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
new_car_buyer yearOfPurchase: Integer
(name) context foo
not exists p2:Person ::
p2.name=name own inv: (self.name=“Joni” or
self.name=“Reima”) implies
p(name) || own(p,c) owner 0..1 self.car.name=“Avensis”

new p Person
name: String


HeaVy Metamodel / Abstract Syntax
M2. HeaVy Metamodel
+participant 0..*
Participant AssociationEnd
1 +association
multiplicity : Multiplicity
2 +connection

1

Class Activity Association c Car
new_car_buyer yearOfPurchase: Integer
name : String name : String name : String (name)
1 1 0..* 0..* not exists p2:Person ::
p2.name=name own

p(name) || own(p,c) owner 0..1
0..* +feature 0..* +parameter 0..* +guard
new p Person
Attribute Parameter Guard name: String

name : String name : String expression : String
type : String type : String

0..* Action
+action
expression : String


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)


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


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


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)


Using UML Profiles, cont’d

<<metaclass>> <<metaclass>>
Parameter Method
+parameter
name : String body: ProcedureExpr
*

1 +type 1 +specification
0..1
<<metaclass>> +constraint <<metaclass>> <<metaclass>>
Constraint * * Classifier Operation
name : String name : String 0..1 0..* name : String
+feature
body : BooleanExpression

UML Metamodel
<<stereotype>> <<stereotype>>
<<stereotype>>
HeaVy Profile

<<stereotype>> +constraint <<stereotype>> +feature <<stereotype>>
HGuard 1 1 HActivity 1 1 HSignature
body : BooleanExpression


A UML Metamodel Instance of HeaVy Model

add_owner
(id, name)
Person
new p
not exists b2:Book :: b2.id=id
id: Integer
name: String
p(id, name)

<<HGuard>>
: Constraint
body="not exists
b2:Book :: b2.id=id" id : Attribute
<<HActivity>> type=Integer
add_owner : Person : Class
<<HSignature>>
Classifier
: Operation
name : Attribute
type=String
id : Parameter
new p :
: AssociationEnd
AssociationEnd

name : Parameter
: Association

: Method
body="p(id,name)"


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?


UML Metamodel Excerpt (Core::Structure)

+parameter 0..1 +specification *
Parameter Operation Method
* 1
name : String name : String body:
0..* +feature ProcedureExpression

+type
1 0..1
+participant 0..*
Constraint +constraint Classifier AssociationEnd
1 +association
*
name : String name : String name : String
body : BooleanExpression 1 +type 0..1 multiplicity : Multiplicity
2..*

0..* +feature 1

Attribute Association



3. MOF in Detail


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”


Questions?
[see if I care]

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


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!


Mof

Recommandé

Recommandé

Contenu connexe

En vedette

En vedette (18)

Similaire à Mof

Similaire à Mof (20)

Plus de bharati k

Plus de bharati k (7)

Dernier

Dernier (20)

Mof