Uma Ferramenta baseada em Modelos para Modelagem Conceitual ontologicamente bem fundada

Transcrição

1 Universidade Federal do Espírito Santo UFES Centro Tecnológico CT Departamento de Informática DI Engenharia de Computação Disciplina: Projeto de Graduação INF02850 Orientador: Prof. Dr. Giancarlo Guizzardi Co orientador: Prof. Dr. João Paulo Almeida Andrade Aluno: Alessander Botti Benevides Matrícula: Período: 2007/1 Uma Ferramenta baseada em Modelos para Modelagem Conceitual ontologicamente bem fundada Vitória 2007

2 Alessander Botti Benevides Uma Ferramenta baseada em Modelos para Modelagem Conceitual ontologicamente bem fundada Monografia apresentada ao Programa de Graduação em Engenharia de Computação do Centro Tecnológico da Universidade Federal do Espírito Santo, como requisito parcial para obtenção do Titulo de Engenheiro de Computação. Orientador: Prof. Dr. Giancarlo Guizzardi Co orientador: Prof. Dr. João Paulo Almeida Andrade Vitória 2007

3 Alessander Botti Benevides Uma Ferramenta baseada em Modelos para Modelagem Conceitual ontologicamente bem fundada Monografia apresentada ao Programa de Graduação em Engenharia de Computação do Centro Tecnológico da Universidade Federal do Espírito Santo, como requisito parcial para obtenção do Titulo de Engenheiro de Computação. Aprovada em 13 de agosto de 2007 Comissão Examinadora Prof. Dr. Giancarlo Guizzardi Universidade Federal do Espírito Santo Orientador Prof. Dr. João Paulo Almeida Andrade Universidade Federal do Espírito Santo Co orientador

4 à meus pais, que me ensinaram o valor da perseverança. à meu irmão, pela amizade e apoio nas disciplinas em que houve a oportunidade de concluirmos juntos. à minha namorada, Renata, pelo amor e compreensão durante os anos de dedicação a este curso. aos mestres que conheci, pelo incentivo, amizade e conhecimentos transmitidos. à todos que me auxiliaram a realizar esse pequeno passo, dentre tantos sonhos.

5 Agradecimentos Aos meus pais, pelo auxílio; ao meu irmão pela amizade e apoio; e à minha namorada, Renata, pelo amor e compreensão. Ao professor Giancarlo, por aceitar me como aluno de iniciação científica, orientar meu projeto de graduação e ser meu orientador no mestrado. Ao professor João Paulo, meu co orientador, pela assistência na realização desse projeto. Ao professor José Gonçalves, por apresentar me ao professor Giancarlo e viabilizar minha bolsa de iniciação científica. Ao CNPq e a todos que me auxiliaram nesse projeto.

6 "Deveríamos ser capazes de recusar nos a viver se o preço da vida é a tortura de seres sensíveis." Mahatma Gandhi O que se pode em geral dizer, pode se dizer claramente; e sobre aquilo de que não se pode falar, deve se calar. Ludwig Wittgenstein

7 Resumo O objetivo dessa monografia é o estudo da proposta de alteração do metamodelo da linguagem UML 2.0, feita em [Guizzardi, 2005], e posterior construção de uma ferramenta para modelagem conceitual ontologicamente bem fundada. Ao longo da monografia, são mostradas as propostas do framework MDA, as limitações da linguagem UML 2.0 e a necessidade da utilização de uma linguagem formal adicional para a escrita de restrições. Também é explicitada a análise feita na tese supracitada, na qual tenta se mapear conceitos da ontologia fundacional UFO à metaclasses do metamodelo UML 2.0. A partir da análise anterior, é colocada uma proposta de alteração ao metamodelo UML, para que o mesmo seja compatível com a ontologia fundacional UFO. Esse novo metamodelo é a sintaxe abstrata da linguagem utilizada na escrita de ontologias de domínio na ferramenta construída nessa monografia. Palavras chave: modelagem, metamodelagem, ontologia, mereologia, OCL, Eclipse, EMF, GMF, MDT. UFO, MDA, UML,

8 Abstract The objective of this monograph is the study of the alteration proposal of the metamodel of the language UML 2.0, made in [Guizzardi, 2005], and further construction of a tool for ontologically well established conceptual modelling. Throughout the monograph, are shown the proposals of the MDA framework, the limitations of UML 2.0 language, and the necessity of the use of an additional formal language for the writing of restrictions. Also is explicited the analysis made in the above mentioned thesis, in which it is tried to map concepts of the foundational ontology UFO to metaclasses of the UML 2.0 metamodel. From the previous analysis, it is placed a proposal of alteration to the UML metamodel, so that the same is compatible with the foundational ontology UFO. This new metamodel is the abstract syntax of the language used in the writing of domain ontologies in the tool constructed in this monograph. Keywords: modelling, metamodelling, ontology, mereology, UFO, MDA, UML, OCL, Eclipse, EMF, GMF, MDT.

9 Lista de Figuras Figura 1: Símbolo usual para plataforma...22 Figura 2: Transformação de modelo...24 Figura 3: Marcação em um modelo...26 Figura 4: Transformação entre metamodelos...27 Figura 5: Aplicação de padrões...27 Figura 6: Padrões como nomes de marcas...28 Figura 7: Transformação de um PIM em um PSM...30 Figura 8: Segunda transformação...31 Figura 9: Terceira transformação...31 Figura 10: PIM, PSM, aplicação e plataforma...32 Figura 11: PIM, PSM, aplicação e plataforma, sob pontos de vista diferentes...32 Figura 12: Três visões distintas do que seriam plataformas...33 Figura 13: Abstração de plataformas...33 Figura 14: Transformação por mapeamento entre metamodelos...34 Figura 15: Modelo expresso em um diagrama UML...38 Figura 16: Fragmento do metamodelo da UFO referente à classes e generalização...51 Figura 17: Fragmento revisado do metamodelo UML...52 Figura 18: Fragmento do metamodelo da UFO referente à classificadores e propriedades...57 Figura 19: Fragmento revisado do metamodelo UML...58 Figura 20: Fragmento do metamodelo da UFO referente à agregação e composição...65 Figura 21: Fragmento revisado do metamodelo UML...65 Figura 22: Metamodelo unificado...73 Figura 23: 1ª, 2ª e 3ª transformações...75 Figura 24: Diagrama das transformações do metamodelo...76 Figura 25: 4ª transformação...77 Figura 26: 5ª transformação...77 Figura 27: 6ª transformação...77 Figura 28: 7ª transformação...78 Figura 29: 8ª transformação...78 Figura 30: Exemplo de ontologia de domínio...79 Figura 31: Ontologia de domínio construída no editor...80 Figura 32: Exemplo de validação em tempo real...81 Figura 33: Exemplo de validação manual...82

10 Lista de Tabelas Tabela 1: Especificação de operações...70 Tabela 2: Especificação de derivações...71

11 Lista de Abreviaturas ALU Arithmetic and Logic Unit (Unidade Aritmética e Lógica); BNF Backus Naur Form (Forma Backus Naur); CD Compact Disc (Disco Compacto); CIM Computation Independent Model (Modelo Independente de Computação); CNPq Conselho Nacional de Desenvolvimento Científico e Tecnológico; CPU Central Process Unit (Unidade Central de Processamento); EM Extensional Mereology (Mereologia Extensional); EMF Eclipse Modeling Framework (Suporte à Modelagem no Eclipse); EMOF Essential MOF (MOF Essencial); GEF Graphical Editing Framework (Suporte à Edição Gráfica); GMF Graphical Modeling Framework (Suporte à Modelagem Gráfica); IDE Integrated Development Environment (Ambiente Integrado de Desenvolvimento); JET Java Emitter Templates (Emissor Java de Padrões); MDA Model Driven Architecture (Arquitetura dirigida à Modelo); MDE Model Driven Engineering (Engenharia dirigida à Modelo); MDT Model Development Tools (Ferramentas de Desenvolvimento de Modelo); MM Minimum Mereology (Mereologia Mínima); MML's Modeling Maturity Levels (Níveis de Maturidade de Modelagem); MOF Meta Object Facility (Aparato de Meta Objeto); OCL Object Constraint Language (Linguagem de Restrição de Objeto); OWL Web Ontology Language (Linguagem de Ontologia para a Web); OMG Object Management Group (Grupo de Gerência de Objeto); PIM Platform Independent Model (Modelo Independente de Plataforma); PSM Platform Specific Model (Modelo Específico de Plataforma); SQL Structured Query Language (Linguagem de Consulta Estruturada); UFES Universidade Federal do Espírito Santo; UFO Unified Foundational Ontology (Ontologia Fundacional Unificada); UML Unified Modeling Language (Linguagem Unificada de Modelagem).

12 Sumário 1. Introdução Estrutura da monografia Pressupostos Teóricos Da (meta)modelagem Da Modelagem Níveis de maturidade de modelagem Nível 0: Nenhuma especificação Nível 1: Textual Nível 2: Texto com diagramas Nível 3: Modelos com texto Nível 4: Modelos precisos Nível 5: Somente modelos Da Metamodelagem MDA Conceitos Básicos Transformações MDA Mapeamentos Mapeamento entre tipos Mapeamento em nível de instâncias Combinação das duas formas de mapeamento anteriores Templates Métodos de Transformação Marcação Transformação entre Metamodelos Aplicação de Padrões Graus de Automação e Suporte Computacional Transformação Manual Transformação de um PIM preparado por um perfil Transformação utilizando Padrões e Marcas Transformações Automáticas Outras Capacidades MDA Múltiplas Aplicações das Transformações MDA Transformações Gerais Modelo para Modelo Reuso de Mapeamentos Extensão Combinação OCL Propriedades da linguagem OCL Linguagem de restrição e de consulta Fundamentação matemática Linguagem declarativa...37

13 Aplicação em diagramas de classe Regras de derivação Valores Default Especificação de operações de consulta Invariantes Pré condições e pós condições Mensagens em pós condições Definição de classes derivadas Multiplicidade dinâmica Multiplicidade opcional Restrições ou Estilos de modelagem Definição de atributos ou operações A restrição de subconjunto Herança X Invariantes MDA, UML e OCL Modelagem com UML/OCL Metamodelagem com UML/OCL Transformações definidas com UML/OCL Metamodelagem utilizando se o Eclipse MOF EMF GMF...47 Das Limitações da Modelagem Conceitual Utilizando se UML Classes e Generalização Classificadores e Propriedades Agregação e Composição Invariantes adicionais Definição de métodos em OCL Definição de meta atributos/meta associações derivados...71 Construção e Uso da Ferramenta de Modelagem Análise das transformações Estudo de Caso...78 Conclusão Das dificuldades Trabalhos futuros...85 Referências...86 Apêndice 1: XML's Código do metamodelo ECore Código do modelo Gen Código do modelo GMFGraph Código do modelo GMFTool Código do modelo GMFMap...112

14 8. Apêndice 2: Códigos Java das decorações Código Java para a implementação da metaclasse Collective Código Java para a implementação da metaclasse GeneralizationSet Código Java para a implementação das relações SubQuantityOfCustomFigure.java SubQuantityOfEditPart.java GeneralizationCustomFigure.java DerivationCustomFigure.java...162

