Your SlideShare is downloading. ×
5
5
5
5
5
5
5
5
5
5
5
5
5
5
5
5
5
5
5
5
5
5
5
5
5
5
5
5
5
5
5
5
5
5
5
5
5
5
5
5
5
5
5
5
5
5
5
5
5
5
5
5
5
5
5
5
5
5
5
5
5
5
5
5
5
5
5
5
5
5
5
5
5
5
5
5
5
5
5
5
5
5
5
5
5
5
5
5
5
5
5
5
Upcoming SlideShare
Loading in...5
×

Thanks for flagging this SlideShare!

Oops! An error has occurred.

×
Saving this for later? Get the SlideShare app to save on your phone or tablet. Read anywhere, anytime – even offline.
Text the download link to your phone
Standard text messaging rates apply

5

1,038

Published on

Published in: Technology
0 Comments
0 Likes
Statistics
Notes
  • Be the first to comment

  • Be the first to like this

No Downloads
Views
Total Views
1,038
On Slideshare
0
From Embeds
0
Number of Embeds
0
Actions
Shares
0
Downloads
22
Comments
0
Likes
0
Embeds 0
No embeds

Report content
Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
No notes for slide

Transcript

  • 1. Metamodeling and theModel Driven Architecture (MDA) Paolo Ciancarini
  • 2. Agenda  Model Driven Engineering  Metamodeling  Metamodeling in UML  Model Driven Architecture  OMG technologies for MDA
  • 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. 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. 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. 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. MDE: Approaches  MDE concepts can be applied in different ways producing different approaches, each one relying on a specific set of tools
  • 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. 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. 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. Models and Reality
  • 12. A class diagrammodels a set of objects
  • 13. Example with three levels
  • 14. Discuss  A model which describes a model is called metamodel  Metamodels are descriptions of descriptions: why are they important to develop software?
  • 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. Metamodeling
  • 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. Multiple levels of abstractions
  • 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. 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. Metadata architecture
  • 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. OMG Modeling Infrastructure Meta-Object Facility (MOF)M3 Instance_of UML MetamodelM2 Instance_of Modeling conceptsM1 Instance_of User DataM0 23
  • 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. Example
  • 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. 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. MOFModel 28
  • 29. MOF KeyAbstract Classes
  • 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. Main Concrete Classes•  The key concrete classes (or meta-metaclasses) of MOF: -  Class -  Association -  Exception (for defining abnormal behaviours) -  Attribute -  Constant -  Constraint 31
  • 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. 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. A fragment of the UML Meta-Model not self.isAbstract implies self.allOperations->forAll(op | self.allMethods->exists(m | m.specification includes (op)))
  • 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. 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. 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. 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. 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. 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. 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. 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. Use Case Diagrams Metamodel
  • 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. State Machines(Main Metamodel)
  • 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. Extension Mechanisms Metamodel
  • 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. 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. 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. 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. MDA: the Big PictureThis picture givessome insightsabout thetechnologiesconstituting MDAtogether with theplatforms, thekinds ofapplication andthe domains ofapplication that itaddresses
  • 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. 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. 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. 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. Models, metamodels and platforms
  • 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. 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. 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. 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. 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. 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. The MOF Meta-metamodel
  • 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. 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. UML 2.0 InfrastructureNote: the Core package is the same of the MOFMeta-metamodel
  • 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. 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. 4-Layers MDA: an Example
  • 71. 4-Layers Metamodelling Instance
  • 72. UML 1.x Metamodel (1/2)
  • 73. UML 1.x Metamodel (2/2)
  • 74. UML 2.1 Use-Case MOF Metamodel
  • 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. Questions?

×