Transcript MOF Meta-Models and UML Profiles Jacques Robin Ontologies Reasoning Components Agents Simulations Outline      MDA’s modeling level hierarchy Purposes of meta-models in MDA Meta-Object Facility (MOF): a standard language for.

MOF Meta-Models and UML Profiles
Jacques Robin
Ontologies
Reasoning
Components
Agents
Simulations
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
MDA’s Modeling Level Hierarchy
Level M3
Level M2
MetaMeta-Model
MOF
+ OCL
Meta-Model
MOF
+ OCL
Level M1
Model
Level M0
Running
Application
UML
+ OCL
AND
-OR
UML
Profile
AND
-OR
Special Purpose
Modeling Language
Implementation
Running on Platform
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 metamodels
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)
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
UML2 Infra-Structure
MOF
Meta-Model
Package Structure
MOF2
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
EMOF: Basic Package
EMOF: Basic Package
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
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
foo;
///example.com:8042 /over/there
urn:
path
example:animal:ferret:nose
query
fragment
?name=ferret
#nose
EMOF: Extension Package
 Any element can be tagged to extend modeling language vocabulary
CMOF: Construct Package
CMOF: Reflection
To identify operation
parameters by names
instead of merely by
position
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




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:
1. No MOF, no UML (the Microsoft way)
 Create and use domain-specific or even application-specific meta-modeling,
modeling and model transformation languages
2. 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
3. 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
4. UML Profile approach (the IBM way)

Define specializations of UML abstractions by stereotyping UML meta-model
elements
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
D1, D2
Meta-Models
in D2
GUI Editor for
D1 Diagrams
Model in
Language D1
D1 Model
Repository
Tailored Modeling: Pure MOF Approach
 Pure MOF approach
 Does not use UML
 Advantages:
UML
Editor
D Meta-Model
in MOF
GUI Editor for
D Diagrams
Model in
Dedicated
Language D
 No need to artificially relate new
abstractions to UML abstractions
 Drawbacks:
 Need to define entirely new metamodel 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
EMF
generates
Menu Editor for
D Diagrams
Tailored Modeling:
Meta-Model and MOF Reuse Operators
 Advantages:
 Reuses consolidated elements
from UML2 meta-model
UML2
Meta-Model
in MOF
 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
