Successfully reported this slideshow.
We use your LinkedIn profile and activity data to personalize ads and to show you more relevant ads. You can change your ad preferences anytime.



Published on

Published in: Education
  • Be the first to comment

  • Be the first to like this


  1. 1. Metamodeling and Meta-Object Facility (MOF) Petri Selonen 8109103 Software Engineering Theory Spring 2004 Tampere University of Technology1 FILENAMs.PPT/ 6-Feb-04 / PSe
  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 Tampere University of Technology2 FILENAMs.PPT/ 6-Feb-04 / PSe
  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! Tampere University of Technology3 FILENAMs.PPT/ 6-Feb-04 / PSe
  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: +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 Tampere University of Technology4 FILENAMs.PPT/ 6-Feb-04 / PSe
  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 Tampere University of Technology5 FILENAMs.PPT/ 6-Feb-04 / PSe
  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 meta- metadata • Next slide presents an example of a four-layer metadata architecture conforming similar to the ones presented by ISO Tampere University of Technology6 FILENAMs.PPT/ 6-Feb-04 / PSe
  7. 7. Four-Layer Metadata Architecture Tampere University of Technology7 FILENAMs.PPT/ 6-Feb-04 / PSe
  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 Tampere University of Technology8 FILENAMs.PPT/ 6-Feb-04 / PSe
  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 Tampere University of Technology9 FILENAMs.PPT/ 6-Feb-04 / PSe
  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 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! Tampere University of Technology10 FILENAMs.PPT/ 6-Feb-04 / PSe
  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 • 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 Tampere University of Technology11 FILENAMs.PPT/ 6-Feb-04 / PSe
  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 Tampere University of Technology12 FILENAMs.PPT/ 6-Feb-04 / PSe
  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 meta- metamodel Tampere University of Technology13 FILENAMs.PPT/ 6-Feb-04 / PSe
  14. 14. Parallel Instances of MOF Layers Tampere University of Technology14 FILENAMs.PPT/ 6-Feb-04 / PSe
  15. 15. MOF Technology Mappings Tampere University of Technology15 FILENAMs.PPT/ 6-Feb-04 / PSe
  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 Tampere University of Technology16 FILENAMs.PPT/ 6-Feb-04 / PSe
  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 Tampere University of Technology17 FILENAMs.PPT/ 6-Feb-04 / PSe
  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. Tampere University of Technology18 FILENAMs.PPT/ 6-Feb-04 / PSe
  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. Tampere University of Technology19 FILENAMs.PPT/ 6-Feb-04 / PSe
  20. 20. MOF Model Package Overview Tampere University of Technology20 FILENAMs.PPT/ 6-Feb-04 / PSe
  21. 21. 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 Tampere University of Technology21 FILENAMs.PPT/ 6-Feb-04 / PSe
  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 Tampere University of Technology22 FILENAMs.PPT/ 6-Feb-04 / PSe
  23. 23. Three-Layer Example M2. Metamodel +participant 0..* Class AssociationEnd 1 +association name : String name : String 1 +type 0..1 multiplicity : Multiplicity 2..* +connection 0..* +feature 1 Attribute Association M1. Model +owner +ownedCar Person Car 1..* 0..* name : String name : String yearOfPurchase: Integer M0. Instance owner Joni : Person Avensis : Car yearOfPurchase := 1999 Tampere University of Technology23 FILENAMs.PPT/ 6-Feb-04 / PSe
  24. 24. Model vs. View M1-model as a UML class diagram +owner +ownedCar Person Car 1..* 0..* name : String name : String yearOfPurchase: Integer 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 Tampere University of Technology24 FILENAMs.PPT/ 6-Feb-04 / PSe
  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 new_car_buyer yearOfPurchase: Integer (name) context foo not exists p2:Person :: own inv: (“Joni” or“Reima”) implies p(name) || own(p,c) owner 0..1“Avensis” new p Person name: String Tampere University of Technology25 FILENAMs.PPT/ 6-Feb-04 / PSe
  26. 26. HeaVy Metamodel / Abstract Syntax M2. HeaVy Metamodel +participant 0..* Participant AssociationEnd 1 +association name : String name : String 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 :: 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 Tampere University of Technology26 FILENAMs.PPT/ 6-Feb-04 / PSe
  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 | 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) Tampere University of Technology27 FILENAMs.PPT/ 6-Feb-04 / PSe
  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 Tampere University of Technology28 FILENAMs.PPT/ 6-Feb-04 / PSe
  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 Tampere University of Technology29 FILENAMs.PPT/ 6-Feb-04 / PSe
  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) Tampere University of Technology30 FILENAMs.PPT/ 6-Feb-04 / PSe
  31. 31. 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 Tampere University of Technology31 FILENAMs.PPT/ 6-Feb-04 / PSe
  32. 32. A UML Metamodel Instance of HeaVy Model add_owner (id, name) Person new p not exists b2:Book :: id: Integer name: String p(id, name) <<HGuard>> : Constraint body="not exists b2:Book ::" 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)" Tampere University of Technology32 FILENAMs.PPT/ 6-Feb-04 / PSe
  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 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? Tampere University of Technology33 FILENAMs.PPT/ 6-Feb-04 / PSe
  34. 34. 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 Tampere University of Technology34 FILENAMs.PPT/ 6-Feb-04 / PSe
  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 Tampere University of Technology35 FILENAMs.PPT/ 6-Feb-04 / PSe
  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” Tampere University of Technology36 FILENAMs.PPT/ 6-Feb-04 / PSe
  37. 37. Questions? [see if I care] “When you can’t beat them, move one metalevel higher. “ -Author you puny instances…. Tampere University of Technology37 FILENAMs.PPT/ 6-Feb-04 / PSe
  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 • 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! Tampere University of Technology38 FILENAMs.PPT/ 6-Feb-04 / PSe