1. Model Repositories (XMI, JMI, EMF)by
Luciana de Paiva Silva
Disciplina: IN0980-MDA, Components and Software Reuse
Professor: Jacques Robin

2. OUTLINE Model repositories Requirements and services
Model manipulation formats
Programming objects
XML document
Exemplos (ZoooMM, AM3, ReMoDD)
Existing tools
XMI
JMI
EMF

3. What is a model repository?
Ideally: combine services from project artifact management system and model base management system
Services:
Persistence and fault tolerance
Concurrent and authenticated access control
Version control
Model query
Model conformity to meta-model
Model creation through meta-model instantiation
API to connect a variety of model manipulation tools
Graphical editors
Indented embedded vertically listed items editors
Transformation engines
Formal verification
Code generation
Test generation
DiVinE
O que é? combina serviços do sistema de gerenciamento de artefatos do projeto e do sistema de gerenciamento de base dos modelos
multiplicity= variety

4. Model Manipulation Formats: Programmable Objects
One programming language class for each meta-model meta-class
One programming object for each model element (i.e., meta-class instance)
Advantages:
Model manipulation services can be directly programmed in same language
To the point => succinct, concise
Paradigm alignment (object-orientation)
Disadvantages:
Intermediate software needed for both persistence and human reading
Conventional OO platform do not support meta-circularity
Model Manipulation Formats: Programmable Objects
Mainstream = conventional, typical, normal
meta-circularity = MOF e UML
Same = equivalentes
Configuration = association = alignment
Uma classe de linguagem de programação para cada meta-classe do meta-modelo
Um objeto programavel para cada elemento do modelo – instancia da meta-classe
O MOF especifica uma linguagem abstrata para descrever outras linguagens e é
também conhecido como meta-meta-modelo (nível M3). As linguagens abstratas
descritas a partir do MOF são chamadas de meta-modelo (M2) [MATULA, 2003]. Um
exemplo dessas linguagens abstratas é o meta-modelo da UML, sendo que cada modelo
UML está no nível M1.
O modelo MOF é orientado ao objecto e os seus construtores de. metamodelo foram definidos utilizando UML ( e portanto os. descritores do UML).

5. XML Language family XML: XML Schema: XSLT:
Flexible language to encode documents or data using sequences of elements containing attribute-value pairs and delimited by opening and closing tags defining an open-ended set of categories
An XML document is well-formed conforms to XML syntax
XML Schema:
XML encoded metadata language to encode XML document schemas
44 built-in data types
Specifies type, cardinality and ordering constraints on the elements and attributes of an XML document
An XML document is valid with respect to a schema if it satisfies the constraints specified in the schema
XSLT:
XML encoded language to specify and apply transformation on XML documents
Exchanged = intercambio
open-ended = ilimitado
Exchanged = troca, substituiçao

6. Model Manipulation Formats: XML Document
One XML tag for each meta-model meta-class
One XML Schema for each graph to tree ordering projection of one MOF meta-model
One XML element or attribute for each model element
Thus, one XML document for each model
Advantages:
Persistent and human understandable
Shared meta-circularity representation principle
XML Schema is meta-level description reusing base level language (XML)
MOF2 is meta-level description reusing base level language (UML2 Infra-structure)
Disadvantages:
Verbose
Paradigm mismatch makes robust parsing challenging
wordy = garrulous = verbose = prolixo
Paradigm mismatch ( divergentes, diferentes) makes robust (strong) parsing challenging
Em Ciência da computação, parsing é o processo de analisar uma sequência de entrada (lida de um arquivo ou do teclado, por exemplo) para determinar sua estrutura gramatical segundo uma determinada gramática formal. Este processo é formalmente chamado de análise sintática. Um parser é um programa de computador que executa essa tarefa. O nome é análogo ao uso (em inglês) em gramática e linguística. O processo de parsing transforma um texto na entrada em uma estrutura de dados, em geral uma árvore, o que é conveniente processamento posterior e captura a a hierarquia implícita desta entrada. Parsers, normalmente, operam em dois estágios, inicialmente identificando tokens significativos na entrada, para então construir uma parse tree desses tokens. Um Parser é um programa de computador (ou apenas um componente de um programa) que serve para analisar a estrutura gramatical de uma entrada, manipulando os tokens, que são segmentos de texto ou símbolos que podem ser manipulados. Em XML, o parser pode ser um leitor que ajuda na conversão do arquivo para manipulação dos dados contidos no mesmo.

