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. MDA’s Modeling Level Hierarchy
Meta- Meta-Model
Level M3
MOF
+ OCL
Meta-Model
MOF
+ OCL
Level M2
Model
UML
+ OCL
AND
-OR
UML
Profile
AND
-OR
Special Purpose
Modeling Language
Level M1
Running
Application
Level M0
Implementation
Running on Platform

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 reader 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. MOF Meta-Model Package Structure
UML2 Infra-Structure
MOF Meta-Model Package Structure
MOF2

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:
Instances unique identifiers
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 contains objects o2, which in turns has property p2 which contains object o3, when useContainment() is true then the extent for o1 includes {o1, o2, o3}
Elements(): returns extent members
URIExtent: extent where OIDs are URIs instead 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.
URI syntax and examples
scheme
authority
path
query
fragment
foo;
///example.com:8042
/over/there
?name=ferret
#nose
urn:
example:animal:ferret:nose

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

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. 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
D1, D2
Meta-Models
in D2
GUI Editor for
D2 Diagrams
Model in Language D1
GUI Editor for
D1 Diagrams
D1 Model
Repository

19. Tailored Modeling: 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
D Meta-Model
in MOF
UML
Editor
Model in Dedicated
Language D
GUI Editor for
D Diagrams
EMF
generates
Menu Editor for
D Diagrams

20. 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
UML2
Meta-Model
in MOF
<< reuse >>
D Meta-Model
in MOF
UML
Editor
Model in Dedicated
Language D
GUI Editor for
D Diagrams
EMF
generates
Menu Editor for
D Diagrams

21. 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
UML2
Meta-Model
in MOF
UML
Editor
EMF
metaclass
Package
Class
Property
Association
Profile
ProfileApplication *
Extension
Stereotype
Image
icon
ExtensionEnd
type
ownedEnd
Model in Dedicated
UML2 Profile P
P UML2 Profile

22. <<agent>> <<agent>>
UML2 Profiles
metaclass
Package
Class
Property
Association
Profile
ProfileApplication *
Extension
Stereotype
Image
icon
ExtensionEnd
type
ownedEnd
<<agent>>
ag1
<<agent>>
ag2
<<proxy>>
// 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)
// 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)
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. UML2 Profiles X X // Creating S1 and S2 stereotypes
s1 = Factory.create(metaclass:Stereotype)
s1.set(property:name, value:”<<S1>>”)
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)
metaclass
Package
Class
Property
Association
Profile
ProfileApplication *
Extension
Stereotype
Image
icon
ExtensionEnd
type
ownedEnd
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. UML2 Extension via Sub-Metaclasses
superclass
// 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:name, value:”S12”)
// 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) *
Class
ownedAttribute
Property
menberEnd
Association C1 C2 S1 S2
neither direct
nor inherited
association
between
C1 and C2
S2 a
sub-metaclass
of C2
S1 a
of C1
Allowed
S1 and S2
i1: S1
i1 and i2 can be linked by an instance of S12
but no reuse of concrete syntax of C1 and C2
S12

25. UML2 Extension via Sub-MetaClasses and Stereotype
Package
Class
Property
Association
Profile
ProfileApplication *
Extension
Stereotype
Image
icon
ExtensionEnd
type
ownedEnd
Class
Property
Association
ownedAttribute
menberEnd
superclass * C1 C2 S1 S2
neither direct
nor inherited
association
between
C1 and C2
S1 both a
sub-metaclass
and a stereotype
of C1
Allowed
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
aS1S2

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-classes g1, ..., 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 specialize g1, ..., gn (respectively)

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

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

29. EnvironmentStateModel
UML2 Profile for MAS
MASML Meta-Model
UML2 Meta-Model
OCL Constraints:
context Agent inv:interface let 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:agent abstraction.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