Uma Ferramenta baseada em Modelos para Modelagem Conceitual ontologicamente bem fundada

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: 2002102326

Período: 2007/1

Uma Ferramenta baseada em Modelos para  Modelagem Conceitual ontologicamente bem­

fundada

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

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

à 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 

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. 

"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

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,    UFO,   MDA,   UML, 

OCL, Eclipse, EMF, GMF, MDT.     

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.

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

Lista de Tabelas

Tabela 1: Especificação de operações...70

Tabela 2: Especificação de derivações...71

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).

Sumário

1. Introdução...15

1. Estrutura da monografia...16

2. Pressupostos Teóricos...18

1. Da (meta)Modelagem...18

1. Da Modelagem...18

1. Níveis de maturidade de modelagem...18

1. Nível 0: Nenhuma especificação...18

2. Nível 1: Textual...19

3. Nível 2: Texto com diagramas...19

4. Nível 3: Modelos com texto...19

5. Nível 4: Modelos precisos...20

6. Nível 5: Somente modelos...20

2. Da Metamodelagem...20

2. MDA...21

1. Conceitos Básicos...21

2. Transformações MDA...24

1. Mapeamentos...24

1. Mapeamento entre tipos...24

2. Mapeamento em nível de instâncias...25

3. Combinação das duas formas de mapeamento anteriores...25

4. Templates...25

2. Métodos de Transformação...25

1. Marcação...26

2. Transformação entre Metamodelos...26

3. Aplicação de Padrões...27

3. Graus de Automação e Suporte Computacional...28

1. Transformação Manual...28

2. Transformação de um PIM preparado por um perfil...29

3. Transformação utilizando Padrões e Marcas...29

4. Transformações Automáticas...29

3. Outras Capacidades MDA...30

1. Múltiplas Aplicações das Transformações MDA...30

2. Transformações Gerais Modelo para Modelo...34

3. Reuso de Mapeamentos...34

1. Extensão...34

2. Combinação...35

3. OCL...36

1. Propriedades da linguagem OCL...36

2. Aplicação em diagramas de classe...37

1. Regras de derivação...38

2. Valores Default...38

3. Especificação de operações de consulta...39

4. Invariantes...39

5. Pré­condições e pós­condições...39

6. Mensagens em pós­condições...40

7. Definição de classes derivadas...40

8. Multiplicidade dinâmica...40

9. Multiplicidade opcional...40

10. Restrições ou...41

3. Estilos de modelagem...41

1. Definição de atributos ou operações...41

2. A restrição de subconjunto...42

3. Herança X Invariantes...42

4. MDA, UML e OCL...44

1. Modelagem com UML/OCL...44

2. Metamodelagem com UML/OCL...45

3. Transformações definidas com UML/OCL...45

5. Metamodelagem utilizando­se o Eclipse...46

1. MOF...47

2. EMF...47

3. GMF...47

3. Das Limitações da Modelagem Conceitual Utilizando­se UML 2.0...49

1. Classes e Generalização...49

2. Classificadores e Propriedades...56

3. Agregação e Composição...63

4. Invariantes adicionais...69

5. Definição de métodos em OCL...70

6. Definição de meta­atributos/meta­associações derivados...71

4. Construção e Uso da Ferramenta de Modelagem...72

1. Análise das transformações...74

2. Estudo de Caso...78

5. Conclusão...83

1. Das dificuldades...83

2. Trabalhos futuros...85

6. Referências...86

7. Apêndice 1: XML's...87

1. Código do metamodelo ECore...87

2. Código do modelo Gen...92

3. Código do modelo GMFGraph...96

8. Apêndice 2: Códigos Java das decorações...144

1. Código Java para a implementação da metaclasse Collective...144

2. Código Java para a implementação da metaclasse GeneralizationSet...149

3. Código Java para a implementação das relações...155

1. SubQuantityOfCustomFigure.java...155

2. SubQuantityOfEditPart.java...157

3. GeneralizationCustomFigure.java...161

4. DerivationCustomFigure.java...162

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) [http://www.uml.org], 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   [http://download. 

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 [http://www.eclipse.org].

Nessa  monografia  também  é  abordado  o  framework  MDA (Model­Driven  Architecture)  [http://www.omg.org/mda], 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 

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. 

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. 3.

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. 

2.1. Da (meta)Modelagem 2.1.1. 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.

2.1.1.1. 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.

2.1.1.1.1. 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 

●

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.

2.1.1.1.2. 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.

2.1.1.1.3. 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 2.

2.1.1.1.4. 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 

influência na arquitetura do sistema.

2.1.1.1.5. 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.

2.1.1.1.6. 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. 

2.1.2. 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.

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.

2.2.1. 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 

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 

●

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.

Figura 2: Transformação de modelo.

2.2.2. 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.  

2.2.2.1. 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.

2.2.2.1.1.  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 

Metamodelos.

2.2.2.1.2.  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.

2.2.2.1.3. 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.  

2.2.2.1.4. 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.

2.2.2.2. 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.

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.

2.2.2.2.1. 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. 

2.2.2.2.2. Transformação entre Metamodelos

O PIM é preparado utilizando­se uma linguagem independente de plataforma, e especificada 

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.

2.2.2.2.3. 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.

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.

2.2.2.3. 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.

2.2.2.3.1. 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 

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.

2.2.2.3.2. 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.

2.2.2.3.3. 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.

2.2.2.3.4. 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 

mapeamento do PIM para essa arquitetura. 

2.2.3 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.

2.2.3.1 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.

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.

Figura 10: PIM, PSM, aplicação e plataforma.

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

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 

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.

2.2.3.2 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.

2.2.3.3. Reuso de Mapeamentos

Mapeamentos podem ser reusados por meio de extensão e combinação.

2.2.3.3.1. 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 

 critério proíbe a supressão de propriedades dos mapeamentos base, a herança é dita estrita.

2.2.3.3.2. 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.

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.

2.3.1. 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.

2.3.1.1. 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. 

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 2.3.2.

2.3.1.2. 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. 

2.3.1.3. 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.

2.3.2. 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.

2.3.2.1. 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:

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.

2.3.2.2. 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 

2.3.2.3. 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()

2.3.2.4. 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 2.3.2.5. 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 operador @pre é 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. 

2.3.2.6. 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

2.3.2.7. 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. 

2.3.2.8. 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() 2.3.2.9 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.