7. Examples
There are several projects that have been started some time ago on model repositories: ZoooMM, AM3, ReMoDD, etc.

8. Zooomm project
ZOOOMM is the International ZOO of MetaModels, Schemas, Grammars and Ontology for Software Engineering.
Megazoo (zoo of megamodels):
Textual megamodels.
Megamodels in UML.
Megamodels in sciences & art.
Metametazoo (zoo of metametamodels):
UML, MOF, XMI, EMF, KM3, Emphatic, GXL, USE, ODMG, Xschema, GXL, RSF, TA, Telos, EXPRESS, OWL, RDFS, DAML, OIL, GXL, RSF, TA, Telos, EXPRESS, OWL, RDFS, DAML, OIL.
Megamodels => tipo de registro para modelos e metamodelos. É um modelo onde pelo menos alguns elementos representam e/ou se referem a metamodelos.
Metazoo (zoo of metamodels):
We have already a few hundreds of metamodels collected over years from more than 2000 papers in software engineering.

9. Planet MDE

10. AM3 - ATLAS MegaModel Management
The goal of AM3 (ATLAS MegaModel Management) is to provide a practical support for modeling in the large. The objective is to deal with global resource management in a model-engineering environment. We base this activity on the concept of a "megamodel".
Features:
Management of various artifacts
Management of various relations between artifacts
Sharing and exchange of megamodel elements
User interfaces for viewing (browsing, creating, changing, etc.) megamodel elements

11. ReMoDD
On May 24 at ICSE, - ReMoDD (ReMoDD: A Repository for Model Driven Development)
Create a community resource of model-driven development artifacts to provide infrastructure to improve the use of model-based development.

12. XML Metadata Interchange (XMI)
XML Metadata Interchange (XMI) provê o mecanismo para implementar a distribuição de modelos entre ferramentas de diferentes empresas e entre repositórios, ou seja, intercâmbio de metadados entre ferramentas de modelagem.
Integra três padrões: XML, UML, MOF
Padrão OMG para codificar modelos de documentos XML em conformidade com o padrão MOF meta-model
Permits automated generation of:
An XML schema document from a MOF meta-model and vice-versa
An XML document from a model and vice-versa
XML document generated from model is valid with respect to the XML schema document generated from the model’s meta-model
Model generated from XML document conforms to the meta-model generated from the XML schema of the XML document
O padrão de arquitetura da UML é baseada no repositório de meta modelos ( Meta-Object Facility (MOF)).
O MOF define fundamentos para criação de linguagens de modelagem usadas para modelagem de objetos, como a UML, e para modelagem de dados, como a Common Warehouse Metamodel (CWM).
O MOF define formatos padrões para elementos chaves de um modelo então eles poderão ser armazenados em um repositório comum e exportados entre ferramentas de modelagem e Linguagens.

