CIn/UFPE – in1008 – Projeto Conceitual de Banco de Dados - Rafael J. Carício da Fonsêca 1

CIn/UFPE – in1008 – Projeto Conceitual de Banco de Dados - Rafael J. Carício da Fonsêca 1

http://www.ufrpe.br/


UML Metamodel

UML Profiles

Por:Rafael Jacinto Carício da Fonsêca

[email protected]

Prof. Robson Fidalgo



Roteiro

• Motivação• Objetivos• Meta Object Facility 1.4• Unified Modeling Language 1.5• Common Warehouse Metamodel 1.1• Visão geral da Model Driven Architeture• Estado da Arte

Meta Object Facility 2.0 Unified Modeling Language 2.2 Information Management Metamodel (versão em desenvolvimento)

• Aplicação prática da utilização e definição de UML2 Profile



Motivação• A evolução dos conceitos de desenvolvimento

de software a um nível mais alto, o nível de metamodelagem. Software não seria mais desenvolvido escrevendo-se

código e sim modelando conceitos de negócio;

• A formalização desse processo é de extrema importância para permitir a criação de ferramentas de Computer-Aided Software Engineering (CASE) e permitir a interoperabilidade entre as mesmas; O grupo responsável pela definição e formalização

dessas especificações é a Object Management Group (OMG);


http://www.omg.org/


Objetivos

• Permitir uma compreensão completa das especificações de metamodelagem padrões pela OMG;

• Identificar os pontos de evolução das especificações;

• Entender profundamente os conceitos envolvidos na metamodelagem e onde podem ser aplicados;

• Apresentar uma abordagem prática de utilização de um dos conceitos apresentados (UML2 Profile);



Meta Object Facility 1.4

• Especificação de um framework para manipulação de meta dados.

• É uma linguagem de definição de metamodelos de alto nível.

• Permite que sejam desenvolvidas ferramentas que possam manipular os dados dos meta modelos desenvolvidos em MOF.

FerramentaCASEMeta dados

Modelo




• Para criação do MOF 1.4 foi necessária a criação de uma notação baseada baseada na notação do modelo de classes da UML.

• Esta notação é descrita em detalhes na especificação e se assemelha bastante a o modelo de classes UML. Não foi utilizada a UML 1.5 porque existem vários

conceitos que não seriam aplicados;




• Comparação com aUML 1.5:

Não são todos os elementos que existem em ambos dos meta-modelos;

[MOF]




• A UML e o MOF fazem parte de um conceito de camadas de meta modelagem.

• Cada elemento em um nível conceitual descreve os elementos da próxima para baixo. O metamodelo MOF é a linguagem usada para definir o

meta modelo da UML; O metamodelo da UML é usado para descrever modelos

UML, e; Um modelo UML é uma linguagem que define aspectos de

um sistema computacional. [MOF]




• Visão do modelo de camadas de metamodelagem:

[MOF]




• O MOF descreve cada detalhe de funcionamento do meta metamodelo visando o que é necessário. Exemplo de descrição de como é um relacionamento;

Exemplo de descrição de como é uma regra:

[MOF]




• Visão geral do metamodelo MOF:

[MOF]



Unified Modeling Language 1.5

• Define uma série de diagramas visuais para modelagem de vários aspectos; Modelo de classes; Modelo de casos de uso; Diagramas estruturais; Diagramas de instância.

• Estes diagramas proveem multiplas pespectivas de um sistema que está sendo analisado. Estas pespectivas são consistentes e permitem análises.

[UML1]




• Principáis objetivos da UML: Prover aos usuários uma linguagem expressiva para

modelagem visual pronta para uso; Fornecer mecanismos de extensibilidade e especialização

para estender os conceitos centrais; Suportar especificações que são idependentes de uma

linguagem de programação particular, de um processo de desenvolvimento.

Prover um base formal para entendimento de linguagem de modelagem;

[UML1]




• Principáis objetivos da UML (Cont.): Encorajar o crescimento de ferramentas baseadas em

objeto no mercado; Suportar desenvolvimento em alto nível como

componentes, colaborações, frameworks e padrões; Integrar as melhores práticas da industria com base em

níveis de abstração.




• Recursos introduzidos na UML 1.5: Extensibilidade (estereótipos, tagged values e regras); Linguagem de definição de regras (Object Constraint

Language - OCL); Diagramas de atividades (modelagem de negócio); Refinamento (inter-relacionar diferentes níveis de

abstração); Interfaces e componentes;

[UML1]




• A especificação da UML 1.5 introduz diversos conceitos e como as notações visuais devem ser utilizadas;

