MOF MetaModels and UML Profiles Jacques Robin Ontologies

MOF Meta-Models and UML Profiles Jacques Robin Ontologies Reasoning Components Agents Simulations

Outline E E E 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 Profiles E Multi-Agent Simulations E Others

MDA’s Modeling Level Hierarchy Meta-Model MOF + OCL Level M 1 Model UML AND Special Purpose + OCL -OR Profile -OR Modeling Language Level M 0 Running Application Implementation Running on Platform Level M 3 Level M 2

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

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

OMG’s Meta-Object Facility (MOF) E Key idea: E Instead of defining entirely new languages for the M 2 and M 3 levels E Reuse structural core of mature, well-known, well-tooled M 1 level language (UML Infra-Structure) E 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 E Specification reuse through inheritance E E E Additional advantages with OCL: E Allows expressing arbitrary complex constraints among language elements (more expressive) E Allows defining formal semantics without mathematical syntax

UML 2 Infra-Structure MOF Meta-Model Package Structure MOF 2

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

EMOF: Basic Package

EMOF: Basic Package

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

EMOF Meta-Model: Identifier Package E OID: class property with feature is. ID true or URI E Extent: OID value range E use. Containment(): when true, all contained elements are added to containing element’s extents (recursive containment) E e. g. , if object o 1 has property p 1 which contains objects o 2, which in turns has property p 2 which contains object o 3, when use. Containment() is true then the extent for o 1 includes {o 1, o 2, o 3} E Elements(): returns extent members E URIExtent: extent where OIDs are URIs instead of properties E A URI (Universal Resource Identifier) is either, E A URL (Universal Resource Locator) providing a name for a resource accessible on a network and a mean to retrieve it; or E A URN (Universal Resource Name) providing a name for a resource in a namespace. URI syntax and examples schem e authority path foo; ///example. com: 8 /over/there 042 query fragme nt ? name=ferr #nose et

EMOF: Extension Package E 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 UML 2 Enough? Too Much? E UML 2 covers domain and platform independent modeling concepts for the object-oriented, relational, imperative, concurrent, event-based, distributed and constraint (through OCL) computational paradigms E It does not cover: E Object-oriented reflection E Functional paradigm which includes powerful generative meta-programming and type inference E Rule-based paradigm which includes powerful model transformation mechanisms and general logical inference E Domain-specific modeling concepts E Platform-specific abstractions So it is not enough for key applications and domains UML 2 thus needs an extension mechanism But isn’t UML 2 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 E To be highly reusable it is also necessarily very under-constrained E So UML 2 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 E E

Tailored Modeling with Software Abstractions Beyond UML E Software abstractions beyond UML can be classified as: E Specializing UML abstractions (i. e. , UML 2 meta-model elements) E Generalizing UML abstractions E Being unrelated to UML abstractions E Approaches: 1. No MOF, no UML (the Microsoft way) E Create and use domain-specific or even application-specific meta-modeling, modeling and model transformation languages 2. Pure MOF, no UML: E 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: E 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) E Define specializations of UML abstractions by stereotyping UML meta-model elements

Tailored Modeling: Domain-Specific Meta-Modeling and Modeling Approach E Advantage: ENo need to understand complex, large and at times under-examplified MOF 2 and UML 2 specifications E Drawbacks: E For each new domain or application E Need to redefine entire MDA language infra-structure alternative to OMG´s E Need to implement CASE tools for non-standard languages GUI Editor for D 2 Diagrams D 1, D 2 Meta-Models in D 2 GUI Editor for D 1 Diagrams Model in Language D 1 Model Repository

Tailored Modeling: Pure MOF Approach E Pure MOF approach E Does not use UML E Advantages: UML Editor D Meta-Model in MOF GUI Editor for D Diagrams Model in Dedicated Language D E No need to artificially relate new abstractions to UML abstractions E Drawbacks: E Need to define entirely new metamodel that does not reuse any elements consolidated by OMG’s long meta-modeling experience E Need to develop entirely new graphical notation and editors E 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 E Advantages: E Reuses consolidated elements from UML 2 meta-model UML 2 Meta-Model in MOF E Drawbacks: E Need to extend UML’s graphical editors to draw elements in DUML 2 E Need to extend model manipulation services (code generation, test generation, reverse engineering) of UML CASE to modeling elements in DUML 2 E Current MOF operators do not cover UML 2 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 E UML 2 meta-classes sub-categorized by stereotypes E Advantages: E Maximum reuse the entire OMG language infra-structure E Maximum reuse of UML CASE tools (no need to develop any new tool) E Drawbacks: E Risk to “artificially” recast modeling abstraction as specializations of UML ones E Little to reuse for non-object oriented modeling languages Promotes property value to the metaclass level Package Profile * * Profile. Application Class * UML Editor metaclass Stereotype EMF P UML 2 Profile Model in Dedicated UML 2 Profile P * * Extension. End owned. End type Extension icon Image UML 2 Meta-Model in MOF Property Association