13. X M I XML MOF UML XMI Simplified XML Streams (Models) XML Schema
(Many - based on each metamodel DTD
XML
Syntax and Encoding X
M I
UML
Models
UML
CWM
Models
UML
MOF
MetaModels
MOF
Metadata Definitions
& Management
Validate
XML Schema
(MetaModels)
(1 per metamodel used for validation)
UML
Metamodel
Analysis & Design

14. XMI Document Every XMI document consists:
An XML version processing instruction. Example: <? XML version=”1.0” ?>
An optional encoding declaration that specifies the character set, which follows the ISO (also called extended Unicode) standard. Example: <? XML version=”1.0” ENCODING=”UCS-2” ?>
Any other valid XML processing instructions.
A schema XML element.
An import XML element for the XMI namespace.
Common Warehouse Metamodel (CWM) - The Common Warehouse Metamodel (CWM™) is a specification that describes metadata interchange among data warehousing, business intelligence, knowledge management and portal technologies.  The OMG Meta-Object Facility (MOF™) bridges the gap between dissimilar meta-models by providing a common basis for meta-models. If two different meta-models are both MOF-conformant, then models based on them can reside in the same repository.  More information about this specification, its benefits and companies implementing the specification is below. 

15. Example of MOF meta-model’s serialization as XML Schema using XMI
extends
extends
0 ..*
useCase
title
0 ..1
actor
name
system
name *
includes
<xsd:schema xmlns:xsd=’
<xsd:complexType name = umlModel>
<xsd:complexType name = actor>
<xsd:sequence> <xsd:element name = “name” type = “xsd:string”/> </xsd:sequence>
</xsd:complexType>
<xsd:complexType name = “useCase”> <xsd:sequence> <xsd:element name = “title” type = “xsd:string”/> </xsd:sequence>
<xsd:complexType name = “system”>
<xsd:complexType name = “actor2useCase” isDirected = “true” isAggregation = “false” isGeneralization = “false”>
<xsd:sequence>
<xsd:element from = “actor” minOccurs = “1” maxOccurs = “1”/> <xsd:element to = “useCase” minOccurs = “1” maxOccurs = “1”/> </xsd:sequence>
<xsd:complexType name = “system2useCase” isDirected = “true” isAggregation = “true” isGeneralization = “false”>
<xsd:element name = “from” ref = “system” minOccurs = “1” maxOccurs = “1”/>
<xsd:element name = “to” ref = “useCase” minOccurs = “1” maxOccurs = “unbounded”/>
</xsd:sequence>
<xsd:complexType name = “actorExtendsActor” isDirected = “true” isAggregation = “false” isGeneralization = “true”>
<xsd:element name = “from” ref = “actor” minOccurs = “1” maxOccurs = “1”/> <xsd:element name = “to” ref = “actor” minOccurs = “0” maxOccurs = “1”/>
...

16. XMI Specification

17. Projeto UFPE

18. Projeto UNIOESTE Objetivos principais
Estudo de diagramas i* gerados pela ferramenta OME na linguagem TELOS
Estudo da tecnologia XML e o padrão XMI
Estudar o padrão XMI para implementar uma ferramenta computacional que possa mapear diagramas SD e SR (i*) para Diagramas de Caso de Uso UML.
Coordenador: Victor Francisco Araya Santander
Strategic Dependency (SD) Model and the Strategic Rationale (SR) Model.

19. Java Metadata Interface - JMI
Enables the implementation of a dynamic, platform-independent infrastructure to manage the creation, storage, access, discovery, and substitute of metadata.
JMI is based on the Meta Object Facility (MOF)
For any MOF model, JMI defines the templates for generating the Java APIs.
Exchange

20. Application Areas Data warehousing and BI
Integration of DW/BI tools & frameworks
Component-based development and deployment (UML)
Integration of tool suites/component frameworks
Enterprise information portals
Integration of disparate data sources
Systems Management
Hardware/software inventory, storage management

21. JMI Use-Cases Data warehousing applications
Different data sources, data warehouse formats, and analytical tools
Community – requires common interchange infrastructure to provide a common programming model and a common interchange format
because of the variety of inter-operational challenges they face, well illustrate some of the problems encountered by the lack of a common metadata infrastructure.
The Data warehousing process has to deal with many different data sources, data warehouse formats, and analytical tools. For example, data could be collected from numerous sources, including databases, files that have captured web site click stream data, applications such as ERP or CRM systems, etc.. The first step of the data warehouse process is to Extract, Transform, and Load (a.k.a ETL process) this data into a data warehouse. There are over 250 vendors in the industry today that provide ETL tools for different kinds of data source on the input end, and analytical tools on the output end. Na organization that is putting a data warehouse solution in place typically uses multiple ETL vendors to address their unique combination of data sources, and a collection of reporting tools to analyze the data that has been distilled into the data
warehouse to generate the required reports. To address these complex inter-operational challenges, the data warehousing community requires a common metadata infrastructure that provides a common programming model, and a common interchange format. In fact, the data warehousing community is well on its way to defining a common metadata infrastructure based on the Common Warehouse Metamodel (CWM) and JMI (see JSR-69 “Java OLAP Interface” and JSR-73 “Data
Mining API” for details).

22. JMI Use-Cases The Software Development Scenario
Different tool for each task
Different tools for the same task
JMI as a platform for integrating heterogeneous software development tools to provide a complete software development solution
Large Enterprise JavaBeans™ (EJB) application (UML tools, Integrated Development Environments (IDEs), EJB deployment tools)
EJB development solution - built around JMI using three metamodels that represent the domains of the different tasks
Each tool participate – integrated solution through an adapter that maps the tool specific APIs to the JMI APIs for the respective model.
Reduce integration complexity
This scenario illustrates using JMI as a platform for integrating heterogeneous software
development tools to provide a complete software development solution. In most cases, the
development team will be using a different tool for each task within the development process, or
may even use different tools for the same task. Let’s take, for example, the development of a large
Enterprise JavaBeans™ (EJB) application. Here, it is likely that the development team will use one or more modeling tools, such as UML tools, to “model” the application, one or more Integrated Development Environments (IDEs) to develop the Java source, and one or more EJB deployment tools to mange the deployment of the application.
For this scenario, an EJB development solution can be built around JMI using three metamodels
that represent the domains of the different tasks, i.e., the UML metamodel, the Java metamodel,
and the EJB metamodel. Each tool would then participate in this integrated solution through an
adapter that maps the tool specific APIs to the JMI APIs for the respective metamodel. Services
that span multiple tasks, such as keeping the model and source code in sync, are then developed
using the JMI APIs. The primary advantages of this solution over a hand crafted solution are:
Services that span multiple domains, or even extensions to all tools of a single domain, can be
developed using the common programming model provided by JMI. Note that such services
and extensions are tool independent.
The complexity of integration has been reduced from N x N where N is the number of tools
being integrated, to M x M where M is the number of domains spanning the problem space (in
this case, modeling, coding, and deployment). Adding a new tool would only require the
development of a single adapter — all services that span the domain of that tool will then work
with the new tool as well.
This example illustrates the advantages of abstraction (i.e., metamodels) and the common Java
programming model for accessing metadata, in any integration framework. Integration platforms
developed using JMI are inherently extensible.

23. Java™ Metadata Interface(JMI) Specification

24. Eclipse Project
Provide open platform for application development tools
Run on a wide range of operating systems
GUI and non-GUI
Language-neutral
HTML, Java, C, JSP, EJB, XML, GIF, …
Facilitate perfect tool integration
At UI and deeper
Add new tools to existing installed products
Attract community of tool developers
Including independent software vendors (ISVs)
Capitalize on popularity of Java for writing tools
perfect

25. Plataforma Eclipse
The Eclipse Platform is a framework with a powerful set of services that support plug-ins, such as JDT and the Plug-in Development Environment. It consists of several major components: the Platform runtime, Workspace, Workbench, Team Support, and Help.
Platform The Platform runtime is the kernel that discovers at start-up what plug-ins are installed and creates a registry of information about them. To reduce start-up time and resource usage, it does not load any plug-in until it is actually needed. Except for the kernel, everything else is implemented as a plug-in.
Workspace The Workspace is the plug-in responsible for managing the user's resources. This includes the projects the user creates, the files in those projects, and changes to files and other resources. The Workspace is also responsible for notifying other interested plug-ins about resource changes, such as files that are created, deleted, or changed.
Workbench The Workbench provides Eclipse with a user interface. It is built using the Standard Widget Toolkit (SWT) -- a non-standard alternative to Java's Swing/AWT GUI API -- and a higher-level API, JFace, built on top of SWT that provides user interface components.
the major components, and APIs, of the Eclipse Platform

26. Eclipse Plug-in Architecture
Plug-in - smallest unit
Big example: HTML editor
Small example: Action to create zip files
Extension point - named entity for collecting “contributions”
Example: extension point for workbench preference UI
Extension - a contribution
Example: specific HTML editor preferences
The SWT has proven to be the most controversial part of Eclipse. SWT is more closely mapped to the native graphics capabilities of the underlying operating system than Swing or AWT, which not only makes SWT faster, but also allows Java programs to have a look and feel more like native applications. The use of this new GUI API could limit the portability of the Eclipse workbench, but SWT ports for the most popular operating systems are already available.
The use of SWT by Eclipse affects only the portability of Eclipse itself -- not any Java applications built using Eclipse, unless they use SWT instead of Swing/AWT.
Team support The team support component is responsible for providing support for version control and configuration management. It adds views as necessary to allow the user to interact with whatever version control system (if any) is being used. Most plug-ins do not need to interact with the team support component unless they provide version control services.
Help The help component parallels the extensibility of the Eclipse Platform itself. In the same way that plug-ins add functionality to Eclipse, help provides an add-on navigation structure that allows tools to add documentation in the form of HTML files.

27. Eclipse Plug-in Architecture
Each plug-in
Contributes to 1 or more extension points
Optionally declares new extension points
Depends on a set of other plug-ins
Contains Java code libraries and other files
Lives in its own plug-in subdirectory
Details spelled out in the plug-in manifest
Manifest declares contributions
Code implements contributions and provides API
plugin.xml file in root of plug-in subdirectory

28. Plug-in Manifest plugin.xml Plug-in identification
<plugin id = “com.example.tool"
name = “Example Plug-in Tool"
class = "com.example.tool.ToolPlugin">
<requires>
<import plugin = "org.eclipse.core.resources"/>
<import plugin = "org.eclipse.ui"/>
</requires>
<runtime>
<library name = “tool.jar"/>
</runtime>
<extension point = "org.eclipse.ui.preferencepages">
<page id = "com.example.tool.preferences"
icon = "icons/knob.gif"
title = “Tool Knobs"
class = "com.example.tool.ToolPreferenceWizard“/>
</extension> <extension-point name = “Frob Providers“ id = "com.example.tool.frobProvider"/>
</plugin>
Plug-in identification
Other plug-ins needed
Location of plug-in’s code
Declare contribution this plug-in makes
Declare new extension point open to contributions from other plug-ins

29. Eclipse
So, what do we mean when we say model? When talking about modeling, we generally think about things like Class Diagrams, Collaboration Diagrams, State Diagrams, and so on. UML (Unified Modeling Language) defines a (the) standard notation for these kinds of diagrams. Using a combination of UML diagrams, a complete model of an application can be specified. This model may be used purely for documentation or, given appropriate tools, it can be used as the input from which to generate part of or, in simple cases, all of an application.
Given that this kind of modeling typically requires expensive Object Oriented Analysis and Design (OOA/D) tools, you might be questioning our assertion, above, that EMF provides a low cost of entry. The reason we can say that is because an EMF model requires just a small subset of the kinds of things that you can model in UML, specifically simple definitions of the classes and their attributes and relations, for which a full-scale graphical modeling tool is unnecessary.
While EMF uses XMI (XML Metadata Interchange) as its canonical form of a model definition[1] , you have several ways of getting your model into that form:
Create the XMI document directly, using an XML or text editor
Export the XMI document from a modeling tool such as Rational Rose
Annotate Java interfaces with model properties
Use XML Schema to describe the form of a serialization of the model
The first approach is the most direct, but generally only appeals to XML gurus. The second choice is the most desirable if you are already using full-scale modeling tools. The third approach provides pure Java programmers a low-cost way to get the benefits of EMF and its code generator using just a basic Java development environment (for example, Eclipse's Java Development Tools). The last approach is most applicable in creating an application that must read or write a particular XML file format.

30. Eclipse Modeling Framework (EMF)
EMF is a modeling framework and code generation facility for building tools and other applications based on a structured data model.
From a model specification described in XMI, EMF provides tools and runtime support to produce a set of Java classes for the model, a set of adapter classes that enable viewing and command-based editing of the model, and a basic editor.
In a nutshell: it is to exchange models into Java code

31. A Reflection API é um pacote que atua sobre as classes existentes na aplicação. É possível acessar atributos, construtores e métodos assim como buscar modificadores, identificar classes e seus pertences.

37. EMF Relation to OMG MOF
For those of you that are familiar with OMG (Object Management Group) MOF (Meta Object Facility), you may be wondering how EMF relates to it. Actually, EMF started out as an implementation of the MOF specification but evolved from there based on the experience we gained from implementing a large set of tools using it. EMF can be thought of as a highly efficient Java implementation of a core subset of the MOF API. However, to avoid any confusion, the MOF-like core meta model in EMF is called Ecore.
In the current proposal for MOF 2.0, a similar subset of the MOF model, which it calls EMOF (Essential MOF), is separated out. There are small, mostly naming differences between Ecore and EMOF; however, EMF can transparently read and write serializations of EMOF.

39. Here is the complete class hierarchy of the Ecore model (shaded boxes are abstract classes):

46. EMF homepage

47. EMF Capítulo 2

48. Summary Há 20 anos atrás… Atualmente: Futuro:
estruturada, procedimentos, dados, função….
Atualmente:
Avanço tecnológico – novas perspectivas
Business intelligence, onlogogies ….
Futuro:
federal global model repository
web semantica

49. References – Model Repositories
- The Data Administration Newsletter (TDAN.com) Robert S. Seiner - Publisher
Bézivin, J, Jouault, F, and Valduriez, P : On the Need for Megamodels. In: Proceedings of the OOPSLA/GPCE: Best Practices for Model-Driven Software Development workshop, 19th Annual ACM Conference on Object-Oriented Programming, Systems, Languages, and Applications Disponível em

50. References – XML and XMI

51. References - JMI http://java.sun.com/products/jmi/

52. References - EMF
Eclipse EMF Help - overviews, tutorials, API reference - EMF Project Web Site
- documentation, newsgroup, mailing list, Bugzilla
Eclipse Modeling Framework by Frank Budinsky et al.
Addison-Wesley; 1st edition (August 13, 2003) - ISBN:
IBM Redbook
publication number: SG

53. Thanks