OntologiesReasoningComponentsAgentsSimulations
MOF Meta-Models and UML ProfilesMOF Meta-Models and UML Profiles
Jacques Robin
OutlineOutline
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 HierarchyMDA’s Modeling Level Hierarchy
Meta-Meta-Model
Level M3 MOF + OCL
Level M2 Meta-Model MOF+ OCL
RunningApplicationLevel M0 Implementation
Running on Platform
Level M1 Model UML+ OCL
UML Profile
Special Purpose Modeling Language
AND-OR
AND-OR
Purposes of Meta-Models in MDAPurposes 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
What is Meta-Modeling?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)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
MOFMOFMeta-Model Meta-Model
Package StructurePackage Structure
UML2 Infra-Structure
MOF2
Essential MOF (EMOF) Meta-ModelEssential 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 PackageEMOF: Basic Package
EMOF: Basic PackageEMOF: Basic Package
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: Reflection and Common EMOF: Reflection and Common PackagesPackages
EMOF Meta-Model: Identifier PackageEMOF 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 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
EMOF: Extension PackageEMOF: Extension Package
Any element can be tagged to extend modeling language vocabulary
CMOF: Construct PackageCMOF: Construct Package
CMOF: ReflectionCMOF: Reflection
To identify operation parameters by names instead of merely by
position
Is UML2 Enough? Too Much?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 Tailored Modeling with Software Abstractions Beyond UMLSoftware 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 Tailored Modeling: Domain-Specific Meta-Modeling and Modeling Meta-Modeling and Modeling
ApproachApproach 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, D2Meta-Models
in D2
Model in Language D1
GUI Editor forD1 Diagrams
D1 ModelRepository
GUI Editor forD2 Diagrams
Tailored Modeling: Pure MOF Tailored Modeling: Pure MOF ApproachApproach
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-Modelin MOF
Model in Dedicated
Language D
GUI Editor forD Diagrams
UMLEditor
EMF
Menu Editor forD Diagrams
generates
Tailored Modeling:Tailored Modeling:Meta-Model and MOF Reuse Meta-Model and MOF Reuse
OperatorsOperators 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-Modelin MOF
Model in Dedicated
Language D
GUI Editor forD Diagrams
UMLEditor
EMF
Menu Editor forD Diagrams
generates
Tailored Modeling: Tailored Modeling: UML Profile ApproachUML 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
P UML2 Profile Model in Dedicated
UML2 Profile P
UML2Meta-Model
in MOF
UMLEditor
EMF
Promotes property value to the metaclass level
metaclassPackage Class
Property Association
Profile
ProfileApplication*
*
*
ExtensionStereotype*
Image
icon
ExtensionEnd*
type ownedEnd
UML2 ProfilesUML2 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)
a2ee.set(property:type, value:a)
<<proxy>>
<<agent>>ag1
<<agent>>ag2
// Stereotyping a2 as agenta2e = 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)
metaclassPackage Class
Property Association
Profile
ProfileApplication*
*
*
ExtensionStereotype*
Image
icon
ExtensionEnd*
type ownedEnd
// Stereotyping a12 as proxya12e = 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)
Agent
Component Associaton
Proxy
UML2 ProfilesUML2 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)
C1 C2
S1 S2
neither directnor inheritedassociation
betweenC1 and C2
S2 only astereotype of C2
but not a sub-metaclass
of C2
S1 only astereotype of C1
but not a sub-metaclass
of C1 XNo allowedassociation
betweenS1 and S2
i1: <<S1>> C1
instance i1cannot be of S1
only of C11w/ property
stereotype = S1
instance i2cannot be of S2
only of C2w/ property
stereotype = S2
i2: <<S2>> C2
i1 and i2 cannot be linked for lack of an associationbetween their respective classes C1 and C2but reuse of concrete syntax of C1 and C2
X
metaclassPackage Class
Property Association
Profile
ProfileApplication*
*
*
ExtensionStereotype*
Image
icon
ExtensionEnd*
type ownedEnd
UML2 Extension via Sub-MetaclassesUML2 Extension via Sub-Metaclasses
// Creating classes C1, C2, S1, S2c1 = 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 S2s1.set(property:superclass, value:c1)s2.set(property:superclass, value:c2)
// Creating Association between S1 and S2s12 = 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”)
C1 C2
S1 S2
neither directnor inheritedassociation
betweenC1 and C2
S2 a sub-metaclass
of C2
S1 a sub-metaclass
of C1 Allowedassociation
betweenS1 and S2
i1: S1
i1 and i2 can be linked by an instance of S12but no reuse of concrete syntax of C1 and C2
S12
i1: S1
Class
Property
Association
ownedAttribute
menberEnd
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)
UML2 Extension via Sub-MetaClasses UML2 Extension via Sub-MetaClasses and Stereotype and Stereotype
C1 C2
S1 S2
neither directnor inheritedassociation
betweenC1 and C2
S1 both a sub-metaclass
and a stereotypeof C1
Allowedassociation
betweenS1 and S2
S1 both a sub-metaclass
and a stereotypeof C1
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
Class
Property
Association
ownedAttribute
menberEnd
superclass
*
metaclassPackage Class
Property Association
Profile
ProfileApplication*
*
*
ExtensionStereotype*
Image
icon
ExtensionEnd*
type ownedEnd
A UML2 Profile Definition ProcessA 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-classesg1, ..., gn that are natural semantic generalizations of s1, ..., sn (respectively)
4. Extend the UML2 meta-model by defining s1, ..., sn as sub-meta-classes of g1, ..., gn (respectively)
5. Add OCL constraints on s1, ..., sn that specify how they specializeg1, ..., gn (respectively)
MOF Meta-Model of a Simple Multi-Agent MOF Meta-Model of a Simple Multi-Agent Simulations Modeling Language (MASML)Simulations Modeling Language (MASML)
MAS2..*
EnvironmentAgent
Sensor Actuator
1..* 1..*
Percept1..*
AgentAction1..*
MAS
ReasoningComponent1..*
Agent
ReflexAgent ReflexComponent
ReflexAgent
ReasoningComponent
Sensor
Actuator1..*
1..*
AutomataAgentGoalBasedAgent
Goal
GoalInitializationComponent
GoalUpdateComponent
GoalBasedBehaviorStrategyComponent
ReasoningComponent
GoalBasedAgent
3..*
EnvironmentStateModel
ModelBasedBehaviorStrategyComponent
AgentAutomataAgent
EnvironmentStateModel
ModelInitializationComponent
PercpetInterpretationComponent
RamificationComponent
ModelBasedBehaviorStrategyComponent
ReasoningComponent
AutomataAgent
Actuator
Sensor4..*
1..*
MOF Meta-Model of a Simple Multi-Agent MOF Meta-Model of a Simple Multi-Agent Simulations Modeling Language (MASML)Simulations Modeling Language (MASML)
Agent
KBAgent KBComponent
KBAgent
ReasoningComponent
1..*
KnowledgeBase
PersistentKB VolatileKB
0..*
KBSentence1..*
1..*
ReflexAgent
ReflexKBAgent ReflexKBComponent
ReflexKBAgent
ReflexComponent
KBAgent KBComponent PersistentKB
ReflexKB
context ReflexKBComponent inv Volat ileKB.isEmpty()
AutomataKBAgent
AutomataAgent
AutomataKBAgent KBComponent
KBAgent EnvironmentStateModelKB
4..*
VolatileKB EnvironmentStateModel
4 ..*
GoalBasedKBAgent
GoalBasedAgent
GoalBasedKBAgent KBComponent
KBAgent GoalKB EnvironmentStateModelKB
6..*
VolatileKB Goal EnvironmentStateModel
4 ..*3 ..*
UML2 Profile for MASUML2 Profile for MAS
MASML Meta-Model
MAS
Environment
Agent
Sensor
Actuator
Percept
AgentAction
ReasoningComponent
EnvironmentStateModel
KnowledgeBase
KBSentence
Component
isActive = true
Component
Interface
Signal
Model
UML2 Meta-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:agentabstraction.oclIsKindOf(Agent)
4. ...
Available UML ProfilesAvailable 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