UML 2 Profiles Package Profile * * Profile. Application Class * metaclass Stereotype * * Extension. End owned. End type Extension <<agent>> ag 1 icon Image // Creating agent stereotype a= Factory. create(metaclass: Stereotype) a. set(property: name, value: ”<<agent>>”) // Creating Components a 1 and a 2 a 1 = Factory. create(metaclass: Component) a 1. set(property: name, value: ”ag 1”) a 2 = Factory. create(metaclass: Component) a 2. set(property: name, value: ”ag 2”) // Stereotyping a 1 as agent a 1 e = Factory. create(metaclass: Extension) a 1. set(property: Extension, value: a 1 e) a 1 ee = Factory. create(metaclass: Exension. End Property <<proxy>> <<agent>> ag 2 Association // Stereotyping a 2 as agent a 2 e = Factory. create(metaclass: Extension) a 2. set(property: Extension, value: a 2 e) a 2 ee = Factory. create(metaclass: Exension. End ) a 2 e. set(property: owned. End, value: a 2 ee) a 2 ee. set(property: type, value: a) // Create proxy stereotype p= Factory. create(metaclass: Stereotype) p. set(property: name, value: ”<<proxy>>”) // Creating Association between a 1 and a 2 a 12 = Factory. create(metaclass: Association) Component Associaton Agent Proxy // Stereotyping a 12 as proxy a 12 e = Factory. create(metaclass: Extension) a 12. set(property: Extension, value: a 12 e) a 12 ee = Factory. create(metaclass: Exension. End) a 12 e. set(property: owned. End, value: a 12 ee) a 12 ee. set(property: type, value: p)

UML 2 Profiles // Creating S 1 and S 2 stereotypes s 1 = Factory. create(metaclass: Stereotype) s 1. set(property: name, value: ”<<S 1>>”) Package Class metaclass s 1 = Factory. create(metaclass: Stereotype) s 1. set(property: name, value: ”<<S 2>>”) * * * // Creating classes C 1 and C 2 Profile Stereotype Extension. End Extension owned. End c 1 = Factory. create(metaclass: Class) type * icon c 1. set(property: name, value: ”C 1”) * c 2 = Factory. create(metaclass: Class) Image Property Association Profile. Application c 2. set(property: name, value: ”C 2”) // Creating instance. Specification i 1 of C 1 i 1 = Factory. create(metaclass: Instance. Specification) neither direct i 1. set(property: name, value: ”i 1”) nor inherited C 2 C 1 S 1 only a S 2 only a i 1. set(property: classifier, value: c 1) association stereotype of C 1 stereotype of C 2 between // Stereotyping i 1 as <<S 1>> but not a C 1 and C 2 sub-metaclass c 1 e = Factory. create(metaclass: Extension) of C 1 of C 2 S 1 S 2 c 1. set(property: Extension, value: c 1 e) c 1 ee = Factory. create(metaclass: Exension. End) No allowed i 1: <<S 1>> C 1 i 2: <<S 2>> C 2 association c 1 e. set(property: owned. End, value: c 1 ee) between c 1 ee. set(property: type, value: s 1) instance i 1 instance i 2 S 1 and S 2 cannot be of S 1 cannot be of S 2 // Stereotyping i 2 as <<S 2>> only of C 11 only of C 2 c 2 e = Factory. create(metaclass: Extension) w/ property c 2. set(property: Extension, value: c 2 e) stereotype = S 1 stereotype = S 2 c 2 ee = Factory. create(metaclass: Exension. End) i 1 and i 2 cannot be linked for lack of an c 2 e. set(property: owned. End, value: c 2 ee) association c 2 ee. set(property: type, value: s 2) between their respective classes C 1 and C 2 X X