• Melhores práticas para implementação dessas notações; Ex.: Nome da classe centralizado e com fonte em negrito.



Common Warehouse Metamodel

• O objetivo primário do Common Warehouse Metamodel (CWM) é definir um metamodelo de um data warehouse de arquitetura genérica.

• Deste modo o metamodelo do CWM define regras formais de modelagem de instâncias de data warehouses;

• Outro requisito do metamodelo CWM é ser expressado em MOF; Permitir interoperabilidade via XMI. [CWM]




• Para permitir a definição do CWM foi-se necessário a “cópia” de parte do core da UML (sub-conjunto);

• Esses elementos providos das definições da UML são subdivididos em 3 pacotes que juntos formam o ObjectModel do CWM; [CWM]




• Reuso de conceitos da UML O CWM é baseado em um ObjectModel que é uma versão

do metamodelo da UML onde os conceitos que não são relevantes no contexto de data warehouse foram retirados;

Muitos dos conceitos de objetos da UML são refletidos no CWM ObjectModel, onde os tipos do ObjectModel são sub-tipados para representar conceitos mais especificos de tipos do metamodelo CWM;

Esta abordagem trás vantagens pois permite que o CWM capture boa parte do investimento no desenvolvimento e refinamento do metamodelo UML;

[CWM]



CWM – Object Model

• Pacote Core

[CWM]




• Classes de suporte




• Pacote Behavioral




• Pacote Relationship




• Pacote Instance




• É uma especificação que engloba vários pacotes: Transformation; Relacional; OLAP.

• Cobre o ciclo de vida inteiro do processo de projeto, construção e gerência de aplicações para data warehouses;

• É um padrão aceito pelo mercado;



Model Driven Architecture

• Os conceitos apresentados são utilizados em uma arquitetura chamada Model Driven Architecture (MDA);

[MDA]



Model Driven Architecture

• MDA é uma especificação de uma arquitetura de desenvolvimento de software utilizando os padrões definidos pela OMG;

• Na MDA não é necessária a programação diretamente em código fonte a implementação do sistema é “inferida” a partir dos seus modelos de especificação;

• Existem três níveis de abstração: CIM – Computational Independent Model;

• Modelo independente de computação; PIM – Platform Independent Model;

• Modelo independente de plataforma. PSM – Platform Specific Model.

• Modelo especifico de plataforma.

[MDA]



[Patrick]



Estado da Arte

• A experiência na implementação das especificações de MOF 1.4 e CWM levaram a percepção de um problema em comum: Todas redefiniam um subconjunto da UML para se auto-

definir e estender; Alguns retiravam partes da definição da UML para abortar

outros conceitos diferentes da UML (o CWM que é voltado para modelagem de dados);

• A percepção destes problemas levaram a definições de projeto importantes para o futuro de UML; Assim a UML2 foi sub-dividida em 2 partes

complementares;




• O MOF2 utiliza os conceitos padrão de modelagem de classes: Subclassificação; Adição de atributos; Adição de novas classes; Adição de operações.

• Estes conceitos são usados para se definir pacotes adicionais em MOF 2.0: Essential MOF (EMOF); Complete MOF (CMOF).

[MOF2]




• Em MOF1 as notações de classes da UML eram usadas apenas como recurso visual;

• Em MOF2, a UML2 e ele compartilham um conjunto comum de conceitos; Para permitir esse compartilhamento de conceitos, a UML2

foi dividida em dois níveis de completude:• UML Infrastructure (Infra-estrutura UML);• UML Superstructure (Super-estrutura UML).

• Essa relação entre a UML2 e MOF2 foi resultado da experiência de se desenvolver padrões como UML e CWM.

[MOF2]



UML Infrastructure

• Contém um conjunto de formalizações de conceitos básicos para definição de metamodelos;

• É subdividido em pacotes: Core; Profile.

[UML2Infra]



UML Core Infrastructure

• O pacote Core é a parte central e reusável da biblioteca de infra-estrutura (InfrastructureLibrary).

[UML2Infra]




• É subdividido em 3 sub-pacotes:




• Pacote Core::PrimitiveTypes Define os tipos primitivos que são usados para definir

metamodelos do Core; Espera-se que todo metamodelo baseado no Core utilize

estes tipos primitivos;



UML Core::PrimitiveTypes

• Define os tipos mais básicos: Integer;

• Números inteiros que podem ser negativos ou não. Boolean;

• Pode assumir os valores true ou false. String;

• Sequencia de caracteres que podem ser letras ou números; UnlimitedNatural;

