Mof kalvot

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

Metamodeling and Meta-Object Facility (MOF)

Petri Selonen8109103 Software Engineering Theory

Spring 2004


Presentation Outline

1. Introduction to Metamodeling2. Introduction to MOF3. MOF in Detail4. MOF and Unified Modeling Language5. 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:

1..*

Joni : Person Avensis : CaryearOfPurchase := 1999

owner

Personname : String

Car

name : StringyearOfPurchase: Integer

+owner

0..*

+ownedCar

"metalevel" boundary

Model instance

Application model


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



1. Introduction to Metamodeling

2. Introduction to MOF3. MOF in Detail4. MOF and Unified Modeling Language5. Concluding Remarks


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



1. Introduction to Metamodeling2. Introduction to MOF

3. MOF in Detail4. MOF and Unified Modeling Language5. Concluding Remarks


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

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



1. Introduction to Metamodeling2. Introduction to MOF3. MOF in Detail

4. MOF and Unified Modeling Language5. Concluding Remarks


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


+owner

0..*

+ownedCar

M0. Instance

M1. Model

M2. Metamodel


Model vs. View

1..*

Person : Class Car : Class

feature

Personname : String

Car


+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


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”


HeaVy Metamodel / Abstract Syntax

Classname : String

Associationname : String


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


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 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


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 HeaVyactivity)


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


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)"


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)

Classifiername : String

Association


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 *



1. Introduction to Metamodeling2. Introduction to MOF3. MOF in Detail4. MOF and Unified Modeling Language

5. Concluding Remarks


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 metalevelhigher. “ -Authoryou 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 kalvot

Education

Transcript of Mof kalvot