UML 2 Extension via Sub-Metaclasses // Creating classes C 1, C 2, S 1, S 2 c 1 = Factory. create(metaclass: Class) c 1. set(property: name, value: ”C 1”) c 2 = Factory. create(metaclass: Class) c 2. set(property: name, value: ”C 2”) s 1 = Factory. create(metaclass: Class) s 1. set(property: name, value: ”S 1”) s 2 = Factory. create(metaclass: Class) s 2. set(property: name, value: ”S 2”) // Creating instance. Specification i 1 of S 1 i 1 = Factory. create(metaclass: Instance. Specification ) i 1. set(property: name, value: ”i 1”) i 1. set(property: classifier, value: s 1) // Creating instance. Specification i 2 of S 2 i 2 = Factory. create(metaclass: Instance. Specification // Specializing C 1 by S 1 and C 2 by S 2 ) s 1. set(property: superclass, value: c 1) i 2. set(property: name, value: ”i 2”) s 2. set(property: superclass, value: c 2) i 2. set(property: classifier, value: s 2) // Creating Association between S 1 // Creating instance. Specification of S 12 and S 2 C 1 is 12= s 12 = Factory. create(metaclass: Association) Factory. create(metaclass: Instance. Specification ) s 12 e 1 = S 1 a Factory. create(metaclass: Property) is 12. set(property: classifier, value: s 12) sub-metaclass S 1 s 12 e 2 = of C 1 Factory. create(metaclass: Property) s 1. set(property: owned. Attributes, value: s 12 e 1) s 2. set(property: owned. Attributes, value: s 12 e 2) s 12. set(property: member. End, value: s 12 e 1) i 1: S 1 superclass * Class owned. Attribute Property menber. End Association neither direct nor inherited association C 2 between C 1 and C 2 S 12 Allowed association between S 1 and S 2 a S 2 sub-metaclass of C 2 i 1: S 1 i 1 and i 2 can be linked by an instance of S 12

UML 2 Extension via Sub-Meta. Classes and Stereotype Package Class * Profile * * superclass metaclass Stereotype * * Extension. End owned. End type Extension icon Profile. Application * Class owned. Attribu Image Property Association Property menber. End S 1 both a sub-metaclass and a stereotype of C 1 S 1 i 1: <<Si 1>> S 1 neither direct nor inherited association C 2 between C 1 and C 2 a. S 1 S 2 Association S 1 both a sub-metaclass and a stereotype of C 1 S 2 Allowed association between i 2: <<Si 2>> S 2 S 1 and S 2 i 1 and i 2 can be linked by an instance a. S 1 S 2 and reuse of concrete syntax of C 1 and C 2

A UML 2 Profile Definition Process 1. Create a special purpose meta-model of an application domain, language or platform 2. Identify the top-level meta-classes s 1, . . . , sn of this meta-model (i. e. , those with no generalizations) 3. Identify in the UML 2 meta-model, the concrete meta-classes g 1, . . . , gn that are natural semantic generalizations of s 1, . . . , sn (respectively) 4. Extend the UML 2 meta-model by defining s 1, . . . , sn as sub-metaclasses of g 1, . . . , gn (respectively) 5. Add OCL constraints on s 1, . . . , sn that specify how they specialize g 1, . . . , gn (respectively)

MOF Meta-Model of a Simple Multi-Agent Simulations Modeling Language (MASML) MAS Reflex. Agent Reasoning. Component 1. . * Percept 1. . * 2. . * Agent MAS Environment Agent Reasoning. Component 1. . * Sensor Actuator Sensor 1. . * Agent. Action Automata. Agent Reflex. Component 1. . * Goal. Based. Agent Automata. Agent 1. . 4. . * Sensor Environment. State. Model * Reasoning. Component Percpet. Interpretation. Component Goal. Based. Agent Goal Automata. Agent 3. . * Reasoning. Component Environment. State. Model. Initialization. Component Goal. Initialization. Component Ramification. Component Goal. Update. Component Model. Based. Behavior. Strategy. Component Goal. Based. Behavior. Strategy. Component Actuator Model. Based. Behavior. Strategy. Component

MOF Meta-Model of a Simple Multi-Agent Simulations Modeling Language (MASML) KBAgent Reflex. KBAgent Reasoning. Component. Knowledge. Base KBAgent 1. . * KBSentence KBComponent Persistent. KB Volatile. KB 1. . * Reflex. Agent Reflex. Component Reflex. KBAgent Reflex. KBComponent Reflex. KB KBAgent KBComponent Persistent. KB 0. . * context Reflex. KBComponent inv Volat ile. KB. is. Empty( Goal. Based. KBAgent Automata. KBAgent Goal. Based. KBAgent 6. . * Automata. Agent KBComponent 3. . * 4. . * Automata. KBAgent 4. . * KBComponent 4. . * KBAgent Volatile. KB Goal. KBEnvironment. State. Model. KB Goal Environment. State. Model KBAgent Environment. State. Model. KB Volatile. KB Environment. State. Model

UML 2 Profile for MAS E MASML Meta-Model E UML 2 Meta -Model MAS Component Environment is. Active = true Agent Reasoning. Component Sensor Interface Actuator Percept Agent. Action Signal Environment. State. Model Knowledge. Base KBSentence Model OCL Constraints: 1. context Agent inv: interface let r = required and (i = Sensor or Actuator) in r. ocl. Is. Kind. Of(i) 2. context Agent inv: signal let s = required. owned. Reception. signal in s. ocl. Is. Kind. Of(Percept or Agent. Action) 3. context Sensor inv: agent abstraction. ocl. Is. Kind. Of(Agent) 4. .

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