• Semelhante ao Integer, mas acrescenta o conceito de ilimitado que é representado pelo valor “ * ” (asterisco).




• Pacote Core::Abstractions Define abstrações genéricas; É subdividido em pacotes menores para permitir maior

modularidade;• Exemplos de definições neste pacote:

Relacionamentos; Herança; Expressões; Namespaces; Classificadores; ...




• Pacote Core::Abstractions• Sub-pacotes:

BehavioralFeatures; Changeabilities; Classifiers; Comments; Constraints; Elements; Expressions; Generalizations; Instances; Literals;

Multiplicities; MultiplicityExpressions; Namespaces; Ownerships; Redefinitions; Relationships; StructuralFeatures; Super; TypedElements; Visibilities.



UML Core::Abstractions




• Pacote que define o suporte de ownership entre elementos. InfrastructuraLibrary::Core::Abstractions::Ownerships




• Pacote que define o que são relacionamentos. InfrastructuraLibrary::Core::Abstractions::Relationships




• Pacote que define o que são namespaces. InfrastructuraLibrary::Core::Abstractions::Namespaces




• Pacote que define os mecanismos para definição de generalizações entre Classifiers. InfrastructuraLibrary::Core::Abstractions::Super




• Pacote que define generalizações: InfrastructuraLibrary::Core::Abstractions::Generalizations

Permite navegação do especifico para o mais geral.

Permite navegação do mais geral para o mais especifico.




• Pacote Core::Basic Define elementos básicos do core relacionados a

definições de estruturas. Não é sub-dividido em pacotes, mas sim em tópicos.

• Exemplos de definições neste pacote: Classes; Tipos de dados (Enumerações); Propriedades; Multiplicidade; Pacotes.



UML Core::Basic

• Destaques: O as classes definidas neste pacote não tem

relacionamentos; O pacote é focado apenas na definição de estruturas; Ao se falar em “Classe” é desejável que se entenda é

estamos querendo nos referir a classes que definem classes, ou seja, Meta-Classes.



UML Core::Basic

• Diagrama que define o que são tipos:

Este não é o Element do Core::Abstractions



UML Core::Basic

Diagrama de classes (meta)Diagrama de classes (meta)



UML Core::Basic

• Diagrama de tipos de dados:




• Pacote Core::Constructs É um pacote especial para ser reutilizado pelo MOF¹ ; Agrupa todos os conceitos definidos pelos outros pacotes,

• Core::Abstractions;• Core::Basic;

Mas não precisa especificar o merge desses pacotes, pois ele usa o conceito de copia.

¹ CWM utiliza o MOF 1.4 que define seus próprios objetos.



UML Core::Constructs

[MOF2]




• Continuando...




• Visão geral

[MOF2]




• Os principais benefícios desse compartilhamento de conceitos são: Regras simples para modelagem de metadados;

• Entendendo o sub-conjunto UML Core não é necessário o uso de notações adicionais;

Varias tecnologias de mapeamento de MOF (como XMI, JMI, etc.) agora também se aplicam a um grande número de modelos UML. Incluindo UML Profiles*;

Maior suporte para ferramentas de metamodelagem.• Qualquer ferramenta CASE UML2 pode ser usada para se modelar

metadados mais fácilmente (ex.: Eclipse EMF).

[MOF2]

[ECore]




• Essential MOF (EMOF): Provê um conjunto mínimo de elementos obrigatórios para

modelagem orientada a objeto (em nível meta); Reusa o pacote Core::Basic da UML 2 InfrastructureLibrary

sem estender, apenas adicionando restrições.



Meta Object Facility 2.0 - EMOF

• Visão geral




• Pacote de reflexão:




• Identificadores:




• Common:




• Extension:




• Diagrama de Classes (revisão):




• Tipos de dados (revisão):




• Pacotes (revisão):




• Complete MOF (CMOF): Provê um conjunto completo de elementos para

modelagem orientada a objetos no nível meta; Acrescenta conceitos ao EMOF unindo-se a ele (merge de

conceitos);



Meta Object Facility 2.0 - CMOF

• Visão Geral




• Definição de operações de reflexão:




• Extension de CMOF: O CMOF estende o pacote Extension para adicionar o

papel “tag” permitindo navegabilidade.




• A UML2 foi subdividida em níveis de completude onde estes níveis permitiram a criação de níveis de abstração. Visão geral dos níveis com o nível LM (nível meta):

Nível meta onde se encontrao MOF2.




• Níveis de completude: L0 - Este nível de capacidade é formalmente definido na UML

Infrastructure. Contém unidades básicas da linguagem baseada em classes encontrados na maioria das linguagens de programação orientadas a objetos.