15 1. Introdução O objetivo dessa monografia é a construção de um editor para a construção de modelos conceituais ontologicamente bem fundados. A motivação para a criação de tal editor é a avaliação da linguagem UML 2.0 (Unified Modelling Language) [ exposta em [Guizzardi, 2005], no qual é proposto um framework para a avaliação de linguagens de modelagem e, utilizando se o mesmo, é mostrada a inadequação da linguagem UML 2.0 em representar uma série de características da realidade. [Guizzardi, 2005] também constrói um metamodelo revisado da UML 2.0 e um perfil de modelagem, que são a especificação da linguagem de modelagem ontologicamente bem fundada utilizada no presente projeto como base para a criação do editor. A avaliação da linguagem UML 2.0 foi feita comparando se o metamodelo da mesma com a teoria ontológica formal UFO (Unified Foundational Ontology), também definida em [Guizzardi, 2005]. Essa avaliação mostra a incapacidade da UML em representar diversos tipos de relações ontológicas propostas na UFO. A ontologia UFO foi a ontologia fundacional adotada na avaliação da linguagem UML por ser teoricamente bem fundamentada (baseada em teorias filosóficas formais e que possuem corroboração empírica) e relevante para a prática de construção de modelos conceituais em sistemas sensíveis ao contexto. Para a realização desse projeto também foi estudada a necessidade da utilização de uma linguagem formal adicional, no caso OCL 2.0 (Object Constraint Language) [10], para ampliar a expressividade dos modelos construídos em UML. Essa linguagem também é utilizada na tradução das restrições propostas no perfil de modelagem exposto em [Guizzardi, 2005], escritas em linguagem natural, para OCL 2.0. Outra linguagem estudada foi a linguagem ECore [ eclipse.org/modeling/emf/emf/javadoc/2.3.1/ org/ eclipse/ emf/ ecore/ package summary.html], na qual foi escrito o metamodelo revisado da UML 2.0. Esse metamodelo, juntamente com as restrições escritas em OCL 2.0, passará por diversas transformações até que seja construído um editor no ambiente Eclipse [ Nessa monografia também é abordado o framework MDA (Model Driven Architecture) [ que auxilia nas diversas transformações entre metamodelos, necessárias à criação do editor. A importância da criação desse editor é que ele representa uma prova de conceito da ontologia fundacional UFO e auxilia no processo de engenharia de ontologias, provendo 15

16 metaclasses e relações que permitem a criação de modelos sem ambigüidades e proíbem a criação de modelos não intencionais, ou seja, de modelos que não correspondem à realidade, na prática da modelagem conceitual. O editor também tem importância na criação de modelos compatíveis com a tecnologia MDA, pois auxiliando na criação de modelos bem definidos, aproxima se a possibilidade da realização de transformações automáticas entre modelos. 1.1 Estrutura da monografia Para facilitar a compreensão dessa monografia, é mostrada aqui uma breve descrição dos assuntos dos capítulos, bem como suas relações com os demais capítulos. O cap. 2 trata dos pressupostos teóricos necessários ao entendimento dessa monografia. A seção 2.1. expõe brevemente as principais características e objetivos da (meta)modelagem. A seção 2.2. mostra o framework MDA, um recente paradigma em modelagem e transformação de conhecimento. Suas características e técnicas são explicadas detalhadamente. O leitor não deverá perder de vista que MDA é a idéia central que permeia a criação e as transformações entre modelos realizadas nesse projeto e explicadas no cap. 4. A seção 2.3. mostra as principais capacidades e características que tornam a linguagem OCL 2.0, atualmente, a linguagem formal mais adequada para a escrita de restrições em (meta)modelos no contexto do paradigma MDA. A seção 2.4. trata da relação entre a proposta MDA e as linguagens de modelagem UML e OCL. O objetivo desse capítulo é expor a incapacidade da linguagem UML para representar uma série de características da realidade, destacando se a importância da utilização da linguagem OCL, em adição à UML, nas atividades de (meta)modelagem. Essas considerações são feitas, sempre que possível, no contexto MDA. A seção 2.5. trata do uso da ferramenta Eclipse para a criação de metamodelos e editores. O cap. 3 é baseado em [Guizzardi, 2005]. Nele são expostas as limitações e incoerências do metamodelo da linguagem UML 2.0, e as conseqüências delas na atividade de modelagem conceitual. Nas primeiras três seções são analisadas características distintas desse metamodelo e, ao final de cada uma dessas seções, são exibidas uma revisão do metamodelo e um perfil de modelagem que expõe restrições, em linguagem natural e traduzidas para OCL 2.0, necessárias ao metamodelo relacionado. O cap. 4 mostra os resultados obtidos nesse projeto. Primeiramente é exposto um metamodelo que unifica os três fragmentos revisados do metamodelo UML 2.0 propostos no cap. 6. A seguir, são exibidas as técnicas MDA utilizadas nas transformações sucessivas realizadas no metamodelo, para que seja criado um editor na plataforma Eclipse. Por fim são mostrados alguns estudos de caso da ferramenta implementada. O cap. 5 conclui a monografia e expõe, de forma sucinta, os objetivos desse projeto, os 16

17 obstáculos, avaliações das ferramentas utilizadas e trabalhos futuros. No cap. 6 constam as referências utilizadas na elaboração dessa monografia. O Apêndice 1 mostra os códigos XML criados nas diversas transformações entre metamodelos, explicadas no cap. 4. O Apêndice 2 mostra as classes Java criadas para construir as decorações utilizadas nas extremidades das relações, conforme sugerido nos perfis exibidos no cap

18 2. Pressupostos Teóricos Nesse capítulo são apresentados os conceitos e tecnologias que serviram de base para a realização desse projeto. A seção 2.1. expõe brevemente a atividade de (meta)modelagem; A seção 2.2. trata do framework MDA; a seção 2.3. trata da linguagem OCL, exemplificando conceitos e aplicações; a seção 2.4. versa sobre a importância das linguagens UML e OCL no contexto MDA; a seção 2.5. mostra princípios básicos da utilização da IDE (Integrated Development Environment) Eclipse para a atividade de metamodelagem Da (meta)modelagem Da Modelagem Um modelo descreve um sistema utilizando uma linguagem bem definida. Ele é um conjunto consistente e coerente de elementos de modelagem que possuem características e restrições. Por exemplo, classes e estados são elementos de modelagem providas pela linguagem UML. Atributos e operações são características de classes e, regras de derivação e invariantes são restrições em atributos e classes, respectivamente. Normalmente o termo repositório de modelos é utilizado para designar um local de armazenamento de modelos e, o termo diagrama é utilizado para indicar uma certa visão do repositório de elementos de modelos Níveis de maturidade de modelagem Para criar alguma ordem e transparência na utilização de modelos, são definidos níveis de maturidade de modelagem (MML's Modeling Maturity Levels). Eles indicam quais são os papeis de modelos em processos de desenvolvimento de software. O termo programar adquire novos significados à medida que aumenta se o nível de maturidade. Em um alto nível de maturidade, modelar e programar são quase sinônimos. Nas subseções a seguir são apresentados esses níveis Nível 0: Nenhuma especificação No nível mais baixo, a especificação do software se encontra somente na mente dos desenvolvedores. Este é o nível mais comum entre desenvolvedores não profissionais, onde idéias sobre o modelo são trocadas informalmente. As características desse nível são as seguintes: freqüentemente há conflitos entre as visões dos desenvolvedores e entre as visões de desenvolvedores e usuários; 18

19 essa maneira de criar software é aceitável para pequenas aplicações. Aplicações grandes e mais complexas necessitam de algum design antes da codificação; a compreensão do código é impossível quando os desenvolvedores não estão disponíveis para esclarecer; muitas escolhas são feitas ad hoc pelos desenvolvedores Nível 1: Textual Nesse nível de maturidade a especificação do software é escrita em linguagem natural em um ou mais documentos, que variam quanto à formalidade. Esse é o nível mais baixo de desenvolvimento profissional de software. As características desse nível são as seguintes: a especificação do software é ambígua, em função do uso de linguagem natural, que é inerentemente ambígua; o desenvolvedor faz decisões de modelagem baseadas em sua interpretação do(s) texto(s); não há como manter a especificação atualizada após ocorrer mudança no código Nível 2: Texto com diagramas No nível 2 de maturidade, a especificação do software é provida em um ou mais documentos escritos em linguagem natural e acrescidos de vários diagramas de alto nível para explicar a arquitetura e detalhes complexos. As características desse nível são as seguintes: o sistema ainda é especificado por texto, mas os diagramas o tornam mais compreensível; todas as características do nível 1 estão presentes no nível Nível 3: Modelos com texto Um conjunto de modelos, que podem ser textos ou diagramas com significado bem definido, forma a especificação do software nesse nível. Adicionalmente são utilizados textos em linguagem natural para explicar detalhes e motivações dos modelos, mas os modelos são a parte mais importante do design. As características desse nível são as seguintes: os diagramas ou textos formais são representações reais do software; a transformação dos modelos em código é predominantemente manual; ainda é muito difícil manter a especificação atualizada em relação a mudanças no código; o codificador ainda faz decisões subjetivas de modelagem, mas elas têm menos 19

20 influência na arquitetura do sistema Nível 4: Modelos precisos Nesse nível de maturidade o software é especificado por modelos que são conjuntos consistentes e coerentes de textos e/ou diagramas que possuem significados bem definidos e muito precisos. Textos em linguagem natural são utilizados para adicionar comentários e explicar a motivação do modelo. Os modelos nesse nível são suficientemente precisos para manter uma relação direta com o código atual. No entanto, eles estão em um nível diferente de abstração. Este é o nível em que o MDA está focado. As características desse nível são as seguintes: os codificadores não fazem mais decisões subjetivas na modelagem; manter modelos e código atualizados é essencial e fácil; desenvolvimentos iterativos e incrementais são facilitados pela transformação direta de modelos em código Nível 5: Somente modelos Nesse nível de maturidade os modelos são descrições completas, consistentes, detalhadas e precisas do sistema. Eles são bons o suficiente para suportar uma completa geração de código, sem ajustes. Nesse nível os desenvolvedores confiarão na geração automática de código da mesma forma que confiam em compiladores. Não existirá a necessidade de verificar o código. Haverá texto nos modelos, mas com funções idênticas aos comentários em códigos fonte Da Metamodelagem O metamodelo de uma linguagem, também chamado de sintaxe abstrata, é a descrição de todos os conceitos que podem ser utilizados nessa linguagem. Por exemplo, o conceito de atributo é parte da linguagem UML; os conceitos construtor e método são partes da linguagem Java; os conceitos tabela, coluna e chave são parte da linguagem SQL. Esses conceitos são chamados metaclasses ou metatipos, e o conjunto de todos as metaclasses e relações entre as mesmas é denominado de metamodelo da linguagem. Qualquer elemento em um modelo é uma instância de um conceito da linguagem utilizada, ou seja, todo elemento do modelo é instância de uma metaclasse. Por exemplo, em um modelo UML, uma classe chamada Pássaro é instância da metaclasse Class do metamodelo UML. Na atividade de modelagem, pode se utilizar somente elementos definidos no metamodelo da linguagem utilizada para modelagem. 20

21 2.2. MDA MDA (Model Driven Architecture) é um framework de design de software, criado pela OMG (Object Management Group), com o objetivo de facilitar o reuso de conhecimento, o desenvolvimento, a integração, a manutenção, o teste, a simulação, a interoperabilidade e a portabilidade de software. Uma das premissas adotadas pela OMG no desenvolvimento do MDA é que não se deve modelar um sistema em vista de sua implementação. Modelagem e implementação são etapas independentes e, se for dada a devida atenção à etapa de modelagem, grande parte das etapas seguintes poderão ser automatizadas. De fato, MDA propõe uma evolução no desenvolvimento de software: a compilação à nível de modelos. Existem compiladores para traduzir dados e modelos de aplicações definidos em MOF ou UML para linguagens de alto nível e, portanto, para plataformas que as implementem. Em suma, os três principais objetivos do MDA são: portabilidade, interoperabilidade e reusabilidade, alcançados por meio de uma separação arquitetural de interesses. O framework MDA é um passo dado na direção de tornar a arte de desenvolver software em uma disciplina de engenharia. O framework MDA possibilita a criação de ferramentas para: especificação de um sistema independentemente da plataforma que o suportará; especificação de plataformas; escolha de uma plataforma particular para o sistema; transformação da especificação do sistema em uma especificação para uma plataforma particular. As seções a seguir o explicam detalhadamente Conceitos Básicos Alguns conceitos básicos em MDA são: Sistema (System): Os conceitos de MDA são apresentados em termos de algum sistema existente ou planejado. Esse sistema pode incluir: um programa, um sistema computacional, uma combinação de partes de diferentes sistemas, uma união de sistemas, um empreendimento, entre outros. Modelo (Model): Um modelo de um sistema é uma descrição ou uma especificação desse sistema e de seu ambiente para um propósito específico. Um modelo é geralmente 21

22 apresentado como uma combinação de elementos gráficos e textuais. O texto pode ser escrito em uma linguagem de modelagem ou em linguagem natural. Orientação à Modelos (Model Driven): MDA é orientado à modelos porque provê meios para utilização de modelos para direcionar o rumo da compreensão, design, construção, operação, manutenção e modificação. Arquitetura (Architecture): A arquitetura de um sistema é a especificação de suas partes, conexões e regras para interação das partes utilizando as conexões. Ponto de Vista (Viewpoint): Um ponto de vista em um sistema é uma técnica para abstração, que utiliza um conjunto selecionado de conceitos arquiteturais e regras de estruturação para focar aspectos particulares do sistema. O framework MDA especifica três pontos de vista em um sistema: um ponto de vista independente de computação, um ponto de vista independente de plataforma e um ponto de vista específico de plataforma. Visão (View): Uma visão de um sistema é a representação do mesmo pela perspectiva de um ponto de vista específico. Plataforma (Platform): Uma plataforma é um subconjunto de sistemas e tecnologias que provê um conjunto coerente de funcionalidades, por meio de interfaces que qualquer aplicação suportada pela plataforma pode utilizar sem preocupar se com detalhes sobre como a funcionalidade provida pela plataforma foi implementada. Figura 1: Símbolo usual para plataforma. Aplicação (Application): O termo aplicação é utilizado para se referir a uma funcionalidade sendo desenvolvida. Um sistema é descrito em termos de uma ou mais aplicações suportadas por uma ou mais plataformas. Independência de Plataforma (Platform Independence): Independência de plataforma é a qualidade que um modelo exibe quando é independente de funcionalidades de quaisquer plataformas. Pontos de Vista MDA (MDA Viewpoints): Ponto de Vista Independente de Computação (Computational Independent Viewpoint): O ponto de vista independente de computação foca no ambiente do sistema e nas exigências para o sistema. Os detalhes da estrutura e processamento do sistema estão omitidos ou ainda indeterminados. Ponto de Vista Independente de Plataforma (Platform Independent Viewpoint): O ponto de vista independente de plataforma foca na operação do sistema, omitindo os detalhes necessários para uma plataforma particular. Esse ponto de vista pode utilizar uma linguagem de modelagem de propósito geral ou uma linguagem específica da área em que o sistema será utilizado. Ponto de Vista Específico de Plataforma (Platform Specific Viewpoint): O ponto de vista específico de plataforma combina o ponto de vista independente de plataforma com um foco adicional nos detalhes de utilização de uma plataforma específica. 22

23 Modelo Independente de Computação (Computation Independent Model) (CIM): Um modelo independente de computação é uma visão de um sistema pelo ponto de vista independente de computação. Um CIM, também chamado de modelo de domínio, não mostra detalhes estruturais do sistema, mas descreve a situação em que o sistema será utilizado. Sua especificação é geralmente feita por meio de um vocabulário familiar aos especialistas no domínio em questão. O CIM tem o importante papel de intercambiar o conhecimento entre os especialistas no domínio e seus requisitos, e os e os especialistas em design e construção de artefatos. Modelo Independente de Plataforma (Platform Independent Model) (PIM): Um modelo independente de plataforma é uma visão de um sistema pelo ponto de vista independente de plataforma. Um PIM exibe um grau específico de independência de plataforma, de forma que seja compatível com um número de plataformas de um tipo similar. Uma técnica muito comum para obter independência de plataforma é direcionar o modelo do sistema para uma máquina virtual tecnologicamente neutra. Uma máquina virtual é definida como um conjunto de partes e serviços que são definidos independentemente de qualquer plataforma específica, e que são realizados de maneiras específicas em diferentes plataformas. Uma máquina virtual é uma plataforma, e um modelo que a utilize será específico para essa plataforma. Mas esse modelo é independente de plataforma no que diz respeito à classe de diferentes plataformas nas quais a máquina virtual foi implementada. Modelo Específico de Plataforma (Platform Specific Model) (PSM): Um modelo específico de plataforma é uma visão de um sistema pelo ponto de vista específico de plataforma. Um PSM combina as especificações de um PIM, com detalhes que especificam como o sistema utiliza um tipo particular de plataforma. Modelo de Plataforma (Platform Model): Um modelo de plataforma provê um conjunto de conceitos técnicos que representam diferentes tipos de partes que formam a plataforma e os serviços providos pela mesma. Ele também provê conceitos que representam diferentes tipos de elementos utilizados na especificação do uso da plataforma por uma aplicação. Um modelo de plataforma também especifica restrições para a conexão e uso de partes da plataforma, e conexão de uma aplicação à plataforma. Transformação de Modelo (Model Transformation): Transformação de modelo é o processo de conversão de um modelo para outro modelo do mesmo sistema. A figura 2 ilustra a transformação de um PIM em um PSM. O PIM e outras informações são combinadas pela transformação para produzir o PSM. Essa figura é genérica. Posteriormente serão mostradas várias maneiras de fazer essa transformação. Transformações não são necessárias para PIM's baseados em máquinas virtuais, pois é a maquina virtual que precisa ser transformada em um PSM para uma plataforma específica. Implementação (Implementation): Implementação é uma especificação que provê toda a informação necessária para construir um sistema e coloca lo em operação. Entendidos os conceitos básicos, passaremos às transformações MDA. 23

24 Figura 2: Transformação de modelo Transformações MDA Transformações de modelo são pontos chave da tecnologia MDA, e a existência de mapeamentos entre os modelos independentes de plataforma e as especificações da plataforma escolhida são imprescindíveis para a transformação de um modelo independente de plataforma (PIM) em um modelo específico de plataforma (PSM). Essas transformações podem ser realizadas de diversas formas e com diferentes graus de automação e suporte computacional. Os tipos de mapeamentos, métodos de transformação e graus de automação e suporte computacional são os assuntos abordados nas próximas subseções Mapeamentos Um mapeamento MDA provê especificações para a transformação de um PIM em um PSM para uma plataforma particular. O modelo da plataforma escolhida vai determinar a natureza do mapeamento Mapeamento entre tipos Essa forma de mapeamento especifica um mapeamento de qualquer modelo construído, utilizando se tipos especificados na linguagem PIM para modelos expressos utilizando se tipos especificados na linguagem PSM. Um PIM é construído escolhendo se elementos de modelagem de uma linguagem de modelagem independente de plataforma, de acordo com as necessidades da aplicação. Se os tipos dos elementos de modelagem, tanto no PIM, quanto no PSM, forem especificados como metamodelos MOF, o mapeamento é chamado de Mapeamento de 24

25 Metamodelos Mapeamento em nível de instâncias Uma outra forma de mapeamento é a identificação de elementos no modelo PIM que deverão ser transformados de uma forma particular, de acordo com a plataforma escolhida para dar suporte ao PSM. Esse tipo de mapeamento utiliza marcas que são aplicadas em elementos do PIM e que representam conceitos no PSM. Essas marcas não são partes do PIM, pois são específicas de plataforma. Elas indicam como o elemento do PIM será transformado, e podem ser vistas como uma camada transparente colocada por cima do modelo. Em geral, elementos do PIM podem ser marcados várias vezes, indicando que o elemento tem papeis distintos em diferentes mapeamentos. Marcas são geralmente utilizadas para indicar parâmetros de qualidade de serviço ou opções mutuamente exclusivas de modelagem para um conceito. Estereótipos UML podem ser utilizados como marcas, indicando templates específicos para serem utilizados na transformação de um modelo PIM para um PSM Combinação das duas formas de mapeamento anteriores A maioria dos mapeamentos consiste de uma combinação das formas anteriores, pois o mapeamento entre tipos é determinístico e dificilmente será capaz de prover todas as informações necessárias para a construção do PSM. É justamente para prover essas informações faltantes que são adicionadas marcas ao modelo. É importante observar que essas marcas possuem uma sintaxe que deve ser obedecida, para que os modelos marcados sejam semanticamente válidos e possam ser transformados em PSM's Templates Um mapeamento também pode incluir templates, que são modelos parametrizados que especificam tipos particulares de transformação. Templates podem ser utilizados em regras para transformar um padrão de elementos de modelagem em um mapeamento entre tipos. Um conjunto de marcas pode ser associado a um template para indicar as instâncias de um modelo que devem ser transformadas de acordo com esse template Métodos de Transformação O passo seguinte é pegar um PIM (marcado ou não) e transforma lo em um PSM. Isso pode ser feito manualmente, com assistência computacional ou automaticamente. 25

26 As entradas da transformação são os PIM's e os mapeamentos, as saídas são os PSM's e registros das transformações. Esses registros contêm informações sobre os mapeamentos dos conceitos do PIM para conceitos do PSM. Uma ferramenta de modelagem MDA pode utilizar esses registros para manter PIM's e PSM's sincronizados quando alguma mudança ocorrer. PSM's podem prover mais ou menos detalhes, dependendo do seu propósito. Um PSM será uma implementação se prover todas as informações necessárias para construir o sistema e coloca lo em operação, ou poderá agir como um PIM, que será posteriormente refinado para um PSM, podendo ser diretamente implementado. Alguns métodos de transformação de modelos são: marcação, transformação entre metamodelos, transformação entre modelos, aplicação de padrões e união de modelos Marcação Figura 3: Marcação em um modelo. A figura acima mostra o processo de transformação por marcação. Escolhida a plataforma que suportará a aplicação, deve se criar ou reusar, se já existir, um mapeamento para a plataforma. Esse mapeamento deve prover um conjunto de marcas que serão utilizadas em elementos do PIM para guiar a transformação do PIM para o PSM Transformação entre Metamodelos O PIM é preparado utilizando se uma linguagem independente de plataforma, e especificada por um metamodelo. Escolhida uma plataforma, uma especificação de transformação para essa 26

27 plataforma deve ser criada, ou reusada. Nesse caso, essa especificação de transformação é um mapeamento entre o metamodelo da linguagem utilizada para a formalização do PIM e a linguagem que será utilizada para a formalização do PSM. Figura 4: Transformação entre metamodelos Aplicação de Padrões Uma extensão das duas técnicas anteriores inclui padrões, além dos tipos ou conceitos da linguagem de modelagem. Figura 5: Aplicação de padrões. 27

28 Em adição aos conceitos da linguagem de modelagem, um modelo genérico pode prover padrões. Tanto os conceitos como os padrões podem ser mapeados para conceitos e padrões dependentes de plataforma. Uma outra forma de se utilizar padrões é usa los como nomes de marcas específicas de plataforma, ou seja, nomes de padrões de design que são específicos de plataforma. A figura abaixo ilustra essa alternativa. Figura 6: Padrões como nomes de marcas Graus de Automação e Suporte Computacional As ferramentas de suporte para transformação entre modelos podem promover diferentes graus de automação de transformação e, há diferentes modos de prover o modelo com todas as informações necessárias para transforma lo em um PSM. Quatro diferentes categorias de transformação são descritas aqui e ilustram essas possibilidades: transformação manual, transformação de um PIM preparado por um perfil, transformação utilizando padrões e marcas, e transformação automática Transformação Manual Durante a transformação de um PIM em um PSM, decisões de design devem ser feitas. Essas decisões podem ser tomadas durante o processo de desenvolvimento, em conformidade com os requisitos de implementação. Essa é uma boa alternativa, pois as decisões são consideradas no contexto de um design específico de implementação. 28

29 Esse processo manual de transformação não difere muito do que tem sido feito em design de software. Mas o método MDA adiciona valor em duas formas: faz uma distinção explícita entre modelos independentes de plataforma e modelos dependentes de plataforma; registra as transformações entre os mesmos Transformação de um PIM preparado por um perfil Um PIM pode ser preparado utilizando se um perfil UML independente de plataforma. Esse modelo pode ser transformado em um PSM utilizando se um segundo perfil UML específico de plataforma. Essa transformação pode envolver a marcação do PIM com marcas providas pelo perfil específico de plataforma Transformação utilizando Padrões e Marcas Padrões podem ser utilizados na especificação de um mapeamento. Um mapeamento inclui um padrão e marcas correspondentes a alguns elementos do padrão. Em transformações em instâncias de modelos, as marcas específicas são utilizadas para estender um PIM. Os elementos marcados do PIM são transformados de acordo com o padrão correspondente para produzir o PSM. Padrões podem ser combinados para produzir novos padrões, e novas marcas podem então ser especificadas para uso com esses novos padrões. Em transformações nos tipos dos modelos, regras podem especificar que todos os elementos, em um PIM, que caracterizam um determinado padrão, sejam transformados em instâncias de outros padrões no PSM. As marcas serão utilizadas para colocar valores do padrão reconhecido no PIM, nos slots apropriados no PSM gerado. Dessa forma, os padrões podem ser vistos como templates para a geração do PSM e, as marcas como um modo de atar os parâmetros dos templates Transformações Automáticas Há contextos em que o PIM provê toda a informação necessária para sua transformação em um PSM, sem a necessidade de marcas ou informações adicionais. Nesse contexto, o desenvolvedor nunca precisa ver o PSM. A ferramenta de transformação interpretará o PIM diretamente ou transformará o modelo diretamente em código de programa. Para que isso seja possível, deve existir um modelo da arquitetura escolhida e um 29

30 mapeamento do PIM para essa arquitetura Outras Capacidades MDA Essa seção discute outros usos da arquitetura MDA, além da utilização em transformações de modelos PIM's em PSM's Múltiplas Aplicações das Transformações MDA Em MDA, um modelo é considerado um PIM quando é independente de uma classe de plataformas. Logo, modelos são considerados PIM's em relação à uma classe de plataformas. Modelos considerados PSM's são dependentes de certas plataformas, mas podem ser considerados PIM's em relação à uma outra classe de plataformas. Portanto, modelos não são absolutamente considerados PIM's ou PSM's, pois essa consideração é relativa às classes de plataformas. Isso nos permite realizar transformações sucessivas entre modelos, nas quais um modelo intermediário é considerado um PSM em relação ao modelo anterior e um PIM em relação ao modelo posterior. Por exemplo, um PIM inicial pode ser um modelo de aplicação designado para ser independente de várias decisões de plataforma. Quando transformado em um PSM, ele será específico de alguns componentes da plataforma, mas ele pode continuar independente da escolha de um componente particular de plataforma. Figura 7: Transformação de um PIM em um PSM. A transformação pode ser aplicada novamente, para especificar outros componentes de plataforma e, o modelo no papel de PSM na primeira transformação fará o papel de PIM nessa transformação. 30

31 Figura 8: Segunda transformação. Pode se realizar outra transformação, por exemplo, para especificar um uso da plataforma em termos de qualidade de serviço. Figura 9: Terceira transformação. Mas, nessa série de transformações, o que exatamente poderia ser uma plataforma? Nas figuras a seguir, o PIM à esquerda é um modelo da aplicação à direita e, o PSM à esquerda é um modelo específico da plataforma mostrada à direita. 31

32 Figura 10: PIM, PSM, aplicação e plataforma. Figura 11: PIM, PSM, aplicação e plataforma, sob pontos de vista diferentes. 32

33 As figuras acima mostram as mesmas aplicações e plataformas, mas sob pontos de vista distintos. A figura abaixo mostra três visões diferentes da mesma aplicação e plataforma. As linhas pontilhadas marcam as partes da tecnologia que, sob diferentes pontos de vista, são consideradas implementações de plataformas. Figura 12: Três visões distintas do que seriam plataformas. Quaisquer partes do modelo que estão fechadas pela linha pontilhada podem ser consideradas plataformas, de acordo com as necessidades do usuário do modelo, desde que contenham todas as implementações abaixo dela, como mostra a figura a seguir. Figura 13: Abstração de plataformas. Não é necessário que um PSM inclua todos os detalhes de plataforma. Se ele não incluir, pode ser um modelo abstrato, que esconde esses detalhes, ou fazer referência explícita, ou implícita, a outros modelos que provêem esses detalhes. Porém, um modelo não é um PSM a menos que possa produzir uma implementação. Por definição, uma implementação deve prover toda a informação necessária para criar um objeto e permitir que o objeto possa prover um apropriado conjunto de serviços. Em suma, um PSM deve ser capaz de ser implementado, provendo assim um conjunto de funcionalidades. 33

34 O que conta como plataforma é relativo ao propósito do modelador. Para muitos usuários MDA, middleware é uma plataforma, enquanto que para desenvolvedores middleware, um sistema operacional é uma plataforma Transformações Gerais Modelo para Modelo As mesmas técnicas utilizadas para transformar modelos PIM's em PSM's, podem ser utilizadas para transformar quaisquer modelos em modelos relacionados. A figura 14, a seguir, mostra a transformação entre modelos, realizada por um mapeamento entre os metamodelos das linguagens em que os mesmos foram formalizados Reuso de Mapeamentos Mapeamentos podem ser reusados por meio de extensão e combinação Extensão A extensão utiliza um mapeamento base, para criar um mapeamento derivado por modificação incremental. Essas modificações podem adicionar ou alterar propriedades do mapeamento base, para criar o mapeamento derivado. Os mapeamentos podem ser arrumados em uma hierarquia de heranças, de acordo com as relações derivadas do mapeamento base. Essa é a interpretação de herança de mapeamentos em MDA. Se mapeamentos podem ter muitos mapeamentos base, a herança é dita múltipla. Se o Figura 14: Transformação por mapeamento entre metamodelos. 34

35 critério proíbe a supressão de propriedades dos mapeamentos base, a herança é dita estrita Combinação A combinação utiliza dois ou mais mapeamentos para criar um novo mapeamento. As características do novo mapeamento são determinadas pelos mapeamentos combinados e, pela forma com que são combinados. O efeito da aplicação de um mapeamento combinado é a combinação dos efeitos dos mapeamentos originais. Os mapeamentos podem ser combinados de forma seqüencial ou concorrente. 35

36 2.3. OCL Um diagrama UML, como um diagrama de classes, não é, na maioria dos casos, refinado o suficiente para prover todos os aspectos relevantes de uma especificação. Há, entre outras coisas, uma necessidade de descrever restrições adicionais sobre os objetos no modelo. Tais restrições são normalmente descritas em linguagem natural, mas a prática mostrou que essa prática pode resultar em ambigüidades. Com o intuito de descrever restrições não ambíguas, foram criadas algumas linguagens formais. A linguagem OCL (Object Constraint Language) foi desenvolvida pela OMG para satisfazer essas questões. Sua finalidade é descrever expressões em modelos UML. Expressões essas que tipicamente especificam condições invariantes (restrições) que precisam valer para o sistema modelado, ou pesquisas sobre objetos descritos no modelo Propriedades da linguagem OCL A avaliação de consultas OCL é instantânea e livre de efeitos colaterais, ou seja, o estado dos objetos do sistema não pode mudar durante a avaliação e, a mesma não altera o estado do sistema executado. Mas expressões em OCL também podem ser utilizadas para especificar operações que quando executadas, alteram o estado do sistema. Outra propriedade da linguagem OCL é ser tipada, ou seja, todas as expressões OCL têm um tipo. Isso possibilita a checagem de expressões antes mesmo de se produzir uma versão executável do modelo, possibilitando a detecção de erros em estágios iniciais do modelo. A seguir são mostradas algumas das principais características da linguagem OCL Linguagem de restrição e de consulta Em UML 1.1, OCL era uma linguagem utilizada para expressar restrições nos diagramas do modelo. Isso significa que apesar de os diagramas mostrarem que certos objetos ou valores podem estar presentes no sistema modelado, esses valores somente são válidos se as restrições especificadas pelas invariantes forem satisfeitas. Em UML 2.0, OCL pode ser utilizada não somente para escrever restrições, mas também para escrever quaisquer expressões nos elementos do diagrama. Qualquer expressão OCL indica um valor ou objeto no sistema. Por exemplo, a expressão 2+5 é uma expressão OCL válida, do tipo Integer, que representa um inteiro de valor 7. Quando o valor de uma expressão é do tipo Boolean, ela pode ser utilizada como uma invariante. Expressões OCL podem ser utilizadas em qualquer lugar no modelo para indicar um valor, 36

37 que pode ser um valor simples, um inteiro, pode fazer referência a algum objeto, a uma coleção de valores ou a uma coleção de referências à objetos. Uma expressão OCL também pode ser utilizada para definir operações de classes. Outros exemplos de uso de expressões OCL são: a definição da derivação de um atributo ou associação derivados e a especificação do valor inicial de atributos ou associações. Esses casos serão mostrados posteriormente, na seção Fundamentação matemática OCL é baseada na teoria dos conjuntos e em lógica de predicados, e possui uma semântica matemática formal [13]. No contexto MDA, onde os modelos precisam ser transformados automaticamente, uma linguagem não ambígua e com fundação matemática é de grande valor para a escrita de modelos Linguagem declarativa OCL é uma linguagem declarativa, então suas expressões mostram o que deve ser feito e não como deve ser feito, que é o caso nas linguagens procedurais. Para garantir isso, as expressões OCL não possuem efeitos colaterais, ou seja, a avaliação de expressões OCL não altera o estado do sistema. Como OCL é uma linguagem declarativa, o modelador pode fazer decisões de alto nível e, as expressões somente dizem respeito ao estado de coisas que se quer modelar, relevando qualquer detalhe sobre a implementação, o que é perfeitamente compatível com a visão MDA Aplicação em diagramas de classe A linguagem OCL pode adicionar informações a um modelo, em um diagrama de classes, de varias maneiras. As próximas subseções ilustram algumas delas, utilizando se o modelo de colheita de amoras proposto na figura abaixo como base para a criação dos exemplos Regras de derivação Alguns modelos definem atributos ou associações derivados. O valor de um elemento derivado precisa ser determinado a partir de outros valores base no modelo. Utilizando se a linguagem OCL, a derivação pode ser escrita como uma regra, como mostra o seguinte exemplo, baseado no modelo da figura 15: 37

38 Figura 15: Modelo expresso em um diagrama UML. context Colheita::totalDeAmoras : Integer derive: self.obtém >size() Geralmente, atributos derivados não são representados nos diagramas e sim definidos por uma definição de atributo OCL Valores Default O valor inicial de um atributo ou associação pode ser especificado por uma expressão OCL. Nos exemplos a seguir, o valor inicial para capacidade da cesta é 20, e o valor inicial para a associação Colheita::utiliza é um conjunto vazio. context Cesta::capacidade : Integer init: 20 context Colheita::utiliza : Set(Cesta) init: Set { A diferença entre valor inicial e derivado é que uma regra de derivação é invariante, ou seja, o elemento derivado sempre terá o valor expresso pela regra de derivação. Um valor inicial somente atuará no momento em que for criada uma instância de seu contexto. Após esse momento, o atributo poderá ter diferentes valores com o passar do tempo. 38

39 Especificação de operações de consulta Operações de consulta não possuem efeitos colaterais. Essas operações podem ser introduzidas em um diagrama de classes e especificadas utilizando se a linguagem OCL. Por exemplo, a operação definida abaixo resulta na quantidade de cestas de uma colheita. context Colheita::mostrarNºDeCestas() : Integer body: self.utiliza >size() Invariantes Outra maneira de melhorar a especificação de um diagrama de classes é a inclusão de invariantes. Invariantes são expressões booleanas que determinam uma condição que precisa ser verdadeira em todos os estados consistentes do sistema para todas as instâncias de seu contexto. No exemplo a seguir, criamos uma restrição que afirma que o número de amoras em uma cesta deve ser sempre menor ou igual à sua capacidade. Nomear invariantes é opcional, mas pode ser extremamente útil, por exemplo, na validação automática de modelos, onde é importante que se possa ter uma forma simples de referenciar as invariantes violadas. context Cesta inv maximodeamorasnacesta: nºdeamoras <= capacidade Pré condições e pós condições Pré condições e pós condições em operações são maneiras de definir precisamente a interface de um sistema, pois elas não especificam como a operação é implementada. Uma pré condição é uma expressão booleana que precisa ser verdadeira no momento em que a operação inicia sua execução. Já uma pós condição é uma expressão booleana que precisa ser verdadeira no momento em que a operação termina sua execução. O seguinte exemplo mostra a utilização de pré/pós condições na operação Colheita::adicionarCestas(c : Cesta), onde a pré condição especifica que não interessam cestas com capacidade menor que 20 e a pós condição especifica que a nova cesta deve estar relacionada com a colheita: context Colheita::adicionarCestas(c : Cesta) pre: c.capacidade >= 20 post: self.utiliza = self.utiliza@pre >including(c) O é utilizado concatenando se o mesmo ao nome do atributo/relação, para obter o valor que o atributo/relação possuía no momento de início da operação. 39

40 Mensagens em pós condições Um aspecto muito útil em pós condições é o fato de que elas podem indicar, pelo envio de mensagens, que uma certa operação foi chamada. Por exemplo, quando o número total de amoras colhidas for 300, pode se chamar a função alertar() em todas as pessoas relacionadas á colheita, para avisar que já foram colhidas amoras suficientes. context Pessoa::colherAmora(a : Amora) post: if totaldeamoras >= 300 then self.colheita.emprega >forall(p : Pessoa p^alertar()) else true endif Definição de classes derivadas Uma visão é um conceito bem conhecido em sistemas relacionais de banco de dados. O conceito de classes derivadas, em modelagem UML/OCL, é um conceito similar ao conceito de visão. Uma classe derivada é uma classe cujas propriedades podem ser completamente derivadas de classes existentes Multiplicidade dinâmica Associações em diagramas de classe podem ser especificações imprecisas do sistema. Esse é o caso quando a multiplicidade de uma associação não é fixada, mas deveria ser determinada de acordo com outro valor no sistema. Isso é chamado de multiplicidade dinâmica. Um exemplo ocorre no modelo da colheita de amoras onde uma associação entre as classes Colheita e Amora, indicando que um certo número de amoras são colhidas, tem multiplicidade muitos (1..*) no lado da classe Amora. Isso significa que o número cardinal máximo de amoras é ilimitado, porém o número cardinal de amoras é limitado pelo número cardinal resultante da soma das capacidades das cestas relacionadas com a colheita. Essa restrição não pode ser expressa no diagrama. Uma forma de especificar essa cardinalidade é adicionar a seguinte restrição OCL ao modelo: context Colheita inv maximodeamoras: obtém >size() <= utiliza >collect(capacidade) >sum() Multiplicidade opcional Uma multiplicidade opcional de uma associação em um diagrama de classes é, geralmente, uma especificação parcial do que é realmente intencionado. Nesses casos, uma associação opcional não é realmente livre e sua presença depende do estado de outros objetos. Em geral, quando há uma multiplicidade opcional em um diagrama de classes, deve se utilizar invariantes OCL para descrever precisamente em que circunstâncias a associação opcional pode ser vazia ou não. 40

41 Restrições ou Um diagrama de classes pode conter uma restrição ou entre duas associações, como mostrado no exemplo da figura 20. Essa restrição significa que somente uma das associações potenciais pode ser instanciada em um instante de tempo para qualquer objeto. Essa restrição é representada no diagrama como uma seta tracejada conectando duas ou mais associações (que possuam ao menos uma classe em comum) com a string {or rotulando a linha. A multiplicidade das associações precisa ser opcional, senão elas não poderão ser vazias. No exemplo da colheita de amoras, supõe se que uma pessoa possa participar da colheita sendo ou proprietário de um número qualquer de colheitas ou funcionário de de um número qualquer de colheitas. Também é suposto que uma colheita possa ter qualquer número de proprietários (exemplos de colheitas sem proprietários poderiam ser os kibutzim de Israel, há algumas gerações) e que uma colheita possa ter qualquer número de funcionários. A escolha de interpretação parece óbvia, mas como todas as associação têm multiplicidade opcional, uma transformação automática MDA poderia interpretar o modelo de outra forma, inter substituindo os operadores lógicos grifados nas frases anteriores. Especificar a restrição ou visual como uma restrição OCL resolve a ambigüidade. Quando desejar se a primeira interpretação, deve se anexar a seguinte invariante ao diagrama: context Pessoa inv: self.proprietário >isempty() or self.trabalha >isempty() A invariante para a segunda interpretação é: context Colheita inv: self.pertence >isempty() or self.emprega >isempty() Estilos de modelagem Além de servir para complementar a linguagem UML na escrita de restrições e consultas, a linguagem OCL também pode ser utilizada para expressar informações iguais de maneiras diferentes. Há vários estilos de modelagem e nessa seção serão explicados alguns deles Definição de atributos ou operações Atributos e operações podem ser definidos em um diagrama de classes adicionando se os mesmos a um tipo. Mas eles também podem ser definidos por uma expressão OCL, não sendo necessário mostrá los no diagrama. No exemplo a seguir, criou se o atributo capacidaderestante e a operação pararcolheita: 41

42 context Cesta def: capacidaderestante : Integer = self.capacidade self.nºdeamoras context Colheita def: pararcolheita() : Boolean = if totaldeamoras >= 300 then true else false endif A expressão após o sinal de igual, em uma definição de atributo, é uma regra de derivação e indica como o valor do atributo será calculado. Em uma definição de operação, a expressão que segue o sinal de igual especifica o resultado da operação A restrição de subconjunto Um diagrama de classe pode conter restrições de subconjunto, como mostrado na figura 20. Elas são representadas por setas tracejadas que vão do subconjunto ao conjunto e que possuem a string {subset rotulando as mesmas. Esse tipo de restrição informa que o conjunto de links de uma associação é um subconjunto do conjunto de links de outra associação. Mostrar todas restrições de subconjunto no diagrama pode torná lo difícil de ler. Nesse caso, pode se especificar essas restrições utilizando expressões OCL. As duas restrições de subconjunto mostradas no modelo de colheita poderiam ser expressas em OCL da seguinte maneira: context Pessoa inv: self.participa >includesall(self.proprietário) inv: self.participa >includesall(self.trabalha) context Colheita inv: self.equipe >includesall(self.pertence) inv: self.equipe >includesall(self.emprega) Herança X Invariantes Novamente será referido o modelo de colheita de amoras, mais precisamente a associação entre Amora e Cesta. Essa associação é especializada nas associações entre os subtipos AmoraVerde e CestaTipo1 e AmoraMadura e CestaTipo2, que impõem que instâncias de AmoraVerde só podem ser armazenadas em instâncias de CestaTipo1 e instâncias de AmoraMadura só podem ser armazenadas em instâncias de CestaTipo2. Essas associações entre os subtipos de Amora e Cesta podem ser vistas como restrições à associação entre Amora e Cesta. Essas restrições podem ser escritas em OCL para diminuir a complexidade do diagrama. No modelo, poderia se retirar as sub associações do diagrama e adicionar as seguintes invariantes: 42

43 context AmoraVerde inv: self.contida >forall(c : Cesta c.ocliskindof(cestatipo1)) context AmoraMadura inv: self.contida >forall(c : Cesta c.ocliskindof(cestatipo2)) Assim cria se um diagrama de mais fácil leitura, mas com a mesma expressividade. Porém, se a única razão para a existência das subclasses de Cesta for diferenciar os tipos de cesta para os diferentes tipos de amoras, poderia se excluir as subclasses de Cesta e criar um DataType TipoCesta que as especificasse, colocando se um atributo tipo:tipocesta na classe Cesta e adicionando se as seguintes invariantes: context AmoraVerde inv: self.contida >forall(c : Cesta c.tipo = TipoCesta::tipo1)) context AmoraMadura inv: self.contida >forall(c : Cesta c.tipo = TipoCesta::tipo2)) Também poderia se excluir as subclasses de Amora e criar um DataType TipoAmora com amoraverde e amoramadura, e criar um atributo tipo:tipoamora na classe Amora. As novas invariantes seriam: context Amora inv: self.tipo = TipoAmora::amoraVerde implies self.contida >forall(c : Cesta c.tipo = TipoCesta::tipo1)) context Amora inv: self.tipo = TipoAmora::amoraMadura implies self.contida >forall(c : Cesta c.tipo = TipoCesta::tipo2)) Nesse exemplo, pode se transformar as subclasses em DataTypes por que as mesmas não possuíam atributos ou comportamentos específicos. Então, nem sempre modelos poderão ser transformados dessa forma, e também não será sempre o caso que essa técnica seja a melhor alternativa. A arte de balancear diagramas com anotações OCL dependerá da finalidade do modelo. 43

44 2.4. MDA, UML e OCL A essência do MDA é que os modelos são a base para o desenvolvimento de software. Portanto, os modelos devem ser bons, sólidos, consistentes e coerentes. As linguagens de modelagem são fundamentais em MDA. Como tanto PIM's, como PSM's são transformados automaticamente, eles devem ser escritos em uma linguagem padrão, bem definida, que possa ser processada automaticamente por ferramentas. Para que se possa aplicar o processo MDA, os modelos devem estar no nível 4 de maturidade (seção ). Pois nesse nível eles são precisos o suficiente para serem transformados de PIM's para PSM's Modelagem com UML/OCL Muitos dos problemas em modelagem são provocados pelas limitações dos diagramas. Um diagrama é incapaz de expressar todos os enunciados que devem ser partes de uma especificação. Por exemplo, o caso de multiplicidade dinâmica mostrado na seção Expressões escritas em uma linguagem precisa e com base matemática, como OCL, oferecem muitos benefícios em relação aos diagramas: não são ambíguas, não podendo ser interpretadas de várias formas; podem ser checadas automaticamente; permitem a geração de modelos derivados, utilizando se transformações MDA; permitem geração de código. Para que essas tarefas possam ser automatizadas, o modelo deve conter toda a informação necessária. Uma ferramenta computacional não consegue interpretar regras em linguagem natural. Regras escritas em OCL incluem toda a informação necessária para que possam ser utilizadas por ferramentas automáticas MDA. Desse modo, a implementação é muito mais rápida e eficiente do que se fosse feita manualmente. No entanto, modelos escritos em linguagens que utilizam expressões para representação geralmente não são facilmente compreendidos. Basta recordar que um código fonte pode ser considerado um modelo último de um sistema. A combinação de UML com OCL oferece a possibilidade da utilização da linguagem UML em modelos diagramáticos, contornando se parte das limitações da linguagem UML pela utilização de expressões OCL. Como explicitado no exemplo anterior, modelos em diagramas UML, sem expressões OCL, podem estar severamente mal especificados. E sem diagramas UML, as expressões OCL farão referência a elementos de modelagem não existentes, pois não há como especificar classes e associações em OCL. Assim, somente combinando se diagramas e restrições é possível especificar completamente um modelo. 44

45 Metamodelagem com UML/OCL A construção de metamodelos é a definição de uma linguagem. As mesmas vantagens da utilização de UML/OCL na construção de modelos são conseguidas na escrita de metamodelos. No framework MDA novas linguagens precisam ser definidas, mas o mais importante é obter a especificação de linguagens existentes. Muitas linguagens de programação ainda não foram formalmente definidas. Normalmente a única parte formal em suas especificações é sua gramática, escrita em BNF. Novas linguagens também podem ser definidas como perfis UML, desobrigando se a criação de um metamodelo completamente novo para a linguagem. Em vez disso, o metamodelo da UML é utilizado juntamente com regras extras e um mapeamento dos conceitos da linguagem com estereótipos UML Transformações definidas com UML/OCL Uma definição de transformação descreve como um modelo escrito em uma linguagem pode ser transformado em um modelo escrito em outra linguagem. Essa descrição é genérica quando é independente dos modelos atuais. Ela tem que utilizar conceitos definidos em ambas as linguagens, ou seja, ela é construída utilizando se as metaclasses dos metamodelos de ambas as linguagens. Uma definição de transformação relaciona metaclasses da linguagem fonte com metaclasses da linguagem destino. Como transformações devem ser executadas por ferramentas automáticas, definições de transformações devem ser escritas de um forma precisa e não ambígua. Nesse contexto, uma expressão OCL pode precisamente indicar quais elementos do metamodelo fonte são utilizados em uma certa transformação em determinados elementos do metamodelo destino. 45

46 2.5. Metamodelagem utilizando se o Eclipse Na realização dessa monografia utilizou se a IDE Eclipse, principalmente devido ao fato dela apresentar, na forma de plugins, uma série de funcionalidades interessantes ao projeto em questão, como ferramentas que auxiliam nas tarefas de metamodelagem, na realização de transformações MDA, na criação de editores gráficos e na validação de modelos. O Eclipse é uma comunidade cujos projetos são direcionados à construção, em código aberto, de uma plataforma extensível de desenvolvimento para a construção e gerência de software em todo o ciclo de vida do último. No Eclipse, diversas funcionalidades são providas por frameworks independentes, implementados em plugins. Por exemplo, no presente projeto, foram utilizados os plugins: EMF (Eclipse Modeling Framework) [ GMF (Graphical Modeling Framework) [ MDT (Model Development Tools) [ Para a criação dos metamodelos revisados da UML 2.0, utilizou se o framework EMF. Esse plugin provê meios para a criação e validação de modelos escritos em ECore com restrições em OCL, via integração com o framework MDT, que provê uma implementação da linguagem OCL para a avaliação de consultas e restrições em (meta)modelos. ECore é o nome dado ao metamodelo, implementado em Java, do núcleo da EMF. Ele é praticamente igual à linguagem EMOF (Essential MOF) [9], com apenas algumas pequenas diferenças, de nomenclatura em sua maioria. Assim, para evitar confusões, decidiu se utilizar nomes distintos para esses metamodelos. A linguagem EMOF é um subset da linguagem MOF 2.0 (Meta Object Facility) [ assunto da subseção Na escrita das restrições no ambiente EMF, foi utilizado um subset da linguagem OCL 2.0, que é definido unicamente baseado no núcleo comum entre UML 2.0 e MOF 2.0 (OCL MOF subset), pois a especificação completa da linguagem OCL só pode ser utilizada com a linguagem UML. O framework GMF é utilizado para a criação de editores gráficos baseados nos frameworks EMF e GEF (Graphical Editing Framework) [ Esse último possibilita a construção de editores gráficos a partir de metamodelos, mas devido à sua difícil utilização, foi criado o GMF, que serve como mediador entre os frameworks EMF e GEF no processo de criação de um editor gráfico. A seguir, a subseção apresentará uma breve exposição da linguagem MOF

47 MOF O MOF, criado pelo OMG, provê um framework de gerenciamento de metadados e um conjunto de serviços para habilitar o desenvolvimento e interoperabilidade de sistemas dirigidos a modelos e metadados. A criação do MOF foi incentivada por um cenário onde a Internet, ao conectar fontes de dados e aplicações em todo o planeta, dirigia a expectativa de um fácil e transparente intercâmbio de dados entre aplicações. Mas, metadados incompatíveis entre diferentes sistemas limitavam o intercâmbio de dados. Muitas aplicações, ao utilizar modelos proprietários de metadados, impediam o intercâmbio de dados entre as fronteiras de aplicações, por causa das diferenças entre esses modelos. A partir da fundação de modelagem estabelecida pela UML, MOF introduziu os conceitos de metamodelos formais e modelos de metadados independentes de plataforma (PIM's) EMF O framework EMF permite a escrita de metamodelos e, a partir de algumas transformações, a criação de um editor. É importante salientar que todas as transformações de modelos feitas no presente projeto não são apresentadas explicitamente como modelos de transformação, e sim como funcionalidades providas pelo Eclipse, ou seja, para realizar uma transformação entre modelos, o usuário deve acionar um comando no Eclipse, que mostrará uma caixa de diálogo, e a partir da interação com o usuário, o Eclipse coletará as informações adicionais mínimas necessárias à transformação. Nesse framework, um metamodelo ECore pode ser transformado em um modelo Gen, que contém as informações necessárias à criação de um editor. Dependendo do metamodelo ECore utilizado, poderá haver a necessidade de alteração manual do modelo Gen, para que o mesmo seja capaz de ser transformado em um editor. Por exemplo, no projeto em questão, o metamodelo ECore possui algumas operações e meta atributos especificados em OCL, e em função disso, houve a necessidade de alterar manualmente o modelo Gen gerado a partir do metamodelo ECore, para que o processo de transformação do modelo Gen no editor seja capaz de interpretar as expressões OCL GMF O framework GMF está acima do EMF e permite a transformação de um editor em árvore, gerado no framework EMF, em um editor gráfico. O Processo de transformação é semelhante ao descrito anteriormente. A partir de um metamodelo ECore, são gerados dois modelos, um modelo GMFGraph, que contém informações relativas à visualização de elementos do metamodelo, e um modelo GMFTool, que contém informações relativas à barra de ferramentas do editor gráfico. No projeto atual, foi necessário alterar o modelo GMFGraph gerado a partir do metamodelo ECore, 47

48 para que as decorações propostas nos perfis de modelagem exibidos no capítulo 3 possam ser implementadas. A partir dos modelos ECore, GMFGraph e GMFTool foi gerado um modelo GMFMap, que tem a função de criar mapeamentos entre os três modelos anteriores. Não há como adicionar as restrições OCL, mostradas nos perfis, no processo de transformação que cria o modelo GMFMap. Então, houve a necessidade de adicionar essas restrições posteriormente. A partir do modelo GMFMap, pôde ser criado o modelo GMFGen, que tem a função de gerar o editor gráfico. Novamente, houve a necessidade de alterar o modelo GMFGen após a sua criação, para habilitar a funcionalidade de validação de modelos no editor gráfico. Feito isso, o modelo GMFGen pôde ser transformado no editor e classes Java que implementam as decorações foram adicionadas ao código fonte do editor gerado. 48

49 3. Das Limitações da Modelagem Conceitual Utilizando se UML 2.0 Em [Guizzardi, 2005], é exposto um framework para avaliação de linguagens de modelagem. Esse framework propõe que seja feito um mapeamento entre o metamodelo da linguagem a ser avaliada e o metamodelo de uma ontologia fundacional escolhida. Ontologias são modelos conceituais consensuais. Ontologias fundacionais são meta ontologias independentes de domínio e que provêem conceitos que serão utilizados na escrita de outras ontologias. Uma linguagem será considerada adequada quando todos os seus conceitos possuírem uma única contraparte na ontologia fundacional. Se existirem conceitos na ontologia que não forem representados em algum elemento da linguagem, será o caso de incompletude ontológica no nível da linguagem em questão. Se existirem conceitos na linguagem avaliada que não são representados na ontologia, eles deverão ser descartados. Se existirem diferentes conceitos ontológicos representados em um mesmo elemento na linguagem, será o caso de sobrecarga de construtor e a linguagem será considerada ambígua. E, finalmente, se existirem conceitos ontológicos representados em mais de um elemento na linguagem, será o caso de excesso de construtores na linguagem. O presente capítulo mostra os resultados obtidos em [Guizzardi, 2005] pela aplicação do framework supracitado na avaliação da linguagem UML 2.0, utilizando se como ontologia fundacional a ontologia UFO (Unified Foundational Ontology) proposta nos caps. 4 ao 7 de [Guizzardi, 2005]. O objetivo dessa avaliação e reconstrução da linguagem UML 2.0 foi obter uma linguagem ontologicamente bem fundada para a construção de ontologias de domínio e modelagem conceitual. A UFO, representada parcialmente nas figuras abaixo, é uma teoria de tipos. Na avaliação da linguagem UML 2.0, foi utilizado somente o fragmento da ontologia UFO relativo à endurantes, ou seja, objetos. Assim como em [Guizzardi, 2005], serão apresentadas as análises dos três fragmentos do metamodelo da UML separadamente, nas seções a seguir Classes e Generalização A figura 16 representa o fragmento do metamodelo da UFO referente à classes e generalização. Nesse fragmento, universais (Universals) são padrões de características independentes do espaço tempo, que podem ser tanto entidades monádicas (ou intrínsecas (Monadic Universals), por exemplo, Pessoa, Areia, Floresta, Mulher, Adolescente, Estudante, EntidadeRelacional, Fornecedor, Flutuabilidade, cor de uma mesa) quanto relações (Relations). Entidades monádicas podem ser tanto substanciais (Substantial Universals) quanto momentâneas (Moment Universals). Entidades substanciais são entidades que persistem no tempo enquanto mantém sua identidade, por exemplo, Pessoa, Areia, Floresta, Mulher, Adolescente, Estudante, 49

50 EntidadeRelacional, Fornecedor, Flutuabilidade. As entidades momentâneas são entidades que dependem existencialmente de outras entidades, como por exemplo, a cor de uma mesa. Entidades substanciais podem ser ou sortais (Sortal Universals) ou mixins (Mixin Universals). Entidades sortais são entidades que possuem princípios de identidade, por exemplo, Pessoa, Areia, Floresta, Mulher, Adolescente, Estudante. Mixins são indivíduos que não possuem princípios de identidade, por exemplo, EntidadeRelacional, Fornecedor, Flutuabilidade. Nessa ontologia, o conceito sortal pode ser especializado em dois outros, sortais rígidos (Rigid Sortals) (por exemplo, Pessoa, Areia, Floresta, Mulher) e sortais anti rígidos (AntiRigid Sortals) (por exemplo, Adolescente, Estudante). Um tipo é rígido quando é aplicado a suas instâncias necessariamente, ou seja, se X é um tipo rígido e existir uma entidade x::x (onde :: representa a relação de instanciação), então enquanto x existir será o caso que x::x. Um sortal rígido pode ser ou um Substance Sortal ou um SubKind. Um Substance Sortal é o sortal, único, que provê um princípio de identidade a suas instâncias, por exemplo, Pessoa, Areia, Floresta. Um SubKind é um sortal rígido que herda o princípio de identidade de um Kind, por exemplo, Mulher, que herda o princípio de identidade de Pessoa. A meta classe Substance Sortal pode ser especializada em Kind, que é um Substance Sortal que provê um princípio de identidade a suas instâncias (por exemplo, Pessoa), Quantity, que é um objeto maximalmente auto conectado que não possui princípios de individuação e contagem (por exemplo, Areia), e Collective, que representa um coleção de entidades conectadas por uma relação unificadora (por exemplo, Floresta). Em tipos sortais anti rígidos, uma instância necessariamente deixará de instanciar esse tipo em algum momento de sua existência. Essa metaclasse pode ser especializada em Phase, que é o tipo que um objeto instancia em um período de tempo, devido à uma característica intrínseca (um exemplo de fase (Phase) é Adolescente), e Role, que é um tipo que uma entidade instancia em um contexto dado, como a participação em um evento ou relação (um exemplo de papel (Role) é Estudante, desempenhado por Pessoa quando vinculada à uma Instituição de Ensino). Mixin Universals (por exemplo, EntidadeRelacional, Fornecedor, Flutuabilidade) podem ser ou mixins rígidos (RigidMixins) (por exemplo, EntidadeRelacional) ou mixins não rígidos (NonRigidMixins) (por exemplo, Fornecedor, Flutuabilidade). Mixins rígidos podem ser especializados em categorias (Categories), que classificam entidades que instanciam diferentes kinds, mas compartilham alguma característica essencial, por exemplo, EntidadeRelacional, como uma generalização de Pessoa e AgenteInteligente. Os mixins não rígidos representam propriedades que são essenciais a algumas de suas instâncias e acidentais para outras. Eles podem ser classificados em anti rígidos (AntiRigidMixins) (por exemplo, Fornecedor) e semi rígidos (SemiRigidMixins) (por exemplo, Flutuabilidade). Os mixins anti rígidos podem ser especializados em RoleMixins, que representam abstrações de propriedades comuns a papeis, como por exemplo, o papel Fornecedor. Os mixins semi rígidos podem ser especializados em Mixins, que representam entidades não rígidas e não sortais, como por exemplo, Flutuabilidade, que é uma característica essencial para um barco, mas acidental para uma cadeira. A seguir são apresentados o metamodelo UML revisado, construído com base na análise da linguagem UML em relação ao fragmento da ontologia UFO mostrado na figura 16, e um perfil de modelagem com as restrições necessárias ao metamodelo. Esse perfil, proposto em [Guizzardi, 50

51 2005], tinha suas restrições inicialmente escritas em linguagem natural. Uma das contribuições do presente trabalho é a formalização dessas restrições na linguagem OCL 2.0. A seguir, esse perfil é apresentado com restrições em linguagem natural e traduzidas para OCL 2.0. Figura 16: Fragmento do metamodelo da UFO referente à classes e generalização. Metaclasse: Substance Sortal Descrição: Substance Sortal é uma metaclasse abstrata que representa as propriedades gerais de todos os sortais substanciais, que são objetos relacionalmente independentes, rígidos e que provêem um princípio de identidade a suas instâncias. Substance Sortal não possui sintaxe concreta. Então representações simbólicas são definidas para suas subclasses concretas. Restrições: 1. Todo objeto substancial representado em um modelo conceitual utilizando se esse perfil precisa ser instância de um sortal substancial direta ou indiretamente. Isso significa que todo elemento concreto desse perfil utilizado em um diagrama de classes (isabstract = false) que não seja estereotipado com «kind», «quantity» ou «collective», tem que incluir em sua coleção de supertipos uma classe estereotipada com «kind», «quantity» ou «collective». 51

52 OCL: inv SubstanceSortalRestrição1: Classifier.allInstances() > forall(x ((x.isabstract = false) and not x.ocliskindof(substancesortal)) implies self.allsupertypes() >exists(y y.ocliskindof(substancesortal))) Figura 17: Fragmento revisado do metamodelo UML. 2. Um objeto substancial representado em um modelo conceitual utilizando se esse perfil não pode ser instância de mais de um sortal substancial. Isso significa que, nesse perfil, toda classe estereotipada utilizada em um diagrama de classes, não pode incluir em sua coleção de supertipos mais de um sortal substancial. Portanto um sortal substancial não pode incluir nem outro sortal substancial nem um «subkind» em sua coleção de supertipos, ou seja, um sortal substancial não pode ter como supertipo um membro de {«kind», «subkind», «quantity», «collective». OCL: inv SubstanceSortalRestrição2: not self.allsupertypes() > exists (y 52

53 y.ocliskindof(rigidsortalclass)) 3. Uma classe que representa um universal substancial rígido não pode ser subclasse de uma classe que representa um universal anti rígido. Logo, um sortal substancial não pode ter como supertipo um membro de {«phase», «role», «rolemixin». OCL: inv SubstanceSortalRestrição3: not self.allsupertypes() >exists(x x.ocliskindof(phase) or x.ocliskindof(role) or x.ocliskindof(rolemixin)) Estereótipo: «kind» Descrição: Um «kind» representa um sortal substancial cujas instâncias são complexos funcionais. Exemplos incluem instâncias de espécies naturais (como Pessoa, Cachorro e Árvore) e de artefatos (como Cadeira, Bicicleta, Computador). Estereótipo: «quantity» Descrição: Um «quantity» representa um sortal substancial cujas instâncias são quantidades. Exemplos são os universais que são tipicamente referenciados em linguagem natural por termos gerais de massa (por exemplo, Ouro, Água, Areia, Barro). Estereótipo: «collective» Descrição: Um «collective» representa um sortal substancial cujas instâncias são coletivos, ou seja, são coleções de complexos que possuem uma estrutura uniforme. Exemplos incluem um maço de cartas, uma floresta, um grupo de pessoas e uma pilha de tijolos. Coletivos podem tipicamente relacionar se com complexos por uma relação de constituição. Por exemplo, uma pilha de tijolos que constitui uma parede, um grupo de pessoas que constitui os músicos de uma orquestra. Restrições: 1. Um coletivo pode ser extensional. Nesse caso o meta atributo isextensional é igual a true. Isso significa que todas as suas partes são essenciais e a mudança (ou destruição) de qualquer uma de suas partes termina a existência do coletivo. Utiliza se o símbolo {extensional para representar um coletivo extensional. OCL: inv CollectiveRestrição1: self.isextensional implies Meronymic.allInstances() >forall(x x.source >forall(y if y.ocliskindof(property) then if (y.oclastype(property).endtype = self) then x.isessential else true endif else false endif)) Estereótipo: «subkind» Descrição: Um «subkind» é uma restrição relacionalmente independente e rígida de um sortal substancial que carrega um principio de identidade. Um exemplo pode ser o subtipo Homem do tipo Pessoa. Em geral, o estereótipo «subkind» pode ser omitido em modelos conceituais sem a perda de informação. Restrições: 1. Um «subkind» não pode ter como supertipo um membro de {«phase», «role», 53

54 «rolemixin». OCL: inv SubKindRestrição1: not self.allsupertypes() >exists(x x.ocliskindof(phase) or x.ocliskindof(role) or x.ocliskindof(rolemixin)) Estereótipo: «phase» Descrição: Um «phase» representa uma fase de um sortal particionado em fases, ou seja, universais anti rígidos e relacionalmente independentes definidos como partes de uma partição de um sortal substancial. Por exemplo, <Lagarta, Borboleta> particiona o tipo Lepidóptero. Restrições: 1. Fases são universais anti rígidos, então um «phase» não pode aparecer como supertipo de um universal rígido em um modelo conceitual. OCL: inv PhaseRestrição1: not SubstanceSortal.allInstances() > exists(x x.allsupertypes() >exists(y y.ocliskindof(phase))) 2. As fases {F1... Fn que formam uma partição de fases de um sortal substancial S são representadas em um diagrama de classes como um Conjunto de Generalizações (GeneralizationSet) disjunto e completo. Em outras palavras, um Conjunto de Generalizações com o meta atributo iscovering e isdisjoint iguais a true é utilizado para representar o conceito ontológico de partição de fases. Estereótipo: «role» Descrição: Um «role» representa um papel de um sortal particionado em fases, ou seja, um universal relacionalmente dependente e anti rígido. Por exemplo, o papel Estudante é exercido por uma instância do tipo Pessoa. Restrições: 1. Papeis são universais anti rígidos e, portanto, um «role» não pode aparecer como supertipo de um universal rígido em um modelo conceitual. OCL: inv RoleRestrição1: not SubstanceSortal.allInstances() > exists(x x.allsupertypes() >exists(y y.ocliskindof(role))) 2. Seja X uma classe estereotipada com «role» e r uma associação representando a condição de restrição de X. Então #X.r 1. Essa restrição é elaborada na próxima seção, depois da consideração de outros elementos do metamodelo UML. Metaclasse: Mixin Class Descrição: Mixin Class é uma metaclasse abstrata que representa as propriedades gerais de todos os mixins, ou seja, não sortais (ou universais dispersivos). Mixin Class não possui sintaxe concreta. Então representações simbólicas são definidas para suas subclasses concretas. Restrições: 1. Uma classe que represente universais não sortais não pode ser subclasse de uma classe que represente um sortal. Como conseqüência desse postulado, tem se que uma instância de Mixin Class não pode ter como supertipo um membro de {«kind», «quantity», 54

55 «collective», «subkind», «phase», «role». OCL: inv MixinClassRestrição1: not self.allsupertypes() >exists(x x.ocliskindof(sortalclass)) 2. Um não sortal não pode ter instâncias diretas. Portanto uma Mixin Class deve ser sempre uma classe abstrata (isabstract = true). OCL: inv MixinClassRestrição2: self.isabstract = true Estereótipo: «category» Descrição: Um «category» representa um mixin rígido e relacionalmente independente, ou seja, um universal dispersivo que agrega propriedades essenciais que são comuns a diferentes sortais substanciais. Por exemplo, a categoria EntidadeRelacional como uma generalização de Pessoa e AgenteInteligente. Restrições: 1. Um «category» não pode ter um «rolemixin» como supertipo. Em outras palavras, juntamente com a restrição 1 para todos os mixins, tem se que um «category» só pode ser subtipo de um «category» ou um «mixin». OCL: inv CategoryRestrição1: self.allsupertypes() >forall(x x.ocliskindof(category) or x.ocliskindof(mixin)) Estereótipo: «rolemixin» Descrição: Um «rolemixin» representa um não sortal anti rígido e externamente dependente, ou seja, um universal dispersivo que agrega propriedades que são comuns a diferentes papeis. Nele são inclusos papeis formais, como todo e parte. Restrições: 1. Seja X uma classe estereotipada com «rolemixin» e r uma associação representando a condição de restrição de X. Então #X.r 1. Essa restrição é elaborada na próxima seção, depois da consideração de outros elementos do metamodelo UML. Estereótipo: «mixin» Descrição: Um «mixin» representa propriedades que são essenciais para algumas de suas instâncias e acidentais para outras (semi rigidez). Um exemplo é o mixin Flutuabilidade, que é uma característica essencial para um barco, mas acidental para uma cadeira. Restrições: 1. Um «mixin» não pode ter um «rolemixin» como supertipo. OCL: inv MixinRestrição1: not self.allsupertypes() >exists(x x.ocliskindof(rolemixin)) 55

56 3.2. Classificadores e Propriedades A figura 18 representa o fragmento do metamodelo da UFO referente à classificadores e propriedades. Nessa figura o conceito Entity representa os tipos de entidades. Essa metaclasse pode ser especializada nos conceitos Universal e Abstrato (Abstract). Universal pode ser especializada em Relação (Relation) (por exemplo, as relações maisvelhoque e casadocom) e Monadic Universal. Essa última pode ser especializada em Object Universal, que representa o conceito Substantial Universal do fragmento do metamodelo analisado anteriormente, e Moment Universal. Nesse fragmento, Object Universal pode ser especializado em Non Sortal, que representa a metaclasse Mixin Universal, e Sortal, que representa a metaclasse SortalUniversal. Aqui, é mostrado RoleMixin como subtipo de Non Sortal e Role como subtipo de Sortal Universal. Nesse fragmento, a metaclasse Moment Universal é mostrada mais detalhadamente. Ela pode ser especializada em Intrinsic Moment Universals, que caracterizam Object Universals e são existencialmente dependentes dos mesmos, e Relator Universals, que são existencialmente dependentes de várias entidades. Intrinsic Moment Universals são a fundamentação para atributos e relações comparativas formais. Relator Universals são a fundamentação para relações materiais (Material Relations) (por exemplo, a relação casadocom, derivada do relator casamento), que sempre requerem relatores para serem estabelecidas. Exemplos de relatores incluem um casamento e um emprego. A metaclasse Intrinsic Moment Universal pode ser especializada em Quality Universal e Mode Universal. Uma Quality Universal é uma instância de Intrinsic Moment Universal que está associada a uma Quality Structure. Um Mode Universal é um Intrinsic Moment Universal que é existencialmente dependente de exatamente uma entidade, como por exemplo, habilidades, crenças, pensamentos. O conceito Relação pode ser especializado em relações materiais e relações formais, que são relações derivadas de propriedades intrínsecas das entidades relacionadas, como por exemplo, a relação maisvelhoque, derivada da propriedade idade do tipo Pessoa. Os conceitos Abstrato e seu subtipo Conjunto (Set) têm seus significados usuais. Uma função de atributo (Attribute Function) é um conjunto e representa a contraparte ontológica do conceito de Atributo em UML. O conceito Estrutura de Qualidade (Quality Structure) também é um conjunto e pode ser entendido como um espaço de valores em que qualidades individuais podem obter seus valores. Por exemplo, o tipo de qualidade altura está associado a um espaço de valores que é uma estrutura linear isomórfica aos números reais positivos. O tipo de qualidade cor é associado a uma estrutura de qualidade tridimensional composta das dimensões brilho, saturação e contraste. Então, cada cor tem como valor um ponto em uma estrutura tridimensional. O conceito Estrutura de Qualidade representa a contraparte ontológica da metaclasse DataType do metamodelo UML. Esse conceito pode ser especializado em Dimensão de Qualidade (Quality Dimension), que é um conjunto de valores que uma qualidade pode assumir e as relações formais entre os mesmos, e Domínio de Qualidade (Quality Domain) que é definido como um conjunto de dimensões de qualidade. Serão agora explicados os significados das relações que constam nesse fragmento do metamodelo da UFO. A relação subconjuntode (subsetof) tem o significado usual de subconjunto. A relação de caracterização (characterization) é a relação entre um modo (Mode Universal) e o 56

57 universal que ele caracteriza. Essa relação é mapeada no nível das instâncias como uma relação de inerência entre a qualidade correspondente e o indivíduo substancial. Por exemplo, o universal Capacidade caracteriza o universal Agente. Uma relação de mediação (mediation) ocorre entre um relator e o universal que ele media. Essa relação é mapeada a nível de instâncias como uma relação de mediação entre as instâncias correspondentes. Assim, toda instância r de um relator R é existencialmente dependente dos indivíduos c1... cn instâncias das classes C1... Cn conectadas a R por uma relação de mediação. A relação de mediação é uma relação binária e é um tipo de dependência existencial. Alguns exemplos são o casamento que media os papeis (Roles) esposo e esposa, e a ligação covalente, que media o universal Átomo. A relação de derivação (derivation) é uma relação especializada entre uma relação material e um relator, ela é um tipo de dependência existencial. Um exemplo é a relação material casadocom, que é derivada do relator casamento. A seguir são apresentados o metamodelo UML revisado, baseado na análise da linguagem UML em relação ao fragmento da ontologia UFO mostrado na figura 18, e um perfil de modelagem com as restrições necessárias ao metamodelo. As restrições são apresentadas em linguagem natural e traduzidas para OCL 2.0. Figura 18: Fragmento do metamodelo da UFO referente à classificadores e propriedades. 57

58 Figura 19: Fragmento revisado do metamodelo UML. Estereótipo: «role» Descrição: Refinamento da definição do estereótipo «role». Classe Base: Class Restrições: 1. Refinamento da condição 2 do estereótipo «role»: toda classe «role» precisa estar conectada à extremidade de uma relação «mediation». OCL: inv RoleRestrição2: Mediation.allInstances() >exists(x x.target >exists(y if y.ocliskindof(property) then ((y.oclastype(property).endtype = self) or (self.allsupertypes() > includes(y.oclastype(property).endtype))) else false endif)) Estereótipo: «rolemixin» Descrição: Refinamento da definição do estereótipo «rolemixin». Classe Base: Class Restrições: 1. Refinamento da condição 1 do estereótipo «rolemixin»: toda classe «rolemixin» precisa estar conectada à extremidade de uma relação «mediation». OCL: inv RoleMixinRestrição1: Mediation.allInstances() >exists(x x.target > exists(y if y.ocliskindof(property) then (y.oclastype(property).endtype = self) else false endif)) 58

59 Estereótipo: «mode» Descrição: Um universal «mode» é um momento universal intrínseco. Toda instância de Mode Universal é existencialmente dependente de exatamente uma entidade. Exemplos incluem habilidades, pensamentos, crenças, intenções, sintomas. Classe Base: Class Restrições: 1. Todo «mode» precisa estar direta ou indiretamente conectado à extremidade de ao menos uma relação «characterization». OCL: inv ModeRestrição1: Characterization.allInstances() > exists(x x.isconected(self) or self.allsupertypes() >exists(y x.isconected(y))) Estereótipo: «relator» Descrição: Um universal «relator» é um momento universal relacional. Toda instância do universal relator é existencialmente dependente de ao menos duas entidades distintas. Relatores são a instanciação de propriedades relacionais como casamentos, beijos, compromissos e compras. Classe Base: Class Restrições: 1. Todo «relator» precisa estar direta ou indiretamente conectado à extremidade de ao menos uma relação «mediation». OCL: inv RelatorRestrição1: Mediation.allInstances() >exists(x x.isconected(self) or self.allsupertypes() >exists(y x.isconected(y))) 2. Seja R um relator universal e seja {C1... Cn um conjunto de universais mediados por R (relacionados a R por uma relação «mediation»). E seja lowerci o valor da cardinalidade mínima da extremidade da relação «mediation» conectado à Ci. Então, tem se que n lower Ci 2. i=1 OCL: inv RelatorRestrição2: Mediation.allInstances() >select(x x.source >exists(y if y.ocliskindof(property) then (y.oclastype(property).endtype = self) else false endif)) >collect(z z.target >collect(w if w.ocliskindof(property) then w.oclastype(property).lower else 0 endif) >sum()) >sum() >= 2 Metaclasse: DirectedBinaryRelationship Descrição: A metaclasse DirectedBinaryRelationship é uma metaclasse abstrata que representa as propriedades gerais de todas as relações binárias direcionadas que ocorrem entre um elemento fonte e um elemento alvo. DirectedBinaryRelationship não possui sintaxe concreta. Então representações simbólicas são definidas para suas subclasses concretas. Classe Base: DirectedRelationship Restrições: 1. As meta relações source e target, herdadas de DirectedRelationship, são aplicadas somente a Properties e possuem meta cardinalidades iguais a um. 59

60 OCL: inv DirectedBinaryRelationshipRestrição1: self.source > forall(x x.ocliskindof(property)) and self.target >forall(x x.ocliskindof(property)) OCL: inv DirectedBinaryRelationshipRestrição2: (self.source > size() = 1) and (self.target >size() = 1) Estereótipo: «mediation» Descrição: Uma «mediation» é uma relação formal feita entre um relator universal e o endurante universal que ele media. Por exemplo, o universal casamento media os papeis universais esposo e esposa, o universal registro media estudante e universidade, e o universal ligação covalente media o universal átomo. Classe Base: Dependency Relationship Restrições: 1. Uma associação estereotipada com «mediation» precisa ter em sua extremidade fonte uma classe estereotipada com «relator» representando o relator universal correspondente. OCL: inv MediationRestrição1: self.source >forall(x if x.ocliskindof(property) then x.oclastype(property).endtype.oclistypeof(relator) else false endif) 2. A extremidade conectada ao universal mediado precisa ter a cardinalidade mínima maior ou igual a um. OCL: inv MediationRestrição2: self.target >forall(x if x.ocliskindof(property) then (x.oclastype(property).lower >= 1) else false endif) 3. A extremidade conectada ao universal mediado precisa ter a propriedade isreadonly igual a true. OCL: inv MediationRestrição3: self.target >forall(x if x.ocliskindof(property) then x.oclastype(property).isreadonly else false endif) 4. A extremidade conectada ao relator universal precisa ter a cardinalidade mínima maior ou igual a um. OCL: inv MediationRestrição4: self.source >forall(x if x.ocliskindof(property) then (x.oclastype(property).lower >= 1) else false endif) 5. Associações «mediation» são sempre associações binárias. OCL: inv MediationRestrição5: self.relatedelement >size() = 2 Estereótipo: «characterization» Descrição: Uma «characterization» é uma relação formal feita entre um modo universal e o endurante universal que esse modo universal caracteriza. Por exemplo, o universal Capacidade caracteriza o universal Agente. Classe Base: Dependency Relationship Restrições: 1. Uma associação estereotipada com «characterization» precisa ter em sua extremidade fonte uma classe estereotipada com «mode» representando o modo universal caracterizante. 60

61 OCL: inv CharacterizationRestrição1: self.source >forall(x if x.ocliskindof(property) then x.oclastype(property).endtype.oclistypeof(mode) else false endif) A cardinalidade na extremidade conectada ao universal caracterizado precisa ser exatamente igual a um. OCL: inv CharacterizationRestrição2: self.target >forall(x if x.ocliskindof(property) then ((x.oclastype(property).lower = 1) and (x.oclastype(property).upper = 1)) else false endif) A cardinalidade mínima na extremidade conectada à qualidade universal caracterizante (extremidade fonte) precisa ser maior ou igual a um. OCL: inv CharacterizationRestrição3: self.source >forall(x if x.ocliskindof(property) then (x.oclastype(property).lower >= 1) else false endif) A extremidade conectada ao universal caracterizado precisa ter a propriedade isreadonly igual a true. OCL: inv CharacterizationRestrição4: self.target >forall(x if x.ocliskindof(property) then x.oclastype(property).isreadonly else false endif) Associações «characterization» são sempre associações binárias. inv CharacterizationRestrição5: self.relatedelement >size() = Estereótipo: Derivation Relation Descrição: Uma relação de derivação representa a relação formal que acontece entre uma relação material e o relator universal da qual essa relação material é derivada. Exemplos incluem a relação material casado com, que é derivada do relator universal Casamento, a relação material beijado por, que é derivada do relator universal Beijo, e a relação material compra de, derivada do relator universal Compra. Classe Base: Dependency Relationship Restrições: 1. Uma associação de derivação precisa ter uma de suas extremidades conectada a um relator universal (a extremidade do círculo negro) e a outra conectada a uma relação material. OCL: inv DerivationRestrição1: self.target >forall(x if x.ocliskindof(property) then x.oclastype(property).endtype.oclistypeof(relator) else false endif) and self.source >forall(x if x.ocliskindof(property) then x.oclastype(property).endtype.oclistypeof(materialassociation) else false endif) 2. Associações de derivação são sempre associações binárias. OCL: inv DerivationRestrição2: self.relatedelement >size() = 2 3. A cardinalidade na extremidade que possui o círculo negro precisa ser exatamente igual a um. OCL: inv DerivationRestrição3: self.target >forall(x if x.ocliskindof(property) then ((x.oclastype(property).lower = 1) and (x.oclastype(property).upper = 1)) else false endif) 61

62 4. A extremidade que possui o círculo negro da relação de derivação precisa ter a propriedade isreadonly igual a true. OCL: inv DerivationRestrição4: self.target >forall(x if x.ocliskindof(property) then x.oclastype(property).isreadonly else false endif) 5. As restrições de cardinalidade da extremidade conectada à associação material, em uma relação de derivação, são o produto das cardinalidades das relações «mediation» do relator universal do qual essa relação material é derivada. Como as relações de mediação requerem uma cardinalidade mínima igual a um em ambas as extremidades, então a cardinalidade mínima na extremidade da relação de derivação conectada à relação material também precisa ser maior ou igual a um. OCL: inv DerivationRestrição5: self.source >forall(x if x.ocliskindof(property) then (x.oclastype(property).lower >= 1) else false endif) Estereótipo: «material» Descrição: Uma relação «material» representa uma relação material, ou seja, um universal relacional que é induzido por um relator universal. Exemplos incluem estudante estuda em uma universidade, paciente é tratado em uma unidade médica, pessoa é casada com pessoa. Classe Base: Association Restrições: 1. Toda associação «material» precisa estar conectada em uma extremidade de exatamente uma relação de derivação. OCL: inv MaterialAssociationRestrição1: Derivation.allInstances() >one(x x.source >exists(y if y.ocliskindof(property) then (y.oclastype(property).endtype = self) else false endif)) 2. As restrições de cardinalidade das extremidades de uma relação material são derivadas das restrições de cardinalidade das relações «mediation» do relator universal do qual essa relação material é derivada. Como as relações de mediação requerem uma cardinalidade mínima igual a um em ambas as extremidades, então a cardinalidade mínima em cada extremidade da relação material derivada também precisa ser maior ou igual a um. OCL: inv MaterialAssociationRestrição2: self.associationend >forall(x x.lower >= 1) 3. Toda associação «material» precisa ter a propriedade isderived igual a true. OCL: inv MaterialAssociationRestrição3: self.associationend > forall(x x.isderived = true) Estereótipo: «formal» Descrição: Um associação «formal» representa uma relação formal, ou seja, ou uma relação comparativa (derivada de propriedades intrínsecas das entidades relacionadas), ou uma relação interna. Exemplos incluem Pessoa é mais velha que Pessoa, um Átomo é mais pesado que outro Átomo. Utiliza se a representação simbólica UML para relações derivadas ( / ) para representar 62

63 relações comparativas. Classe Base: Association Metaclasse: DatatypeAssociation Descrição: Uma DatatypeAssociation representa uma relação entre um universal e um «datatype». Essa relação não é estereotipada. Um exemplo é um «kind» Museu que possui a relação localização para um «datatype» CoordenadasGeofráficas. Classe Base: Association Restrições: 1. Uma das extremidades da relação deve conter uma instância de Datatype. OCL: inv DatatypeAssociationRestrição1: self.associationend > exists(x if x.ocliskindof(property) then x.oclastype(property).endtype.ocliskindof(datatype) else false endif) Metaclasse: Property Descrição: Um atributo no metamodelo UML é uma propriedade possuída por um classificador. Atributos são utilizados nesse perfil para representar funções atributo (Attribute Functions) derivadas para qualidades universais. Exemplos são os atributos cor, idade. Restrições: 1. Uma propriedade possuída por um classificador (representando um atributo desse classificador) precisa ter a cardinalidade mínima maior ou igual a um, pois não existem atributos opcionais Agregação e Composição A figura 20 representa o fragmento do metamodelo da UFO referente à agregação e composição. Nesse fragmento, a classe Object representa uma instância de Substantial Universal. Essa classe pode ser especializada nos conceitos Quantity, Collective ou Complex. O conceito Complex representa os complexos funcionais, que são coleções em que seus membros podem desempenhar diferentes papeis (o que não é o caso em coletivos). A classe Member representa a qualidade que uma entidade singular apresenta quando é membro de um outro coletivo. Esse conceito pode ser especializado em CollectiveMember, que representa um coletivo considerado como uma unidade e que também é subtipo de Collective, e ComplexMember, que representa um complexo funcional considerado como uma unidade e que também é subtipo de Complex. A principal relação mostrada nesse fragmento do metamodelo da UFO é a relação partede (partof) que é irreflexiva, anti simétrica e não transitiva (ou seja, é transitiva somente em alguns casos), pois duas de suas subclasses são transitivas (subquantityof e subcollectioof), uma é intransitiva (memberof) e a outra é não transitiva (componentof). A relação partede também obedece ao princípio de suplementação fraca (ou seja, se x é parte de y, então tem que haver um z, disjunto de x, que também é parte de y). Desse princípio, decorre que, sendo U um universal, {C1...Cn um conjunto de universais relacionados a U por relações partede, e lowerci o valor da 63

64 cardinalidade mínima da extremidade da associação conectada a Ci pela relação, então tem se que: n lower Ci 2. i=1 A relação componentede (componentof) é uma relação partede entre complexos funcionais. Exemplos dessa relação são as relações entre uma mão e um braço e entre um coração e um sistema circulatório. Uma relação subquantidadede (subquantityof) é uma relação exclusiva que ocorre entre quantidades, e como todas as partes de uma quantidade são essenciais, a relação também é essencial. Exemplos dessa relação incluem as relações parte todo entre Plasma e Sangue e entre Álcool e Vinho. A relação subcoleçãode (subcollectiveof) é uma relação entre coletivos e é obtida pelo refinamento da relação unificadora do coletivo que representa o todo. Por exemplo, a coleção de fêmeas como parte de uma população e a coleção de valetes como parte de um baralho. Uma relação membrode (memberof) é uma relação mantida entre uma entidade singular (ou um CollectiveMember ou um ComplexMember) e um coletivo. Exemplos dessa relação são uma árvore como parte de uma floresta, uma carta como parte de um maço de cartas. Abaixo, são apresentados o metamodelo UML revisado, baseado na análise da linguagem UML em relação ao fragmento da ontologia UFO mostrado na figura 20, e um perfil de modelagem com as restrições necessárias ao metamodelo. Novamente, aqui as restrições são apresentadas em linguagem natural e traduzidas para OCL 2.0. Metaclasse: Meronymic Descrição: É uma metaclasse abstrata que representa propriedades gerais de todas as relações meronímicas (onde meronímia é a relação parte todo, opondo se à holonímia, que é a relação todo parte). Meronymic não possui sintaxe concreta. Então representações simbólicas são definidas para suas subclasses concretas. Meta propriedades: não reflexividade, anti simetria, não transitividade e suplementação fraca. Restrições: 1. Suplementação fraca: Seja U um universal cujas instâncias são todos e seja {C1... Cn um conjunto de universais relacionados a U por relações meronímicas. E seja lower Ci o valor da cardinalidade mínima da extremidade da relação conectada à C i. Então, tem se n que lower Ci 2. i=1 OCL: inv MeronymicRestrição1: Meronymic.allInstances() > select(x x.source > exists(y if y.ocliskindof(property) then (self.source >exists(z if z.ocliskindof(property) then (z.oclastype(property).endtype = y.oclastype(property).endtype) else false endif)) else false endif)) >collect(w w.target >collect(k if k.ocliskindof(property) then k.oclastype(property).lower else 0 endif) >sum()) >sum() >= 2 64

65 Figura 20: Fragmento do metamodelo da UFO referente à agregação e composição. Figura 21: Fragmento revisado do metamodelo UML. 65

66 2. Pertinência essencial: O meta atributo isessential representa quando a parte é essencial ao todo. No caso de o classificador conectado à extremidade que representa o todo ser um classificador anti rígido, então o meta atributo isessential deve ser false, enquanto o meta atributo isimmutablepart pode ser true. No entanto, se isessential for true, então isimmutablepart deverá ser true. A representação concreta dessa meta propriedade é via a decoração {essential na associação. OCL: inv MeronymicRestrição2: (self.target >forall(x if x.ocliskindof(property) then (x.oclastype(property).endtype.ocliskindof(antirigidsortalclass) or x.oclastype(property).endtype.ocliskindof(antirigidmixinclass)) else false endif)) implies (self.isessential = false) OCL: inv MeronymicRestrição5: self.isessential implies self.isimmutablepart 3. Pertinência inseparável: O meta atributo isinseparable representa quando o todo é essencial à parte. Sempre que isinseparable for true, então isimmutablewhole também deverá ser true. A representação concreta dessa meta propriedade é via a decoração {inseparable na associação. OCL: inv MeronymicRestrição6: self.isinseparable implies self.isimmutablewhole 4. Pertinência compartilhável: O meta atributo isshareable representa quando a parte pode se relacionar a mais de um todo do mesmo tipo. A representação concreta dessa meta propriedade é via a cor do símbolo utilizado para representar a relação (um diamante com ou sem uma letra): Se isshareable for true, então o símbolo é mostrado na cor branca, senão será mostrado na cor preta. 5. Se o meta atributo isimmutablepart for true, então a extremidade da relação conectada à parte precisa ter a propriedade isreadonly igual a true. OCL: inv MeronymicRestrição3: self.isimmutablepart implies self.target >forall(x if x.ocliskindof(property) then x.oclastype(property).isreadonly else false endif) 6. Se o meta atributo isimmutablewhole for true, então a extremidade da relação conectada ao todo precisa ter a propriedade isreadonly igual a true. OCL: inv MeronymicRestrição4: self.isimmutablewhole implies self.source > forall(x if x.ocliskindof(property) then x.oclastype(property).isreadonly else false endif) Metaclasse: componentof Descrição: ComponenteDe é uma relação parte todo entre dois complexos. Exemplos incluem: (a) minha mão é parte de meu braço, (b) um coração é parte de um sistema circulatório. Essa relação é representada pelo símbolo UML padrão para agregação/composição, ou seja, são utilizados os símbolos e para representar relações componentede exclusivas e não exclusivas, respectivamente. Meta propriedades: não reflexividade, anti simetria, não transitividade e suplementação fraca. Restrições: 1. As classes conectadas a ambas as extremidades dessa associação devem representar universais cujas instâncias são complexos funcionais. Um universal X é um universal 66

67 cujas instâncias são complexos funcionais se ele satisfaz as seguintes condições: (i) Se X é um sortal universal, então ele precisa ser estereotipado com «kind» ou ser um subtipo de uma classe estereotipada com «kind». (ii) De outra forma, se X é um mixin universal, então para todas as classes Y tais que Y é subtipo de X, tem se que Y nem pode ser estereotipado com «quantity» nem «collective», e Y não pode ser subtipo de uma classe estereotipada com «quantity» nem «collective». OCL: inv componentofrestrição1: self.source >forall(x if x.ocliskindof(property) then x.oclastype(property).endtype. hasfunctionalcomplexesinstances() else false endif) and self.target >forall(x if x.ocliskindof(property) then x.oclastype(property).endtype. hasfunctionalcomplexesinstances() else false endif) Metaclasse: subquantityof Descrição: SubQuantidadeDe é uma relação parte todo entre duas quantidades. Exemplos incluem: (a) álcool é parte do Vinho; (b) Plasma é parte do Sangue. É proposto o ícone para representar essa relação. Meta propriedades: não reflexividade, anti simetria, transitividade e suplementação forte. O princípio de suplementação forte impõe que, se existe um indivíduo y que não é parte de um indivíduo x, então existe um indivíduo z, que é parte de y e não sobrepõe x. Restrições: 1. Essa relação é sempre exclusiva. OCL: inv subquantityofrestrição1: self.isshareable = false 2. Todas as entidades estereotipadas com «quantity» são indivíduos extensionais e, portanto, todas as relações parte todo são relações essenciais. OCL: inv subquantityofrestrição2: self.isessential = true 3. A cardinalidade máxima na extremidade da relação conectada à parte precisa ser igual a um. OCL: inv subquantityofrestrição3: self.target >forall(x if x.ocliskindof(property) then (x.oclastype(property).upper = 1) else false endif) 4. As classes conectadas a ambas as extremidades dessa associação devem representar universais cujas instâncias são quantidades. Um universal X é um universal cujas instâncias são quantidades se ele satisfaz as seguintes condições: (i) Se X é um sortal universal, então ele precisa ser estereotipado com «quantity» ou ser um subtipo de uma classe estereotipada com «quantity». (ii) De outra forma, se X é um mixin universal, então para todas as classes Y tais que Y é subtipo de X, tem se que Y nem pode ser estereotipado com «kind» nem «collective», e Y não pode ser subtipo de uma classe estereotipada com «kind» nem «collective». OCL: inv subquantityofrestrição4: self.source >forall(x if x.ocliskindof(property) then x.oclastype(property).endtype.hasquantitiesinstances() else false endif) and self.target >forall(x if x.ocliskindof(property) then 67

68 x.oclastype(property).endtype.hasquantitiesinstances() else false endif) Metaclasse: subcollectionof Descrição: SubColeçãoDe é uma relação parte todo entre dois coletivos. Exemplos incluem: (a) A coleção de valetes em um baralho é parte do baralho; (b) A coleção de fêmeas em uma população é parte da população. São utilizados os símbolos e para representar relações subcoleçãode exclusivas e não exclusivas, respectivamente. Meta propriedades: não reflexividade, anti simetria, transitividade e suplementação fraca. Restrições: 1. As classes conectadas a ambas as extremidades dessa associação devem representar universais cujas instâncias são coletivos. Um universal X é um universal cujas instâncias são coletivos se ele satisfaz as seguintes condições: (i) Se X é um sortal universal, então ele precisa ser estereotipado com «collective» ou ser um subtipo de uma classe estereotipada com «collective». (ii) De outra forma, se X é um mixin universal, então para todas as classes Y tais que Y é subtipo de X, tem se que Y nem pode ser estereotipado com «kind» nem «quantity», e Y não pode ser subtipo de uma classe estereotipada com «kind» nem «quantity». OCL: inv subcollectionofrestrição1: self.source >forall(x if x.ocliskindof(property) then x.oclastype(property).endtype.hascollectivesinstances() else false endif) and self.target >forall(x if x.ocliskindof(property) then x.oclastype(property).endtype.hascollectivesinstances() else false endif) 2. A cardinalidade máxima na extremidade da relação conectada à parte precisa ser igual a um. OCL: inv subcollectionofrestrição2: self.target >forall(x if x.ocliskindof(property) then (x.oclastype(property).upper = 1) else false endif) Metaclasse: memberof Descrição: MembroDe é uma relação parte todo entre um complexo ou um coletivo (como uma parte) e um coletivo (como um todo). Exemplos incluem: (a) uma árvore é parte de uma floresta; (b) uma carta é parte de um maço de cartas. São utilizados os símbolos e para representar relações membrode exclusivas e não exclusivas, respectivamente. Meta propriedades: não reflexividade, anti simetria, intransitividade e suplementação fraca. Embora não ocorra transitividade entre duas relações membrode, uma relação membrode seguida de uma subcoleçãode é transitiva. Então, para todos a, b, c, se membrode(a,b) e membrode(b,c) então não é o caso que membrode(a,c). Mas, se membrode(a,b) e subcoleçãode(b,c) então membrode(a,c). Restrições: 1. Essa relação só pode representar pertinência essencial (isessencial = true) se o objeto representando o todo nessa relação for um indivíduo extensional (isextensional = true). Nesse caso, todas as relações todo parte em que esse indivíduo participa como um todo 68

69 são relações essenciais. OCL: inv memberofrestrição1: self.isessential implies self.source >forall(x if x.ocliskindof(property) then (if x.oclastype(property).endtype.ocliskindof(collective) then x.oclastype(property).endtype.oclastype(collective). isextensional else false endif) else false endif) 2. O classificador conectado na extremidade relativa ao todo deve ser um universal cujas instâncias são coletivos. O classificador conectado na extremidade relativa à parte pode ser tanto um universal cujas instâncias são coletivos quanto um universal cujas instâncias são complexos funcionais. OCL: inv memberofrestrição2: self.source >forall(x if x.ocliskindof(property) then x.oclastype(property).endtype.hascollectivesinstances() else false endif) and self.target >forall(x if x.ocliskindof(property) then (x.oclastype(property).endtype.hascollectivesinstances() or x.oclastype(property).endtype. hasfunctionalcomplexesinstances()) else false endif) 3.4. Invariantes adicionais Foi necessário definir duas invariantes em adição às do perfil. A primeira, relativa à metaclasse Generalization, ocorre em função da diferença entre as meta cardinalidades dos meta atributos specific, general, target e source. Os meta atributos specific e general da metaclasse Generalization são derivados dos meta atributos target e source, respectivamente, e devido às meta cardinalidades de specific e general serem iguais a um, houve a necessidade de restringir as meta cardinalidades dos meta atributos source e target, herdados de DirectedRelationship, pois os mesmos possuem meta cardinalidades maiores ou iguais a um. Para isso, a seguinte restrição é imposta: context Generalization inv GeneralizationRestrição1: (self.source >size() <= 1) and (self.target >size() <= 1) A segunda invariante definida é relativa à metaclasse MultiplicityElement, onde o meta atributo upper é definido como um número natural. Mas, a linguagem ECore, na qual o metamodelo foi implementado, não possui o tipo natural. Assim, foi necessário definir o meta atributo upper como um inteiro e escrever uma restrição proibindo que ao mesmo sejam atribuídos números negativos, excetuando se o número 1, que é interpretado como o infinito positivo. context MultiplicityElement inv MultiplicityElementRestrição1: (self.upper >= 0) or (self.upper = 1) 69

70 3.5. Definição de métodos em OCL Foram implementados alguns métodos na metaclasse Element, com o objetivo de facilitar a escrita das restrições OCL. Esses métodos, referenciados diversas vezes em invariantes no perfil apresentado, são especificados em OCL na tabela abaixo. Tabela 1: Especificação de operações. context Element::allSuperTypes() : Bag(Element) body: if self.ocliskindof(classifier) then (if self.oclastype(classifier).generalization >forall(x x.oclisundefined()) then Set{ else Set{self.oclAsType(Classifier).generalization >collect(x x.general), self.oclastype(classifier).generalization >collect(x if x.general.ocliskindof(classifier) then x.general.allsupertypes() else Set{ endif) >flatten() endif) else Set{ endif context Element::isConected(Element) : EBoolean body: if self.ocliskindof(relationship) then if self.oclastype(relationship).relatedelement >forall(y y.oclisundefined()) then false else if self.oclastype(relationship).relatedelement >exists(z if z.ocliskindof(property) then (z.oclastype(property).endtype = x) else false endif) then true else self.oclastype(relationship).relatedelement >exists(w if w.ocliskindof(property) then w.oclastype(property).endtype.isconected(x) else false endif) endif endif else false endif context Element::subInstanceType(Element) : EBoolean body: self.allsupertypes() >includes(x) context Element::subMetaTypeKind() : EBoolean body: if self.ocliskindof(kind) then true else self.allsupertypes() >exists(x x.ocliskindof(kind)) endif context Element::subMetaTypeCollective() : EBoolean body: if self.ocliskindof(collective) then true else self.allsupertypes() >exists(x x.ocliskindof(collective)) endif context Element::subMetaTypeQuantity() : EBoolean body: if self.ocliskindof(quantity) then true else self.allsupertypes() >exists(x x.ocliskindof(quantity)) endif context Element::hasFunctionalComplexesInstances() : EBoolean body: if self.ocliskindof(sortalclass) then self.submetatypekind() else if self.ocliskindof(mixinclass) then Element.allInstances() >forall(x x.subinstancetype(self) implies not (x.submetatypequantity() or x.submetatypecollective())) else false endif endif context Element::hasCollectivesInstances() : EBoolean body: if self.ocliskindof(sortalclass) then self.submetatypecollective() else if self.ocliskindof(mixinclass) then Element.allInstances() >forall(x x.subinstancetype(self) implies not (x.submetatypekind() or x.submetatypequantity())) else false endif endif 70

71 context Element::hasQuantitiesInstances() : EBoolean body: if self.ocliskindof(sortalclass) then self.submetatypequantity() else if self.ocliskindof(mixinclass) then Element.allInstances() >forall(x x.subinstancetype(self) implies not (x.submetatypekind() or x.submetatypecollective())) else false endif endif 3.6. Definição de meta atributos/meta associações derivados Alguns meta atributos/meta associações do metamodelo revisado da UML são derivados de outros meta atributos/meta associações. A especificação em OCL da derivação dos mesmos é mostrada na tabela abaixo. Tabela 2: Especificação de derivações. context Classifier::general : Bag(Classifier) derive: self.allsupertypes() context Classifier::generalization : Bag(Classifier) derive: Generalization.allInstances() >select(x x.specific = self) context Generalization::specific : Classifier derive: self.target >any(x x.ocliskindof(classifier)) context Generalization::general : Classifier derive: self.source >any(x x.ocliskindof(classifier)) context Property::source : DirectedBinaryRelationship derive: DirectedBinaryRelationship.allInstances() >any(x x.source >includes(self) or x.sourceaux2 >includes(self)) context Property::target : DirectedBinaryRelationship derive: DirectedBinaryRelationship.allInstances() >any(x x.target >includes(self) or x.targetaux2 >includes(self)) context Relationship::relatedElement : Bag(Element) derive: if self.ocliskindof(association) then self.oclastype(association).associationend else if self.ocliskindof(directedrelationship) then Set{self.oclAsType(DirectedRelationship).source, self.oclastype(directedrelationship).target >flatten() else null endif endif 71

72 4. Construção e Uso da Ferramenta de Modelagem Primeiramente, modelou se em ECore a unificação dos três fragmentos do metamodelo revisado da UML 2.0, mostrados no cap. 3, gerando o metamodelo da figura 22 (e cujo código ECore está na seção 7.1. do Apêndice 1). A seguir, as restrições descritas nos frameworks propostos no capítulo anterior foram traduzidas de linguagem natural para OCL 2.0, gerando assim, um único metamodelo em ECore e um conjunto de anotações semânticas, em OCL 2.0, das restrições propostas. As restrições em OCL 2.0 são mostradas na tabela nos perfis, no capítulo 3. A partir do metamodelo em ECore, foi criado um projeto EMF que gerou automaticamente um modelo Gen (seção 7.2. do Apêndice 1). Esse novo arquivo, com a adição de algumas informações, é capaz de gerar o código em Java, que representa o metamodelo, e um editor simples, em estilo árvore, que permite a instanciação de metaclasses. De posse do metamodelo em ECore, do código Java e do editor, criou se um projeto GMF. Nesse projeto foram criados três arquivos, baseados no metamodelo. O primeiro arquivo é um modelo GMFGraph (seção 7.3. do Apêndice 1). Esse arquivo descreve a visualização dos elementos gráficos do editor, quais sejam, os tipos de nós (classes), os tipos e espessuras das linhas que representam as relações e as figuras utilizadas para decorar as extremidades das relações. A criação desse arquivo é semi automática, pois indica se quais metaclasses ou meta atributos serão nós, conexões ou rótulos. Criado o arquivo, devido à natureza do presente projeto, ainda foi preciso modificar algumas figuras da galeria de figuras, para criar os estereótipos, decorações de relações e visualização de meta atributos, definidos nos perfis do capítulo 3. A criação dos estereótipos consiste na associação de rótulos às metaclasses definidas como nós. A criação de decorações para relações é mais complexa. Para criar as figuras, foi preciso criar classes Java que estendam a classe org.eclipse.draw2d.graphics.shape e reescrevam os métodos fillShape() e outlineshape(). Utilizou se vários métodos, descritos em classes do package org.eclipse.draw2d, para desenhar vetorialmente as sugestões de decorações de relações, mostradas nos perfis. Para implementar a visualização condicional de meta atributos, foi necessário alterar as classes *EditPart.java. Essas classes Java encontram se no Apêndice 2. O segundo arquivo criado é um modelo GMFTool (seção 7.4. do Apêndice 1). Esse arquivo contém os nomes das ferramentas utilizadas para a instanciação das metaclasses e meta atributos em nós e relações no editor gráfico gerado. A criação desse arquivo também é semi automática, pois indica se quais metaclasses serão nós e quais serão conexões. Modificou se esse arquivo através da inserção de duas categorias distintas de ferramentas, as utilizadas para instanciar classes e as utilizadas para a criação de relações. 72

73 Figura 22: Metamodelo unificado. 73

74 O terceiro arquivo criado é um modelo GMFMap (seção 7.5. do Apêndice 1). Esse arquivo tem como objetivo criar mapeamentos entre o arquivo do metamodelo em ECore, o arquivo GMFGraph e o arquivo GMFTool. É nesse arquivo que são especificados os nós, relações e rótulos dos elementos anteriores. Nesse arquivo também são colocadas as restrições em OCL. A verificação das restrições pode ser feita de duas formas: em tempo real ou em lote. Para criar verificações em tempo real, como restrições na instanciação de classes ou criação de relações, coloca se as restrições dentro das estruturas que especificam os nós e relações ou em contêineres e marca se a propriedade Use In Live Mode com true. Para a criação de validações em lote, avaliadas manualmente, cria se contêineres com as restrições em OCL e seus respectivos contextos, deixando a opção Use In Live Mode com o valor default false. As seguintes restrições OCL dos perfis são validadas em tempo real: CategoryRestrição1, CharacterizationRestrição1, componentofrestrição1, DerivationRestrição1, GeneralizationRestrição1, MediationRestrição1, memberofrestrição1, MixinRestrição1, MixinClassRestrição1, PhaseRestrição1, RoleRestrição1, subcollectionofrestrição1, SubKindRestrição1, subquantityofrestrição1, SubstanceSortalRestrição2 e SubstanceSortalRestrição3. Terminadas as alterações no arquivo GMFMap, cria se, a partir do mesmo, um modelo GMFGen (disponível no CD que acompanha a monografia). Esse arquivo será utilizado para a criação automática do editor gráfico. Nesse arquivo ainda será necessário marcar manualmente alguns campos para habilitar o framework MDT de validação OCL no editor. Finalmente, pode se gerar automaticamente o código do editor. Feito isso, coloca se as classes responsáveis pela visualização condicional de meta atributos e por desenhar as decorações das extremidades das relações dentro do package UMLPlus.diagram.edit.parts, que está no diretório src do diretório recém criado UMLPlus.diagram. Em suma, o presente projeto caracteriza perfeitamente um projeto MDE (Model Driven Engineering), pois os modelos criados são utilizados como artefatos primários. Todas as transformações realizadas entre metamodelos caracterizam transformações MDA, a mais famosa iniciativa MDE. Na próxima subseção serão sistematicamente analisadas todas as transformações realizadas entre metamodelos. 4.1 Análise das transformações A figura 24 representa as transformações sofridas pelo metamodelo ECore no processo de criação do editor gráfico. Nessa figura, o conjunto dos retângulos ocos representa o editor; os retângulos cheios, os (meta)modelos intermediários; as setas numeradas representam as transformações; as setas simples, a adição de informações extras à transformação e as elipses simbolizam informações adicionais necessárias à transformação em questão. Informações adicionais 74

75 que dizem respeito à interação com o usuário no processo semi automático de transformação são estereotipadas com IA e numeradas. Considerou se o metamodelo ECore inicial como um PIM e o Eclipse como plataforma. De fato, o metamodelo ECore é independente do Eclipse, e o único modelo capaz de prover a implementação do editor é o modelo GMFGen, adicionando se as Classes Java e IA 6 ao mesmo e, supondo se que o Código Java e Edit já foram construídos. Esse conjunto será considerado o PSM. A primeira transformação, representada na figura 23, foi realizada de um metamodelo ECore para um modelo Gen. Nessa transformação, a informação adicional IA 1 se refere à escolha de um package no modelo ECore, onde escolheu se UMLPlus, o único package do arquivo. As marcas OCL dizem respeito à especificação de meta atributos derivados (seção 3.6) e métodos implementados em algumas metaclasses, com o objetivo de facilitar a escrita das restrições OCL no framework GMF (seção 3.5). Figura 23: 1ª, 2ª e 3ª transformações. A segunda e a terceira transformações, também representadas na figura 23, são as transformações que geram o código Java e o Edit. Elas utilizam templates JET (Java Emitter Templates) [ modeling/m2t/?project=jet] para tratamento das marcas OCL no framework EMF e, necessitam que o usuário adicione algumas informações ao modelo Gen, como nomes de variáveis para utilização dos templates e a localização do mesmo. Essas informações são representadas pelo bloco IA 2. Feito isso, criou se um projeto GMF e foram realizadas novas transformações. 75

76 Código Java Edit Templates JET 3 2 IA 2 Modelo Gen 1 Modelo ECore 6 IA 5 IA IA 3 Modelo GMFGraph IA 1 Modelo GMFTool Modelo GMFMap 7 Modelo GMFGen 8 Classes Java IA 6 Código do Editor Gráfico Figura 24: Diagrama das transformações do metamodelo. 76

77 A quarta transformação está representada na figura 25 e é a criação do modelo GMFGraph. Nessa transformação, é necessário indicar manualmente quais metaclasses ou meta atributos serão nós, conexões ou rótulos. Também, definiu se manualmente os rótulos que representarão os estereótipos definidos nos frameworks do cap. 6 e as figuras que decorarão as extremidades de algumas relações. Todas essas informações são representadas pelo bloco IA 3. A quinta transformação, representada na figura 26, é a criação do modelo GMFTool, que define a estrutura da barra de ferramentas do editor. Nessa transformação, novamente precisa se indicar, manualmente, quais metaclasses ou meta atributos serão nós ou conexões. Ainda foram criadas categorias distintas de ferramentas. Essas informações são representadas pelo bloco IA 4. Figura 25: 4ª transformação. Figura 26: 5ª transformação. A sexta transformação é a criação do modelo GMFMap e está representada na figura 27. Essa transformação utiliza os modelos ECore, GMFGraph e GMFTool, além de algumas informações adicionais, representadas pelo bloco IA 5. Nessa transformação é necessário indicar qual metaclasse do metamodelo ECore será o elemento raiz. Essa metaclasse precisa estar relacionada com todos as metaclasses que poderão ser instanciadas no editor, e os meta meta atributos Containment (ou seja, Containment é um atributo definido na linguagem ECore) das meta relações supracitadas deverão estar com o valor true. Também é indicado, manualmente, quais metaclasses ou meta atributos serão nós, conexões ou rótulos. É nesse modelo que são escritas as restrições OCL. Figura 27: 6ª transformação. 77

78 A sétima transformação é automática e, a partir do modelo GMFMap, gera o modelo GMFGen, como mostrado na figura 28. Figura 28: 7ª transformação. A oitava e última transformação é mostrada na figura 29. Nessa transformação, precisa se marcar manualmente os campos Validation Enabled, Validation Decorators e Live Validation UI Feedback do modelo GMFGen com true para habilitar o framework MDT de validação das restrições OCL. Essas informação adicionais são representadas pelo bloco IA 6. Também é necessário colocar as classes Java responsáveis por desenhar as decorações, já mencionadas, junto ao código gerado do editor, para que o mesmo se torne funcional. Figura 29: 8ª transformação Estudo de Caso De posse do editor, como um estudo de caso, foi modelado o exemplo da figura 30, retirado da seção 8.4 de [Guizzardi, 2005], que mostra a união de várias ontologias de domínio. A figura 31 ilustra esse exemplo, modelado no editor recém construído. Nota se que não pôde se modelar no editor os atributos de LocationCoordinates. Isso deve se ao fato de o metamodelo da figura 22, utilizado como sintaxe abstrata da linguagem utilizada para modelagem no editor, não contemplar todo o metamodelo UML 2.0, e sim uma parte, revisada, do mesmo. 78

79 Figura 30: Exemplo de ontologia de domínio. 79

80 Figura 31: Ontologia de domínio construída no editor. 80

81 Abaixo, na figura 32, mostra se outro exemplo, no qual é ilustrada a ocorrência de uma violação em tempo real da restrição CharacterizationRestrição1, que impõe que uma relação «characterization» deve sempre partir de um «mode». Essa violação ocorreu porque, no exemplo, tentou se construir uma relação «characterization» de um «mixin» para um «kind». Figura 32: Exemplo de validação em tempo real. A figura 33 mostra um modelo cuja validação foi realizada manualmente. Feita a validação, um ícone surge no «collective» à esquerda, indicando que o mesmo viola a restrição CollectiveRestrição1. Essa restrição impõe que todas as relações de sub coleção de uma coleção marcada com {extencional devem ser essenciais, ou seja, devem ser marcadas com {essencial. Uma das relações de sub coleção é marcada com {immutable part, mas essa característica não é tão estrita quanto {essencial. De fato, toda relação marcada com {essencial é {immutable part e toda relação marcada com {inseparable é {immutable whole, o que dispensa a visualização desses últimos meta atributos quando a relação for {essencial ou {inseparable, respectivamente. Porém a relação inversa não é necessariamente verdadeira. No «collective» à direita, não há violação dessa restrição, pois todas as relações de sub coleção são essenciais. 81

82 Figura 33: Exemplo de validação manual. 82