Published on

Published in: Technology
  • Be the first to comment

  • Be the first to like this

No Downloads
Total views
On SlideShare
From Embeds
Number of Embeds
Embeds 0
No embeds

No notes for slide


  1. 1. Metamodeling and theModel Driven Architecture (MDA) Paolo Ciancarini
  2. 2. Agenda  Model Driven Engineering  Metamodeling  Metamodeling in UML  Model Driven Architecture  OMG technologies for MDA
  3. 3. 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
  4. 4. 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
  5. 5. Levels of abstractions  The history of software development is a history of raising the level of abstraction A stack of •  In Programming Languages Programming Languages •  e.g., Assembler, C, C++, Visual C#, … •  In Software Architectures 3GL •  e.g., Client-Server, n-tier, SOA, … Assembly •  In Operative Systems Language •  e.g., Virtual Machines, Middleware, Grid 0s and 1s •  In data representation •  e.g., File, Database, XML, …
  6. 6. 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 the modeling space the real world isRepresentedBy System
  7. 7. MDE: Approaches  MDE concepts can be applied in different ways producing different approaches, each one relying on a specific set of tools
  8. 8. 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
  9. 9. 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
  10. 10. 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
  11. 11. Models and Reality
  12. 12. A class diagrammodels a set of objects
  13. 13. Example with three levels
  14. 14. Discuss  A model which describes a model is called metamodel  Metamodels are descriptions of descriptions: why are they important to develop software?
  15. 15. 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
  16. 16. Metamodeling
  17. 17. Meta-modelA meta-model defines conceptsand their relationships thanks toa class diagramA meta-model only definesstructure (no semantics)A model is an instance of ameta-model if it respects thestructure defined by the meta-modelThe relation between a modeland its metamodel is calledconformanceThe UML meta-model definesthe structure that all UMLmodels must have
  18. 18. Multiple levels of abstractions
  19. 19. 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 conformsTo repOf terminal system S Representation of model M
  20. 20. 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
  21. 21. Metadata architecture
  22. 22. Four Layered ArchitectureLayer Description ExampleMeta-metamodel Defines metamodel metaClass, metaAttribute, metaOperationMetamodel An instance of meta- Class, attribute Metamodel. Defines a operation, component modelModel Language for describing an Employee information domain. Defines a set of related objects that represent a conceptUser object An instance of the model. :Sally An example information domain
  23. 23. OMG Modeling Infrastructure Meta-Object Facility (MOF)M3 Instance_of UML MetamodelM2 Instance_of Modeling conceptsM1 Instance_of User DataM0 23
  24. 24. 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)
  25. 25. Example
  26. 26. 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
  27. 27. 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
  28. 28. MOFModel 28
  29. 29. MOF KeyAbstract Classes
  30. 30. 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
  31. 31. Main Concrete Classes•  The key concrete classes (or meta-metaclasses) of MOF: -  Class -  Association -  Exception (for defining abnormal behaviours) -  Attribute -  Constant -  Constraint 31
  32. 32. 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
  33. 33. UML Metaclasses used in class, package,Meta Element component and deployment diagramsModel importedElement ModelElement * ownedElement name * 0..1 0..1 Relationship FeatureLink Comment Namespace Parameter Instance visibility * GeneralizableElement {ordered} defaultValue* isRoot * * kind child isLeaf Generalization * * * {ordered} * isAbstract specialization parent discriminator Object type owner AssociationEnd * 2..* type connection participant specification Classifier isNavigable aggregation * * 1..* Association multiplicity 0..1 StructuralFeature BehaviouralFeature multiplicity Package * qualifier * Attribute Operation Method ** initialValue isAbstract specification body Model resident Class Interface DataType Subsystem Node * Component deploymmentLocation * AssociationClass Primitive Enumeration ProgrammingLanguageType 1..* EnumerationLiteral 34
  34. 34. A fragment of the UML Meta-Model not self.isAbstract implies self.allOperations->forAll(op | self.allMethods->exists(m | m.specification includes (op)))
  35. 35. Model Elements•  An element is an atomic constituent of a model Element•  Element is the top metaclass in the metaclass hierarchy ModelElement•  A model element is a named entity in a model name•  It is the base for all modeling metaclasses in UML -  All other modeling metaclasses are either direct or indirect subclasses of ModelElement
  36. 36. Features•  Feature is an abstract class Feature that declares a behavioral or visibility * {ordered} structural property of -  an instance of a Classifier -  the Classifier itself owner Classifier•  A behavioral feature refers to a dynamic feature of a model StructuralFeature BehaviouralFeature multiplicity element -  E.g. operation or method Attribute Operation ** Method initialValue isAbstract specification body•  A structural feature refers to a static feature of a model element -  E.g. attribute
  37. 37. Classifier•  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 Feature * Namespace Classifier visibility {ordered} resident Class Interface DataType Subsystem Node * Component deploymmentLocation * Primitive Structure Enumeration ProgrammingLanguageType 1..* EnumerationLiteral 38
  38. 38. Classifier•  A classifier is a generalizable element and defines a namespace•  It can have -  association ends -  parameters -  instances Feature Namespace Parameter Instance visibility * GeneralizableElement {ordered} defaultValue isRoot * kind isLeaf * isAbstract Object * type owner AssociationEnd Classifier type isNavigable participant specification aggregation * * 1..* multiplicity
  39. 39. Relationship Relationship•  A relationship is a connection among model elements Generalization discriminator•  UML defines several relationships such as: Association -  Association -  Generalization•  UML defines other types of relationships that are not shown in this diagram, such as: Class -  Dependency -  Flow AssociationClass
  40. 40. Namespace importedElement•  A namespace is a part of a ModelElement name * ownedElement model that contains a set of * 0..1 0..1 other model elements GeneralizableElement Namespace -  E.g. Associations and isRoot isLeaf Classifiers isAbstract -  the name of an owned model element is unique Classifier within the namespace•  Namespace is an abstract Package * metaclass and it subclasses are Subsystem Model -  Classifier -  Package
  41. 41. Data Types•  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 DataType Primitive Enumeration ProgrammingLanguageType 1.. * EnumerationLiteral 42
  42. 42. Namespace Classifier Relationship AssociationEnd isNavigable Package aggregation Class Association multiplicity BankSystem Customer 1..2 * Account accountNumber StructuralFeature balance Relationship multiplicity overdraftLimit withdraw Attribute deposit Generalization initialValue discriminatorBehaviouralFeature Chequing Saving CreditCard expiryDate Method Mapping of UML Models to Metamodel Elements (Example)
  43. 43. Use Case Diagrams Metamodel
  44. 44. Mapping Use Cases Model to Metamodel Classifier Classifier UseCase Actor Relationship Open file Generalization discriminator Ordinary User Open file by Open file by typing name browsing Relationship «extend» «include» Include Browse for file System Attempt to open file Administrator that does not exist Relationship Extend
  45. 45. State Machines(Main Metamodel)
  46. 46. Mapping State Machines to Metamodel State State StateVertex SimpleState 0..1 PseudoState 0..1 +entry Procedure Closed Opening Enter / pressButton Enter / stop motor run motor forwards closingCompleted Transition * openingCompleted pressButton 0..1 Closing pressButton Open Event Enter / Enter / run motor in reverse stop motor
  47. 47. Extension Mechanisms Metamodel
  48. 48. Example GeneralizableElement Stereotype {ordered} edge <<geometry> LinearShape 1..* LineSegment startPoint: Point endPoint: Point length : int Path Line Polygon {startPoint <> endPoint} length {edge->size=1} {edge->first.startPoint ={length = edge->last.endPoint}edge.length->sum} RegularPolygon {edge->forAll(e1,e2 | e1.length = e2.length)} Constraint
  49. 49. 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
  50. 50. 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
  51. 51. 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
  52. 52. MDA: the Big PictureThis picture givessome insightsabout thetechnologiesconstituting MDAtogether with theplatforms, thekinds ofapplication andthe domains ofapplication that itaddresses
  53. 53. 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
  54. 54. 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
  55. 55. 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
  56. 56. 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
  57. 57. Models, metamodels and platforms
  58. 58. 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)
  59. 59. 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
  60. 60. 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
  61. 61. 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
  62. 62. 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
  63. 63. 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
  64. 64. The MOF Meta-metamodel
  65. 65. 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)
  66. 66. 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
  67. 67. UML 2.0 InfrastructureNote: the Core package is the same of the MOFMeta-metamodel
  68. 68. 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
  69. 69. 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
  70. 70. 4-Layers MDA: an Example
  71. 71. 4-Layers Metamodelling Instance
  72. 72. UML 1.x Metamodel (1/2)
  73. 73. UML 1.x Metamodel (2/2)
  74. 74. UML 2.1 Use-Case MOF Metamodel
  75. 75. 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
  76. 76. 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)
  77. 77. 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
  78. 78. The Metadata ProblemCWM addresses the problems facing any company:  Many databases  Many repositories  Different schemas describing the “same” data  Moving data requires manual schema transformation
  79. 79. 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
  80. 80. CWM Defines Metamodels  CWM Foundation   OLAP  Relational Data   Data Mining  Record Data   Info Visualization  Multidimensional Data   Business Nomenclature  XML Data   Warehouse Process  Data Transformations   Warehouse Operation 81
  81. 81. CWM: Fragment of the Relational Metamodel /constraint /constrainedElement CheckConstraint {ordered} deferrability : DeferrabilityType * * Column /type SQLDataType * /constrant precision : Integer * typeNumber : Integer scale : Integer /structuralFeature 1 0..1 /feature isNullable : NullableType ColumnSet length : Integer /owner * collationName : String {ordered} characterSetName : String / optionScopeColumnSet : NamedColumnSet / referencedTableType : SQLStructuredType NamedColumnSet / optionScopeColumn : Column / type : SQLStructuredType / usingTrigger : Trigger SQLDistinctType length : Integer /constrainedElement QueryColumnSet precision : Integer scale : Integer query : QueryExpression / sqlSimpleType : SQLSimpleType sqlDistinctType * * SQLSimpleType{ordered} characterMaximumLength : Integer 1 characterOctetLength : Integer numericPrecision : Integer sqlSimpleType numericPrecisionRadix : Integer numericScale : Integer Table dateTimePrecision : Integer View isTemporary : Boolean isReadOnly : Boolean temporaryScope : String checkOption : Boolean / trigger : Trigger queryExpression : QueryExpression isSystem : Boolean
  82. 82. The CWM MetamodelOperational Data Warehouses Extract TransformData Sources Source Target Source Target Source Target Source CWM Tool Target Source Target Source Target Pairwise Hub (9 connections) Drill Down (6 connections)
  83. 83. OMG Metamodel Architecture M MOF: Class, Attribute, I Meta-metamodel Operation, D Layer (M3) Association D LStandard Components E W Modeling Notation: UML A UML: Class, Attribute R Metadata Interchange: XMI Metamodel CWM: Table, Column E Layer(M2) ElementType, Attribute Metadata API: MOF IDL Mapping JMI – MOF/Java Mapping A P P Metadata/Model Stock: name, priceCWM is based on L I Layer(M1) UML C A MOF T XMI I O User Data/Object <Stock name=“IBM” Layer (M0) N price=“112”/>
  84. 84. The CWM Metamodel (1.0)Management Warehouse Warehouse Process OperationAnalysis Data Information Business Transformation OLAP Mining Visualization Nomenclature Object Multi-Resource (Core+Behavioral+ Relational Record XML Relationships) DimensionalFoundation Business Data Keys Type Software Expressions Information Types Index Mapping DeploymentObject Model Core Behavioral Relationships Instance
  85. 85. 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
  86. 86. 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
  87. 87. 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?
  88. 88. 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
  89. 89. 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
  90. 90. 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/
  91. 91. Questions?