5
-
Upload
majong-devjfu -
Category
Technology
-
view
1.312 -
download
0
description
Transcript of 5
![Page 1: 5](https://reader034.fdocuments.us/reader034/viewer/2022051816/546627cdaf795937498b6523/html5/thumbnails/1.jpg)
Metamodeling and the Model Driven Architecture
(MDA) Paolo Ciancarini
![Page 2: 5](https://reader034.fdocuments.us/reader034/viewer/2022051816/546627cdaf795937498b6523/html5/thumbnails/2.jpg)
Agenda
Model Driven Engineering Metamodeling Metamodeling in UML Model Driven Architecture OMG technologies for MDA
![Page 3: 5](https://reader034.fdocuments.us/reader034/viewer/2022051816/546627cdaf795937498b6523/html5/thumbnails/3.jpg)
Enterprise Computing Software is a complex and expensive product Enterprise Computing adds further requirements:
Rapid change in organizational assets Continuous evolving partnerships Heterogeneous end-user clients
e.g., Fat clients, Web clients, Cellular Phone, iPod, DTT TV Need for information ubiquity
e.g., in mobile/opportunistic networking, cross-network roaming
The only thing we can predict with confidence about the future of software platforms is that things we cannot predict will happen
![Page 4: 5](https://reader034.fdocuments.us/reader034/viewer/2022051816/546627cdaf795937498b6523/html5/thumbnails/4.jpg)
Motivations
There is a strong pressure on the industry to increase Quality Longevity Reusability of software products, while reducing costs
In order to fulfill this needs the productivity of the software industry must be improved
Most increments in software productivity are obtained increasing the abstraction level
![Page 5: 5](https://reader034.fdocuments.us/reader034/viewer/2022051816/546627cdaf795937498b6523/html5/thumbnails/5.jpg)
Levels of abstractions
The history of software development is a history of raising the level of abstraction
• In Programming Languages • e.g., Assembler, C, C++, Visual C#, …
• In Software Architectures
• e.g., Client-Server, n-tier, SOA, …
• In Operative Systems
• e.g., Virtual Machines, Middleware, Grid
• In data representation
• e.g., File, Database, XML, …
A stack of Programming Languages
0s and 1s
3GL
Assembly Language
![Page 6: 5](https://reader034.fdocuments.us/reader034/viewer/2022051816/546627cdaf795937498b6523/html5/thumbnails/6.jpg)
Model Driven Engineering (MDE) MDE is a software development method for handling the
complexity of software platforms and related problems Main feature: “Everything is a model”: the models are first-
class abstractions closer to domains than to algorithmic ideas and concerns
A model is a simplified representation of a part (i.e. a system) of the real world
Model
System isRepresentedBy the real world
the modeling space
![Page 7: 5](https://reader034.fdocuments.us/reader034/viewer/2022051816/546627cdaf795937498b6523/html5/thumbnails/7.jpg)
MDE: Approaches
MDE concepts can be applied in different ways producing different approaches, each one relying on a specific set of tools
![Page 8: 5](https://reader034.fdocuments.us/reader034/viewer/2022051816/546627cdaf795937498b6523/html5/thumbnails/8.jpg)
Example: EMF
The Eclipse Modeling Framework (EMF) is a modeling framework and code generation facility for building applications based on a structured data model
From a model specification described in XMI, EMF produces a set of Java classes for the model, a set of adapter classes that enable viewing and editing the model, and a basic editor
Models can be specified using annotated Java, UML, XML documents, or modeling tools, then imported into EMF
EMF itself provides the foundation for interoperability with other EMF-based tools and applications
![Page 9: 5](https://reader034.fdocuments.us/reader034/viewer/2022051816/546627cdaf795937498b6523/html5/thumbnails/9.jpg)
Approach Requirement model:
defines the system in its environment
Analysis and design model: defines the
system architecture
Realization model: defines how the system is built
Code of the system and configuration artifacts
![Page 10: 5](https://reader034.fdocuments.us/reader034/viewer/2022051816/546627cdaf795937498b6523/html5/thumbnails/10.jpg)
Models represent systems A system S is a delimited part of the world considered
as a set of elements in interaction A model M is a representation of a given system S
satisfying the principle of substitutability Principle of substitutability: A model M is said to be a
representation of a system S for a given set of questions Q if, for each question q in Q, the model M will provide exactly the same answer that the system S would have provided in answering the same q
The relation between a model and a system is called representation of
![Page 11: 5](https://reader034.fdocuments.us/reader034/viewer/2022051816/546627cdaf795937498b6523/html5/thumbnails/11.jpg)
Models and Reality
![Page 12: 5](https://reader034.fdocuments.us/reader034/viewer/2022051816/546627cdaf795937498b6523/html5/thumbnails/12.jpg)
A class diagram models a set of objects
![Page 13: 5](https://reader034.fdocuments.us/reader034/viewer/2022051816/546627cdaf795937498b6523/html5/thumbnails/13.jpg)
Example with three levels
![Page 14: 5](https://reader034.fdocuments.us/reader034/viewer/2022051816/546627cdaf795937498b6523/html5/thumbnails/14.jpg)
Discuss
A model which describes a model is called metamodel
Metamodels are descriptions of descriptions: why are they important to develop software?
![Page 15: 5](https://reader034.fdocuments.us/reader034/viewer/2022051816/546627cdaf795937498b6523/html5/thumbnails/15.jpg)
Genesi, 2:19
So out of the ground the Lord God formed every beast of the field and every bird of the air, and brought them to the man to see what he would call them; and whatever the man called every living creature, that was its name
![Page 16: 5](https://reader034.fdocuments.us/reader034/viewer/2022051816/546627cdaf795937498b6523/html5/thumbnails/16.jpg)
Metamodeling
![Page 17: 5](https://reader034.fdocuments.us/reader034/viewer/2022051816/546627cdaf795937498b6523/html5/thumbnails/17.jpg)
Meta-model A meta-model defines concepts and their relationships thanks to a class diagram
A meta-model only defines structure (no semantics)
A model is an instance of a meta-model if it respects the structure defined by the meta-model
The relation between a model and its metamodel is called conformance
The UML meta-model defines the structure that all UML models must have
![Page 18: 5](https://reader034.fdocuments.us/reader034/viewer/2022051816/546627cdaf795937498b6523/html5/thumbnails/18.jpg)
Multiple levels of abstractions
![Page 19: 5](https://reader034.fdocuments.us/reader034/viewer/2022051816/546627cdaf795937498b6523/html5/thumbnails/19.jpg)
System-Model-Metamodel Relations
The extraction of an element from system S to build a model M is guided by a meta-model MM
MM plays the role of “filter” in the selecting from the system S the elements for building the model M
metamodel MM
terminal model M
system S
conformsTo
repOf Representation of
![Page 20: 5](https://reader034.fdocuments.us/reader034/viewer/2022051816/546627cdaf795937498b6523/html5/thumbnails/20.jpg)
Exercises
Describe a metamodel for libraries Describe a metamodel for cars Describe a metamodel for TV sets Describe a metamodel for CRC cards Describe a metamodel for Petri Nets
![Page 21: 5](https://reader034.fdocuments.us/reader034/viewer/2022051816/546627cdaf795937498b6523/html5/thumbnails/21.jpg)
Metadata architecture
![Page 22: 5](https://reader034.fdocuments.us/reader034/viewer/2022051816/546627cdaf795937498b6523/html5/thumbnails/22.jpg)
Four Layered Architecture Layer Description Example
Meta-metamodel Defines metamodel metaClass, metaAttribute, metaOperation
Metamodel An instance of meta-Metamodel. Defines a model
Class, attribute operation, component
Model Language for describing an information domain. Defines a set of related objects that represent a concept
Employee
User object An instance of the model. An example information domain
:Sally
![Page 23: 5](https://reader034.fdocuments.us/reader034/viewer/2022051816/546627cdaf795937498b6523/html5/thumbnails/23.jpg)
OMG Modeling Infrastructure
23
M3
M2
M1
M0
Meta-Object Facility (MOF)
UML Metamodel
Modeling concepts
User Data
Instance_of
Instance_of
Instance_of
![Page 24: 5](https://reader034.fdocuments.us/reader034/viewer/2022051816/546627cdaf795937498b6523/html5/thumbnails/24.jpg)
4-Layers Metamodeling A model, or terminal model, (M1) is a
representation of a real object (in M0) conforming to a metamodel (M2)
A metamodel (M2) is a representation of a set of modelling elements (in M1) conforming to a meta-metamodel (M3)
A meta-metamodel (M3) is a set of modeling elements used to define metamodels (M2 ed M3) conforming to itself
N.B. M2, M2 and M3 are all “models”. We could represent them using the same modeling language (e.g., UML)
![Page 25: 5](https://reader034.fdocuments.us/reader034/viewer/2022051816/546627cdaf795937498b6523/html5/thumbnails/25.jpg)
Example
![Page 26: 5](https://reader034.fdocuments.us/reader034/viewer/2022051816/546627cdaf795937498b6523/html5/thumbnails/26.jpg)
Meta-metamodel • A metamodel describes information about models • A meta-metamodel describes information about
metamodels • Metamodels defined using the same meta-
metamodel - can be compared for conformance - can exchange information - can be used by the same tools that understand
the meta-metamodel
![Page 27: 5](https://reader034.fdocuments.us/reader034/viewer/2022051816/546627cdaf795937498b6523/html5/thumbnails/27.jpg)
Meta Object Facility (MOF)
• Enables meta-metamodeling of UML level metamodels
• It defines a small set of concepts (such as package, class, method, attribute…) that allow to define and manipulate models of metadata (data about data)
• All definitions are described using a subset UML notation
![Page 28: 5](https://reader034.fdocuments.us/reader034/viewer/2022051816/546627cdaf795937498b6523/html5/thumbnails/28.jpg)
28
MOF Model
![Page 29: 5](https://reader034.fdocuments.us/reader034/viewer/2022051816/546627cdaf795937498b6523/html5/thumbnails/29.jpg)
MOF Key Abstract Classes
![Page 30: 5](https://reader034.fdocuments.us/reader034/viewer/2022051816/546627cdaf795937498b6523/html5/thumbnails/30.jpg)
MOF Key Abstract Classes • ModelElement base Class of all M3-level Classes;
every ModelElement has a name • Namespace base Class for all M3-level Classes that
need to act as containers • GeneralizableElement base Class for all M3-level
Classes that support generalization (i.e. inheritance) • TypedElement base Class for M3-level Classes such
as Attribute, Parameter, and Constant whose definition requires a type specification
• Classifier base Class for all M3-level Classes that (notionally) define types; examples of Classifier include Class and DataType
![Page 31: 5](https://reader034.fdocuments.us/reader034/viewer/2022051816/546627cdaf795937498b6523/html5/thumbnails/31.jpg)
31
Main Concrete Classes • The key concrete classes (or meta-metaclasses) of MOF:
- Class - Association - Exception (for defining abnormal behaviours) - Attribute - Constant - Constraint
![Page 32: 5](https://reader034.fdocuments.us/reader034/viewer/2022051816/546627cdaf795937498b6523/html5/thumbnails/32.jpg)
Key associations • Contains: relates a ModelElement to the Namespace that
contains it
• Generalizes: relates a GeneralizableElement to its ancestors (superclass and subclass)
• IsOfType: relates a TypedElement to the Classifier that defines its type - An object is an instance of a class
• DependsOn : relates a ModelElement to others that its definition depends on - E.g. a package depends on another package
![Page 33: 5](https://reader034.fdocuments.us/reader034/viewer/2022051816/546627cdaf795937498b6523/html5/thumbnails/33.jpg)
![Page 34: 5](https://reader034.fdocuments.us/reader034/viewer/2022051816/546627cdaf795937498b6523/html5/thumbnails/34.jpg)
34
Component
0..1 0..1 0..1
ownedElement
Comment * Link
1..* 1..* 1..* EnumerationLiteral
ProgrammingLanguageType Enumeration Primitive
* * * * * *
1..*
* Object
Parameter defaultValue kind
Instance Namespace
specialization * parent
* child
GeneralizableElement isRoot isLeaf isAbstract
Package
Model Subsystem DataType Interface
deploymmentLocation * resident *
AssociationClass
Class Node
owner
{ordered}
participant * specification
* AssociationEnd
isNavigable aggregation multiplicity
connection 2..* 2..* 2..* Association
Method body
Operation isAbstract
0..1
qualifier * Attribute initialValue
{ordered} *
specification * * * * * *
* type Generalization
discriminator
Feature visibility
BehaviouralFeature StructuralFeature multiplicity
Classifier
ModelElement name
Element
Relationship *
*
type
importedElement *
*
UML Meta Model
Metaclasses used in class, package, component and deployment diagrams
![Page 35: 5](https://reader034.fdocuments.us/reader034/viewer/2022051816/546627cdaf795937498b6523/html5/thumbnails/35.jpg)
A fragment of the UML Meta-Model
not self.isAbstract implies self.allOperations->forAll(op | self.allMethods->exists(m | m.specification includes (op)))
![Page 36: 5](https://reader034.fdocuments.us/reader034/viewer/2022051816/546627cdaf795937498b6523/html5/thumbnails/36.jpg)
Model Elements • An element is an atomic
constituent of a model
• Element is the top metaclass in the metaclass hierarchy
• A model element is a named entity in a model
• It is the base for all modeling metaclasses in UML - All other modeling metaclasses are
either direct or indirect subclasses of ModelElement
ModelElement
name
Element
![Page 37: 5](https://reader034.fdocuments.us/reader034/viewer/2022051816/546627cdaf795937498b6523/html5/thumbnails/37.jpg)
owner
{ordered}
Method body
Operation isAbstract
Attribute initialValue specification
* * * * * *
Feature visibility
BehaviouralFeature StructuralFeature multiplicity
Classifier
*
Features • Feature is an abstract class
that declares a behavioral or structural property of - an instance of a Classifier - the Classifier itself
• A behavioral feature refers to a dynamic feature of a model element - E.g. operation or method
• A structural feature refers to a static feature of a model element - E.g. attribute
![Page 38: 5](https://reader034.fdocuments.us/reader034/viewer/2022051816/546627cdaf795937498b6523/html5/thumbnails/38.jpg)
38
• A classifier is an element that describes behavioral and structural features - E.g. class, data type, interface, component
• Classifier is an abstract class that - declares a collection of Features, such as Attributes, Methods… - has a name, which is unique in the Namespace enclosing the
Classifier
Classifier
Component
Structure 1..* 1..* 1..*
EnumerationLiteral
ProgrammingLanguageType Enumeration Primitive
Subsystem DataType Interface deploymmentLocation * resident
* Class Node
Classifier {ordered}
Feature
visibility * Namespace
![Page 39: 5](https://reader034.fdocuments.us/reader034/viewer/2022051816/546627cdaf795937498b6523/html5/thumbnails/39.jpg)
Classifier
*
1..*
*
Object
Parameter
defaultValue kind
Instance GeneralizableElement
isRoot isLeaf isAbstract
owner
{ordered}
participant *
specification *
AssociationEnd
isNavigable aggregation multiplicity
* type
Feature
visibility
Classifier
*
type
Namespace
• A classifier is a generalizable element and defines a namespace
• It can have - association ends - parameters - instances
![Page 40: 5](https://reader034.fdocuments.us/reader034/viewer/2022051816/546627cdaf795937498b6523/html5/thumbnails/40.jpg)
AssociationClass
Class
Association
Generalization discriminator
Relationship
Relationship • A relationship is a connection
among model elements
• UML defines several relationships such as: - Association - Generalization
• UML defines other types of relationships that are not shown in this diagram, such as: - Dependency - Flow
![Page 41: 5](https://reader034.fdocuments.us/reader034/viewer/2022051816/546627cdaf795937498b6523/html5/thumbnails/41.jpg)
Namespace
0..1 0..1 0..1
ownedElement
Namespace GeneralizableElement
isRoot isLeaf isAbstract
Package
Model Subsystem
Classifier
ModelElement name
* importedElement *
*
• A namespace is a part of a model that contains a set of other model elements - E.g. Associations and
Classifiers - the name of an owned
model element is unique within the namespace
• Namespace is an abstract metaclass and it subclasses are - Classifier - Package
![Page 42: 5](https://reader034.fdocuments.us/reader034/viewer/2022051816/546627cdaf795937498b6523/html5/thumbnails/42.jpg)
42
Data Types
1..* 1..* 1..*
EnumerationLiteral
ProgrammingLanguageType Enumeration Primitive
DataType
• UML data types include - primitive built-in types (such as integer and string) - definable enumeration types (such as Boolean whose literals are false
and true); enumerations are a user-defined data types whose instances are literals (specified by the user)
• Programming languages data types - are specified according to the semantics of a particular programming
language - are not portable among languages (except by agreement among the
languages) - do not map into other UML classifiers
![Page 43: 5](https://reader034.fdocuments.us/reader034/viewer/2022051816/546627cdaf795937498b6523/html5/thumbnails/43.jpg)
Mapping of UML Models to Metamodel Elements (Example)
Customer Account accountNumber balance overdraftLimit
CreditCard expiryDate
*1..2
withdraw deposit
Saving Chequing
BankSystem
Generalization discriminator
Relationship
Association
Relationship AssociationEnd
isNavigable aggregation multiplicity Class
Classifier Namespace
Package
Attribute initialValue
StructuralFeature multiplicity
Method
BehaviouralFeature
![Page 44: 5](https://reader034.fdocuments.us/reader034/viewer/2022051816/546627cdaf795937498b6523/html5/thumbnails/44.jpg)
Use Case Diagrams Metamodel
![Page 45: 5](https://reader034.fdocuments.us/reader034/viewer/2022051816/546627cdaf795937498b6523/html5/thumbnails/45.jpg)
Mapping Use Cases Model to Metamodel
Generalization discriminator
Relationship
Include
Relationship
Actor
Classifier UseCase
Classifier
Extend
Relationship
Open file by typing name Open file by
browsing
Open file
System Administrator
Browse for file
Ordinary User
Attempt to open file that does not exist
«extend» «include»
![Page 46: 5](https://reader034.fdocuments.us/reader034/viewer/2022051816/546627cdaf795937498b6523/html5/thumbnails/46.jpg)
State Machines (Main Metamodel)
![Page 47: 5](https://reader034.fdocuments.us/reader034/viewer/2022051816/546627cdaf795937498b6523/html5/thumbnails/47.jpg)
Mapping State Machines to Metamodel
SimpleState
State
PseudoState
StateVertex
Event
Transition
0..1
*
Enter / run motor forwards
Enter / run motor in reverse
Enter / stop motor
Enter / stop motor
openingCompleted
closingCompleted
pressButton
pressButton
pressButton
Closing Open
Opening Closed
Procedure
State
0..1 +entry
0..1
![Page 48: 5](https://reader034.fdocuments.us/reader034/viewer/2022051816/546627cdaf795937498b6523/html5/thumbnails/48.jpg)
Extension Mechanisms Metamodel
![Page 49: 5](https://reader034.fdocuments.us/reader034/viewer/2022051816/546627cdaf795937498b6523/html5/thumbnails/49.jpg)
Example
LinearShape startPoint: Point
1..* edge <<geometry>
LineSegment
Path Line Polygon
RegularPolygon
endPoint: Point {startPoint <> endPoint}
{ordered}
{edge->size=1}
{edge->forAll(e1,e2 | e1.length = e2.length)}
length : int length
{length = edge.length->sum}
{edge->first.startPoint = edge->last.endPoint}
Stereotype
GeneralizableElement
Constraint
![Page 50: 5](https://reader034.fdocuments.us/reader034/viewer/2022051816/546627cdaf795937498b6523/html5/thumbnails/50.jpg)
Model Driven Architecture (MDA)
MDA is a theory of software construction based on a set of standards provided by the Object Management Group
MDA is a kind of MDE, that is domain engineering based on developing models of software systems
The idea of MDA is to exploit a modeling language (such as UML) as a programming language rather than just as a support for design
This is not a new approach, it has notable ancestors: Database schemas, generative programming, CASE
tools, WYSIWYG interfaces
![Page 51: 5](https://reader034.fdocuments.us/reader034/viewer/2022051816/546627cdaf795937498b6523/html5/thumbnails/51.jpg)
MDA Base Components
MDA is based on a set of technologies that allow: Domain specification (domain specific
languages) Modeling and metamodeling Model transformations which support the
development of a system independently from: platforms platforms evolution application domains
![Page 52: 5](https://reader034.fdocuments.us/reader034/viewer/2022051816/546627cdaf795937498b6523/html5/thumbnails/52.jpg)
MDA Dimensions Horizontal: different domains that are not more or less abstract
than others, like business or technology E.g., marketing, engineering, sales, etc. E.g., performance, security, fault tolerance etc.
Vertical: different level of abstraction of the same domain of a system From physical data, logical data models, middleware,
applications specifications, component assemblies, business process models, business goals and strategies
Evolutionary: different systems, legacy, ongoing and upcoming, as-is, as-was and as-could-be This is technically similar to the horizontal dimension, but it is
more concerned with evolution-focused architectural rules and modeling standards
![Page 53: 5](https://reader034.fdocuments.us/reader034/viewer/2022051816/546627cdaf795937498b6523/html5/thumbnails/53.jpg)
MDA: the Big Picture
This picture gives some insights about the technologies constituting MDA together with the platforms, the kinds of application and the domains of application that it addresses
![Page 54: 5](https://reader034.fdocuments.us/reader034/viewer/2022051816/546627cdaf795937498b6523/html5/thumbnails/54.jpg)
Key Idea
create a source model independent from platform implementation details transform it in a target model richer of details than the
source model Use of a proper transformation language
![Page 55: 5](https://reader034.fdocuments.us/reader034/viewer/2022051816/546627cdaf795937498b6523/html5/thumbnails/55.jpg)
Basic Concepts
Model: a simplified representation of a system a part of a system a set of system functionalities
Point of view: an abstraction technique with the goal of highlighting some features of the system
View: a representation of the system from the perspective of a particular point of view
![Page 56: 5](https://reader034.fdocuments.us/reader034/viewer/2022051816/546627cdaf795937498b6523/html5/thumbnails/56.jpg)
Basic Concepts
Refinement: it is related to a model M1 derived from model M2, where M1 has a number of details greater than M2 M1 is a refinement of M2
Zooming: when we move from a model with a different level of abstraction than another one we have like a zoom-effect
System architecture: the specification of Components Connectors Interaction rules of components by means of
connectors
![Page 57: 5](https://reader034.fdocuments.us/reader034/viewer/2022051816/546627cdaf795937498b6523/html5/thumbnails/57.jpg)
Basic Concepts
Model driven: the use of models through all the phases of software development
Platform independence: a property of a model developed regardless of platform details
Model transformation: the process of converting one model into another one concerning the same system
![Page 58: 5](https://reader034.fdocuments.us/reader034/viewer/2022051816/546627cdaf795937498b6523/html5/thumbnails/58.jpg)
Models, metamodels and platforms
![Page 59: 5](https://reader034.fdocuments.us/reader034/viewer/2022051816/546627cdaf795937498b6523/html5/thumbnails/59.jpg)
MDA: Core Standards
How do we can specify models, metamodels and meta-metamodels?
OMG provides a set of standards supporting such activities: MOF 2.0 UML 2.3 XMI 2.0 CWM 1.1 QVT (Query View Transform)
![Page 60: 5](https://reader034.fdocuments.us/reader034/viewer/2022051816/546627cdaf795937498b6523/html5/thumbnails/60.jpg)
MOF
MOF is an OMG standard to write metamodels Can be used to model the abstract syntax of
Domain Specific Languages Two flavors: EMOF (Essential MOF), CMOF
(complete MOF) Kermeta is an extension to MOF allowing
executable actions to be attached to EMOF meta-models, hence making it possible to also model a DSL operational semantics and obtain an interpreter for it
![Page 61: 5](https://reader034.fdocuments.us/reader034/viewer/2022051816/546627cdaf795937498b6523/html5/thumbnails/61.jpg)
Metamodel The correspondence between a model and a system is
defined by a metamodel:
Terminology: a collection of concepts with their properties and relations
Assertions: a collection of additional rules by which terminology elements can be constrained
![Page 62: 5](https://reader034.fdocuments.us/reader034/viewer/2022051816/546627cdaf795937498b6523/html5/thumbnails/62.jpg)
Metamodels in Software Engineering
Currently, metamodels focus on: Software process modeling (PIF) Software product modeling (UML, CWM)
Many new fields are involved: Model of cost Model of resource consumption Models of test, QoS, and software measurements Requirements modeling (e.g. Use Cases) Know-how modeling (e.g. Patterns) Model validation
![Page 63: 5](https://reader034.fdocuments.us/reader034/viewer/2022051816/546627cdaf795937498b6523/html5/thumbnails/63.jpg)
Meta-metamodel
A Meta-metamodel provides the language to define a set of metamodels Definition of abstract syntax: concepts, relationships, and
wellformedness rules Definition of concrete syntax: shapes, layout, and physical
interchange formats Definition of semantic domains: the abstract logical space in
which models find their meanings Definition of mappings between domains
![Page 64: 5](https://reader034.fdocuments.us/reader034/viewer/2022051816/546627cdaf795937498b6523/html5/thumbnails/64.jpg)
A Metamodel Language: MOF 2.0
The Meta-Object Facility (MOF) is an OMG specification defining an abstract language and a framework for specifying, constructing, managing, and exchanging, technology-neutral metamodels
MOF defines a framework for implementing repositories holding the persistent representation of the metamodels
![Page 65: 5](https://reader034.fdocuments.us/reader034/viewer/2022051816/546627cdaf795937498b6523/html5/thumbnails/65.jpg)
The MOF Meta-metamodel
![Page 66: 5](https://reader034.fdocuments.us/reader034/viewer/2022051816/546627cdaf795937498b6523/html5/thumbnails/66.jpg)
MOF: Features
MOF belongs to the MDA architecture MOF meta-metamodel defined in itself MOF 2.0 reuses a part of the UML 2.0 metamodel MOF to XML mapping: OMG XMI (XML Metadata
Interchange) specification MOF to Java mapping: JMI (Java Metadata
Interchange)
![Page 67: 5](https://reader034.fdocuments.us/reader034/viewer/2022051816/546627cdaf795937498b6523/html5/thumbnails/67.jpg)
UML 2.0
UML is a language with a very broad scope covering a large and diverse set of application domains
It is structured in two main parts: Infrastructure Superstructure
The UML 2.0 metamodel is aligned with the MOF 2.0 meta-metamodel for accomplishing the MDA-vision
In MDA all the four-layer models are defined by means of UML or its extensions
![Page 68: 5](https://reader034.fdocuments.us/reader034/viewer/2022051816/546627cdaf795937498b6523/html5/thumbnails/68.jpg)
UML 2.0 Infrastructure
Note: the Core package is the same of the MOF Meta-metamodel
![Page 69: 5](https://reader034.fdocuments.us/reader034/viewer/2022051816/546627cdaf795937498b6523/html5/thumbnails/69.jpg)
The MDA 4-Layers Architecture (1/2)
The alignment between UML 2.0 and MOF 2.0 enables to see every UML 2.0 construct like an instance of a MOF 2.0 element In this way, we can see MOF 2.0 like the meta-
metamodel of UML2 Every UML 2.0 model is an instance of the
UML 2.0 metamodel
![Page 70: 5](https://reader034.fdocuments.us/reader034/viewer/2022051816/546627cdaf795937498b6523/html5/thumbnails/70.jpg)
The MDA 4-Layers Architecture (2/2)
The UML metamodel stack is instantiated in MDA by: M3: MOF 2.0 M2: UML 2.0 M1: An UML 2.0 model at the “class” level M0: A “real world” object represented by an UML 2.0
model at the “object” level This stack represents the four-layers architecture
![Page 71: 5](https://reader034.fdocuments.us/reader034/viewer/2022051816/546627cdaf795937498b6523/html5/thumbnails/71.jpg)
4-Layers MDA: an Example
![Page 72: 5](https://reader034.fdocuments.us/reader034/viewer/2022051816/546627cdaf795937498b6523/html5/thumbnails/72.jpg)
4-Layers Metamodelling Instance
![Page 73: 5](https://reader034.fdocuments.us/reader034/viewer/2022051816/546627cdaf795937498b6523/html5/thumbnails/73.jpg)
UML 1.x Metamodel (1/2)
![Page 74: 5](https://reader034.fdocuments.us/reader034/viewer/2022051816/546627cdaf795937498b6523/html5/thumbnails/74.jpg)
UML 1.x Metamodel (2/2)
![Page 75: 5](https://reader034.fdocuments.us/reader034/viewer/2022051816/546627cdaf795937498b6523/html5/thumbnails/75.jpg)
UML 2.1 Use-Case MOF Metamodel
![Page 76: 5](https://reader034.fdocuments.us/reader034/viewer/2022051816/546627cdaf795937498b6523/html5/thumbnails/76.jpg)
XMI
XML Metadata Interchange (XMI) is the OMG technology for interchanging models in a serialized form
XMI focuses on the interchange of MOF metadata i.e., metadata conforming to a MOF-based
metamodel XMI can also be used for model representation
in model transformations
![Page 77: 5](https://reader034.fdocuments.us/reader034/viewer/2022051816/546627cdaf795937498b6523/html5/thumbnails/77.jpg)
XMI XMI uses XML for the transfer syntax and interchange format XML Document Type Definitions (DTD) or Schema are specified
to enable the transfer and verification of: UML-based models (e.g. mymodel.xmi, using uml.dtd or
uml.xsd) MOF-based metamodels (e.g. uml.xmi, using mof.dtd or
mof.xsd) Models based on other MOF-based meta-models (e.g.
mymodel.xmi using cwm.dtd or cwm.xsd)
![Page 78: 5](https://reader034.fdocuments.us/reader034/viewer/2022051816/546627cdaf795937498b6523/html5/thumbnails/78.jpg)
CWM The Common Warehouse Metamodel (CWM)
is the OMG standard for data warehouse CWM is a specification for modeling metadata
for relational, non-relational, multi-dimensional, and other objects found in a data warehouse
CWM can be used to extend UML for supporting data warehouse environments modeling transformations structuring transformation specifications
The goal is to integrate development tools with data deployment solutions
![Page 79: 5](https://reader034.fdocuments.us/reader034/viewer/2022051816/546627cdaf795937498b6523/html5/thumbnails/79.jpg)
The Metadata Problem CWM addresses the problems facing any company: Many databases Many repositories Different schemas describing the “same” data Moving data requires manual schema
transformation
![Page 80: 5](https://reader034.fdocuments.us/reader034/viewer/2022051816/546627cdaf795937498b6523/html5/thumbnails/80.jpg)
CWM Integrates Data
CWM integrates existing data models
Maps to existing schemas
Supports automated schema generation
Supports automated database loading
The basis for data mining and OLAP (OnLine Analytical Processing) across an enterprise
![Page 81: 5](https://reader034.fdocuments.us/reader034/viewer/2022051816/546627cdaf795937498b6523/html5/thumbnails/81.jpg)
81
CWM Defines Metamodels
CWM Foundation
Relational Data
Record Data
Multidimensional Data
XML Data
Data Transformations
OLAP
Data Mining
Info Visualization
Business Nomenclature
Warehouse Process
Warehouse Operation
![Page 82: 5](https://reader034.fdocuments.us/reader034/viewer/2022051816/546627cdaf795937498b6523/html5/thumbnails/82.jpg)
CWM: Fragment of the Relational Metamodel
TableisTemporary : BooleantemporaryScope : String/ trigger : TriggerisSystem : Boolean
ViewisReadOnly : BooleancheckOption : BooleanqueryExpression : QueryExpression
QueryColumnSetquery : QueryExpression
NamedColumnSet/ optionScopeColumn : Column/ type : SQLStructuredType/ usingTrigger : Trigger
SQLSimpleTypecharacterMaximumLength : IntegercharacterOctetLength : IntegernumericPrecision : IntegernumericPrecisionRadix : IntegernumericScale : IntegerdateTimePrecision : Integer
SQLDistinctTypelength : Integerprecision : Integerscale : Integer/ sqlSimpleType : SQLSimpleType
1
*
sqlSimpleType
1
sqlDistinctType *
{ordered}
{ordered}
{ordered}
CheckConstraintdeferrability : DeferrabilityType
*
*
/constrainedElement
*
/constrant*
ColumnSet
SQLDataTypetypeNumber : Integer
Columnprecision : Integerscale : IntegerisNullable : NullableTypelength : IntegercollationName : StringcharacterSetName : String/ optionScopeColumnSet : NamedColumnSet/ referencedTableType : SQLStructuredType
**
/constrainedElement
*
/constraint
*
*
0..1 /feature
*/owner
0..11
*/type
1/structuralFeature*
![Page 83: 5](https://reader034.fdocuments.us/reader034/viewer/2022051816/546627cdaf795937498b6523/html5/thumbnails/83.jpg)
Pairwise (9 connections)
CWM Tool
Source
Source
Source
Target
Target
Target
Hub (6 connections)
The CWM Metamodel
Extract Transform
Drill Down
Source
Source
Source
Operational Data Sources
Target
Target
Target
Data Warehouses
![Page 84: 5](https://reader034.fdocuments.us/reader034/viewer/2022051816/546627cdaf795937498b6523/html5/thumbnails/84.jpg)
OMG Metamodel Architecture
Standard Components Modeling Notation: UML Metadata Interchange: XMI Metadata API:
MOF IDL Mapping JMI – MOF/Java Mapping
M I D D L E W A R E
A P P L I C A T I O N
User Data/Object Layer (M0)
Metadata/Model Layer(M1)
Metamodel Layer(M2)
Meta-metamodel Layer (M3)
<Stock name=“IBM” price=“112”/>
Stock: name, price
UML: Class, Attribute CWM: Table, Column ElementType, Attribute
MOF: Class, Attribute, Operation, Association
CWM is based on UML MOF XMI
![Page 85: 5](https://reader034.fdocuments.us/reader034/viewer/2022051816/546627cdaf795937498b6523/html5/thumbnails/85.jpg)
The CWM Metamodel (1.0) Warehouse
Process Warehouse Operation
Transformation
XML Record Multi- Dimensional Relational
Business Information
Software Deployment
Core
Management
Resource
Analysis
Object (Core+Behavioral+
Relationships)
Foundation
OLAP Data Mining
Information Visualization
Business Nomenclature
Data Types Expressions Keys
Index Type
Mapping
Behavioral Relationships Instance Object Model
![Page 86: 5](https://reader034.fdocuments.us/reader034/viewer/2022051816/546627cdaf795937498b6523/html5/thumbnails/86.jpg)
Metamodels, Syntaxes and Semantics
The UML language has been defined by means of a MOF metamodel
In order to define a MOF metamodel we can use: MOF to (formally) define the abstract syntax of a set of
modelling constructs The natural language to (informally) describe some
parts of the semantics The concrete syntax can be expressed by a
graphical notation or not Example: a UML diagram can be represented in XML
by means of the XMI concrete syntax In this case, the XMI file represents the UML diagram
![Page 87: 5](https://reader034.fdocuments.us/reader034/viewer/2022051816/546627cdaf795937498b6523/html5/thumbnails/87.jpg)
Conclusions
MDA is a powerful family of technologies Its basis is metamodeling The technology of model transformations
(see next lecture) makes the approach practical and powerful
It is important because it allows to manage automatically the design and maintenance problems typical of large software systems
![Page 88: 5](https://reader034.fdocuments.us/reader034/viewer/2022051816/546627cdaf795937498b6523/html5/thumbnails/88.jpg)
Self test questions
What is a model? What is a metamodel? What is conformance to a metamodel? What is MOF? What is CWM? Which are the main differences between
UML1.x and UML2.x?
![Page 89: 5](https://reader034.fdocuments.us/reader034/viewer/2022051816/546627cdaf795937498b6523/html5/thumbnails/89.jpg)
References
Schmidt, Model-Driven Engineering. IEEE Computer, 39:2(25-31), February 2006.
Frankel, Model Driven Architecture: Applying MDA to Enterprise Computing, Wiley, 2003
Mellor, Scott, Uhl, Weise MDA Distilled: Principles of Model-Driven Architecture, Addison-Wesley, 2004
Mellor & Balcer, Executable UML, a foundation for MDA, Addison-Wesley 2002
OMG, UML Infrastructure 2.3, 2010
![Page 90: 5](https://reader034.fdocuments.us/reader034/viewer/2022051816/546627cdaf795937498b6523/html5/thumbnails/90.jpg)
Useful sites
www.omg.org/mda! www.ibm.com/developerworks/rational/library/3100.html!
www.agilemodeling.com/essays/mda.htm! martinfowler.com/bliki/ModelDrivenArchitecture.html
![Page 91: 5](https://reader034.fdocuments.us/reader034/viewer/2022051816/546627cdaf795937498b6523/html5/thumbnails/91.jpg)
Interesting tools
www.eclipse.org/modeling/emf/?project=emf www.andromda.org www.bluage.com/ www.openarchitectureware.org www.openmdx.org www.ibm.com/developerworks/rational/products/rhapsody/
![Page 92: 5](https://reader034.fdocuments.us/reader034/viewer/2022051816/546627cdaf795937498b6523/html5/thumbnails/92.jpg)
Questions?