1 / 30

MOF Meta-Models and UML Profiles

MOF Meta-Models and UML Profiles. Jacques Robin. Outline. MDA’s modeling level hierarchy Purposes of meta-models in MDA Meta-Object Facility (MOF): a standard language for meta-modeling Modeling with software abstractions beyond UML UML Profiles Multi-Agent Simulations Others.

truda
Download Presentation

MOF Meta-Models and UML Profiles

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  1. MOF Meta-Models and UML Profiles Jacques Robin

  2. Outline • MDA’s modeling level hierarchy • Purposes of meta-models in MDA • Meta-Object Facility (MOF): a standard language for meta-modeling • Modeling with software abstractions beyond UML • UML Profiles • Multi-Agent Simulations • Others

  3. Meta-Meta-Model Meta-Model Model MDA’s Modeling Level Hierarchy MOF + OCL Level M3 MOF + OCL Level M2 UML + OCL AND -OR UML Profile AND -OR Special Purpose Modeling Language Level M1 Running Application Implementation Running on Platform Level M0

  4. Purposes of Meta-Models in MDA • Define modeling languages • Their abstract syntax • Their formal semantics • Define source and target anchors for model transformations • What about APIs and Libraries? • They are all written in a given language • They are thus best viewed as built-in model elements to reuse than as part of a modeling language • Thus they should be part of platform models, not of language meta-models

  5. What is Meta-Modeling? • Meta-Modeling vs. Modeling • Similar formalisms but different purposes • One models applications and meta-models languages and formalisms • Meta-Modeling vs. Ontology Engineering • An ontology is a domain knowledge model, not a meta-model • But a domain is an intermediate level of abstraction and generality between application and language • Meta-Modeling Methodologies • Uncharted territory • Should integrate and reuse principles and techniques from: • Application modeling (formalism similarities) • Language design (purpose similarities) • Ontology engineering (process similarities)

  6. OMG’s Meta-Object Facility (MOF) • Key idea: • Instead of defining entirely new languages for the M2 and M3 levels • Reuse structural core of mature, well-known, well-tooled M1 level language (UML Infra-Structure) • Advantages of MOF over traditional formalisms such as grammars to define languages: • Abstract instead of concrete syntax (more synthetic) • Visual notation instead of textual notation (clarity) • Graph-based instead of tree-based (abstracts from any reading order) • Entities (classes) can have behavior (grammar symbols do not) • Relations between elements include generalization and undirected associations instead of only composition and order • Specification reuse through inheritance • Additional advantages with OCL: • Allows expressing arbitrary complex constraints among language elements (more expressive) • Allows defining formal semantics without mathematical syntax

  7. UML2 Infra-Structure MOF2 MOFMeta-Model Package Structure

  8. Essential MOF (EMOF) Meta-Model • Minimum bootstrap elements for modeling, meta-modeling and MDA tools • Includes only classes, attributes, operations, packages and primitive types from UML2 Infra-Structure • Does not includes associations, which are replaces by references (properties whose values are classes instead of primitive types) • Basis for Ecore the metametamodel implemented by the Eclipse Modeling Framework • Any CMOF meta-model can be transformed into an EMOF meta-model • EMOF extends UML2 Infra-Structure with elements to represent: • Unique identifiers of instances/objects • Their reflective relations with classes • Minimal tag-value based extension mechanism

  9. EMOF: Basic Package

  10. EMOF: Basic Package

  11. EMOF: Reflection and Common Packages • Views any model element as an instance of a meta-model meta-class • Provide operations that cut across MDA layers to manipulate model and meta-model elements as meta-objects of their meta-classes • Provides meta-meta-model of a generic reflective API to programmatically manipulate models

  12. EMOF Meta-Model: Identifier Package • OID: class property with feature isID true or URI • Extent: OID value range • useContainment(): when true, all contained elements are added to containing element’s extents(recursive containment) • e.g., if object o1 has property p1 which containsobjects o2, which in turns has property p2 whichcontains object o3, when useContainment() is truethen the extent for o1 includes {o1, o2, o3} • Elements(): returns extent members • URIExtent: extent where OIDs are URIsinstead of properties • A URI (Universal Resource Identifier) is either, • A URL (Universal Resource Locator) providing a name for a resource accessible on a network and a mean to retrieve it; or • A URN (Universal Resource Name) providing a name for a resource in a namespace.

  13. Any element can be tagged to extend modeling language vocabulary EMOF: Extension Package

  14. CMOF: Construct Package

  15. CMOF: Reflection To identify operation parameters by names instead of merely by position

  16. Is UML2 Enough? Too Much? • UML2 covers domain and platform independent modeling concepts for the object-oriented, relational, imperative, concurrent, event-based, distributed and constraint (through OCL) computational paradigms • It does not cover: • Object-oriented reflection • Functional paradigm which includes powerful generative meta-programming and type inference • Rule-based paradigm which includes powerful model transformation mechanisms and general logical inference • Domain-specific modeling concepts • Platform-specific abstractions • So it is not enough for key applications and domains • UML2 thus needs an extension mechanism • But isn’t UML2 rather already too much? • Yes, it is only a vast menu of concepts only a few of which are practically useful for a particular application or application domain • To be highly reusable it is also necessarily very under-constrained • So UML2 also needs a reduction mechanism allowing a methodology to choose a relevant subset of its metamodel and add more stringent OCL constraints among the elements of such subset

  17. Tailored Modeling with Software Abstractions Beyond UML • Software abstractions beyond UML can be classified as: • Specializing UML abstractions (i.e., UML2 meta-model elements) • Generalizing UML abstractions • Being unrelated to UML abstractions • Approaches: • No MOF, no UML (the Microsoft way) • Create and use domain-specific or even application-specific meta-modeling, modeling and model transformation languages • Pure MOF, no UML: • Create domain-specific or application-specific modeling language that does not reuse any UML meta-model element but which is specified as a MOF meta-model • MOF meta-model reuse operators applied to UML packages: • Define MOF meta-model of new modeling language that reuses UML meta-model elements and add new ones • UML Profile approach (the IBM way) • Define specializations of UML abstractions by stereotyping UML meta-model elements

  18. D1, D2 Meta-Models in D2 Model in Language D1 Tailored Modeling: Domain-Specific Meta-Modeling and Modeling Approach • Advantage: • No need to understand complex, large and at times under-examplified MOF2 and UML2 specifications • Drawbacks: • For each new domain or application • Need to redefine entire MDA language infra-structure alternative to OMG´s • Need to implement CASE tools for non-standard languages GUI Editor for D2 Diagrams GUI Editor for D1 Diagrams D1 Model Repository

  19. D Meta-Model in MOF Model in Dedicated Language D Tailored Modeling: Pure MOF Approach • Pure MOF approach • Does not use UML • Advantages: • No need to artificially relate new abstractions to UML abstractions • Drawbacks: • Need to define entirely new meta-model that does not reuse any elements consolidated by OMG’s long meta-modeling experience • Need to develop entirely new graphical notation and editors • Need to develop all model manipulation services (code generation, test generation, reverse engineering) that UML CASE tools already provide UML Editor GUI Editor for D Diagrams EMF generates Menu Editor for D Diagrams

  20. UML2 Meta-Model in MOF D Meta-Model in MOF Model in Dedicated Language D Tailored Modeling:Meta-Model and MOF Reuse Operators • Advantages: • Reuses consolidated elements from UML2 meta-model • Drawbacks: • Need to extend UML’s graphical editors to draw elements in D\UML2 • Need to extend model manipulation services (code generation, test generation, reverse engineering) of UML CASE to modeling elements in D\UML2 • Current MOF operators do not cover UML2 concept generalizing reuse, only reuse “as is” or as specialization << reuse >> UML Editor GUI Editor for D Diagrams EMF generates Menu Editor for D Diagrams

  21. Package Class metaclass * * * Profile Stereotype ExtensionEnd Extension ownedEnd type * icon * Image Property Association ProfileApplication UML2 Meta-Model in MOF Model in Dedicated UML2 Profile P P UML2 Profile Tailored Modeling: UML Profile Approach • UML2 meta-classes sub-categorized by stereotypes • Advantages: • Maximum reuse the entire OMG language infra-structure • Maximum reuse of UML CASE tools (no need to develop any new tool) • Drawbacks: • Risk to “artificially” recast modeling abstraction as specializations of UML ones • Little to reuse for non-object oriented modeling languages Promotes property value to the metaclass level EMF UML Editor

  22. Package Class metaclass * * * Profile Stereotype ExtensionEnd Extension ownedEnd type * icon * Image Property Association ProfileApplication UML2 Profiles // Creating agent stereotype a = Factory.create(metaclass:Stereotype) a.set(property:name, value:”<<agent>>”) // Creating Components a1 and a2 a1 = Factory.create(metaclass:Component) a1.set(property:name, value:”ag1”) a2 = Factory.create(metaclass:Component) a2.set(property:name, value:”ag2”) // Stereotyping a1 as agent a1e = Factory.create(metaclass:Extension) a1.set(property:Extension, value:a1e) a1ee = Factory.create(metaclass:ExensionEnd) a1e.set(property:ownedEnd, value:a1ee) a1ee.set(property:type, value:a) <<agent>> ag1 <<agent>> ag2 <<proxy>> // Stereotyping a2 as agent a2e = Factory.create(metaclass:Extension) a2.set(property:Extension, value:a2e) a2ee = Factory.create(metaclass:ExensionEnd) a2e.set(property:ownedEnd, value:a2ee) a2ee.set(property:type, value:a) // Create proxy stereotype p = Factory.create(metaclass:Stereotype) p.set(property:name, value:”<<proxy>>”) // Creating Association between a1 and a2 a12 = Factory.create(metaclass:Association) a12e1 = Factory.create(metaclass:Property) a12e2 = Factory.create(metaclass:Property) a1.set(property:ownedAttributes, value:a12e1) a2.set(property:ownedAttributes, value:a12e2) a12.set(property:memberEnd, value:a12e1) a12.set(property:memberEnd, value:a12e1) Component Associaton Agent Proxy // Stereotyping a12 as proxy a12e = Factory.create(metaclass:Extension) a12.set(property:Extension, value:a12e) a12ee = Factory.create(metaclass:ExensionEnd) a12e.set(property:ownedEnd, value:a12ee) a12ee.set(property:type, value:p)

  23. Package Class metaclass * * * Profile Stereotype ExtensionEnd Extension ownedEnd type * icon * Image Property Association ProfileApplication UML2 Profiles // Creating S1 and S2 stereotypes s1 = Factory.create(metaclass:Stereotype) s1.set(property:name, value:”<<S1>>”) s1 = Factory.create(metaclass:Stereotype) s1.set(property:name, value:”<<S2>>”) // Creating classes C1 and C2 c1 = Factory.create(metaclass:Class) c1.set(property:name, value:”C1”) c2 = Factory.create(metaclass:Class) c2.set(property:name, value:”C2”) // Creating instanceSpecification i1 of C1 i1 = Factory.create(metaclass:InstanceSpecification) i1.set(property:name, value:”i1”) i1.set(property:classifier, value:c1) // Stereotyping i1 as <<S1>> c1e = Factory.create(metaclass:Extension) c1.set(property:Extension, value:c1e) c1ee = Factory.create(metaclass:ExensionEnd) c1e.set(property:ownedEnd, value:c1ee) c1ee.set(property:type, value:s1) // Stereotyping i2 as <<S2>> c2e = Factory.create(metaclass:Extension) c2.set(property:Extension, value:c2e) c2ee = Factory.create(metaclass:ExensionEnd) c2e.set(property:ownedEnd, value:c2ee) c2ee.set(property:type, value:s2) neither direct nor inherited association between C1 and C2 S1 only a stereotype of C1 but not a sub-metaclass of C1 C1 C2 S2 only a stereotype of C2 but not a sub-metaclass of C2 X S1 S2 No allowed association between S1 and S2 i1: <<S1>> C1 i2: <<S2>> C2 instance i1 cannot be of S1 only of C11 w/ property stereotype = S1 instance i2 cannot be of S2 only of C2 w/ property stereotype = S2 X i1 and i2 cannot be linked for lack of an association between their respective classes C1 and C2 but reuse of concrete syntax of C1 and C2

  24. neither direct nor inherited association between C1 and C2 C1 C2 S1 a sub-metaclass of C1 S2 a sub-metaclass of C2 S12 S1 S2 Allowed association between S1 and S2 i1: S1 i1: S1 i1 and i2 can be linked by an instance of S12 but no reuse of concrete syntax of C1 and C2 UML2 Extension via Sub-Metaclasses superclass // Creating instanceSpecification i1 of S1 i1 = Factory.create(metaclass:InstanceSpecification) i1.set(property:name, value:”i1”) i1.set(property:classifier, value:s1) // Creating instanceSpecification i2 of S2 i2 = Factory.create(metaclass:InstanceSpecification) i2.set(property:name, value:”i2”) i2.set(property:classifier, value:s2) // Creating instanceSpecification of S12 is12= Factory.create(metaclass:InstanceSpecification) is12.set(property:classifier, value:s12) // Creating classes C1, C2, S1, S2 c1 = Factory.create(metaclass:Class) c1.set(property:name, value:”C1”) c2 = Factory.create(metaclass:Class) c2.set(property:name, value:”C2”) s1 = Factory.create(metaclass:Class) s1.set(property:name, value:”S1”) s2 = Factory.create(metaclass:Class) s2.set(property:name, value:”S2”) // Specializing C1 by S1 and C2 by S2 s1.set(property:superclass, value:c1) s2.set(property:superclass, value:c2) // Creating Association between S1 and S2 s12 = Factory.create(metaclass:Association) s12e1 = Factory.create(metaclass:Property) s12e2 = Factory.create(metaclass:Property) s1.set(property:ownedAttributes, value:s12e1) s2.set(property:ownedAttributes, value:s12e2) s12.set(property:memberEnd, value:s12e1) s12.set(property:memberEnd, value:s12e1) s12.set(property:name, value:”S12”) * Class ownedAttribute Property menberEnd Association

  25. Package Class metaclass * * * superclass Profile Stereotype ExtensionEnd Extension ownedEnd type * * icon Class * Image Property Association ProfileApplication ownedAttribute Property menberEnd Association neither direct nor inherited association between C1 and C2 S1 both a sub-metaclass and a stereotype of C1 S1 both a sub-metaclass and a stereotype of C1 C1 C2 aS1S2 S1 S2 Allowed association between S1 and S2 i1: <<Si1>> S1 i2: <<Si2>> S2 i1 and i2 can be linked by an instance aS1S2 and reuse of concrete syntax of C1 and C2 UML2 Extension via Sub-MetaClasses and Stereotype

  26. A UML2 Profile Definition Process • Create a special purpose meta-model of an application domain, language or platform • Identify the top-level meta-classes s1, ..., sn of this meta-model (i.e., those with no generalizations) • Identify in the UML2 meta-model, the concrete meta-classesg1, ..., gn that are natural semantic generalizations of s1, ..., sn (respectively) • Extend the UML2 meta-model by defining s1, ..., sn as sub-meta-classes of g1, ..., gn (respectively) • Add OCL constraints on s1, ..., sn that specify how they specializeg1, ..., gn (respectively)

  27. MAS ReflexAgent 2..* ReasoningComponent Agent MAS Environment Agent ReasoningComponent 1..* 1..* Sensor 1..* 1..* 1..* 1..* ReflexAgent ReflexComponent Actuator Percept Sensor Actuator AgentAction 1..* AutomataAgent GoalBasedAgent AutomataAgent Agent GoalBasedAgent AutomataAgent 1..* 6..* 4..* Goal ReasoningComponent ReasoningComponent Sensor EnvironmentStateModel PerceptInterpretationComponent EnvironmentStateModel GoalInitializationComponent ModelInitializationComponent GoalUpdateComponent RamificationComponent GoalBasedBehaviorStrategyComponent ModelBasedBehaviorStrategyComponent ModelBasedBehaviorStrategyComponent Actuator MOF Meta-Model of a Simple Multi-Agent Simulations Modeling Language (MASML)

  28. ReflexKBAgent ReflexAgent ReflexComponent ReflexKBAgent ReflexKBComponent ReflexKB PersistentKB KBAgent KBComponent context ReflexKBComponent inv VolatileKB.isEmpty() GoalBasedKBAgent GoalBasedAgent AutomataKBAgent AutomataAgent 6..* GoalBasedKBAgent KBComponent 3 ..* 4 ..* 4..* AutomataKBAgent KBComponent 4 ..* KBAgent GoalKB EnvironmentStateModelKB KBAgent EnvironmentStateModelKB EnvironmentStateModel VolatileKB Goal VolatileKB EnvironmentStateModel MOF Meta-Model of a Simple Multi-Agent Simulations Modeling Language (MASML) KBAgent 1..* Agent ReasoningComponent KnowledgeBase KBSentence 1..* PersistentKB KBAgent KBComponent VolatileKB 1..* 0..*

  29. MASML Meta-Model UML2 Profile for MAS • UML2 Meta-Model • OCL Constraints: • context Agent inv:interfacelet r = required and (i = Sensor or Actuator)in r.oclIsKindOf(i) • context Agent inv:signal let s = required.ownedReception.signal in s.oclIsKindOf(Percept or AgentAction) • context Sensor inv:agentabstraction.oclIsKindOf(Agent) • ... MAS Component isActive = true Environment Agent ReasoningComponent Component Sensor Interface Actuator Percept Signal AgentAction EnvironmentStateModel KnowledgeBase Model KBSentence

  30. Available UML Profiles • By OMG: • Enterprise Application Integration (application interoperability through standard metadata) • Enterprise Distributed Object Computing (EDOC) • QoS and Fault Tolerance • Schedulability, Performance and Time • Testing • Third parties: • Enterprise Java Beans (by Java Community Process) • Software Services (by IBM, supported by Rational Software Architect UML CASE tool) • Knowledge-Based Systems (University of York) • Data Modeling (by agiledata.org) • Framework Architectures (UML-F) • Requirement Engineering with KAOS • Formal Methods in B (UML-B) • Embedded System Design

More Related