L1 - Este nível adiciona novas unidades a linguagem estendendo as capacidades do nível 0 (L0).

L2 - Este nível estende as unidades da linguagem já providas no nível 1 (L1) e adiciona novas unidades para deployment, modelagem de estados, estruturas, ações e atividades.

L3 - Este nível representa a UML completa. Ele estende a linguagem do nível 2 (L2) e adiciona novas unidades para modelagem de fluxo de informações, templates,e empacotamento de modelos.

[UML2Super]




• L0:

[UML2Super]




• L1:

[UML2Super]




• L2:




• L3:




• Continua representando vários níveis de abstração mas a maior mudança foi na sua estrutura interna com o conceito de Infra-estrutura e Super-estrutura;

• Um conceito importante introduzido pela UML2 foi o de Profile. É parte da especificação UML2.

[UML2Super]



UML2 Profile

• É uma evolução do conceito de estereotipo da UML1;

• Acrescenta semântica aos estereótipos, agora chamados de meta-classes, e introduz o conceito de meta-atributos (são os Tagged Values da UML1);

• Serve para especializar de modelo UML2; Para uma determinada plataforma;

• J2EE;• .NET;

Para um determinado domínio;• Modelos de tempo-real;• Modelos de negócio. [UML2Super]



UML2 Profile

• Caracteristicas: Um profile provê mecanismos para especializar um

metamodelo de referencia de forma que a semântica não pode contradizer a semântica do metamodelo de referência;

• Isto é, regras definidas em um profile tipicamente são mais restritivas, mas coerentes com) as especificadas pelo metamodelo de referência.

É possível trabalhar com profiles entre diferentes ferramentas juntamente com os modelos em que são aplicados usando o mecanismo XMI. Profiles podem ser incorporados a um modelo (dentro do XMI do modelo), bem como ser definido "por referêcia“;

• Isto é, profiles não precisam ser trasportados dentro dos modelos se ele já existe na ferramenta onde será usado o modelo.

[UML2Super]



UML2 Profile

• Caracteristicas (Cont.): Uma notação gráfica pode ser criada para representar um

esteriotipo e isto faz parte da definição profile;

Profiles também não podem modificar o modelo que está sendo usado como referência. No sentido de adicionar uma nova metaclasse na hierarquia padrão da UML.

• Os modelos de referência são usados de forma "read only".

A maioria das ferramentas CASE que usa UML já deveriam implementar Profiles. Pois o projeto de Profiles UML não é muito diferente do que já existia (estereótipos e tagged values);



UML2 Profile

• Caracteristicas (Cont.): Profiles podem ser aplicados e retirados dinâmicamente

em modelos;• É possivel em um modelo já existente aplicar novos profiles ou

moficar um conjunto de profiles aplicados.

Profiles podem ser dinâmicamente combinados;• Profiles diferentes podem ser aplicados em um mesmo modelo ao

mesmo tempo.

Profiles podem ser aplicados de forma inconsistente em um modelo, pois a ferramenta só deve validar a utilização do Profile se a mesma estiver de posse da definição do Profile.



UML2 Profile

• Exemplo de um modelo usando um Profile UML:



UML2 Profile

• Visão geral

[UML2Super]



UML2 Profile

• Metamodelo:



Information Management Metamodel

• Históricamente existe um “gap” entre os desenvolvedores orientados a objetos, dados e XML.

• Embora os desenvolvedores de tecnologias tenhas interesse em acabar com este “gap” de conceitos, cada um desenvolve sua propria solução para o problema;

• Como resultado, não existe nenhum padrão aceito para interoperabilidade dos modelos desenvolvidos;

• O maior objetivo do IMM é acabar com esse problema sendo um padrão para interoperabilidade destes modelos;

[IMM]




• A comunidade de modelagem de dados tem uma certa resistência em utilizar a UML para modelagem de dados;

• O IMM vem para ser a solução que visa permitir que ferramentas possam migrar entre a notação UML e outras notações fácilmente;

• Muitos dos usuários do CWM não teem ligação com desenvolvimento de data warehouses, por isso achou-se necessária a mudança do nome para Information Management Metamodel (IMM) ao invés de CWM 2.0;

[IMM]




• Este inclui o escopo do padrão CWM, mas estendendo com as seguintes temas:

Um metamodelo IMM;

UML 2 Profile para Modelagem Relacional de dados mapeado para o metamodelo IMM e SQL DDL;

UML 2 Profile para Modelagem Lógica de dados com mapeamento para IMM;

UML 2 Profile para Modelagem de dados em XML com mapeamento para IMM e XML Schema;