D Meta-Model
in MOF
GUI Editor for
D Diagrams
Model in
Dedicated
Language D
EMF
generates
Menu Editor for
D Diagrams
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
Package
Profile
*
*
ProfileApplication
Class
*
Stereotype
UML
Editor
metaclass
*
EMF
P UML2 Profile
Model in
Dedicated
UML2 Profile P
*
ExtensionEnd
ownedEnd
type
Extension
icon
Image
UML2
Meta-Model
in MOF
Property
Association
UML2 Profiles
Package
Profile
*
*
ProfileApplication
Class
*
Stereotype
metaclass
*
*
ExtensionEnd
ownedEnd
type
Extension
<<agent>>
ag1
icon
Image
// 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)
a2ee.set(property:type, value:a)
Property
Association
// 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)
<<proxy>>
<<agent>>
ag2
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)
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)
Package
Profile
*
ProfileApplication
Class
*
Stereotype
metaclass
*
*
ExtensionEnd
ownedEnd
type
Extension
icon
Image
S1 only a
stereotype of C1
but not a
sub-metaclass
of C1
Property
C1
S1
i1: <<S1>> C1
instance i1
cannot be of S1
only of C11
w/ property
stereotype = S1
neither direct
nor inherited
association
between
C1 and C2
X
No allowed
association
between
S1 and S2
X
Association
C2
S2
S2 only a
stereotype of C2
but not a
sub-metaclass
of C2
i2: <<S2>> C2
instance i2
cannot be of S2
only of C2
w/ property
stereotype = S2
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
UML2 Extension via Sub-Metaclasses
// 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”)
superclass
// Creating instanceSpecification i1 of S1
i1 = Factory.create(metaclass:InstanceSpecification)
i1.set(property:name, value:”i1”)
i1.set(property:classifier, value:s1)
*
Class
ownedAttribute
// Creating instanceSpecification i2 of S2
i2 = Factory.create(metaclass:InstanceSpecification)
i2.set(property:name, value:”i2”)
i2.set(property:classifier, value:s2)
Property
menberEnd
Association
// Creating instanceSpecification of S12
is12= Factory.create(metaclass:InstanceSpecification)
is12.set(property:classifier, value:s12)
C1
S1 a
sub-metaclass S1
of C1
i1: S1
neither direct
nor inherited
association
between
C1 and C2
S12
Allowed
association
between
S1 and S2
C2
S2
S2 a
sub-metaclass
of C2
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
and Stereotype
Package
Class
*
Profile
Stereotype
*
*
*
ExtensionEnd
ownedEnd
type
*
*
superclass
metaclass
Extension
icon
ProfileApplication
Class
ownedAttribute
Image
Property
Association
Property
menberEnd
S1 both a
sub-metaclass
and a stereotype
of C1
C1
S1
i1: <<Si1>> S1
neither direct
nor inherited
association
between
C1 and C2
aS1S2
Allowed
association
between
S1 and S2
Association
C2
S1 both a
sub-metaclass
and a stereotype
of C1
S2
i2: <<Si2>> S2
i1 and i2 can be linked by an instance aS1S2
and reuse of concrete syntax of C1 and C2
A UML2 Profile Definition Process
1. Create a special purpose meta-model of an application domain,
language or platform
2. Identify the top-level meta-classes s1, ..., sn of this meta-model (i.e.,
those with no generalizations)
3. Identify in the UML2 meta-model, the concrete meta-classes
g1, ..., gn that are natural semantic generalizations of s1, ..., sn
(respectively)
4. Extend the UML2 meta-model by defining s1, ..., sn as sub-metaclasses of g1, ..., gn (respectively)
5. Add OCL constraints on s1, ..., sn that specify how they specialize
g1, ..., gn (respectively)
MOF Meta-Model of a Simple Multi-Agent
Simulations Modeling Language (MASML)
MAS
ReflexAgent
ReasoningComponent
1..*
1..*
MAS
Environment
Sensor
1..*
ReasoningComponent
Actuator
Sensor
1..*
AgentAction
AutomataAgent
ReflexAgent
ReflexComponent
1..*
Actuator
GoalBasedAgent
AutomataAgent
1..*
Sensor
Agent
1..*
1..*
Percept
2..*
Agent
EnvironmentStateModel
Agent
4..*
PercpetInterpretationComponent
ReasoningComponent
GoalBasedAgent
Goal
AutomataAgent
3..*
ReasoningComponent
EnvironmentStateModel
ModelInitializationComponent
GoalInitializationComponent
RamificationComponent
GoalUpdateComponent
ModelBasedBehaviorStrategyComponent
GoalBasedBehaviorStrategyComponent
Actuator
ModelBasedBehaviorStrategyComponent
MOF Meta-Model of a Simple Multi-Agent
Simulations Modeling Language (MASML)
KBAgent
Agent
ReflexKBAgent
ReasoningComponent
KBAgent
1..*
KnowledgeBase
KBComponent
1..*
PersistentKB
1..*
VolatileKB
ReflexAgent
ReflexComponent
ReflexKBAgent
ReflexKBComponent
ReflexKB
KBAgent
KBComponent
PersistentKB
0..*
context ReflexKBComponent inv Volat ileKB.isEmpty()
GoalBasedKBAgent
AutomataKBAgent
GoalBasedAgent
GoalBasedKBAgent
KBSentence
6..*
AutomataAgent
KBComponent
3 ..*
4 ..*
AutomataKBAgent
4..*
KBComponent
4 ..*
KBAgent
GoalKB
EnvironmentStateModelKB
VolatileKB
Goal
EnvironmentStateModel
KBAgent
VolatileKB
EnvironmentStateModelKB
EnvironmentStateModel
UML2 Profile for MAS
 MASML
Meta-Model
 UML2
Meta-Model
MAS
Component
Environment
isActive = true
Agent
ReasoningComponent
Component
Sensor
Interface
Actuator
Percept
AgentAction
Signal
EnvironmentStateModel
KnowledgeBase
KBSentence
Model
OCL Constraints:
1. context Agent inv:interface
let r = required and (i = Sensor or Actuator)
in r.oclIsKindOf(i)
2. context Agent inv:signal
let s = required.ownedReception.signal
in s.oclIsKindOf(Percept or AgentAction)
3. context Sensor inv:agent
abstraction.oclIsKindOf(Agent)
4. ...
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