1 / 49

OCL 2.0 Metamodel support for EMF

OCL 2.0 Metamodel support for EMF. Object Constraint Language (OCL) 2.0 Metamodel Support for Eclipse Modelling Framework (EMF) by Shah Rukh Humayoun Supervised by: Dr. Andy S. Evans MSc Dissertation for the Degree of MSc in Software Engineering Department of Computer Science

gali
Download Presentation

OCL 2.0 Metamodel support for EMF

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  1. OCL 2.0 Metamodel support for EMF

  2. Object Constraint Language (OCL) 2.0 Metamodel Support for Eclipse Modelling Framework (EMF) by Shah Rukh Humayoun Supervised by:Dr. Andy S. Evans MSc Dissertation for the Degree of MSc in Software Engineering Department of Computer Science University of York

  3. Abstract The Eclipse Modelling Framework (EMF), a modelling framework and code generation facility, is one of those tools that partially support OMG’s Model Driven Architecture (MDA) framework. This project defines an approach for the integration of OCL 2.0 metamodel with EMF Ecore metamodel and implements the resulting metamodel in EMF tool. It enables EMF to provide more functionalities of MDA framework, especially related to transformation of models.

  4. Agenda • Related Technologies • Aim and Objective • The Approach • Conclusion / Benefits

  5. Technologies • Model Driven Architecture (MDA) • Metamodelling Mechanism • Object Constraint Language (OCL) • Eclipse Modelling Framework (EMF)

  6. [Figure from http://www.omg.org/mda] Model Driven Architecture • An Open Standard by Object Management Group (OMG) for the rapid development of quality software products • Development through different levels of models (PIMs, PSMs, Code) • Three levels of models: • Platform Independent Models (PIMs) • Platform Dependent Models (PSMs) • Implementation Code • Transformation from one level of models to another level of models and vice versa is through automated tools • Benefits: Improves productivity, increase portability, defines interoperability, increases reusability, helps during documentation and maintenance, reduce development cost, scalability, robustness & security via generated code

  7. Models Transformation Process in MDA enabled Tools System Requirements created in UML, OCL, MOF, CWM, etc Platform Independent Models (PIMs) MDA enabled Tools generate specify inJEE, XMI, Java, .Net, CORBA, XML, etc technologies Platform Specific Models (PSMs) MDA enabled Tools generate Components, classes, interfaces, etc in target platform Code MDA enabled Tools generate System Deployed

  8. MDA Standard Technologies • There are a number of standard technologies by OMG, which are used in MDA framework • A list of these standard technologies is: • Unified Modelling Language (UML) • Object Constraint Language (OCL) • UML Profiles • Common Warehouse Metamodel (CWM) • Meta-Object Facility (MOF) • Software Process Engineering Metamodel (SPEM) • Common Object Request Broker Architecture (CORBA/IIOP) • XML Metamodel Interchange (XMI) • Others….. • Information available from OMG website http://www.omg.org

  9. Object Constraint Language (OCL) • Formal language for defining expressions/constraints on OO/UML models • Developed at IBM in 1995 and now (OCL 2.0) part of UML standard • Benefits:Formal language but not purely mathematical , pure specification language, query language, unambiguous and precise • OCL 2.0 specification contains a MOF-compliant metamodel that defines the concepts and the semantics of OCL and acts as an abstract syntax for the language • Usage of OCL expressions in UML Models: • Invariants on classes • Pre-conditions & post-conditions on operations/methods of class • Constraints on Operations • Type invariant for Stereotypes • Expressions over UML models • As a query language on UML models • To specifying types in UML class model diagram • To specifying Target (sets) for message and actions • To define derivation rules for attributes

  10. Metamodelling Mechanism • A mechanism by which we define more precisely the element constructs of a modeling language and its semantics rules It consists of: • Metalanguage: A language that is used for defining metamodels of other languages (e.g MOF) • Metamodel: A Model that specifies element constructs and the semantic rules of a modeling language (e.g UML metamodel, OCL metamodel, CWM metamodel) • Modeling Language: A Language that is used for constructing the models of systems (e.g UML, CWM, OCL) Metalanguage or Metamodelling Language defines Metamodel Metamodelling Mechanism specifies Modelling Language constructs User-Level Models

  11. Meta-Metamodel M3 MOF Metamodel The Model of the Model M2 UML, OCL, CWM and Others Metamodels The Model of the System M1 UML Models and Other system Models The Instances of Model Instances of UML and other System Models M0 Metamodelling Mechanism • The relationships between metalanguage, metamodel, and modeling language is called as Metamodel Mechanism OMG 4-Layer Architecture: • OMG has defined an architecture for representing different constructs of metamodelling mechanism at different levels

  12. Eclipse Modelling Framework (EMF) • A Java/XML based framework for generating tools and applications based on structure data model • An open source tool, part of Eclipse platform, so enjoys and is supported by a vast open source community • It contains a metamodel of itself, EMF Ecore metamodel, which acts as MOF-like metamodel in EMF • EMF does transformation process: • Takes models in form of XML documents/Annotated Java Classes/UML models • Transfers these models into Code (Java Implementation Classes) without business logic • Saves objects as XML documents for interchange with other tools & applications • Partially supports MDA approach (lacks of OCL & Action Language)

  13. Aims & Objectives

  14. The Problem: • Development with MDA framework needs automated tools • MDA enabled automated tools transfer PIMs to PSMs and PSMs to Code and vice versa • MDA enable tools use: • Detailed models mostly written in UML • Stating pre-conditions, post-conditions, constraints in OCL • Semantic of models in Action Language • Currently available automated tools Do they support full functionalities of MDA approach (PIMs -> PSM -> Code)?????

  15. Currently Available Automated Tools • Three types of Tools: • PIM to PSM: Barely available, some offer few functionalities • PSM to Code:Mostly tools support this transformation • PIM to Code:Mostly use UML models and create code without any business logic or dynamic functionality • They are unable to do complete models transformation according to MDA approach, and they only generate partial part of code • They lack of: • Fully automated models transformation from one level to another level • They lack of standard UML Definition, as mostly tools use their own UML definition internally • OCL support for writing pre-conditions, post-conditions, and constraints on models • Action Language support for describing the semantic of models

  16. The Solution: • Development with MDA framework needs a combination of different automated tools • Transformation tools, Model Editors, Code File Generators, Model Repositories, Code Editors, Model Validators etc etc… • However, the core of the framework is automated transformation from PIM -> PSM and from PSM -> Code and vice versa • Currently available automated transformation tools support UML models, but do not support OCL and Action Language on models e.g EMF The Solution is: • Need an automated models transformation tool that: • Takes UML models as input for development • Provides support of OCL and Action Language on UML models • Does models transformation according to MDA framework

  17. Project Objective • An automated tool that fully supports the models transformation process of MDA framework The target tool is EMF • Improvements in EMF to enable it to provide the functionality of models transformation according to MDA framework • The first step towards this is to provide the support of OCL expressions in EMF

  18. Support of OCL + Action Language on UML Models UML Models EMF transforms Models transformation according to MDA Approach

  19. How to achieve the Objective? • The objective is to provide the support of OCL expressions on UML models in EMF • Questions: • How to achieve this Objective? • What steps are needed to do to achieve this? • Answers (Aims of the project): • By providing the OCL metamodel support in EMF • By integrating this metamodel with EMF metamodel Why and How????? Discuss later!!!

  20. Project Aims & Limitations Project Aims: • To define an approach for the integration of OCL 2.0 metamodel with EMF Ecore metamodel • Implementation of the resulting integrated metamodel in EMF Limitations: • Only metamodel support in EMF • The metamodel support is limit to only Invariant type of constraints • The invariant constraints must be on classes in UML models

  21. Why & How????? • Why we need to integrate OCL metamodel with EMF metamodel? • How to integrate OCL metamodel with EMF metamodel?

  22. The Question: Why we need to provide support of OCL in EMF through metamodelling?

  23. The Answer: In metamodelling, the languages are defined in a unified way Benefits: • Easy to provide support of one language in another by integrating their metamodels • Can be uniformly managed and manipulated • To do mapping between two languages is easy and standardised • Can add any other language (with metamodel) with the existing metamodels

  24. The Question: Why we need to integrate OCL metamodel with EMF Ecore metamodel?

  25. The Answer: • EMF Ecore Model: • EMF generates instances of Ecore metamodel according to user model, which is called as Ecore Model • EMF generates Java code according to Ecore Model • To provide OCL support in EMF, we need implementation of OCL metamodel in EMF that have relationship with Ecore metamodel • From this OCL metamodel in EMF, we can create the instances of integrated OCL metamodel according to user model (EOcl model) • The transformation of models/generation of code in EMF will be according to Ecore Model and EOcl Model

  26. EMF EMF Ecore Metamodel EMF EMF Ecore Metamodel User Model (UML) User Model (UML + OCL) OCL(EOCL) Metamodel generates Ecore Model (Instances of Ecore metamodel according to user model in EMF) Ecore Model + EOcl Model (Instances of Ecore & EOcl metamodel according to user model) generates OCL(EOCL) Metamodel Code (Java Implementation Classes) Code (Java Implementation Classes with business logic as defined in OCL)

  27. The Question: How to integrate OCL metamodel with EMF Ecore metamodel?

  28. The Answer: EOCL Metamodel Approach • An approach for the integration of OCL 2.0 metamodel with EMF Ecore metamodel • EOCL (EMF Object Constraint Language) metamodel is the integrated metamodel form of OCL metamodel and Ecore metamodel in EMF

  29. EOCL Metamodel Approach

  30. EMF Ecore Metamodel • EMF bases on a metamodel of itself, EMF Ecore metamodel, which acts as a MOF-like metamodel in EMF • It also acts as UML-like metamodel in EMF, and due to its flexibility, it can be reside at any layer of OMG 4-layer architecture • EMF generates instances model of Ecore metamodel according to user model, called as Ecore Model, for all generating applications

  31. OCL 2.0 Metamodel • OCL Specification version 2.0 (part of UML 2.0 Specification) contains a MOF 2.0–compliant metamodel • Acts as an abstract syntax of language • Describes the concepts and the semantics of OCL • This metamodel integrates OCL to UML metamodel • The root of OCL metamodel is the root of UML Core Metamodel

  32. Class Attributes public class Student; Student 1 * Features of Languages Concrete Syntax: • A set of notations for the presentation and the construction of models or programs in a language (Textual, visual or mixed form) Abstract Syntax: • The vocabulary of concepts in the language • Describes how these concepts may combine to build models Semantics: • Describes the meaning of concepts, and defines what the language represents and means Mappings: • Rules for mapping between internal components of language and between two languages Extensibility: • Ability to extend a language by adding new concepts and deleting unused elements

  33. 1 Expression Type Abstract Syntax Expression Evaluation * Of_ Mapping Relationship 1 Evaluation Value Semantics Relationships inside OCL Metamodel • OCL is a typed language and each expression in OCL has a type • Each expression in OCL has one or more evaluation in a special environment • Each evaluation of the same OCL expression yields to the same resulting value

  34. Expression 1 Type Abstract Syntax Value Evaluation 1 * Semantics OCL Metamodel • The complete OCL metamodel is a combination of: • Syntax metamodel of OCL • Model of Semantics • And the relationship between Syntax and Semantics, called as Mapping Relationship

  35. Abstract Syntax Semantics * Of_ Abstract Syntax and Semantics • The relationship between OCL abstract syntax and semantics is one to many

  36. referred UML core Abstract Syntax Semantic * Of_ Relationship b/w OCL Metamodel and UML Metamodel • OCL 2.0 metamodel, a MOF–compliant metamodel, has a tight relationship with UML core metamodel • The OCL abstract syntax metamodel is inherited from UML core metamodel • OCL type model follows UML kernel type model • OCL abstract syntax also has references to UML core

  37. referred OCL Metamodel Integration with EMF Ecore Metamodel • EMF Ecore works like both MOF & UML metamodel in EMF and can reside at any level of OMG 4-layers architecture • It also works like UML core metamodel • For providing support of OCL metamodel in EMF: • By replacing EMF Ecore metamodel in the place of UML core metamodel • The relationships are same between OCL and EMF Ecore metamodels as the relationships between OCL and UML metamodels UML core EMF Ecore EMF Ecore Abstract Syntax Semantics * Of_

  38. referred EMF Ecore OCL Expressions Metamodel Invariants Pre-conditions Post-conditions Project Limitations • The project’s support is limit to only those OCL expressions that contain Invariant type of constraints • In this project, this integrated OCL metamodel in EMF is called as EOCL Metamodel

  39. EOCL Metamodel in EMF

  40. EMF Ecore EOclAbstractSyntax EOclDomian EOclTypes EOclExpressions EOclValues EOclEvaluations EOCL-AS-Domain-Mapping EOCL-Type-Values EOCL-Expression-Evaluations EOCL Metamodel Package Hierarchy • EOCL metamodel consists of a package hierarchy • This package hierarchy contains different packages in EMF, which contain the implementation of different parts of EOCL metamodel • Three main packages:

  41. EOCL Metamodel in EMF • The meta–classes of OCL invariant type of constraints in EMF

  42. EOCL Metamodel in EMF • The result of root expression is the result of invariant constraint

  43. Semantic Environment EOCL Metamodel in EMF • EOCL Semantic Model • Semantic Environment:To evaluate an OCL expression • Semantic Evaluations:The set of possible evaluations • Semantic Domain: The set of possible resulting values • These models reside at layer M1 instead of metamodel layer

  44. Semantic Evaluation Semantic Domain EOCL Metamodel in EMF

  45. Syntax Tree Instances Diagram of EOCL Abstract Syntax EOCL Metamodel Validation • Invariant constraint on Student class context Student inv: self.age > 16

  46. Instance Diagram of EOCL Semantic Model EOCL Metamodel Validation • Invariant constraint on Student class context Student inv: self.age > 16

  47. Further Work Structure Data Model (with OCL Expressions) EOCL Metamodel contains Ecore and EOcl Model Generator EMF Ecore Metamodel generates Ecore Model + EOcl Model (Instances of Ecore and EOCL metamodel) Code Generator Editor Generator generates generates Source Code (Java Interfaces and corresponding implementation classes) Model Editor (Instances of Ecore Model and EOcl Model for checking the models)

  48. Conclusion / Benefits Approach: • At highly abstract level • Platform independent • Reusable – can be use in any MOF-compliant metamodel enabled tool • Easy to implementation in any tool that does work with metamodelling mechanism OCL Support in EMF: • Improve support of MDA especially related to models transformation • Automated code generation of business logic • Automated implementation of operations/methods behaviour • Can check constraints on models • Can generate tools of modelling languages Overall: • Improve quality and reliable products • Reduction in product cost and time to product delivery • Reusability • Think about benefits of MDA framework

  49. The End

More Related