UML 2 Profile para Modelagem de Registros com mapeamento para IMM e COBOL Copybooks;

Uma padronizada notação de modelagem de dados de “Engenharia de Informações” com mapeamento para IMM;

[IMM]




• Resumindo:

O IMM foi desenvolvido como um metamodelo com mapeamentos para Profiles UML 2 especializados para modelagem de dados;

Existe um metamodelo geral e o metamodelo de mapeamentos para Profiles UML 2;

Não existe uma notação específica para o metamodelo IMM;



Conclusões

• A evolução das especificações é importante para o fortalecimento das formalizações; Cada evolução (nova versão) leva ao amadurecimento da tecnologia.

• A experiência no desenvolvimento de formalizações permitiu a evolução mais coerente para os metamodelos especificados pela OMG, permitindo uma maior uniformidade;

• Esta uniformidade permite uma melhor interoperação das implementações das formalizações: Ferramentas desenvolvidas para uso de UML2 podem ser usadas

para metamodelagem;• Exp.: A tecnologia ECore que implementa o EMOF pode ser usada para

manipulação de metamodelos UML2, permitindo a definição de profiles UML2 usando ECore.



Conclusões

• Cada formalização tem um objetivo bem especifico:

MOF 1.4 – Criação de uma base para manipulação de metadados e uma estrutura para ser auto-definido;

CWM – Criação de uma extensão especifica de domínio (no caso a modelagem de dados);

MOF 2.0 – Foco muda para a criação de uma base para manipulação de metadados sem preocupação com criação de uma estrutura de auto-definição, essa estrutura agora é a UML Core;



Conclusões

• Cada formalização tem um objetivo bem especifico (Cont.): UML2 InfrastructureLibrary – Base sólida e abstrata de

construtores de metaclasses. Serve como base para MOF2, UML2, CWM e IMM. Espera-se que seja utilizado em especificações de metamodelos que desejam estar em conformidade com as especificações da OMG;

UML2 Superstructure – UML2 completa, com todos os metamodelos de diagramas que permitem a modelagem de conceitos para desenvolvimento de soluções;

IMM – Evolução do CWM para permitir que diferentes soluções de mapeamentos entre OO e modelagem de dados sejam interoperáveis, para isso, definem um metamodelo geral e seus respectivos mapeamentos para Profiles UML 2;



Conclusões

• Visão geral: IMM

[UML2Infra]



Abordagem prática• UML2 Profile na prática

Definição de um profile:



Referências[ECore] The Eclipse Modeling Framework (EMF) Overview,

Disponível emhttp://help.eclipse.org/ganymede/index.jsp?topic=/org.eclipse.emf.doc/references/overview/EMF.htmlAcessado em 28/05/2009.

[IMM] Information Management Metamodel (IMM) Specification,ptc/07-08-30.Disponível em http://www.omg.org/docs/ptc/07-08-30.doc

[Patrick] Könemann, Patrick, Meta-Leves.Disponível em http://www2.imm.dtu.dk/~pk/images/meta-

levels.pdfAcessado em 29/05/2009

[MDA] MDA Guide Version 1.0.1, omg/2003-06-01.Disponível em http://www.omg.org/docs/omg/03-06-01.pdf

[Frankel] FRANKEL, DAVID,Model Driven Architecture, 1ª Edição – 2003.

[UML2Infra] OMG Unified Modeling Language (UML) Infrastructure,Version 2.2, formal/2009-02-04. Disponível em http://www.omg.org/spec/UML/2.2/Infrastructure

[UML1] OMG Unified Modeling Language Specification,Version 1.5, formal/03-03-01Disponível em http://www.omg.org/docs/formal/03-03-01.pdf

[UML2Super] OMG Unified Modeling Language (UML) Superstructure,Version 2.2, formal/2009-02-02. Disponível em http://www.omg.org/spec/UML/2.2/Superstructure

[CWM] Common Warehouse Metamodel (CWM) SpecificationVersion 1.1, formal/03-03-02.Disponível em http://www.omg.org/cgi-bin/doc?formal/03- 03-02

[MOF2] Meta Object Facility (MOF) Core SpecificationVersion 2.0, formal/06-01-01. Disponível em http://www.omg.org/spec/MOF/2.0

[MOF]Meta Object Facility (MOF) Core SpecificationVersion 1.4, formal/02-04-03.Disponível em http://www.omg.org/docs/formal/02-04-03.pdf




Documents

CIn/UFPE – in1008 – Projeto Conceitual de Banco de Dados - Rafael J. Carício da Fonsêca 1