Você está na página 1de 111

FELIPE DE LUCA MEDEIROS

Metamodelagem com Meta Object Facility

FLORIANPOLIS
2004

FELIPE DE LUCA MEDEIROS

Metamodelagem com Meta Object Facility

Relatrio Final do trabalho para a concluso do curso de Bacharelado em Cincias da


Computao da Universidade Federal de Santa Catarina.

Orientador: Prof. Dr. Joo Bosco Mangueira Sobral, INE/CTC/UFSC

Membros da Banca:
Prof. Ph.D. Frank Augusto Siqueira, INE/CTC/UFSC
Profa. Carla Adriana Barvinski Zanchett, CPGCC/UFSC

FLORIANPOLIS
2004

Dedico aos meus pais,


aos meus amigos e a minha
namorada Aline pelo apoio e
compreenso nos momentos de
grande
trabalho.

ocupao

com

este

O que fazemos durante


as horas de trabalho determina
o que temos; o que fazemos
nas horas de lazer determina o
que somos.
Charles Schulz

RESUMO
O MDA (Model Driven Architeture) promove ganhos de produtividade para o ciclo de
vida de desenvolvimento de um sistema de software, agregando a capacidade de
gerao automtica de cdigo a partir de modelos formais independentes de
plataforma. Este processo viabilizado pelo ncleo do MDA, a linguagem de
metamodelagem MOF (Meta Object Facility), que oferece facilidades para lidar com
metaobjetos, que so objetos capazes de representar metadados. Este trabalho
compreende um estudo do MOF, uma anlise de suas vantagens e desvantagens,
das principais tecnologias relacionadas e de um caso real de uso do MOF.
Palavras-chaves: MOF, MDA, modelos

ABSTRACT
MDA (Model Driven Architecture) provides productivity gains for software system
development life cycle, allowing automatic generation of code from plataform
independent formal models. This process is enabled by the MDA core, the
metamodeling language MOF (Meta Object Facility), that offers facilities to cope with
metaobjects, that are objects that can represent metadata. This thesis comprises a
study of MOF, a analisys of its advantages and disadvantages, of its major related
technologies and of a real use case of MOF.
Keywords: MOF, MDA, models

SUMRIO
1 INTRODUO E JUSTIFICATIVA...........................................................................1
1.1 Objetivo Geral .......................................................................................................2
1.2 Objetivos Especficos ............................................................................................2
1.3 Justificativa............................................................................................................3
1.4 Organizao do Trabalho ......................................................................................3
2 MDA (MODEL DRIVEN ARCHITECTURE)..............................................................4
2.1.1 O Problema da Produtividade ............................................................................5
2.1.2 O Problema da Portabilidade .............................................................................6
2.1.3 O Problema da Interoperabilidade......................................................................7
2.1.4 O Problema da Manuteno e Documentao...................................................7
2.2 A Arquitetura Dirigida a Modelo.............................................................................7
2.2.1 Conceitos Bsicos ..............................................................................................8
2.2.1.1 Sistema ...........................................................................................................8
2.2.1.2 Modelo.............................................................................................................8
2.2.1.3 Dirigido a Modelo (Model-Driven) ....................................................................9
2.2.1.4 Arquitetura.......................................................................................................9
2.2.1.5 Ponto de Vista .................................................................................................9
2.2.1.6 Viso ...............................................................................................................9
2.2.1.7 Plataforma .......................................................................................................9
2.2.1.8 Independncia de Plataforma........................................................................10
2.2.1.9 Ponto de Vista Computacionalmente Independente .....................................10
2.2.1.10 Ponto de Vista Independente de Plataforma ...............................................10
2.2.1.11 Ponto de Vista Especfico de Plataforma ....................................................10
2.2.1.12 Modelo de Plataforma .................................................................................10
2.2.2 O Ciclo de Vida de Desenvolvimento MDA ......................................................11
2.2.2.1 Modelo Independente de Plataforma.............................................................11
2.2.2.2 Modelo Especfico de Plataforma..................................................................12
2.2.2.3 Cdigo ...........................................................................................................12
2.2.2.4 Vantagens dos Modelos ................................................................................12
2.2.3 Automao das Etapas de Transformao ......................................................13
2.3 Benefcios do MDA..............................................................................................13
2.3.1 Produtividade ...................................................................................................13
2.3.2 Portabilidade ....................................................................................................14
2.3.3 Interoperabilidade.............................................................................................14
2.3.4 Manuteno e Documentao..........................................................................15
2.3.5 Elementos Fundamentais do MDA...................................................................16
2.4 A Estrutura do MDA ............................................................................................16
2.4.1 Modelo..............................................................................................................16
2.4.1.1 Relaes Entre Modelos ...............................................................................18
2.4.2 Tipos de Modelos .............................................................................................18
2.4.2.1 Modelos de Domnio e de Software...............................................................19
2.4.2.2 Modelos Estruturais e Dinmicos ..................................................................20
2.4.2.3 Modelos Independentes de Plataforma e Especficos de Plataforma ...........22
2.4.2.4 As Plataformas-Alvo de um Modelo ..............................................................22
2.4.3 Transformaes ...............................................................................................22
2.4.3.1 Transformaes entre Linguagens Idnticas.................................................24
2.4.4 A Estrutura Bsica do MDA..............................................................................24
2.5 Caractersticas Desejveis em Transformaes .................................................25

2.5.1 Ajustabilidade ...................................................................................................25


2.5.1.1 Controle Manual ............................................................................................26
2.5.1.2 Condies sobre Transformaes.................................................................26
2.5.1.3 Parmetros de Transformao......................................................................26
2.5.1.4 Informao Adicional .....................................................................................26
2.5.2 Rastreabilidade ................................................................................................27
2.5.3 Consistncia Incremental .................................................................................27
2.5.4 Bidirecionalidade ..............................................................................................28
3 METAMODELAGEM ..............................................................................................30
3.1 As Quatro Camadas definidas pela OMG ...........................................................31
3.1.1 Camada M0: As Instncias...............................................................................32
3.1.2 Camada M1: O Modelo do Sistema .................................................................32
3.1.3 Camada M2: O Modelo do Modelo...................................................................33
3.1.4 Camada M3: O Modelo do M2 .........................................................................34
3.1.5 Anlise das Camadas.......................................................................................36
3.2 Metamodelagem e o MDA...................................................................................36
3.2.1 A Estrutura Completa do MDA .........................................................................37
4 MOF .......................................................................................................................38
4.1 Viso Geral..........................................................................................................38
4.1.1 A Origem do MOF ............................................................................................38
4.1.1.1 Uma Premissa Adicional ...............................................................................39
4.1.2 Ferramentas MOF ............................................................................................39
4.1.2.1 A Interface de Repositrio MOF ....................................................................39
4.1.2.2 Intercmbio de Modelos ................................................................................40
4.1.3 A Funo do MOF no MDA ..............................................................................40
4.2 Terminologia........................................................................................................40
4.2.1 O Prefixo Meta .................................................................................................41
4.3 Caractersticas da Linguagem.............................................................................42
4.3.1 Garantindo a Corretude da Semntica .............................................................42
4.3.2 Notao Grfica ...............................................................................................42
4.3.3 A Orientao a Objeto em MOF .......................................................................43
4.3.4 Auto-Descrio.................................................................................................43
4.3.4.1 Implicaes da Auto-Descrio do MOF .......................................................44
4.3.5 Implementaes Genricas de MOF................................................................45
4.4 O Modelo MOF Construtores de Modelagem...................................................46
4.4.1 Classes (em ingls, tambm Classes) .............................................................48
4.4.1.1 Atributos (Attributes)......................................................................................49
4.4.1.2 Operaes (Operations) ................................................................................49
4.4.1.3 Escopo dos Atributos e Operaes ...............................................................50
4.4.1.4 Multiplicidades de Atributos e Parmetros ....................................................50
4.4.1.5 Generalizao de Classe ..............................................................................51
4.4.1.6 Classes Abstratas (Abstract Classes) ...........................................................52
4.4.1.7 Classes Folha (Leaf) e Raiz (Root) ...............................................................52
4.4.2 Associaes (Associations)..............................................................................52
4.4.2.1 Extremidades de Associao (Association Ends) .........................................52
4.4.2.2 Multiplicidades de Extremidade de Associao.............................................53
4.4.3 Agregao (Aggregation) .................................................................................53
4.4.3.1 Semntica da Agregao ..............................................................................54
4.4.3.2 Agregao de Associao.............................................................................54
4.4.3.3 Agregao de Atributo...................................................................................55

4.4.4 Referncias (References).................................................................................55


4.4.5 Tipos de Dados (DataTypes)............................................................................57
4.4.6 Pacotes ............................................................................................................58
4.4.6.1 Generalizao de Pacotes (Generalization Packages) .................................58
4.4.6.2 Aninhamento de Pacote (Package Nesting)..................................................59
4.4.6.3 Importao de Pacotes (Package Importing) ................................................59
4.4.6.4 Agrupamento de Pacotes (Package Clustering)............................................60
4.4.6.5 Sumrio dos Construtores de Pacotes ..........................................................61
4.4.7 Restries (Constraints) e Consistncia (Consistency)....................................62
4.4.7.1 Restries .....................................................................................................62
4.4.7.2 Consistncia Estrutural..................................................................................63
4.4.7.3 Mecanismos de Checagem de Consistncia.................................................63
4.4.8 Demais Construtores de Modelagem ...............................................................64
4.4.8.1 Constantes (Constants).................................................................................64
4.4.8.2 Excees (Exceptions) ..................................................................................64
4.4.8.3 Etiquetas (Tags) ............................................................................................64
4.5 Cenrios de Uso do MOF....................................................................................65
4.6 Anlise de Tecnologias Correlatas ao MOF ........................................................66
4.6.1 Anlise do CORBA frente ao MOF...................................................................67
4.6.1.1 MOF no Baseado em CORBA..................................................................67
4.6.1.2 Mapeamento alm da Sintaxe.......................................................................67
4.6.1.3 O Mapeamento MOF-CORBA.......................................................................68
4.6.2 Anlise do XMI .................................................................................................68
4.6.2.1 Funcionamento do XMI .................................................................................69
4.6.2.2 XMI e XML Schema.......................................................................................70
4.6.2.3 Uma Falsa Crena sobre o XMI ....................................................................70
4.6.2.4 Gerao Manual e Automtica de DTDs e Schemas ....................................71
4.6.2.5 XMI e UML ....................................................................................................71
4.6.2.6 XMI e o Intercmbio de Diagramas UML.......................................................72
4.6.3 Anlise do JMI..................................................................................................72
4.7 Aplicaes Adicionais..........................................................................................72
4.7.1 HUTN (Human Usable Textual Notation) .........................................................73
4.7.2 Mapeamento Reverso de XMI..........................................................................73
4.8 Desvantagens .....................................................................................................74
4.8.1 Falta de Suporte a Notao Grfica .................................................................74
4.8.2 Desalinhamento com UML ...............................................................................74
4.8.3 Problemas de Mapeamento MOF-CORBA.......................................................75
4.8.4 Problemas de Interoperabilidade......................................................................75
4.9 Vantagem Principal .............................................................................................75
4.10 Futuro do MOF ..................................................................................................75
5 CASO REAL DE USO DO MOF: PARLAY.............................................................76
5.1 O Middleware Parlay ...........................................................................................77
5.2 Relao entre Parlay, MDA e MOF .....................................................................80
6 CONCLUSES ......................................................................................................82
7 REFERNCIAS BIBLIOGRFICAS .......................................................................86
GLOSSRIO .............................................................................................................87
ANEXO ARTIGO ....................................................................................................90

LISTA DE FIGURAS
Figura 1 Ciclo de vida de desenvolvimento de software tradicional (WARMER,
2003) ....................................................................................................................5
Figura 2 Ciclo de vida do desenvolvimento de software MDA (WARMER, 2003) ..11
Figura 3 Interoperabilidade do MDA usando pontes (baseado em WARMER, 2003)
...........................................................................................................................15
Figura 4 Modelos e Linguagens (WARMER, 2003)................................................17
Figura 5 Modelos de Domnio e de Software (baseado em WARMER, 2003) .......19
Figura 6 Diferentes vises de um sistema em um modelo UML (WARMER, 2003)
...........................................................................................................................20
Figura 7 Diferentes modelos de um mesmo sistema especificados por linguagens
diferentes (WARMER, 2003)..............................................................................21
Figura 8 Definies de transformaes dentro das ferramentas de transformao
(WARMER, 2003) ..............................................................................................22
Figura 9 Definies de transformao so definidas entre linguagens (baseado em
WARMER, 2003)................................................................................................23
Figura 10 Viso geral da estrutura bsica do MDA (baseado em WARMER, 2003)
...........................................................................................................................24
Figura 11 Transformao bidirecional (WARMER, 2003) ......................................28
Figura 12 Metalinguagens, metamodelos, linguagens e modelos (WARMER, 2003)
...........................................................................................................................31
Figura 13 Metalinguagens, linguagens e modelos (WARMER, 2003)....................31
Figura 14 Relaes entre as camadas M0 e M1 (baseado em WARMER, 2003)..33
Figura 15 Relaes entre as camadas M2 e M1 (baseado em WARMER, 2003)..33
Figura 16 Relaes entre as camadas M3 e M2 (baseado em WARMER, 2003)..34
Figura 17 Viso geral das quatro camadas (baseado em WARMER, 2003)..........35
Figura 18 Relaes entre os conjuntos M3, M2, M1 e M0 (WARMER, 2003)........36
Figura 19 A estrutura completa do MDA, incluindo a metalinguagem (baseado em
WARMER, 2003)................................................................................................37
Figura 20 O Pacote do Modelo MOF (OMG, 2002)................................................48
Figura 21 Exemplo de uma Referncia (OMG, 2002) ............................................56
Figura 22 Esquema de funcionamento do XMI ......................................................70
Figura 23 Desenvolvimento tradicional de aplicaes em redes de
telecomunicaes (FARSHCHIAN, 2004) ..........................................................78
Figura 24 Desenvolvimento de aplicaes em redes de telecomunicaes usando
o Parlay (baseado em FARSHCHIAN, 2004).....................................................78
Figura 25 Arquitetura do Parlay (FARSHCHIAN, 2004) .........................................79
Figura 26 Desenvolvimento baseado em MDA de aplicaes que usam Parlay
(baseado em FARSHCHIAN, 2004)...................................................................81

LISTA DE TABELAS
Tabela 1 Quadro comparativo das quatro camadas do MDA.................................35
Tabela 2 Termos equivalentes (termos numa mesma linha referem-se a conceitos
iguais).................................................................................................................42
Tabela 3 Propriedades de um Atributo (OMG, 2002) .............................................49
Tabela 4 Propriedades de uma Operao (OMG, 2002)........................................49
Tabela 5 Propriedades de Extremidades de Associao (OMG, 2002) .................52
Tabela 6 Construtores de Pacotes (OMG, 2002) ...................................................61

1 INTRODUO E JUSTIFICATIVA
O processo utilizado atualmente para o desenvolvimento de sistemas de
software ainda muito dependente de tecnologias especficas. Sistemas altamente
dependentes de tecnologia tendem a tornarem-se obsoletos mais cedo ou mais
tarde, devido grande volatilidade e ao rpido avano da tecnologia na rea da
informtica que se sucede nos dias de hoje. Estes sistemas, ao necessitarem serem
migrados para uma nova tecnologia para melhor atender as suas demandas, tm de
passar novamente pela massiva etapa de implementao de cdigo.
Esta alta dependncia de tecnologia que se d no desenvolvimento de
sistemas de software tambm faz com que o poder de reusabilidade recaia
demasiadamente. Os componentes estruturais de um sistema desenvolvido para um
determinado domnio, com uma determinada tecnologia, no podem ser reutilizados
em um outro sistema a ser desenvolvido para o mesmo domnio, caso este sistema
seja implementado em uma tecnologia diferente. Implementaes inteiras de cdigo
precisam ser refeitas e reescritas mo na maioria dos casos onde um sistema
precisa ser desenvolvido.
Outro

problema

que

pode

ser

levantado

no

atual

processo

de

desenvolvimento de sistemas de software a falta de interoperabilidade entre


sistemas distintos que precisem se comunicar uns com os outros. Outro
inconveniente a falta de sincronia freqentemente existente entre a documentao
do software e a sua real implementao. Como os requisitos mudam no decorrer do
desenvolvimento, a documentao do sistema acaba ficando desatualizada.
Para

tentar

acabar

com

estes

inconvenientes

no

processo

de

desenvolvimento de software, e para oferecer tcnicas que auxiliem em todo o ciclo


de vida de um software, a OMG (Object Managament Group) uma organizao
sem fins lucrativos que tem como objetivo especificar padres voltados aplicaes
interoperveis para a indstria de computadores desenvolveu uma nova
arquitetura de desenvolvimento chamada MDA (Model Driven Architecture). Esta
arquitetura, como o prprio nome diz, dirigida a modelos, i.e., os modelos
compem o bloco fundamental de desenvolvimento de sistemas de software nesta
arquitetura. Os modelos a serem utilizados neste processo inovador satisfazem a
algumas propriedades, as quais viabilizam uma grande independncia tecnolgica

na criao e manuteno do sistema. Alm disto, os modelos so fortemente interrelacionados e coesos porque as linguagens usadas para a criao deles so
definidas por uma linguagem nica e comum a todas as outras linguagens de
modelagem, chamada MOF (Meta Object Facility). Como o MDA uma arquitetura
dirigida a modelos, e todos os modelos possuem como ponto em comum o MOF,
esta linguagem o ncleo do MDA.
Devido existncia desta tecnologia de modelagem comum a todas as
outras, possvel fazer com que sistemas totalmente independentes um do outro
possam interoperar. possvel fazer com que repositrios de modelos de empresas
diferentes intercambiem seus modelos. E a mais revolucionria e inovadora
conseqncia deste processo que, como todas as linguagens de modelagem
baseadas na arquitetura MDA possuem um forte ponto em comum, a linguagem
MOF, possvel gerar automaticamente cdigo para plataformas com tecnologias
distintas a partir de um nico modelo independente de plataforma.
1.1 Objetivo Geral
O presente trabalho tem como intuito fundamental expor um estudo
aprofundado da linguagem de metamodelagem MOF, bem como a anlise das
vantagens e desvantagens de seu uso, demonstrar como ela pode ser usada, e
em que casos esta tecnologia pode ser aplicada.
1.2 Objetivos Especficos
Este trabalho possui como objetivos especficos:

Fornecer uma viso geral do processo de desenvolvimento de sistemas de


software baseados na arquitetura MDA;

Analisar as vantagens, desvantagens, e as conseqncias do uso do


MOF;

Analisar as tecnologias CORBA, XMI e JMI em frente ao MOF;

Analisar os principais construtores de metamodelagem do MOF;

Analisar um caso real de uso do MOF, o middleware Parlay.

1.3 Justificativa
A utilizao e divulgao das tcnicas de desenvolvimento de sistemas de
software baseadas na arquitetura MDA ainda no so largamente difundidas, e
conseqentemente a linguagem de metamodelagem MOF tambm no . Este
trabalho, portanto, visa introduzir os conceitos fundamentais do MDA, e em seguida
apresentar o MOF de forma a mostrar atravs de exemplos e casos reais onde ele
pode ser usado efetivamente.
O estudo aprofundado da linguagem MOF, junto com uma apresentao geral
da arquitetura MDA, e uma mostra de casos reais de uso contribuir para a
exposio destas tecnologias no difundidas, de forma crtica e comparativa, atravs
da anlise das vantagens e desvantagens em cada caso.
1.4 Organizao do Trabalho
O trabalho est dividido em cinco captulos. O primeiro captulo composto
pela presente Introduo. O segundo captulo descreve a arquitetura MDA,
descrevendo seu ciclo de vida bsico de desenvolvimento e seus benefcios.
Descreve tambm a estrutura do MDA, analisando o conceito de modelo e alguns
tipos especiais de modelos. Trata tambm das transformaes e suas caractersticas
desejveis, como rastreabilidade e bidirecionalidade.
O terceiro captulo tece o conceito de metamodelagem e apresenta a
estrutura de quatro camadas adotada pela OMG.
O enfoque do quarto captulo o MOF. Seus benefcios so descritos, seu
campo de aplicabilidade, seus pontos fortes e fraquezas, e os construtores de
modelagem do MOF, que funcionam como os elementos mnimos de modelagem e
construo desta linguagem. Tambm h uma anlise das principais tecnologias
relacionadas com o MOF, como o CORBA, XMI e JMI.
No quinto captulo ser apresentado um exemplo de caso real de uso do
MOF, onde o middleware Parlay, utilizado na rea de telecomunicaes,
analisado.

2 MDA (MODEL DRIVEN ARCHITECTURE)


Atualmente, muito do desenvolvimento de software comparado com o
desenvolvimento de hardware. As conquistas e descobertas no campo do
desenvolvimento de hardware geralmente acalentam grande alarde, ocorrem com
freqncia, e so facilmente divulgadas pela mdia. Porm, avanos no campo de
desenvolvimento de software no ocorrem to freqentemente e nem so to
divulgados, dando a falsa impresso de que nesta rea nenhum tipo de avano
ocorre. Pelo contrrio, progressos nessa rea tambm ocorrem e vm ocorrendo
cada vez mais, porm no so to fceis de serem medidos em termos de
velocidade e custos quanto os da rea de desenvolvimento de hardware .
O que mais evidente no campo de desenvolvimento de software so os
avanos no sentido de que muito mais praticvel e gerencivel o desenvolvimento
de sistemas grandes e complexos. Atualmente, o desenvolvimento de sistemas
deste porte conta com o suporte de inmeras linguagens de modelagem que
auxiliam no controle e gerenciamento de projetos deste tipo, sem contar nas
inmeras linguagens de programao que existem no mercado, possibilitando que o
sistema a ser construdo utilize uma ou mais tecnologias, de acordo com a parte do
sistema que se estiver modelando.
Embora o desenvolvimento de software venha passando por considerveis
avanos, ainda existem muitos problemas a serem solucionados. A volatilidade de
tecnologias faz com que muito do trabalho que j foi feito tenha que ser feito
novamente. Sistemas nunca so escritos usando somente uma tecnologia e
sistemas sempre precisam se comunicar com outros sistemas (WARMER, 2003).
H tambm o problema de que os requisitos de um software continuamente
mudam durante seu desenvolvimento.
A OMG, ento, vem tentando entrar em cena com uma tecnologia que
promete mudar o paradigma de desenvolvimento de software. Esta tecnologia uma
nova arquitetura de desenvolvimento, chamada MDA (Model Driven Architecture, ou
Arquitetura Dirigida a Modelo).

2.1.1 O Problema da Produtividade


O processo de desenvolvimento de software como o concebemos hoje
baseado em modelos e implementao de baixo-nvel. Um processo tpico incluiria
as seguintes fases (as quais so ilustradas na figura 1):

Anlise de requisitos;

Anlise funcional;

Modelagem;

Implementao;

Teste;

Implantao.

Figura 1 Ciclo de vida de desenvolvimento de software tradicional (WARMER, 2003)

Um problema comum neste ciclo de vida de desenvolvimento de software


tradicional que os diagramas e textos produzidos nas trs primeiras fases
frequentemente perdem o seu valor to rpido quanto a fase de implementao
inicia. A conexo que idealmente deveria existir entre o cdigo e seus respectivos
modelos acaba se tornando cada vez mais fraca a medida em que a fase de
implementao avana, principalmente porque seria um processo altamente rduo, e
que considerado perda de tempo, atualizar os modelos concebidos nas primeiras
fases quando, na fase de implementao, ocorrem mudanas de requisitos.
Freqentemente os programadores alteram somente o cdigo, deixando cada vez
mais os modelos obsoletos e com baixo poder de representao sobre o cdigo
implementado.

Um tpico importante deste problema de que a abordagem de preocupar-se


somente com a implementao, deixando de lado por completo a fase de
modelagem invibializa no futuro uma manuteno eficiente. Apesar de que os
programadores geralmente consideram escrever cdigo como uma tarefa produtiva
e

escrever

modelos

ou

documentao

uma

tarefa

no

produtiva,

num

desenvolvimento de software maduro estas tarefas precisam ser feitas.


2.1.2 O Problema da Portabilidade
No mundo da informtica, outro grande problema na rea de desenvolvimento
de software que distingue esta indstria de indstrias de muitas outras reas o fato
de que novas tecnologias surgem constantemente com cada vez mais freqncia
(como por exemplo Java, Linux, XML, HTML, SOAP, UML, J2EE, .NET, JSP, ASP,
Flash, Web Services, e assim por diante).
Ao surgir uma nova tecnologia, as empresas geralmente precisam aderir a
ela. Dentre os motivos pelos quais elas precisam aderir s novas tecnologias tem-se
(WARMER, 2003):

A tecnologia demandada pelos consumidores;

A tecnologia resolve problemas antes insolveis, agregando mais fora


empresa;

Vendedores de ferramentas param de dar suporte a velhas tecnologias e


concentram seu enfoque somente nas novas.

Estas novas tecnologias, apesar de poderem trazer benefcios empresa,


implicam numa complexa operao de migrao para a nova tecnologia. Como
conseqncia, muito do investimento realizado na velha tecnologia perde o seu
valor. A situao ainda mais complexa porque algumas vezes a prpria tecnologia
pode ser alterada, como quando ela troca de verso.
Nos casos onde o software existente no migrado para as novas
tecnologias e se torna obsoleto, um outro problema surge. Este sistema muitas
vezes precisar interoperar com novos sistemas que utilizam novas tecnologias.

2.1.3 O Problema da Interoperabilidade


Sistemas de software freqentemente necessitam comunicar-se uns com os
outros, e esta imensa gama de tecnologias impe uma barreira interoperabilidade
dos sistemas.
Ao longo dos anos observou-se que no se deve construir gigantescos
sistemas monolticos. Ao invs disso, deve-se construir sistemas modularizados em
componentes independentes que se comunicam entre si. Cada um destes
componentes ento criado com a melhor tecnologia que se ajusta ao seu domnio.
Este emaranhado de componentes precisa de uma forma eficaz de comunicao,
criando a necessidade de interoperabilidade.
2.1.4 O Problema da Manuteno e Documentao
Uma manuteno eficiente de um sistema viabilizada principalmente se o
ele possuir uma boa documentao. Como visto anteriormente, os programadores
consideram a tarefa de documentao em um desenvolvimento de software algo
penoso e uma perda de tempo. Esta uma das principais razes pelas quais as
documentaes freqentemente no so de boa qualidade.
claro que os programadores esto errados, j que sua funo desenvolver
sistemas flexveis que possam ser alterados e que possam receber manuteno no
futuro.
Uma soluo para este tipo de problema seria um meio de gerar a
documentao diretamente a partir do cdigo-fonte. Esta tcnica suportada por
vrias linguagens de programao como Eiffel e Java, porm s resolvem o
problema da documentao de baixo-nvel. A documentao de alto nvel (textos e
diagramas) ainda precisa ser atualizada a mo. Dada a complexidade dos sistemas
que so construdos, documentao num alto nvel de abstrao absolutamente
necessria (WARMER, 2003).
2.2 A Arquitetura Dirigida a Modelo
A Arquitetura Dirigida a Modelo, ou MDA, uma arquitetura para o
desenvolvimento de software, possuindo como idia fundamental o uso de modelos
neste processo, como o prprio nome diz.

Esta idia fundamental baseia-se no consenso bem estabelecido de que


ideal separar a especificao do funcionamento de um sistema dos detalhes de
como este sistema interage com a sua plataforma.
MDA fornece uma abordagem para, e ferramentas capazes de ser usadas
para:

Especificao de um sistema independentemente da plataforma que ele


usa;

Especificao de plataformas;

Escolha de uma plataforma particular para o sistema;

Transformao da especificao do sistema para uma plataforma


especfica.

Os trs objetivos primrios do MDA so portabilidade, interoperabilidade e


reusabilidade atravs de uma separao arquitetural de entidades (MILLER, 2003).
2.2.1 Conceitos Bsicos
Esta seo apresenta os conceitos bsicos que compem o ncleo do MDA.
2.2.1.1 Sistema
Os conceitos do MDA esto relacionados sempre com algum sistema
existente ou um sistema a ser desenvolvido. Este sistema pode ser qualquer coisa:
um programa, um sistema simples de computador, alguma combinao de partes de
diferentes sistemas, uma federao de sistemas, pessoas, uma empresa, etc
(MILLER, 2003).
2.2.1.2 Modelo
Um modelo de um sistema uma descrio ou especificao do sistema e de
sua funcionalidade. Um modelo geralmente composto por uma combinao de
diagramas e textos. O texto pode ser escrito em uma linguagem de modelagem ou
uma linguagem natural (MILLER, 2003).

2.2.1.3 Dirigido a Modelo (Model-Driven)


MDA uma abordagem para desenvolvimento de sistemas, e que incrementa
o poder e influncia de modelos nesta funo. dirigido a modelo porque oferece
meios para usar os modelos de forma a dirigir a compreenso, projeto, construo,
implantao, operao, manuteno e modificao (MILLER, 2003).
2.2.1.4 Arquitetura
A arquitetura de um sistema a especificao das partes e conectores do
sistema e as regras para as interaes das partes usando os conectores (MILLER,
2003).
O MDA prescreve certos tipos de modelos a serem usados, como eles podem
ser usados e as relaes entre os diferentes tipos de modelos.
2.2.1.5 Ponto de Vista
Um ponto de vista de um sistema uma abstrao que usa um conjunto
definido de conceitos arquiteturais e regras de estruturao, com o intuito de dar
enfoque em caractersticas particulares do sistema (MILLER, 2003).
O MDA especifica trs pontos de vista sobre um sistema, um ponto de vista
computacionalmente independente, um ponto de vista independente de plataforma,
e um ponto de vista especfico de plataforma.
2.2.1.6 Viso
Um modelo de ponto de vista ou viso de um sistema uma representao
deste a partir da perspectiva de um ponto de vista escolhido (MILLER, 2003).
2.2.1.7 Plataforma
Uma plataforma em geral um conjunto de subsistemas/tecnologias que
oferece um conjunto coerente de funcionalidade atravs de interfaces e padres
definidos, de forma que qualquer subsistema que dependa dessa plataforma possa
utiliz-la sem preocupar-se com os detalhes de como sua funcionalidade foi
implementada (MILLER, 2003).

10

2.2.1.8 Independncia de Plataforma


Independncia de plataforma uma qualidade que pode ser expressa por um
modelo. Infere que o modelo independente de quaisquer caractersticas de uma
plataforma de qualquer tipo e sobre quaisquer aspectos (MILLER, 2003).
2.2.1.9 Ponto de Vista Computacionalmente Independente
O ponto de vista computacionalmente independente tem um enfoque no
domnio sobre o qual o sistema atua, e nos requisitos do sistema; informaes
estruturais e processos do sistema so ocultos ou ainda indefinidos (MILLER, 2003).
2.2.1.10 Ponto de Vista Independente de Plataforma
O ponto de vista independente de plataforma tem enfoque sobre as
operaes do sistema, abstraindo qualquer tipo de informao atrelada a uma
plataforma especfica. Uma viso independente de plataforma mostra aquela parte
do sistema que no muda de uma plataforma para outra (MILLER, 2003).
Uma viso independente de plataforma pode usar uma linguagem de
modelagem de propsito geral, ou uma linguagem especfica para a rea na qual o
sistema ser usado.
2.2.1.11 Ponto de Vista Especfico de Plataforma
Um ponto de vista especfico de plataforma complementa o ponto de vista
independente de plataforma com os detalhes de uso do sistema de uma plataforma
especfica (MILLER, 2003).
2.2.1.12 Modelo de Plataforma
Um modelo de plataforma descreve as diferentes partes que compem uma
plataforma e os servios oferecidos por ela (MILLER, 2003).

11

2.2.2 O Ciclo de Vida de Desenvolvimento MDA


Comparando o ciclo de vida de desenvolvimento MDA (o qual exibido na
figura 2) com o ciclo de vida de desenvolvimento de software tradicional, no so
encontradas muitas diferenas.

Figura 2 Ciclo de vida do desenvolvimento de software MDA (WARMER, 2003)

As mesmas fases podem ser identificadas, porm os artefatos produzidos nas


fases iniciais so muito diferentes. Estes artefatos so modelos formais, i.e.,
modelos que podem ser compreendidos por computadores, e que portanto podem
participar em processos automatizados no desenvolvimento.
Os trs modelos a seguir compem o ncleo do MDA.
2.2.2.1 Modelo Independente de Plataforma
O primeiro modelo que o MDA define um modelo com um alto nvel de
abstrao que independente de qualquer tecnologia. Este modelo chamado de
PIM (Platform Independent Model).
Em outras palavras, um modelo independente de plataforma uma viso de
um sistema a partir de um ponto de vista independente de plataforma. Um PIM deve
apresentar um grau de independncia de plataforma que seja adequado para utilizlo com um variado nmero de plataformas especficas (MILLER, 2003).
Uma tcnica comum para alcanar a independncia de plataforma orientar o
modelo de um sistema para uma mquina virtual tecnologicamente neutra. Uma
mquina virtual definida como um conjunto de partes e servios (comunicaes,

12

sincronizao, etc), os quais so definidos independentemente de qualquer


plataforma e os quais so usados de forma especfica sobre as diferentes
plataformas. Uma mquina virtual uma plataforma, e um PIM modelado sobre esta
mquina virtual especifico para esta plataforma. Porm, este PIM continua sendo
independente de plataforma no que diz respeito s diferentes plataformas sobre as
quais a mquina virtual pode ser implementada.
2.2.2.2 Modelo Especfico de Plataforma
No prximo passo, o PIM transformado em um ou mais Modelos Especficos
de Plataforma, chamados PSM (Platform Specific Model). Um PSM gerado para
cada plataforma especfica. Como muitos sistemas atualmente utilizam vrias
tecnologias, comum ter vrios PSMs relacionados com um nico PIM.
Em outras palavras, um modelo especfico de plataforma uma viso de um
sistema a partir do ponto de vista especfico de plataforma. Um PSM combina as
especificaes contidas no PIM com os detalhes que especificam como o sistema
usa uma plataforma especfica (MILLER, 2003).
2.2.2.3 Cdigo
A ltima etapa no processo de desenvolvimento a transformao de cada
PSM em cdigo. Esta transformao feita de forma simples e direta, j que um
PSM est fortemente relacionado com a sua plataforma especfica.
2.2.2.4 Vantagens dos Modelos
Estes modelos oferecem ao desenvolvedor uma alta capacidade de
abstrao, permitindo um enfoque direto sobre o verdadeiro domnio do sistema. Ao
criar-se um PIM, por exemplo, no necessrio preocupar-se com detalhes
especficos de uma determinada plataforma. como criar um sistema que nunca
morre, pois ele independente da tecnologia. A capacidade de transformar um PIM
de alto nvel em diversos PSMs permite ao desenvolvedor lidar com sistemas mais
complexos com menos esforo.

13

2.2.3 Automao das Etapas de Transformao


Aparentemente, todas estas etapas explicadas at agora do desenvolvimento
baseado em MDA assemelham-se demasiadamente com os mtodos tradicionais de
desenvolvimento. Porm, h uma diferena crucial, que faz com que o MDA possa
revolucionar o paradigma de desenvolvimento de software.
Mtodos tradicionais possibilitam a gerao automatizada de cdigo a partir
de um modelo. S que este cdigo gerado nada mais do que um modelo,
incompleto, e que precisa ser preenchido a mo. Em contraste, as transformaes
no MDA so todas completamente executadas por ferramentas, sendo portanto um
processo automatizado. Contudo a grande novidade no est no uso de ferramentas
para a transformao de PSMs em cdigo, j que estas ferramentas j existem
atualmente. A diferena crucial est na capacidade de transformar PIM em PSMs
automaticamente tambm.
2.3 Benefcios do MDA
Esta seo apresenta os principais benefcios do uso do MDA no
desenvolvimento de software.
2.3.1 Produtividade
No MDA o enfoque do desenvolvedor est na criao do PIM. Concentrandose somente num PIM, no necessrio preocupar-se com os detalhes especficos
de uma determinada plataforma, e portanto inmeros detalhes tcnicos podem ser
deixados de lado. Quanto definio de uma transformao, uma vez concebida,
ela pode ser utilizada diversas vezes para transformar diferentes PIMs em seus
respectivos PSMs (WARMER, 2003).
Como foi visto, os detalhes tcnicos so abordados somente durante o
processo de transformao do PIM em um PSM. Isso traz ganhos considerveis na
produtividade. Os desenvolvedores do PIM tm menos trabalho a fazer, j que
muitos dos detalhes especficos de plataforma so abordados pela definio da
transformao. Quanto ao PSM e fase de implementao, h menos cdigo a ser
escrito porque boa parte j foi escrito no PIM.

14

Tal ganho de produtividade s vivel devido utilizao das ferramentas de


transformao. Como o modelo de alto-nvel (PIM) agora incorpora no somente
informaes lidas por humanos, mas informaes lidas por computadores, h uma
forte demanda na completude e consistncia deste modelo de alto-nvel.
2.3.2 Portabilidade
A portabilidade do MDA alcanada atravs do enfoque no desenvolvimento
de PIMs. Um PIM pode, teoricamente, durar uma eternidade, independente das
novas tecnologias que venham a surgir. Tudo que especificado num PIM
completamente portvel (WARMER, 2003).
O nvel de portabilidade depende das ferramentas de transformao
disponveis. Para plataformas populares, provavelmente havero mais e melhores
ferramentas de transformao.
Dada a chegada de uma nova tecnologia, desenvolver um software utilizando
um velho PIM possvel. Basta a definio de transformao para esta nova
tecnologia ser criada.
2.3.3 Interoperabilidade
O processo de desenvolvimento MDA no seria completo se os PSMs
gerados no pudessem comunicar-se entre si. Isto possvel graas a um recurso
denominado ponte. Porm, esta ponte no permite uma comunicao direta, j que
uma plataforma especfica no compreende uma outra plataforma de tipo diferente.
A interoperabilidade s alcanada graas transformao dos elementos de uma
plataforma em elementos equivalentes na outra plataforma (WARMER, 2003). A
figura 3 representa a interoperabilidade presente no MDA.

15

Figura 3 Interoperabilidade do MDA usando pontes (baseado em WARMER, 2003)

Esta transformao de elemento de um PSM em um elemento equivalente em


outro PSM viabilizada pelo que h de comum entre eles, ou seja, o PIM. A partir de
um elemento de um PSM possvel saber de qual elemento ele foi gerado no PIM. A
partir deste elemento do PIM, possvel saber qual ele elemento ele gerou no
segundo PSM com o qual se deseja fazer uma ponte. Todas as informaes
tcnicas necessrias para ocorrer uma comunicao efetiva por esta ponte esto
disponveis graas ao detalhes tcnicos inerentes a cada PSM.
interessante observar que possvel, portanto, a existncia no s de
ferramentas que gerem PSMs, mas de ferramentas que gerem pontes tambm.
2.3.4 Manuteno e Documentao
Como o PIM no MDA uma representao exata do cdigo gerado, ele por si
s preenche a funo de documentao de alto-nvel necessrio num sistema de
software. H tambm um outro benefcio perante os demais mtodos tradicionais de
desenvolvimento de software. Mesmo que no decorrer do desenvolvimento
alteraes sejam realizadas diretamente no PSM, boas ferramentas podero
propagar automaticamente essas alteraes para o PIM. Portanto, alteraes no
PSM so refletidas diretamente no PIM, e a documentao de alto-nvel continuar
consistente com o cdigo atual (WARMER, 2003).

16

2.3.5 Elementos Fundamentais do MDA


Reunindo as informaes apresentadas neste captulo, possvel distinguir
alguns elementos fundamentais necessrios para pr em ao um desenvolvimento
baseado em MDA:

Modelos de alto-nvel consistentes e precisos, escritos numa linguagem


bem-definida, i.e., uma linguagem com sintaxe e semntica bem-definida e
automaticamente interpretvel por um computador. Os modelos devem
conter informaes suficientes sobre o sistema;

Linguagens bem-definidas para a escrita destes modelos de alto-nvel;

Definies de transformao, que descrevem como um PIM deve ser


mapeado para um PSM de uma plataforma especfica;

Linguagens bem-definidas para a escrita de definies de transformao;

Ferramentas que executam a transformao de PIMs em PSMs baseadas


nas definies de transformao;

Ferramentas que executam a transformao de PSMs em cdigo.

2.4 A Estrutura do MDA


Este captulo mostra a estrutura do MDA que reside por trs do processo
explicado no captulo anterior. Esta estrutura composta por elementos por um
nmero de elementos que se encaixam de forma bem particular.
2.4.1 Modelo
O prprio nome MDA (Arquitetura Dirigida a Modelo) enfatiza o fato de que
modelos so uma pea-chave no MDA. Estes modelos referem-se a todos os
modelos relevantes ao desenvolvimento de software, e no apenas modelos de
software. Ou seja, modelos que representam o domnio do sistema tambm so
relevantes.
Um modelo nada mais do que algo que descreve e representa alguma coisa
que existe na realidade. importante observar que um modelo descreve um sistema
de tal forma que ele possa ser usado para produzir um sistema similar. O novo
sistema produzido difere do sistema velho descrito pelo modelo. Porm, as
caractersticas principais do sistema do modelo estaro presentes no sistema novo.

17

Ou seja, o sistema produzido similar ao sistema modelado. Quanto mais detalhado


for um modelo, mais similares sero os sistemas produzidos por ele.
Um modelo sempre escrito em uma linguagem. Para habilitar a
transformao automtica de um modelo em outro, estes modelos precisam ser
escritos em uma linguagem bem-definida, ou seja, uma linguagem que possua
sintaxe e semntica bem-definidas. Duas definies podem ser levadas em conta:

Um modelo uma descrio de um sistema ou parte dele, escrita em uma


linguagem bem-definida (WARMER, 2003);

Umal linguagem bem-definida uma linguagem com sintaxe e semntica


bem definida e automaticamente interpretvel por um computador
(WARMER, 2003).

importante observar que no h restrio quanto ao formato do modelo (a


sintaxe) desde que o modelo seja bem-definido. O prprio cdigo-fonte de um
sistema pode ser considerado um modelo pertencente ao software. Um cdigo-fonte
escrito numa linguagem bem-definida e descreve um sistema. Apesar de ser
altamente dependente da plataforma para o qual ele foi escrito, um modelo. A
figura 4 mostra a relao existente entre um modelo, o sistema que ele descreve, e a
linguagem em que foi escrito.

Figura 4 Modelos e Linguagens (WARMER, 2003)

18

2.4.1.1 Relaes Entre Modelos


Para um dado sistema podem existir vrios modelos, e cada modelo descreve
parte do sistema num grau especfico de detalhamento. Dois modelos de um sistema
podem possuir alguma relao, e h vrios tipos de relao entre modelos.
O tipo de relao entre modelos sobre o qual o MDA tem enfoque na
gerao automtica de um modelo a partir de outro. Outros tipos de relaes
tambm so importantes, mas no podem ainda ser automatizadas.
2.4.2 Tipos de Modelos
Modelos diferem uns dos outros baseados em caractersticas como:

A parte do processo de desenvolvimento de software em que o modelo


usado (anlise ou projeto);

Nvel de detalhamento do modelo (abstrato ou detalhado);

O sistema que o modelo descreve (modelo de domnio ou modelo de


software);

O aspecto do sistema que o modelo descreve (modelo estrutural ou


modelo dinmico);

A grau de dependncia de plataforma do modelo (modelo independente de


plataforma ou modelo especfico de plataforma);

A plataforma-alvo do modelo (modelo para Java, C++, etc).

Certas caractersticas descritas acima no so inerentes ao prprio modelo,


ou seja, so subjetivas. Particularmente, as duas primeiras caractersticas citadas
acima so subjetivas. Se um modelo considerado ser um modelo de anlise ou de
projeto depende da interpretao das fases de anlise e projeto de um determinado
processo de desenvolvimento de software. Quanto a um modelo ser considerado
abstrato ou detalhado, isto depende do que se pressupe ser detalhe.
As demais caractersticas, no sendo subjetivas, podem descrever de forma
mais coerente as diferenas entre modelos distintos, e so essas as caractersticas
relevantes no contexto de transformaes de modelos.

19

2.4.2.1 Modelos de Domnio e de Software


O sistema descrito por um modelo de domnio o prprio domnio ou uma
empresa. Linguagens especficas para este tipo de modelo possuem um vocabulrio
prprio para descrio de elementos como processos, departamentos, dependncias
entre os processos, e assim por diante.
Um modelo de domnio pode no descrever nada a respeito do sistema de
software, e portanto tambm chamado de Modelo Computacionalmente
Independente, ou CIM (Computational Independent Model). Quando uma parte do
domnio est relacionada com o sistema de software, um modelo especfico de
software para este sistema escrito. Este modelo de software uma descrio do
modelo de software. Sistemas de domnio e de software descrevem categorias
completamente diferentes de sistemas no mundo real.
Os requisitos de um sistema de software so baseados no modelo de
domnio. Um nico modelo de domnio pode descrever diversos sistemas de
software cada qual com seu modelo de software. Cada sistema de software,
portanto, d suporte a uma parte diferente do modelo de domnio. Como pode-se
perceber, h uma relao entre os modelos de domnio e os de software, como
mostrado na figura 5.

Figura 5 Modelos de Domnio e de Software (baseado em WARMER, 2003)

Como visto anteriormente, o tipo de sistema descrito por um modelo


relevante para transformaes de modelos. Um CIM um modelo independente de
software usado para descrever o domnio de um sistema, mas derivaes
automticas de PIMs a partir de um CIM no so possveis, porque a escolha de

20

quais peas do CIM sero implementadas pelo sistema de software no pode ser
automatizada. uma tarefa que exige a inteligncia humana.
2.4.2.2 Modelos Estruturais e Dinmicos
Muito se fala sobre modelos estruturais e modelos dinmicos. Em UML, por
exemplo, um diagrama de classes considerado um modelo estrutural enquanto um
diagrama de estados considerado um modelo dinmico. Contudo, esta
terminologia pode ser considerada errnea. Na verdade, estes dois diagramas
pertencem a um mesmo modelo, e cada um deles oferece uma viso distinta do
modelo. Um diagrama de classes define aspectos estticos do modelo atravs de
uma viso esttica, enquanto um diagrama de estados define aspectos dinmicos do
modelo atravs de uma viso dinmica. Portanto, os diagramas de classes e
diagramas de estado poderiam ser chamados respectivamente de vises estruturais
e dinmicas. Como mostra a figura 6, diagramas diferentes em UML nada mais so
que vises pertencentes a um mesmo modelo, e escritas na mesma linguagem:
UML.

Figura 6 Diferentes vises de um sistema em um modelo UML (WARMER, 2003)

O que esta seo tem o intuito de enfatizar de que um modelo pode


representar diferentes vises de um sistema, sejam elas estticas ou dinmicas.
Como representado na figura acima, a relao entre vises estticas e dinmicas em

21

UML direta, pois elas mostram diferentes visualizaes da mesma coisa no mesmo
modelo.
Se um sistema possui tanto aspectos estruturais quanto aspectos dinmicos,
e a linguagem usada para expressar este sistema capaz de representar ambos os
aspectos, um nico modelo pode descrever ambos os aspectos (como o caso da
linguagem UML). Contudo, algumas vezes ambos os aspectos no podem ser
representados num nico modelo devido linguagem utilizada. O importante a
observar que neste caso, dois ou mais modelos estaro relacionados entre si
mesmo assim, pois descrevem um mesmo sistema. Quando h mais de um modelo
em um sistema, ao invs de chamar um modelo pelo tipo (estrutural ou dinmico),
mais conveniente cham-lo pelo nome da linguagem utilizada para descrev-lo, e.g.,
um modelo Entidade-Relacionamento ou um modelo de Rede de Petri. A figura 7
mostra dois modelos escritos em linguagens distintas descrevendo um mesmo
sistema.

Figura 7 Diferentes modelos de um mesmo sistema especificados por linguagens diferentes


(WARMER, 2003)

Pode-se concluir com o que foi dito acima que o que essencial em um
modelo no o aspecto descrito por ele (i.e., estrutural ou dinmico), e sim a
linguagem utilizada para descrev-lo. Algumas linguagens so melhores que outras
e mais adequadas para descrever determinados aspectos de um sistema.

22

2.4.2.3 Modelos Independentes de Plataforma e Especficos de Plataforma


As especificaes definidas pela OMG no deixam explicitamente claras qual
a exata linha divisria entre o que caracteriza um modelo como sendo
independente de plataforma e o que caracteriza outro como sendo especfico de
plataforma. Portanto, os termos PIM e PSM so termos relativos. O que possvel
afirmar que em uma transformao MDA transforma-se um modelo mais
independente de plataforma para outro mais especfico de plataforma.
2.4.2.4 As Plataformas-Alvo de um Modelo
O ltimo ponto a ser analisado que no contexto das transformaes de
modelos, a plataforma-alvo uma distino relevante entre os modelos. Cada
plataforma-alvo necessita de uma definio de transformao especfica para que
seja possvel transformar um PIM em um PSM especfico para esta plataforma-alvo.
O grau de dependncia de um modelo a uma determinada plataforma tambm
muito importante.
2.4.3 Transformaes
O processo do MDA, como vem sendo descrito at agora, baseado em
modelos e suas transformaes, respectivamente de um PIM para seus PSMs, e de
seus PSMs para cdigo. Estes dois tipos de transformaes podem ser realizados
por ferramentas distintas ou por uma mesma ferramenta.
Uma ferramenta de transformao composta por uma definio que
descreve como um modelo deve ser transformado. Esta definio chamada de
definio de transformao. A figura 8 mostra a estrutura de uma ferramenta de
transformao.

Figura 8 Definies de transformaes dentro das ferramentas de transformao


(WARMER, 2003)

23

A figura acima mostra a diferena entre uma transformao em si e a


definio de transformao. Uma definio de transformao define o mapeamento
de elementos de uma linguagem-fonte para elementos em uma linguagem-destino.
Como exemplo, pode-se definir uma definio de transformao de UML para
Java, sendo que esta definio pode ser usada para qualquer modelo UML. Esta
situao ilustrada na figura 9.

Figura 9 Definies de transformao so definidas entre linguagens


(baseado em WARMER, 2003)

Pode-se afirmar que uma definio de transformao consiste em um


conjunto de regras de transformao, as quais so especificaes no-ambguas da
maneira como um modelo (ou parte dele) pode ser usado para criar um outro modelo
(ou parte dele).
Baseado nas informaes acima, pode-se constatar trs definies.

Uma transformao a gerao automtica de um modelo-destino a partir


de um modelo-fonte, de acordo com uma definio de transformao
(WARMER, 2003);

Uma definio de transformao um

conjunto de regras

de

transformao que descrevem juntas como um modelo em uma


linguagem-fonte pode ser transformado em um modelo na linguagemdestino (WARMER, 2003);

Uma regra de transformao uma descrio de como um ou mais


construtores na linguagem-fonte pode ser transformado em um ou mais
construtores na linguagem-destino (WARMER, 2003).

A caracterstica mais importante de uma transformao que ela deve


preservar a semntica entre o modelo fonte e o destino. Entretanto, a semntica de
um modelo s pode ser preservada se ela pode ser expressa de maneira
equivalente tanto no modelo fonte quanto no destino.

24

2.4.3.1 Transformaes entre Linguagens Idnticas


As definies acima no impem limitaes quanto ao fato de que a
linguagem do modelo-fonte precisa ser a mesma do modelo-destino. H situaes
onde transformaes entre modelos escritos em linguagens idnticas desejvel,
e.g., quando um modelo Entidade-Relacionamento precisa ser normalizado, ele
pode ser utilizado como entrada numa ferramenta de transformao que gera como
sada o respectivo modelo j normalizado.
Quanto s transformaes entre modelos UML h uma pequena detalhe que
interessante salientar. Como se pode estender a linguagem UML para a criao de
uma nova linguagem, chamada de UML Profile, nem sempre se pode afirmar que
transformaes entre modelos UML so transformaes entre linguagens idnticas.
2.4.4 A Estrutura Bsica do MDA
Como foram mostrados nas sees anteriores, os principais elementos que
compem

estrutura

do

MDA

so: modelos,

PIMs,

PSMs,

linguagens,

transformaes, definies de transformaes, e ferramentas de transformao. A


figura 10 mostra a relao existente entre todos estes elementos.

Figura 10 Viso geral da estrutura bsica do MDA (baseado em WARMER, 2003)

Para o desenvolvedor as etapas mais importantes no processo do


desenvolvimento de software so a criao do PIM e a sua transformao em seus
respectivos PSMs. O desenvolvedor deve ento ter em mente quais ferramentas
sero usadas nas etapas de transformao.

25

2.5 Caractersticas Desejveis em Transformaes


Como foi visto nas sees anteriores, uma transformao pode ser definida
como a gerao de um modelo-destino a partir de um modelo-fonte, utilizando para
tal uma ferramenta de transformao que utiliza uma definio de transformao
especfica, que composta por regras de transformao. Porm, estas
transformaes no podem ser executadas de uma forma qualquer. H
caractersticas desejveis para a execuo de uma transformao de qualidade, i.e.,
uma transformao que mantenha a consistncia entre o modelo-fonte e o modelodestino. Elas so, em ordem de importncia (WARMER, 2003):

Ajustabilidade, que significa que regras de transformao de uma definio


de transformao podem ser ajustadas para melhor atender s
necessidades do desenvolvedor;

Rastreabilidade, que significa que possvel rastrear, partindo de um


elemento do modelo-destino, qual o seu elemento correspondente no
modelo-fonte;

Consistncia incremental, que significa que quando uma informao


especfica foi adicionada a um modelo-destino, e ele regenerado a partir
de uma nova transformao de seu modelo-fonte, a informao extra
persiste;

Bidirecionalidade, que significa que uma transformao pode ser


executada no sentido oposto, i.e., gerar o modelo-fonte a partir de uma
transformao do modelo-destino.

Cada uma destas caractersticas impe exigncias nas transformaes. As


prximas sees descrevem as implicaes destas caractersticas desejveis sobre
as transformaes.
2.5.1 Ajustabilidade
extremamente desejvel que uma ferramenta de transformao oferea a
possibilidade de ajuste de determinadas caractersticas da transformao. O
desenvolvedor deve observar que cada ferramenta possui diferentes opes de
ajuste. A seguir sero apresentadas as maneiras sobre as quais o desenvolvedor
pode interferir no processo de transformao.

26

2.5.1.1 Controle Manual


Este tipo de ajuste permite ao usurio um controle fino, realizado
manualmente, sobre as opes de ajuste. Permite definir qual elemento do modelo
ser transformado por qual regra de transformao. Apesar deste tipo de ajuste
oferecer um alto nvel de ajustabilidade, um tipo de ajuste muito propenso a erros e
que requer muita mo-de-obra.
2.5.1.2 Condies sobre Transformaes
Uma outra forma de oferecer o poder de controlar o modo como a
transformao ir ser executada anexando uma condio a cada regra de
transformao. Esta condio descreve quando esta regra deve ser aplicada. Em
princpio, todas as propriedades dos elementos do modelo-fonte podem ser usadas
pelas condies. Preferencialmente deve-se fazer com que as condies sejam
mutuamente exclusivas, viabilizando assim uma completa automatizao do
processo de transformao.
Este tipo de ajuste pode ser combinado com o controle manual para um maior
controle do ajuste.
2.5.1.3 Parmetros de Transformao
O processo de transformao pode tambm ser ajustado atravs do uso de
parmetros. O usurio ento seria requisitado que antes da transformao ele
preenchesse estes parmetros.
Deve-se observar que este tipo de ajuste diferente do controle manual.
Neste ltimo o usurio deve definir e configurar cada detalhe de ajuste. Atravs da
utilizao de parmetros, a ferramenta oferece flexibilidade sem tanta mo-de-obra,
disponibilizando a opo de ajuste focada em apenas uma caracterstica especfica
por parmetro. Cabe a ferramenta de transformao definir a quantidade de
parmetros disponveis para uma determinada transformao.
2.5.1.4 Informao Adicional
Em determinadas ocasies pode-se desejar formular uma condio, mas a
informao para tal no est entre as propriedades dos elementos no modelo-fonte.

27

Isto implica na necessidade de uma interveno manual do usurio para alcanar o


ajuste desejado, tendo que utilizar ento o ajuste atravs de controle manual.
2.5.2 Rastreabilidade
H ocasies em que desejvel utilizar-se de rastreabilidade. Como visto nas
sees anteriores, o PIM um modelo incompleto e suas lacunas precisam ser
preenchidas. Estas lacunas so ento preenchidas manualmente diretamente no
PSM. Ao preencher estas lacunas, porm, deve-se tomar o cuidado ao alterar
elementos do PSM que podem fazer com que ele desalinhe-se em relao ao
modelo do PIM. Nestas ocasies, a possibilidade de rastrear qual elemento no PSM
corresponde a qual elemento no PIM permite que os modelos estejam sempre
alinhados e conformes um com o outro.
O mnimo que uma boa ferramenta pode fazer alertar o usurio quando
ocorrer uma alterao no PSM que requeira uma alterao no PIM para que estes
dois modelos mantenham-se alinhados, e.g., quando o usurio troca o nome de uma
operao num PSM, a ferramenta pode sugerir que o nome seja trocado no PIM
tambm, ou renomear a operao no PIM automaticamente.
Outro tipo de situao onde desejvel oferecer suporte rastreabilidade
quando o projeto j est em fase adiantada de desenvolvimento, e ento algum
requisito muda. freqentemente mais fcil indicar qual parte do PIM afetada por
alteraes nos requisitos do que qual parte do cdigo ou do PSM foi afetada.
Quando partes do cdigo ou do PSM podem ser rastreadas para elementos no PIM,
a anlise de impacto das alteraes dos requisitos torna-se mais fcil.
No caso onde o sistema j foi implantado e erros so reportados, as partes do
cdigo responsveis pelo erro podem ser rastreadas a partir dos elementos do PIM
que representam a funcionalidade defeituosa.
2.5.3 Consistncia Incremental
comum ocorrer a situao onde depois que um modelo-destino tenha sido
gerado, ele seja ajustado de acordo com as necessidades do usurio para
preenchimento das lacunas. Quando, aps a gerao do modelo-destino e aps os
ajustes executados sobre ele, ocorrem alteraes no modelo-fonte, e ento o
modelo-fonte novamente transformado no modelo-destino, capacidade de

28

manter os ajustes no modelo-destino mesmo aps ele ter sido gerado novamente
d-se o nome de consistncia incremental. Portanto, transformaes que oferecem
suporte consistncia incremental permitem a realizao de alteraes no modelofonte com um impacto mnimo no modelo-destino.
Tanto a caracterstica de rastreabilidade quanto a de consistncia incremental
so mais importantes nas fases de transformao de PIMs para PSMs, do que estes
ltimos para cdigo.
2.5.4 Bidirecionalidade
Esta caracterstica no essencial s transformaes, e permite que o
modelo-fonte seja gerado a partir do modelo-destino. Existem duas maneiras de se
atingir a bidirecionalidade: atravs de uma nica definio de transformao, que
pode ser utilizada tanto no sentido normal de transformao quanto no sentido
reverso; ou atravs de duas definies de transformao, uma para o sentido normal
e outra para o sentido reverso. A figura 11 mostra uma nica definio de
transformao sendo usada nos dois sentidos.

Figura 11 Transformao bidirecional (WARMER, 2003)

Um dos motivos pelo qual se d baixa prioridade bidirecionalidade que


nos casos onde so criadas duas definies de transformaes, uma para cada
sentido, no possvel provar formalmente que uma definio o inverso da outra.
Este julgamento s pode ser feito subjetivamente.
Outro motivo que se ao modelo-fonte ou modelo-destino foram adicionados
informaes extras que o outro no possui, a bidirecionalidade no pode ser
atingida, e.g., quando apenas os aspectos estruturais de um PIM so mapeados
para um PSM, uma transformao reversa deste PSM resultaria em um PIM
incompleto. Num outro caso, se informaes extras fossem adicionadas ao PSM,

29

uma transformao reversa resultaria num PIM com informaes extras e


indesejveis.
Um terceiro motivo para se dar uma baixa prioridade bidirecionalidade que
uma bidirecionalidade completa s pode ser atingida se o poder de expressividade
das linguagens do modelo-fonte e do modelo-destino forem idnticas, situao esta
que invalidaria a necessidade de existncia de dois modelos. Se ambas as
linguagens possuem o mesmo poder de expressividade, ento um modelo bastaria.

30

3 METAMODELAGEM
Anteriormente foi dada a definio de modelo como sendo uma descrio de
um sistema (ou de parte dele), escrita numa linguagem bem-definida, a qual uma
linguagem formal apta a ser interpretada por computadores. Este captulo trata da
metamodelagem, i.e., a modelagem de modelos de modelos, e sua importncia
dentro do MDA. Os conceitos explicados neste captulo possuem relao direta com
MOF.
No passado, linguagens eram freqentemente definidas usando a gramtica
BNF (Backus Nour Form). Esta gramtica define a sintaxe de uma linguagem, mas
somente de linguagens baseadas em texto. Apesar de preencher o requisito de ser
uma linguagem capaz de ser automaticamente interpretada por computadores, ela
no preenche o requisito de criao de uma sintaxe grfica. J que em MDA os
modelos compem sua estrutura base, necessita-se de algum recurso capaz de
gerar linguagens com sintaxe grfica. Este recurso chama-se metamodelagem.
Um modelo define quais elementos podem existir num sistema, e uma
linguagem pode ser usada para definir quais elementos podem existir neste modelo.
Utilizando este mesmo princpio, esta linguagem tambm pode ser descrita por um
modelo. Um modelo de uma linguagem descreve os elementos que podem ser
usados nesta linguagem, e a este modelo d-se o nome de metamodelo.
Cada elemento utilizado na construo de um modelo escrito numa
determinada linguagem definido pelo metamodelo desta linguagem. Como o
prprio metamodelo tambm um modelo, ele tambm precisa ser escrito numa
linguagem bem-definida. Esta linguagem chamada de metalinguagem. Portanto, o
BNF uma metalinguagem. A figura 12 mostra toda esta inter-relao.

31

Figura 12 Metalinguagens, metamodelos, linguagens e modelos (WARMER, 2003)

Como um metamodelo equivalente linguagem definida por ele,


desnecessrio fazer uma distino entre um metamodelo e sua respectiva
linguagem definida por ele (WARMER, 2003). A figura 13 mostra a relao entre um
modelo, sua linguagem e a metalinguagem. Por motivos de diferenciao visual
entre a linguagem e sua metalinguagem na figura abaixo, a figura abaixo exibe como
smbolo de metalinguagem a letra M.

Figura 13 Metalinguagens, linguagens e modelos (WARMER, 2003)

Como a prpria metalinguagem tambm uma linguagem, ela tambm pode


ser

representada

por

um

metamodelo

escrito

em

outra

metalinguagem.

Teoricamente h um nmero infinito de camadas que representam estas relaes


entre metalinguagens, linguagens e modelos. Porm, para uma interpretao
computacionalmente automatizada destes conceitos, necessrio um nmero finito
de camadas.
3.1 As Quatro Camadas definidas pela OMG
A estrutura do MDA por definio composta por quatro camadas (ou
metanveis) de modelagem. Na verdade, estas quatro camadas so usadas como

32

um padro de arquitetura para todos os padres definidos pela OMG. Na


terminologia prpria da OMG, estas camadas so chamadas de M0, M1, M2 e M3 (o
M que precede o nmero de cada camada deriva do termo em ingls que pode ser
traduzido como metanvel: metalevel).
3.1.1 Camada M0: As Instncias
A camada M0 compreendida pelo sistema de software, no qual as
instncias reais existem, e.g., a instncia formada pelo empregado nomeado Jos
Firmino morando na rua Joo da Cunha em Blumenau. Inmeras instncias
podem existir,

e existem vrias tecnologias capazes de implementar estas

instncias.
Vale observar que quando se est modelando um domnio e no software, as
instncias da camada M0 so os elementos do domnio, como por exemplo pessoas,
produtos, etc. Quando se est modelando software, as instncias so as
representaes de software dos itens do mundo real, como por exemplo a verso
computadorizada das pessoas e dos produtos.
3.1.2 Camada M1: O Modelo do Sistema
A camada M1 composta por modelos, os quais descrevem os elementos
reais do sistema de software da camada M0, e.g., o conceito de empregado pode
ser definido pelas propriedades nome, endereo e cidade.
H uma relao definida entre as camadas M1 e M0. Os elementos da
camada M1 so classificaes ou categorizaes das instncias da camada M0,
assim como cada elemento da camada M0 nada mais so do que instncias de um
elemento da camada M1.
A figura 14 ilustra as camadas M0 e M1 com seus elementos e suas relaes.

33

Figura 14 Relaes entre as camadas M0 e M1 (baseado em WARMER, 2003)

3.1.3 Camada M2: O Modelo do Modelo


O modelo que reside na camada M2 chamado de metamodelo. Cada
elemento de um metamodelo classifica ou categoriza um elemento da camada M1,
i.e., um elemento de um modelo. Assim como os elementos da camada M1
oferecem os recursos necessrios para lidar com os elementos da camada M0, os
elementos da camada M2 oferecem os recursos necessrios para lidar com os
elementos da camada M1.
Portanto, como cada modelo criado na camada M2 um modelo para
descrever outros modelos (os modelos da camada M1), eles so chamados de
metamodelos. Por este motivo a camada M2 denominada de camada de
metamodelagem. A figura 15 mostra a relao entre elementos de um modelo UML
da camada M1 e elementos do metamodelo UML na camada M2.

Figura 15 Relaes entre as camadas M2 e M1 (baseado em WARMER, 2003)

Analisando a figura acima e a figura que mostra a relao entre os elementos


da camada M1 e M0, pode-se claramente perceber que uma instncia da camada
M0 definida por uma classe do modelo UML da camada M1, e esta classe do

34

modelo UML definida por uma classe que define classes no metamodelo UML na
camada M2.
3.1.4 Camada M3: O Modelo do M2
A ltima das definies de camadas do MDA, a camada M3, composta por
elementos que oferecem os recursos necessrios para lidar com os elementos da
camada M2. A mesma relao existente entre os elementos da camada M0 e M1, e
entre os elementos da camada M2 e M1, existe entre os elementos da camada M3 e
M2, ou seja, cada elemento da camada M3 categoriza ou classifica cada elemento
da camada M2. A figura 16 mostra a relao entre a camada M3 e M2.

Figura 16 Relaes entre as camadas M3 e M2 (baseado em WARMER, 2003)

A figura 17 mostra uma viso geral desta arquitetura de quatro camadas.

35

Figura 17 Viso geral das quatro camadas (baseado em WARMER, 2003)

Um quadro comparativo e explicativo das quatro camadas pode ser


visualizado na tabela 1.
Tabela 1 Quadro comparativo das quatro camadas do MDA

Camada

Contedo

Descrio

M3

Metametamodelo

Linguagem para a
construo de
metamodelos
Linguagem para a
construo de modelos

M2

Metamodelo

M1

Modelo

Descreve aspectos
estruturais e/ou dinmicos
dos dados

M0

Dados

Dados do mundo real

Elementos
(exemplos)
MOF Class, MOF
MOF Attribute, MOF
Association, etc.
UML Class, UML
Association, UML
Attribute, UML State,
etc.
Classe Empregado,
Atributo Nome,
Atributo Endereo,
etc.
Empregado (Jos
Firmino, Joo da
Cunha, Blumenau),
etc.

36

3.1.5 Anlise das Camadas


Como afirmado anteriormente, em princpio no h um limite para o nmero
de camadas que podem existir. A camada M3 poderia ser representada por uma
camada M4 que relaciona cada elemento deste ltimo com um elemento do
metamodelo da camada M3. O fator limitante para esta arquitetura possuir quatro
camadas foi arbitrrio, e seguido por todos os padres definidos pela OMG. O que
realmente essencial compreender em toda esta arquitetura de quatro camadas a
relao de instnciao que existe entre uma camada e outra, i.e., elementos de
uma camada inferior so instncias de elementos categorizadores ou classificadores
da camada superior (WARMER, 2003).
Analisando por outro ponto de vista, na verdade todos os elementos de todas
as camadas existem no mundo real, e portanto pertencem camada M0. Pode-se
afirmar que o conjunto de elementos da camada M3 pertence ao conjunto de
elementos da camada M2, cujos elementos pertencem ao conjunto de elementos da
camada M1, cujos elementos pertencem ao conjunto de elementos da camada M0.
Esta relao de conjuntos pode ser vista na figura 18 atravs de um Diagrama de
Venn.

Figura 18 Relaes entre os conjuntos M3, M2, M1 e M0 (WARMER, 2003)

3.2 Metamodelagem e o MDA


H dois fatores que elucidam a importncia da metamodelagem para o MDA.
A primeira delas que a metamodelagem um meio de definio formal de
modelos. Como o processo de desenvolvimento no MDA baseado na
transformao automatizada entre modelos, necessrio que estes modelos
possam ser interpretados por computadores.

37

Em segundo lugar, as regras de transformao que definem o mapeamento


entre um elemento de um modelo-fonte em um elemento de um modelo-destino so
definidas em termos de mapeamento entre elementos do meta-modelo-fonte e
elementos do meta-modelo-destino. Em outras palavras, pode-se afirmar que as
regras de transformao so definidas em termos de mapeamento entre elementos
das linguagens dos modelos fonte e destino.
3.2.1 A Estrutura Completa do MDA
A figura 19 mostra a estrutura completa do MDA. Esta figura semelhante
figura 10, porm em sua parte superior foi introduzida a metalinguagem para
definio de linguagens.

Figura 19 A estrutura completa do MDA, incluindo a metalinguagem


(baseado em WARMER, 2003)

Num

processo

de

desenvolvimento

de

software,

maioria

dos

desenvolvedores vero somente a base desta arquitetura. Porm, um pequeno


nmero de desenvolvedores, os mais experientes, sero responsveis pelo estudo,
pela escolha, ou at mesmo pela criao de linguagens e suas respectivas
transformaes.

38

4 MOF
O MOF (Meta Object Facility) um padro criado pela OMG que define uma
linguagem para a definio de linguagens de modelagem. Como o MOF uma
linguagem

para

criao

de

linguagens,

ela

pode

ser

considerada

uma

metalinguagem. O MOF reside na camada M3 da arquitetura MDA, e como no h


uma camada superior para definir o MOF, ele definido atravs dele mesmo. O
MOF a linguagem em que as definies de UML e CWM, ou seja, os metamodelos
de UML e CWM so escritos.
4.1 Viso Geral
Esta seo apresenta uma viso geral do MOF, explanando sua origem, as
ferramentas relacionadas, e a funo do MOF no MDA.
4.1.1 A Origem do MOF
A OMG ratificou o MOF em 1997. Os arquitetos do MOF perceberam que a
indstria estava utilizando padres completamente diferentes para descrever
diferentes tipos de construtores de modelagem, e.g., os mecanismos usados para
expressar que uma tabela possui suas colunas eram diferentes dos utilizados para
expressar que uma classe possui seus atributos.
Os arquitetos ento rejeitaram a idia de unificar os construtores de
modelagem de linguagens distintas em uma s porque isso acabaria criando uma
nica linguagem para todo e qualquer tipo de modelo, diminuindo assim
consideravelmente o poder de expressibilidade na realizao de modelagens. Ento
os arquitetos criaram uma maneira universal de descrever construtores de
modelagem. Isto ento resultou numa maneira comum de descrever as propriedades
e relaes destes construtores de modelagem usados para construir um
determinado metamodelo (FRANKEL, 2003).
Portanto, o MOF foi concebido primordialmente como uma maneira para
descrever construtores de modelagem. Para tal, a premissa fundamental utilizada
de que haver e deve haver vrios tipos de modelos.

39

4.1.1.1 Uma Premissa Adicional


Os arquitetos do MOF asseguraram-se de outro princpio fundamental, de que
possvel alcanar um grau significativo de comunalidade no gerenciamento de
metadados sem sacrificar a habilidade de usar vrios tipos de modelos ou a
habilidade de criar novos tipos de linguagens de modelagem. Ter uma maneira
comum de descrever construtores de modelagem que formam diversas linguagens
de modelagem o conceito-chave para tornar isto possvel (FRANKEL, 2003).
Todos estes princpios fundamentais foram declarados para atender a um
forte propsito, o de utilizar ferramentas de gerenciamento de metadados que
entendam tais descries para que possam inferir como gerenciar os modelos que
usam estes construtores. Se os mesmos termos so usados para descrever o fato
de que uma tabela possui suas colunas e que uma classe possui suas operaes,
uma ferramenta de gerenciamento de metadados pode aplicar um conjunto
consistente de regas para gerenciar estes metadados pertencentes a outros
metadados. Se os mesmos termos so usados para descrever as propriedades de
uma coluna e as propriedades de uma operao, uma ferramenta de gerenciamento
de metadados pode ento gerenciar de forma consistente o conceito de propriedade.
Pode-se tambm concluir com o que foi dito acima que o MOF uma maneira
universal de descrever as relaes entre os elementos de um determinado modelo.
4.1.2 Ferramentas MOF
O MOF no somente usado para definir linguagens de modelagem, mas
tambm para servir como base para a construo de ferramentas para definio de
linguagens de modelagem.
O MOF oferece um modelo de repositrio que pode ser usado para
especificar e manipular modelos, impulsionando a consistncia na manipulao de
modelos em todas as fases do uso do MDA (MILLER, 2003).
4.1.2.1 A Interface de Repositrio MOF
A definio do MOF inclui uma especificao da interface para um repositrio
MOF, permitindo assim o acesso a modelos da camada M1 de um repositrio
atravs de uma interface comum. Esta interface especifica operaes comuns para o

40

acesso dos dados contidos neste repositrio, e definida atravs de CORBA-IDL.


Portanto, ela pode ser utilizada por vrias plataformas. Especialmente para Java, h
uma interface nativa que oferece esta funcionalidade, e chamada de JMI (Java
Metadata Interface).
4.1.2.2 Intercmbio de Modelos
O MOF tambm usado para definir um meio para intercmbio de modelos
M1, desde que estes modelos possuam seus metamodelos definidos por MOF.
Atualmente, o formato de intercmbio mais conhecido e popular um formato
baseado no XML, e chamado XMI (XML Metadata Interchange). Como o MOF
definido atravs dele prprio, XMI pode ser usado para gerar formatos de
intercmbio de padres para metamodelos tambm.
O XMI vem sendo amplamente utilizado como o formato oficial de intercmbio
de modelos UML, levando as pessoas a ver o XMI como um formato de intercmbio
de UML. Porm, esta uma viso limitada do XMI.
4.1.3 A Funo do MOF no MDA
A verdadeira funo do MOF no MDA fazer com que os elementos dos
modelos especificados no MDA possuam uma semntica em comum, para ento
viabilizar as transformaes entre modelos de camadas distintas. Atravs da
utilizao de uma linguagem padro, atravs da qual derivam todas as outras
linguagens, as transformaes podem ser aplicadas em qualquer uma das quatro
camadas mantendo a semntica dos modelos. Portanto, pode-se afirmar que o MOF
o ncleo do MDA (WARMER, 2003).
4.2 Terminologia
Vale a pena olhar com mais ateno sobre a terminologia utilizada para os
conceitos referentes ao MOF. Esta terminologia, se no bem compreendida, pode
causar confuso no entendimento e na leitura dos conceitos explicados neste
trabalho.

41

4.2.1 O Prefixo Meta


A utilizao do prefixo meta pode causar confuso. Para evitar tal confuso,
esta seo visa explanar precisamente o significado de cada termo que utiliza este
prefixo:

Metadado: significa estritamente dado sobre dado. Ou seja, usado para


referir-se a dados cujo propsito descrever outros dados;

Metaobjeto: refere-se a um objeto que descreve um metadado, e.g., um


objeto Java ou um objeto CORBA. O termo metaobjeto uma abreviao
de objeto de metadado. Foi a partir deste termo que o MOF ganhou o
nome de Meta Object Facility;

Metamodelo: refere-se a um modelo que descreve algum tipo de


metadado;

Metametamodelo: refere-se a um modelo que descreve um metamodelo.


Como na arquitetura MDA s existe um nico metametamodelo, que o
prprio MOF, e como o termo metametamodelo pode causar confuso
durante a sua leitura, convencionou-se que o metametamodelo tambm
pode ser chamado inequivocamente de o Modelo MOF.

Uma outra ocasio onde pode haver confuso na terminologia no


rastreamento de um elemento de uma camada qualquer, e.g., o elemento Classe da
camada M1 de um modelo UML, que uma instanciao do elemento Classe da
camada M2 do metamodelo UML, que foi instanciada pelo elemento Classe da
camada M3 do metametamodelo MOF. O termo Classe foi utilizado em trs
situaes distintas com significados completamente diferentes. Para contornar esta
ambigidade poderia-se utilizar o termo classe para referir-se ao elemento Classe da
camada M1, o termo metaclasse para referir-se ao elemento classe da camada M2,
e o termo metametaclasse para referir-se ao elemento Classe da camada M3.
Porm, esta terminologia tambm pode ser considerada confusa.
Portanto, para evitar o uso de termos como meta-meta-classe, meta-metaatributo, entre outros, convencionou-se chamar, por exemplo, o elemento Classe da
camada M1 de uma instncia da camada-M1 de uma Classe da camada-M2.
Concluindo a explanao da terminologia, vale ressaltar ento que h
equivalncia entre certos termos. A tabela 2 mostra a equivalncia de alguns termos.
Os termos que se encontram na mesma linha referem-se a conceitos iguais.

42

Tabela 2 Termos equivalentes (termos numa mesma linha referem-se a conceitos iguais)

Camada
M0
M1
M2
M3

Dados
Dado
Metadado
Metametadado

Modelos
Modelo
Metamodelo
Metametamodelo

Linguagens
Linguagem
Metalinguagem

4.3 Caractersticas da Linguagem


Esta seo apresenta algumas peculiaridades concernentes linguagem
MOF.
4.3.1 Garantindo a Corretude da Semntica
Esta seo mostra atravs de um exemplo como o MOF pode garantir que um
modelo est semanticamente correto.
Se um metamodelo diz que uma tabela possui suas colunas via agregao
composta, uma ferramenta de gerenciamento de metadados MOF pode no
entender realmente o que uma tabela nem o que uma coluna , mas ela entende o
que uma agregao composta porque uma agregao composta um dos
construtores de modelagem do MOF. Este software de gerenciamento de metadados
pode ento garantir a propriedade de pertinncia entre os elementos do modelo,
fazendo com que quando uma tabela seja removida de um repositrio, todas as suas
colunas sejam removidas tambm. Esta mesma estratgia pode ser utilizada, por
exemplo, para garantir que quando uma operao de um modelo UML qualquer for
removida de um repositrio, os seus parmetros sejam removidos tambm. Isto
vivel porque os parmetros em um modelo UML esto formalmente relacionados
com a sua operao que os contm, atravs de uma associao que tambm do
tipo agregao composta (FRANKEL, 2003).
4.3.2 Notao Grfica
MOF utiliza como elementos sintticos de construo de seus metamodelos
os construtores de modelagem de classes orientadas a objeto do UML. Assim, os
metamodelos assemelham-se muito aos diagramas de classes em UML. At mesmo
as ferramentas utilizadas para a modelagem de classes em UML podem ser

43

utilizadas para a construo de metamodelos MOF. Com MOF, um construtor de


modelagem modelado como uma classe e as propriedades do construtor como
atributos da classe. As relaes entre os construtores so modeladas como
associaes. Com isso pode-se concluir que modelar um metamodelo MOF muito
semelhante a criar um diagrama de classes em UML. Portanto, a notao grfica do
MOF a mesma do UML.
4.3.3 A Orientao a Objeto em MOF
Apesar dos construtores de modelagem do MOF serem os mesmos do UML e
serem, portanto, orientados a objetos, isto no significa que estes construtores no
possam ser utilizados para definir metamodelos no orientados a objeto.
Quando se usa UML para criar diagramas de classes, o fato de poder-se
utilizar a orientao a objeto, i.e., poder-se generalizar/especializar classes, no
deriva do fato de que o metamodelo de UML foi definido via MOF. Deriva do fato de
que os construtores que possibilitam a generalizao/especializao foram
explicitamente definidos no metamodelo UML.
Portanto, perfeitamente legtimo definir um metamodelo MOF que no
suporta orientao a objeto. Isto relevante pois existem metamodelos que no
devem suportar qualquer mecanismo de orientao a objeto. Um dos intuitos
fundamentais do MOF justamente oferecer suporte a variados tipos de
modelagem, e portanto ele oferece suporte a modelagens no orientadas a objeto.
4.3.4 Auto-Descrio
O prprio MOF precisa ser definido por alguma linguagem. Afinal, se os
elementos da camada M0 so instncias de elementos da camada M1, que so
instncias de elementos da camada M2, que por sua vez so instncias de
elementos da camada M3, os elementos da camada M3 precisam ser instanciados
por elementos oriundos de algum outro conjunto de elementos.
A soluo adotada pela OMG para descrever os elementos da camada M3 foi
que os prprios elementos da camada M3 so instncias dos elementos da camada
M3. Em outras palavras, o MOF usa o MOF para descrever a si prprio. Em termos
tcnicos, o MOF considerado auto-descritivo. O prprio MOF define um modelo
que descreve o MOF utilizando para tal seus prprios construtores. Este modelo

44

chamado de Modelo MOF (MOF Model). O Modelo MOF distinto de qualquer outro
tipo de metamodelo, porque o metamodelo do MOF.
4.3.4.1 Implicaes da Auto-Descrio do MOF
Assim como importante representar modelos atravs de documentos XML,
metaobjetos CORBA, metaobjetos Java, e assim por diante, tambm importante
representar

metamodelos

como

documentos

XML,

metaobjetos

CORBA,

metaobjetos Java, e assim por diante. A propriedade de auto-descrio do MOF, i.e.,


o fato do MOF ser definido pelo prprio MOF, faz com que seja possvel que os
mesmos mecanismos usados na gerao de modelos possam ser utilizados na
gerao de metamodelos.
Como conseqncia disso, pode-se aplicar, por exemplo, um mapeamento
MOF-XML usando o XMI em um metamodelo MOF, obtendo-se assim um XMI DTD
para a representao de modelos que esto de acordo com as normas definidas
pelos seus metamodelos. Porm, quando se aplica o XMI para o mapeamento MOFXML sobre o Modelo MOF, i.e., o modelo MOF do prprio MOF, obtm-se um XMI
DTD para a representao de metamodelos MOF. Este DTD chamado de o MOF
DTD, e DTD oficial da OMG. Para cada um dos metamodelos padres da OMG, a
OMG tem um documento XMI padro que representa o metamodelo e que pode ser
validado contra o MOF DTD.
Assim, um metamodelo MOF pode ser dois tipos de transformao via XMI:

A transformao de um metamodelo da camada M2 em outro metamodelo


da camada M2, i.e., um metamodelo qualquer pode ser representado
atravs de seu mapeamento para um documento XMI equivalente ao
metamodelo original, contendo todas as propriedades de todos os
elementos deste metamodelo. Este documento XMI pode ento ser
validado pelo MOF DTD;

A transformao de um metamodelo da camada M2 em um DTD a ser


usado na camada M1. Este DTD representaria instncias da camada M1
referentes aos elementos do metamodelo da camada M2.

claro que outras tecnologias podem ser utilizadas em transformaes que


tm como entrada o Modelo MOF. Assim, interfaces de outras tecnologias,
diferentes da XMI, j foram criadas para representar o Modelo MOF na camada

45

M2. A OMG, por exemplo, j executou o mapeamento MOF-CORBA sobre o


Modelo MOF, obtendo assim uma IDL para objetos CORBA que representam
elementos da camada M2. A especificao do JMI contm uma definio
padronizada de seu mapeamento MOF-Java sobre o Modelo MOF, podendo-se
obter assim interfaces para objetos Java que representam elementos da camada
M2.
4.3.5 Implementaes Genricas de MOF
Uma grande qualidade do MOF que a gerao automtica de cdigo, a
partir de um metamodelo, para a manipulao de metadados que residem em um
repositrio pode no somente ser estaticamente realizada para cada metamodelo,
como pode ser realizada dinamicamente. Assim, o mesmo cdigo gerado para
manipular modelos UML poderia manipular, por exemplo, modelos escritos em
outras linguagens.
Toda e qualquer interface gerada a partir de um determinado metamodelo
herda as caractersticas de um conjunto pr-definido e padronizado de interfaces
chamado de Interfaces MOF Reflexivas (MOF Reflective Interfaces) (FRANKEL,
2003). H, por exemplo, Interfaces MOF Reflexivas para CORBA e um conjunto
similar para Java. Interfaces Reflexivas possuem a mesma funcionalidade de uma
interface gerada especificamente para um determinado metamodelo, porm, o
cdigo gerado dinamicamente no to inteligvel e simples quanto um gerado
estaticamente, e.g., um cliente usando interfaces Java especficas para um
metamodelo UML poderiam determinar se uma classe ou no abstrata atravs do
comando:
boolean isAbstract = myClass.getIsAbstract();
A obteno deste resultado no seria to simples e direta para um cliente
usando Interfaces Reflexivas. Para tal, o cliente teria que criar um objeto Java
contendo uma definio do atributo isAbstract do metamodelo, passar o objeto para
uma operao genrica do tipo refGetValue, e ento converter o valor de retorne
desta operao para boolean.
Tambm possvel fazer com que um cliente genrico sem prvio
conhecimento do modelo a acessar obter informaes do mesmo. Na situao

46

descrita no exemplo acima, este cliente genrico MOF que usa Interfaces Reflexivas
leria o metamodelo UML dinamicamente, i.e., em tempo de execuo. Assim, o
cliente genrico pode obter a sintaxe abstrata do metamodelo dinamicamente.
possvel que o programa cliente gere automaticamente uma GUI que viabilize a
realizao de operaes CRUD sobre os metadados do repositrio bastando para tal
que o programa cliente tenha acesso de leitura aos metadados.
Esta atravs dessa maneira que ferramentas de repositrios MOF oferecem
editores de repositrio genricos. Os editores usam somente Interfaces Reflexivas e
so totalmente criadas dinamicamente a partir dos metamodelos e modelos do
repositrio .
Porm, editores genricos podem possuir uma srie de limitaes, e.g., um
editor genrico, no tendo qualquer tipo de conhecimento a respeito de um
metamodelo particular e portanto utilizando a mesma GUI para todo e qualquer
metadado, no saberia como exibir um modelo UML na forma de diagramas UML.
Portanto, editores genricos podem ser teis, mas contudo so limitados.
Um cdigo genrico pode, por exemplo, ser apto a importar e exportar
documentos XML representando modelos de um repositrio MOF sem ter acesso ao
XML DTD ou Schema gerado a partir do metamodelo correspondentem, e sim tendo
acesso ao metamodelo. Se o cdigo genrico entende as regras de transformao
MOF-XML, ento ele pode us-las para interpretar o documento XML representando
o modelo.
4.4 O Modelo MOF Construtores de Modelagem
Esta seo tem como objetivo apresentar os construtores de modelagem do
MOF (i.e., a linguagem abstrata de MOF) para a definio de metamodelos. A
presente verso descrita do MOF a 1.4. A metamodelagem baseada em MOF
baseada na definio de modelos que descrevem metadados. O MOF usa para tal
uma estrutura de modelagem de objetos que essencialmente um subconjunto do
ncleo do UML. Os quatro principais conceitos relacionados com a metamodelagem
baseada em MOF so (OMG, 2002):

Classes: modelam os metaobjetos MOF;

Associaes: modela relaes binrias entre metaobjetos;

47

Tipos de Dados: modelam outros dados (e.g., tipos primitivos, tipos


externos, etc);

Pacotes: modularizam os modelos.

A verso completa do Modelo MOF pode ser vista na figura 20. A classe
ModelElement a super-classe a partir da qual todas as demais classes so
derivadas. A classe Classifier (Classificador) a super-classe abstrata para os
tipos do MOF: Class (Classe), Association (Associao) e DataType (Tipo de
Dado). A classe Feature (Caracterstica) define a caracterstica do ModelElement
(Elemento do Modelo) que o contm. Especificamente, Classes so definidas por
vrias composies de sub-classes de Features, como Attributes (Atributos) e
Operations (Operaes).
A

classe

StructuralFeature

(Caracterstica

Estrutural)

define

uma

caracterstica esttica de um ModelElement que o contm. Os atributos e referncias


de uma Classe definem propriedades estruturais, os quais do suporte
representao do estado das suas instncias. A classe BehavioralFeature
(Caracterstica

Comportamental)

super-classe

da

classe

Operation

(Operao) e Exception (Exceo), e define uma caracterstica dinmica do


ModelElement que o contm.

48

Figura 20 O Pacote do Modelo MOF (OMG, 2002)

4.4.1 Classes (em ingls, tambm Classes)


Classes so descries de tipos dos metaobjetos MOF. O estado (atributos) e
comportamento (operaes) de instncias da camada M1 so definidos por classes
da camada M2.

49

Classes podem possuir trs caractersticas essenciais: Atributos (Attributes),


Operaes (Operations) e Referncias (References). Alm destas caractersticas,
podem conter tambm Excees (Exceptions), Constantes (Constants), Tipos de
Dados (DataTypes), Restries (Constraints), entre outros (OMG, 2002).
4.4.1.1 Atributos (Attributes)
Um Atributo define um local reservado para guardar valores (informao). Um
Atributo possui propriedades como nome, tipo, alguns sinalizadores (flags) e
especificao de multplicidade (OMG, 2002). Estas propriedades podem ser vistas
abaixo na tabela 3.
Tabela 3 Propriedades de um Atributo (OMG, 2002)

Propriedade
Nome (name)
Tipo (type)
Sinalizador isChangeable
Sinalizador isDerived

Especificao de Multiplicidade
(multiplicity)

Descrio
nico no escopo da Classe
Pode ser Class ou um DataType
Determina se o cliente pode alterar o
valor do atributo
Determina se o valor do atributo parte
de um estado explcito de uma
instncia de uma Classe, ou se
derivado de outro estado
(Ver seo Multiplicidade de Atributos
e Parmetros)

4.4.1.2 Operaes (Operations)


Operaes

so

entidades

atravs

das

quais

se

pode

acessar

comportamento de uma Classe. Operaes no especificam o comportamento ou os


mtodos que implementam este comportamento. Ao invs disso, eles simplesmente
especificam os nomes usados para referenciar a invocao do referido
comportamento (OMG, 2002). As propriedades das Operaes podem ser vistas na
tabela 4.
Tabela 4 Propriedades de uma Operao (OMG, 2002)

Propriedade
Descrio
Nome (name)
nico no escopo da Classe
Lista dos parmetros posicionais tendo as seguintes propriedades:
Nome do parmetro:

50

Tipo do parmetro
Direo do parmetro: in, out, ou in
out
Multiplicidade

Pode ser denotado por um elemento do


tipo Class ou do tipo DataType
Determina se os argumentos atuais so
passados do cliente para o servidor, do
servidor para o cliente, ou ambos
(Ver seo Multiplicidade de Atributos
e Parmetros)

Um tipo opcional de retorno


Uma lista de Excees que podem ser lanadas por uma invocao

4.4.1.3 Escopo dos Atributos e Operaes


Atributos e Operaes podem ser definidos em nvel de classificador
(classifier level) ou em nvel de instncia (instance level). Um Atributo em nvel de
instncia tem um local reservado para armazenar valores para cada instncia de
uma Classe. J um atributo em nvel de classificador tem um local reservado para
guardar valores que compartilhado com todas as instncias da Classe (OMG,
2002).
Similarmente, uma Operao em nvel de instncia pode somente ser
invocada sobre uma instncia de uma Classe e ser aplicada somente sobre o
estado desta instncia. J uma Operao em nvel de classificador pode ser
invocada independentemente de qualquer instncia, e pode ser aplicado sobre
algumas ou todas as instncias da classe em questo.
4.4.1.4 Multiplicidades de Atributos e Parmetros
Um Atributo ou Parmetro pode possuir valorao opcional, valorao
simples, ou pode ser multi-valorado, dependendo da sua especificao de
multiplicidade. Isto consiste em trs partes (OMG, 2002):
1) Os campos lower (inferior) e upper (superior) definem limites para o
nmero de elementos no valor do Atributo ou Parmetro. O limite inferior
pode ser zero e o superior pode ser ilimitado. Um Atributo ou Parmetro
de valorao simples possui limite inferior igual a 1 e limite superior igual a
1. Um Atributo ou Parmetro de valorao opcional possui um limite
inferior igual a 0 e um limite superior igual a 1. Todos os outros casos so
chamados de multi-valorados, j que seus limites superiores so maiores

51

do que 1. Para a representao do limite superior ilimitado, o smbolo *


usado;
2) O sinalizador is_ordered ( ordenado) informa se a ordem dos valores
em um lugar reservado para guard-los semanticamente relevante. Por
exemplo, se um Atributo ordenado, a ordem dos valores individuais em
uma instncia do Atributo ser preservada;
3) O sinalizador is_unique ( nico) informa se instncias com valores
iguais so permitidas para um dado Atributo ou Parmetro. O significado
de valor igual depende do tipo base do Atributo ou Parmetro.
4.4.1.5 Generalizao de Classe
O MOF permite que Classes sejam herdadas de uma ou mais Classes. Assim
como em UML, o Modelo MOF usa o verbo generalizar para descrever a relao
de herana (i.e., uma super-Classe generaliza uma sub-Classe).
O significado de generalizao de uma Classe MOF similar ao de
generalizao em UML. As sub-Classes herdam todo o contedo de suas superClasses (i.e., todos os Atributos das super-Classes, Operaes e Referncias, e
todos os Tipo de Dados aninhados, Excees e Constantes). Qualquer Restrio
explcita que seja aplicada a uma super-Classe e qualquer comportamento explcito
para a super-Classe aplicam-se tambm a sub-Classe. Na camada M1, uma
instncia de uma Classe da camada M1 pode ser substituda por instncias de suas
super-Classes da camada M2 (OMG, 2002).
O MOF define restries sobre generalizaes para assegurar que so
semanticamente corretas e que possam ser mapeadas para diversas tecnologias:

Uma classe no pode generalizar a si prpria, tanto diretamente quanto


indiretamente;

Uma Classe no pode generalizar outra Classe se a sub-Classe contm


um elemento com o mesmo nome de um elemento contido ou herdado
pela super-Classe (i.e., no permitido sobrescrever nomes de
elementos);

Quando uma Classe possui vrias super-Classes, nenhum elemento


contido ou herdado pelas super-Classes pode ter o mesmo nome. H uma

52

exceo que permite que super-Classes herdem nomes de uma Classe


ancestral comum.
4.4.1.6 Classes Abstratas (Abstract Classes)
Uma Classe pode ser definida como abstrata. Uma Classe abstrata usada
somente para propsitos de herana. Nenhum metaobjeto com o tipo sendo o de
uma Classe abstrata pode existir (OMG, 2002).
4.4.1.7 Classes Folha (Leaf) e Raiz (Root)
Uma Classe pode ser definida como folha ou raiz. Declarar uma Classe
como folha impede a criao de quaisquer sub-Classes. Declarar uma Classe como
raiz impede a declarao de quaisquer super-Classes (OMG, 2002).
4.4.2 Associaes (Associations)
Associaes so os construtores primrios do Modelo MOF para expressar
relaes em um metamodelo. Na camada M1, uma Associao MOF da camada M2
define relaes (ligaes) entre pares de instncias de Classes. Conceitualmente,
estas ligaes no possuem identidade de objeto (no podem ser instanciadas), e
portanto no podem conter Atributos ou Operaes (OMG, 2002).
4.4.2.1 Extremidades de Associao (Association Ends)
Cada Associao do MOF contm precisamente duas Extremidades de
Associao descrevendo as duas extremidades da conexo. As propriedades das
Extremidades de Associao podem ser vistas na tabela 5 (OMG, 2002).
Tabela 5 Propriedades de Extremidades de Associao (OMG, 2002)

Propriedade
Um nome para a extremidade
Um tipo para a extremidade
Especificao de multiplicidade
Uma especificao de agregao
A propriedade de navegabilidade
(navigability)

Descrio
Este nome nico dentro da
Associao
Este tipo precisa ser uma Classe
Ver a seo Multiplicidades de
Extremidade de Associao
Ver a seo Agregao de
Associao
Controla se Referncias podem ser
definidas para a extremidade

53

A propriedade de alterabilidade
(changeability)

Determina se esta extremidade de uma


conexo pode ser atualizada

4.4.2.2 Multiplicidades de Extremidade de Associao


Cada Extremidade de Associao tem uma especificao de multiplicidade.
Enquanto esta especificao conceitualmente similar a de multiplicidade de
Atributos e Operaes, h algumas diferenas importantes (OMG, 2002):

A multiplicidade de uma Extremidade de Associao no se aplica a todo o


conjunto de ligaes, e sim para projees de um conjunto de ligaes;

Como ligaes duplicadas no so permitidas em conjuntos de ligao da


camada M1, o sinalizador is_unique ( nico) implicitamente true
(verdadeiro). A checagem de ligaes duplicadas baseada na igualdade
das instncias que elas conetam.

Os limites inferior e superior de uma Extremidade de Associao


restringem o nmero de instncias de uma projeo, e.g., considere uma Associao
entre uma classe A e B, onde a Extremidade de Associao da classe A tem como
limite o intervalo [0..3], ento a projeo do conjunto de ligaes para qualquer
instncia de B precisa conter entre zero a trs instncias de A.
O sinalizador is_ordered ( ordenado) para uma Extremidade de Associao
determina se as projees da outra Extremidade possuem uma ordem. O Modelo
MOF permite que somente uma das duas extremidades de uma associao seja
marcada como ordenada.
4.4.3 Agregao (Aggregation)
Num metamodelo MOF, Classes e Tipos de Dados podem ser relacionados
com outras Classes usando Associaes ou Atributos. Em ambos os casos,
aspectos do comportamento das relaes podem ser descritos como semntica de
agregao.

54

4.4.3.1 Semntica da Agregao


O MOF suporta dois tipos de agregao para relaes entre instncias:
composta (composite) e no-agregada (non-aggregate). O terceiro tipo, chamado
de compartilhado, no mais suportado pela especificao do MOF 1.4.
Uma relao no-agregada uma ligao fraca entre instncias, e possui as
seguintes propriedades (OMG, 2002):

No h nenhuma restrio especial quanto multiplicidade das relaes;

No h nenhuma restrio especial quanto origem das instncias nas


relaes;

As relaes no afetam a semntica do ciclo de vida das instncias


relacionadas. Em particular, a remoo de uma instncia no causa a
remoo de instncias relacionadas.

Pelo contrrio, uma relao composta uma ligao mais forte entre
instncias, e possui as seguintes propriedades:

Uma relao composta assimtrica, com uma extremidade denotando o


composto ou o todo na relao e a outra denotando os componentes
ou partes;

Uma instncia no pode ser um componente de mais de um composto


num dado instante;

Uma instncia no pode ser um componente de si mesma, de seus


componentes, ou dos componentes de seus componentes, e assim por
diante;

Quando

uma

instncia

composta

removida,

todos

os

seus

componentes so removidos, e tambm todos os componentes dos


componentes, e assim por diante;

A Regra de Fechamento da Composio: uma instncia no pode ser um


componente de uma instncia de um pacote diferente.

4.4.3.2 Agregao de Associao


A semntica da agregao de uma Associao so explicitamente definidas
usando-se o Atributo aggregation (agregao) das Extremidades da Associao
(AssociationEnds). No caso de uma Associao composta, o Atributo aggregation

55

do elemento AssociationEnd do composto definido como true (verdadeiro) e o


Atributo aggregation do elemento AssociationEnd do componente definido como
false (falso). Tambm, a multiplicidade do elemento AssociationEnd do composto
deve ser [0..1] ou [1..1], em consonncia com a regra de que uma instncia no
pode ser um componente de compostos mltiplos (OMG, 2002).
4.4.3.3 Agregao de Atributo
A semntica efetiva de uma agregao para um Atributo depende do tipo do
Atributo. Por exemplo:

Um Atributo cujo tipo expresso como um DataType possui semntica


no-agregada;

Um Atributo cujo tipo expresso como uma Classe possui semntica


composta.

possvel usar um DataType para codificar o tipo de uma Classe. Fazer isto
permite que o metamodelo defina um Atributo cujo valor ou valores so instncias de
uma Classe sem causar a sobrecarga de semnticas compostas.
4.4.4 Referncias (References)
O Modelo MOF oferece dois construtores para a modelagem de relaes
entre Classes (i.e., Associaes e Atributos). Enquanto as Associaes e Atributos
MOF so similares do ponto de vista de modelagem da informao, eles tm
diferenas importantes do ponto de vista de seus modelos computacionais e suas
correspondentes interfaces mapeadas (OMG, 2002).
Associaes oferecem um modelo computacional guiado por consulta. O
usurio executa operaes sobre um objeto que encapsula uma coleo de
ligaes:

Vantagem: Os objetos da associao permitem que o usurio execute


consultas globais sobre todas as relaes, e no apenas para um
determinado objeto;

Desvantagem: As operaes do cliente para acesso e atualizao das


relaes tendem a ser mais complexas.

Atributos oferecem um modelo computacional guiado por navegao. O


usurio tipicamente executa operao do tipo get e set sobre um atributo.

56

Vantagem: O estilo get e set das interfaces simples, e tende a ser


mais natural para tpicas aplicaes orientadas a metadados;

Desvantagem: Realizar uma consulta global sobre uma relao expresa


como um Atributo computacionalmente intensivo.

O Modelo MOF oferece um tipo adicional de caracterstica de Classe


chamado de Referncia, que fornece uma alternativa semelhante viso de Atributo
de Associaes. Uma Referncia definida pelas seguintes caractersticas:

Um nome para a Referncia em sua Classe;

Uma Extremidade da Associao exposta (exposed Association End) em


alguma Associao cujo tipo esta Classe ou uma super-Classe desta
Classe;

Uma Extremidade da Associao referenciada (referenced Association


End), que a outra extremidade na mesma Associao.

Definir uma Referncia em uma Classe faz com que a interface resultante
contenha operaes com nomes que so idnticos queles para um Atributo
equivalente. Entretanto, no lugar de operar sobre os valores em um atributo de
uma instncia de uma Classe, estas operaes acessam e atualizam a Associao,
ou mais precisamente uma projeo da Associao. Isto ilustrado na notao UML
na figura 21.

Figura 21 Exemplo de uma Referncia (OMG, 2002)

A figura acima mostra uma Classe chamada My_Class_1 que relacionada


com a Classe My_Class_2 atravs da Associao My_Assoc. My_Class_1 tem um
Atributo chamado attr cujo tipo Integer. Alm disto, ele tem uma Referncia
chamada ref que referencia end2 (a extremidade 2) da Associao. Isto oferece
uma interface para ref que permite que um usurio acesse e atualize uma instncia
de My_Class_2 usando operaes do tipo get e set.

57

A figura acima tambm mostra uma Referncia que expe uma Extremidade
da Associao com uma multiplicidade de [1..1]. Referncias podem de fato expor
extremidades com qualquer especificao de multiplicidade vlida. As operaes de
Referncia resultantes so similares quelas para um Atributo com a mesma
multiplicidade. Entretanto, como as Associaes MOF no permitem duplicatas,
Extremidades de Associaes e portanto Referncias precisam sempre ter seu
sinalizador de multiplicidade is_unique definido como true (verdadeiro).
H algumas restries importantes sobre Referncias:

Quando a propriedade is_navigable de uma Extremidade de Associao


false (falsa), no permitido definir uma Referncia que referencia
esta Extremidade de Associao;

Uma instncia M1 de uma Classe que referencia uma Associao no


pode ser usada para fazer uma ligao em uma instncia da Associao
em um contexto diferente.

4.4.5 Tipos de Dados (DataTypes)


Definies de metamodelo freqentemente precisam usar valores de
parmetros de operao e atributos que tenham tipos cujos valores no tenham
identidade de objeto. O MOF oferece o conceito de metamodelagem de um Tipo de
Dado para preencher esta necessidade (OMG, 2002).
Tipos de Dados podem representar dois tipos de dados:
4) Tipos de dados primitivos como Boolean, Integer, e String so blocos de
construo bsicos para expressar estado. O MOF define seis tipos de
dados

padres

que

so

adequados

para

uma

metamodelagem

independente de tecnologia. (Outros tipos de dados primitivos podem ser


definidos por mapeamentos de tecnologias especficas ou como extenses
de um usurio ou de terceiros. Entretanto, a especificao do ncleo do
MOF no diz nada sobre o que eles significam).
5) Construtores de tipos de dados permitem ao metamodelador definir tipos
de dados mais complexos. Os construtores padres de tipos de dados do
MOF so enumerao (enumeration), estrutura (structure), coleo
(collection), e apelido (alias).

58

4.4.6 Pacotes
O Pacote o construtor do Modelo MOF para agrupamento de elementos em
um metamodelo. Pacotes servem para dois propsitos (OMG, 2002):
1) Na camada M2, Pacotes oferecem um meio de segmentar e modularizar o
espao do metamodelo. Pacotes podem conter muitos tipos de elementos
(e.g., outros Pacotes, Classes, Associaes, Tipos de Dados, Excees,
Constantes, e assim por diante).
2) Na camada M1, instncias de Pacotes atuam como recipientes para
metadados. Indiretamente, eles tambm definem o escopo dos conjuntos
de Associaes e de Operaes e Atributos em nvel de classificador
sobre instncias de Classes.
O Modelo MOF prov quatro mecanismos para composio e reuso de
metamodelos (i.e., generalizao, aninhamento, importao, e agrupamento).
4.4.6.1 Generalizao de Pacotes (Generalization Packages)
Pacotes podem ser generalizados por um ou mais Pacotes em um modo
anlogo ao de generalizao de uma Classe. Quando um Pacote herdado de
outro, o sub-Pacote herdado adquire todos os elementos de metamodelagem
pertencentes ao super-Pacote. A herana de Pacotes est sujeita a regras que
previnem a coliso de nomes entre elementos locais e herdados.
Na camada M1, uma instncia de um sub-Pacote tem o poder de criar e
gerencias suas prprias colees de instncias de Classes e suas ligaes. Isto
aplica-se s Classes e Associaes definidas explicitamente, e quelas herdadas.
A relao entre instncias de um super-Pacote e seus sub-Pacotes similar
relao entre instncias de uma super-Classe e suas sub-Classes:

A instncia de um sub-Pacote tipo substituvel para instncias de seus


super-Pacotes (i.e., a instncia do sub-Pacote uma instncia do superPacote);

Uma instncia de um sub-Pacote no usa ou depende de uma instncia do


super-Pacote (i.e., no h nenhuma relao do tipo parte de).

Pacotes podem ser definidos como Pacotes raiz ou folha (com significado
anlogo ao de Classes raiz ou folha), porm Pacotes no podem ser abstratos.

59

4.4.6.2 Aninhamento de Pacote (Package Nesting)


Um Pacote pode conter outros Pacotes, o qual pode por sua vez conter outros
Pacotes. Elementos de modelagem definidos em Pacotes aninhados podem ser
fortemente acoplados com outros elementos de modelagem na mesma conteno.
Por exemplo, uma Classe em um Pacote aninhado pode ter uma Referncia que a
conecta por uma Associao em seu contexto, ou sua semntica pode ser coberta
por uma Restrio definida pelo usurio no Pacote que o cerca.
Um Pacote aninhado um componente de seu Pacote que o cerca. Como,
em geral, os elementos de modelagem em um Pacote aninhado podem ser
inseparavelmente associados com seu contexto, h algumas restries significativas
em como os Pacotes aninhados podem ser compostos. Em particular:

Um Pacote aninhado no pode generalizar ou ser generalizado por outros


Pacotes;

Um Pacote aninhado no pode ser importado ou agrupado por outros


Pacotes.

Pacotes aninhados no so diretamente instanciveis. Nenhuma fbrica de


objetos ou operao definida para instncias de Pacotes aninhados. Uma instncia
da camada M1 de um Pacote aninhado pode existir somente em conjuno com
uma instncia de seu Pacote que o contm. Conceitualmente, uma instncia de um
Pacote aninhado um componente de uma instncia de seu Pacote que o contm.
Concluindo, o principal efeito do aninhamento de um Pacote em outro dividir
os conceitos e o espao de nomes (namespace) de outro Pacote. Aninhar no um
mecanismo para reuso. Na realidade, quando um Pacote aninhado, a sua
capacidade de reusabilidade restringida.
4.4.6.3 Importao de Pacotes (Package Importing)
Em muitas situaes, a semntica de aninhamentos e generalizaes de
Pacotes no oferece o melhor mecanismo para composio de metamodelos. Por
exemplo, o metamodelador pode querer reusar alguns elementos de um
metamodelo existente e no outros. O MOF fornece um mecanismo de importao
que suporta esta caracterstica.

60

Um Pacote pode ser definido atravs da importao de um ou mais Pacotes.


Quando um Pacote importa outro, o Pacote importador pode fazer uso dos
elementos do Pacote importado.
Aqui esto alguns exemplos de como um Pacote pode reusar elementos
importados. O Pacote importador pode declarar:

Atributos, Operaes, ou Excees usando Classes ou Tipos de Dados


importados;

Operaes que lanam Excees importadas;

Tipos de Dados e Constantes usando Tipos de Dados ou Constantes


importadas;

Classes cujas super-Classes so importadas;

Associaes para as quais os tipos de uma ou ambas as Extremidades de


Associaes uma Classe importada.

Na camada M1, uma instncia de um Pacote importador no tem uma relao


explcita com quaisquer instncias do Pacote importado. Diferente de um pacote
herdado (um sub-Pacote), um Pacote importador no tem o poder de criar instncias
das Classes importadas. A obteno de instncias da Classe importada no cliente
feita atravs de uma instncia independente do Pacote importado.
4.4.6.4 Agrupamento de Pacotes (Package Clustering)
O agrupamento de Pacotes uma forma mais forte de importao de Pacotes
que vincula o Pacote importador e o importado em um cluster (grupo). Assim como
nas importaes, um Pacote pode agrupar um nmero de outros Pacotes, e pode
ser agrupado por um nmero de outros Pacotes.
Uma instncia de um Pacote agrupador comporta-se como se os Pacotes
agrupados fossem aninhados dentro do Pacote, i.e., o ciclo de vida da instncia de
um Pacote agrupado determinado pelo ciclo de vida da instncia de seu Pacote
agrupador. Em particular:

Quando o usurio cria uma instncia de um Pacote agrupador, uma


instncia

de

cada

um

de

seus

Pacotes

agrupados

criado

automaticamente;

Todas as instncias dos Pacotes agrupados criados acima pertencem ao


mesmo domnio do Pacote agrupador;

61

A remoo de uma instncia de um Pacote agrupador automaticamente


remove todos as instncias dos Pacotes agrupados, e as instncias dos
Pacotes agrupados no podem ser removidas a no ser que a instncia de
seu Pacote agrupador seja removida.

Entretanto, diferente de um Pacote aninhado, possvel criar uma instncia


independente de um Pacote agrupado. Tambm, em algumas situaes, instncias
de Pacotes agrupados no so estritamente aninhadas. Entretanto, vale observar
que um Pacote agrupador pode ser agrupado ou herdar outro Pacote.
Concluindo, a relao entre as instncias da camada M1 em um agrupamento
de Pacotes que cada instncia de um Pacote agrupado um componente da
instncia do Pacote agrupador. Diferentemente de Pacotes aninhados, no h uma
relao composta entre os Pacotes da camada M2.
4.4.6.5 Sumrio dos Construtores de Pacotes
A tabela 6 mostra as propriedades dos quatro mecanismos de criao de
Pacotes definidos pelo Modelo MOF.
Tabela 6 Construtores de Pacotes (OMG, 2002)

Construtor
Aninhamento
Generalizao
/ Herana
Importao
Agrupamento

Relao Conceitual
P1 contm P2
P2 generaliza P1

Propriedades da
Relao na
Camada M2
P1
P2
P1
P2

Propriedades da
Relao na
Camada M1
P1
P2
P1
P2

P1 importa P2
P2 agrupa P1

P1
P1

nenhum
P1
P2 ou
nenhum

P2
P2

A simbologia da tabela baseada em UML, i.e., um diamante preenchido


significa composio, um diamante oco significa agregao, um triangulo oco
significa herana, e uma flecha pontilhada significa depende de.
Observe que P1 e P2 denotam entidades distintas, embora relacionadas, em
diferentes colunas da tabela:

Na coluna 2, eles representam Pacotes da camada M2 em um


metamodelo;

Na coluna 3, eles representam tanto Pacotes da camada M2 quanto


objetos de um metamodelo;

62

Na coluna 4, eles representam instncias do Pacote da camada M1


(quando sublinhados) ou seus tipos.

4.4.7 Restries (Constraints) e Consistncia (Consistency)


Os construtores do Modelo MOF descritos at agora permitem ao
metamodelador definir metadados que abrangem nodos (Classes) com propriedades
anexas (Atributos / Tipos de Dados) e relaes entre nodos (Associaes). Enquanto
os construtores acima so suficientes para definir a sintaxe abstrata consistindo de
nodos e ligaes compondo metadados, esta sintaxe tipicamente precisa ser
incrementada com regras de consistncia adicionais (OMG, 2002).
4.4.7.1 Restries
O Modelo MOF define um elemento chamado Restrio (Constraint) que pode
ser usado para anexar regras de consistncia a outros componentes do
metamodelo. Uma Restrio abrange:

Um nome;

Uma linguagem que identifica a linguagem usada para expressas as


regras de consistncia;

Uma expresso escrita na linguagem que especifica a regra;

Uma poltica de avaliao que determina quando a regra deve ser


colocada em ao;

Um conjunto de elementos restringidos.

Uma expresso de Restrio uma expresso em alguma linguagem que


pode ser avaliada no contexto de um metamodelo para decidir se ela vlida. A
especificao do MOF no define ou exige quaisquer linguagens especficas para
expresses de Restries, ou quaisquer mecanismos de avaliao particulares. De
fato, legtimo para Restries expressas em linguagem informal (e.g., Portugus) e
para validao serem implementadas. Entretanto, as Restries que so partes da
especificao do Modelo MOF so expressas em OCL (Object Constraint
Language), linguagem a qual definida na especificao do UML.
A poltica de avaliao de uma Restrio determina se a regra de consistncia
deve ser imposta imediatamente ou posteriormente.

63

Concluindo, o construtor Restrio usado para a especificao de regras de


consistncia para modelos ao invs de ser usado, por exemplo, para definir o
comportamento computacional de Operaes. considerado um mau estilo
especificar expresses de Restrio que afetem o estado de um modelo.
4.4.7.2 Consistncia Estrutural
Um metamodelo baseado em MOF define uma sintaxe abstrata para
metadados. Alguns aspectos da sintaxe abstrata so validados pela interface de
metadados do servidor. Entretanto, alguns aspectos da sintaxe abstrata s podem
ser validados atravs de checagens de consistncia estruturais realizadas
dinamicamente, ou seja, em tempo de execuo. Enquanto que muitas das
checagens

estruturais

so

realizadas

imediatamente,

outras

precisam

ser

postergadas (OMG, 2002).


No prtico para um metamodelo especificar desde o incio tudo o que pode
acontecer de errado em um servidor de metadados baseado em MOF. necessrio
ento reconhecer que o servidor MOF pode precisar realizar uma variedade de
checagens dinamicamente que no so definidas pelo metamodelo. Isto inclui
validaes de metadados adicionais que no so especificadas pelo metamodelo,
checagens de controle de acesso e recurso, e checagens de erros internos.
4.4.7.3 Mecanismos de Checagem de Consistncia
A

especificao

do

MOF

oferece

uma

grande

flexibilidade

para

implementaes de servidores de metadados na rea de checagem de restries ou


validao:

Suporte checagem de Restries no obrigatrio. Em particular, no


h a exigncia de suportar qualquer tipo de linguagem especfica para
expresses de Restrio;

O conjunto de eventos (caso houver) que pode ativar checagens


postergadas no especificado. Nenhum tipo de interface geral
especificado para iniciar a checagem de consistncia postergada;

Persistncia e intercmbio de metadados, o qual um estado de


inconsistncia pode ser permitido;

64

No h mecanismos definidos para assegurar que os metadados


validados continuem vlidos, ou que eles no mudem.

O aspecto de checagem de consistncia que obrigatrio que um servidor


de metadados precisa implementar todas as checagens de consistncia estruturais
que so designadas de imediato.
4.4.8 Demais Construtores de Modelagem
Esta seo descreve o significado dos elementos remanescentes do Modelo
MOF.
4.4.8.1 Constantes (Constants)
O elemento de modelagem Constante permite que o metamodelador defina
uma conexo simples entre um nome e um valor constante.
4.4.8.2 Excees (Exceptions)
O elemento de modelagem Exceo permite que o metamodelador declare
uma exceo que possa ser lanada por uma Operao.
4.4.8.3 Etiquetas (Tags)
O elemento de modelagem Etiqueta a base de um mecanismo que permite
que um metamodelo MOF puro seja estendido ou modificado. Uma Etiqueta
consiste de:

Um nome que pode ser usado para denotar a Etiqueta em seu recipiente
(container);

Uma identificao da etiqueta (tag id) que denota o tipo da Etiqueta;

Uma coleo de zero ou mais valores associados com a Etiqueta;

O conjunto dos elementos de modelagem aos quais a Etiqueta


anexada.

O significado de um elemento de modelagem conceitualmente modificado


anexando-se uma Etiqueta a ele. O tag id da Etiqueta classifica o significado
pretendido da extenso ou modificao. Os valores ento servem como
parmetros adicionais para incrementar o significado.

65

4.5 Cenrios de Uso do MOF


Um cenrio tpico de uso para o MOF oferecer suporte ao desenvolvimento
de softwares distribudos orientados a objeto a partir de modelos de alto-nvel. Tal
sistema ento consistiria de um servio de repositrios para o armazenamento dos
modelos e uma coleo de ferramentas relacionadas. Estas ferramentas ofereceriam
suporte importao e exportao de dados deste repositrio. Os dados a serem
importados seriam os prprios modelos, e as ferramentas poderiam auxiliar no
processo de exportar estes modelos em forma de cdigo, atravs da execuo de
transformaes bem-definidas.
Um repositrio MOF pode armazenar diversos tipos de modelos. Os
metadados contidos neste repositrio podem ser armazenados, por exemplo, pelo
uso de metaobjetos Java ou CORBA, sendo que estes metaobjetos podem ser
acessados respectivamente por suas interfaces Java ou CORBA. atravs destas
interfaces que os clientes dos repositrios obtm acesso aos metadados, podendo
executar quatro tipos de operaes bsicas: criao, leitura, alterao ou remoo
de metadados. A este conjunto de quatro operaes bsicas d-se o nome de
CRUD (create, read, update, delete).
Com uma ferramenta de modelagem de dados o usurio pode, por exemplo,
salvar os metadados criados pela ferramenta de modelagem diretamente no
repositrio, atravs do uso de interfaces Java. Estas mesmas ferramentas poderiam
acessar novamente os metadados salvos lendo diretamente os dados contidos no
repositrio. O desenvolvedor pode utilizar a interface que bem desejar para o acesso
ao repositrio, como por exemplo, ele poderia usar um documento XML baseado em
XMI (descrito na seo 4.6.2) para salvar os metadados e importar tais documentos
do repositrio para acess-los novamente.
Pode-se concluir, portanto, que o cenrio tpico de uso de MOF o MOF ser
utilizado como base para o gerenciamento de metadados. Como modelos formais
compem a base no processo desenvolvimento de software no MDA, e como estes
modelos so metadados, o gerenciamento automatizado de metadados no
pertence somente s etapas de anlise e projeto, mas tambm etapa de
implementao. Portanto, os metadados originados a partir do MOF podem ser
utilizados durante todo a vida do ciclo de desenvolvimento.

66

As interfaces usadas para manipular os modelos do repositrio so


especficas para cada tipo de modelo. Para um dado tipo particular de modelo, um
gerador fica ento encarregado de produzir as interfaces com suas respectivas
implementaes, a partir de um metamodelo MOF que descreve este tipo de
modelo, e.g., geradores poderiam produzir DTDs XML e Schemas que descrevem o
formado dos documentos XML usados para importar e exportar modelos, junto com
o cdigo que realiza de fato a importao e exportao (FRANKEL, 2003).
A ferramenta utilizada como base para o acesso aos dados do repositrio que
determina como os modelos so fisicamente armazenados, e.g., um banco de dados
Oracle, uma base de dados orientada a objeto, um sistema de arquivos comum,
atravs de arquivos XML, somente na memria, e assim por diante. Algumas
ferramentas MOF isolam a camada de persistncia, oferecendo implementaes
padro capazes de serem combinadas com outros tipos de implementaes de
persistncia. Alguns oferecem diversas opes de persistncia. No importando qual
a forma escolhida, os mapeamentos padronizados do MOF determinam as interfaces
e formatos XML usados para interagir com o repositrio, alm de serem
absolutamente independentes da forma com que os metadados so fisicamente
armezenados.
Uma maneira tpica de realizar o intercmbio de metadados entre repositrios
MOF, pertencentes a uma federao de de repositrios independentes um do outro
coexistindo em diferentes sistemas, seria atravs de importaes/exportaes de
documentos XML. O uso de interfaces CORBA ou Java nestas transaes tem como
desvantagem restries quanto passagem de seus dados por firewalls.
Repositrios MOF podem at mesmo ser utilizados em conjunto com Web
Services. A OMG vem atualmente desenvolvendo um mapeamento MOF-WSDL que
pretende tornar isto vivel.
4.6 Anlise de Tecnologias Correlatas ao MOF
Esta seo faz uma anlise sobre as principais tecnologias relacionadas com
o MOF. Dentre elas tem-se o CORBA (Common Object Request Broker
Architecture), o XMI (XML Metadata Interchange) e o JMI (Java Metadata Interface).

67

4.6.1 Anlise do CORBA frente ao MOF


Existe um falso consenso em relao ao MOF de que ele baseado e
estritamente ligado ao CORBA. Quando o MOF foi lanado em 1997, CORBA era
considerado o modelo de programao revolucionrio. Assim, havia um forte
interesse na organizao em criar um forte elo de dependncia entre MOF e
CORBA, tanto que algumas das primeiras verses de MOF usaram como tipos de
dados primitivos os mesmos tipos do CORBA. A verso 1.4 do MOF mudou isto,
definindo um conjunto de tipos de dados primitivos mais neutro (FRANKEL, 2003).
Portanto, os arquitetos de MOF evitaram este tipo de dependncia porque
atrelar o MOF a uma plataforma especfica reduziria seu campo de ao. Contudo,
ao escolherem emprestar alguns dos construtores de modelagem de UML para
serem os construtores de modelagem de MOF, eles acabaram criando uma forte
associao entre MOF e UML.
4.6.1.1 MOF no Baseado em CORBA
Como a especificao oficial do MOF possui sees inteiras dedicadas
especialmente a mapeamentos MOF-CORBA, muitas pessoas tm a impresso de
que o MOF um padro baseado em CORBA. Como dito anteriormente, MOF
totalmente independente de CORBA, mas no pelo fato do CORBA ser
considerado uma plataforma importante e o mapeamento MOF-CORBA tambm ser
importante que o MOF pode ser visto como fortemente baseado em CORBA. O
verdadeiro intuito dos arquitetos do MOF acima de tudo fazer com que o MOF
possa ser mapeado para mltiplas tecnologias.
O mapeamento para CORBA define regras para representao de metadados
atravs de metaobjetos CORBA. O mapeamento especifica como transformar uma
sintaxe abstrata de um metamodelo em uma interface baseada em CORBA IDL. As
interfaces oferecem uma maneira de representar qualquer uma das instncias
(modelos) de um metamodelo qualquer como objetos CORBA.
4.6.1.2 Mapeamento alm da Sintaxe
O mapeamento MOF-CORBA no se limita em criar somente a sintaxe das
interfaces CORBA-IDL produzidas a partir da sintaxe abstrata de um determinado

68

metamodelo. Se assim fosse, saber-se-ia somente quais operaes CORBA foram


geradas, mas no o que elas fazem, ou seja, no se saberia qual a semntica
destas operaes. Assim, o mapeamento tambm mapeia a semntica destas
interfaces, incluindo todos os seus correspondentes comportamentos, como o fato
de que uma implementao de uma operao de remoo de um metaobjeto deve
tambm remover todos os objetos pertinentes via agregao composta.
Atravs da especificao da semntica das interfaces em combinao com a
sua sintaxe, o mapeamento torna possvel aos compiladores MOF gerar tambm as
implementaes

destas

interfaces.

Isto

promove

interoperabilidade

entre

implementaes distintas de interfaces.


4.6.1.3 O Mapeamento MOF-CORBA
O primeiro metamodelo MOF padronizado pela OMG foi o metamodelo UML.
A OMG aplicou ento o mapeamento MOF-CORBA a este metamodelo. O resultado
deste mapeamento foi uma especificao de como representar modelos UML como
metaobjetos CORBA atravs de um conjunto de interfaces CORBA IDL. Estas
interfaces oferecem suporte s operaes CRUD sobre os modelos UML. A idia
que clientes baseados em CORBA de um repositrio de metadados usassem estas
interfaces (FRANKEL, 2003).
Mais tarde, a OMG padronizou mais metamodelos e tambm aplicou o
mapeamento MOF-CORBA a eles, como por exemplo, o mapeamento dos
metamodelos do CWM em interfaces CORBA baseadas em IDL. Assim, modelos
CWM podem ser representados como metaobjetos CORBA.
4.6.2 Anlise do XMI
XMI (XML Metadata Interchange) um padro importante baseado em MOF
devido a grande popularidade de XML nos sistemas distribudos da atualidade. XML
tornou-se popular aps a especificao do MOF ser escrita. A medida que XML
comeou a ser usado para a representao de metadados, ele passou a ser usado
como um excelente meio para o intercmbio destes metadados.
Como o MOF foi projetado para ser independente de qualquer tipo de
plataforma, a criao de um mapeamento MOF-XML foi simples de ser definida. Em
1998 a OMG padronizou este mapeamento, criando ento o XMI.

69

XMI tambm define um conjunto de regras para a produo de documentos


XML que possam ser validados com um DTD gerado. Estas regras so necessrias
porque as regras de produo de DTD especificam somente a sintaxe dos modelos.
Se o XMI s fosse utilizado para tal, seria como se um mapeamento MOF-IDL
especificasse somente a sintaxe e no a semntica das interfaces geradas de
CORBA baseadas em IDL. As regras de produo de documentos XMI especificam
a semntica da informao XML que por sua vez validada por um XMI DTD
(FRANKEL, 2003).
As regras de XMI para a produo de DTDs e documentos fazem tambm
que seja possvel no somente gerar DTDs a partir de um metamodelo
automaticamente, mas tambm gerar o cdigo de implementao que importa
modelo de e para um repositrio de metadados.
Por exemplo, um gerador MOF que conhea as regras de mapeamento MOFCORBA e MOF-XML pode produzir cdigo que leia modelos a partir de um
repositrio de metadados baseado em CORBA atravs das interfaces CORBA
derivadas do MOF, e em seguida export-las via XMI. Um gerador MOF pode
tambm produzir cdigo que importa um documento XMI representando um modelo
e usa as interfaces CORBA para popular o repositrio com o modelo.
4.6.2.1 Funcionamento do XMI
O XMI, como ferramenta de intercmbio de metadados, pode mapear um
modelo qualquer das camadas M3 e M2 em um DTD XML que armazenar a
estrutura deste modelo. Pode tambm mapear um modelo qualquer das camadas
M2 e M1 para um documento XML que armazenar todas as propriedades de todos
os elementos deste modelo.
Os DTDs produzidos a partir da camada M3 validam documentos XML da
camada M2, e os DTDs produzidos a partir da camada M2 validam documentos XML
da camada M1. A OMG criou alguns DTDs padres, como o DTD do MOF,
produzido a partir da camada M3, e o DTD do UML, produzido a partir da camada
M2. A figura 22 exibe um esquema do funcionamento do XMI sobre todas as
camadas, mostrando seu campo de atuao.

70

Figura 22 Esquema de funcionamento do XMI

4.6.2.2 XMI e XML Schema


Em 2001 a W3C, organizao proprietria da especificao do XML, criou
uma especificao sucessora dos DTDs de XML, chamada de XML Schema. No
mesmo ano a OMG adotou uma nova especificao para o XMI (o XMI Schema), o
qual define um mapeamento do MOF para o XML Schema. Esta nova especificao
do XMI tambm incrementa o nvel de parametrizao das transformaes MOFXML.
4.6.2.3 Uma Falsa Crena sobre o XMI
UML o metamodelo MOF mais conhecido e utilizado atualmente. Como
resultado, o XMI DTD para UML que foi gerado a partir do metamodelo UML o XMI
DTD mais conhecido. Muitas ferramentas UML passaram ento a oferecer suporte a
importao e exportao de modelos UML atravs de documentos XMI que validam
estes ltimos contra este DTD.
Devido a este fato, muitas pessoas na indstria encontraram no XMI a
soluo para a realizao de intercmbio de modelos UML entre ferramentas. Ento,
h uma falsa crena de que o XMI simplesmente um DTD especfico para o

71

intercmbio de modelos UML, enquanto funciona na verdade como uma forma de


produzir DTDs para um metamodelo qualquer.
Assim, comum existirem no mercado ferramentas que dizem suportar XMI,
enquanto na verdade estas ferramentas apenas suportam o intercmbio de modelos
UML. Para uma ferramenta oferecer suporte completo ao XMI ela deve ser capaz de
atuar como um gerador que produz XML DTDs ou Schemas a partir de um
metamodelo qualquer, e tambm oferecer suporte gerao de cdigo que
implementa a importao e exportao de documentos XMI em repositrios MOF de
acordo com o DTD ou Schema gerado.
4.6.2.4 Gerao Manual e Automtica de DTDs e Schemas
interessante fazer uma comparao e entre a gerao manual de DTDs e
Schemas e a gerao destes feitas a partir do XMI, e analisar as implicaes desta
comparao.
Um DTD ou Schema gerado manualmente muito mais inteligvel e simples
do que os gerados automaticamente atravs do uso de XMI, e isto pode ser mal
visto pelos desenvolvedores acostumados com o uso de XML. Porm, um dos
conceitos fundamentais do MDA liberar os desenvolvedores da repetitiva tarefa de
implementao onde o cdigo pode ser gerado automaticamente. J que os XMI
DTDs e Schema no so feitos para serem lidos e escritos por seres humanos, mas
sim para serem lidos e escritos por mquinas, a forma com que os XMI DTDs e
Schema so escritos irrelevante.
4.6.2.5 XMI e UML
Outro problema referente ao XMI que os DTDs e Schemas gerados para
representar modelos UML so enormes e mal modularizados. Porm, a culpa deste
problema no pertence somente ao XMI, mas sim ao metamodelo UML 1.X, o qual
complexo e no possui um bom gerenciamento das dependncias entre seus
elementos. Se um compilador XMI recebe um grande metamodelo como entrada, um
grande DTD ser gerado como sada. Se dependncias entre os elementos do
metamodelo, ento tambm haver dependncias excessivas no DTD gerado
(FRANKEL, 2003).

72

Muitos dos problemas existentes no metamodelo UML esto sendo estudados


e provavelmente deixaro de existir na verso 2.0. O UML 2.0 ainda ser muito
grande porque o seu alcance extenso. Mas assim que ele for melhor modularizado,
os XMI DTDs e Schemas gerados a partir de um novo metamodelo sero melhor
modularizados.
4.6.2.6 XMI e o Intercmbio de Diagramas UML
Como o metamodelo UML no cobre a notao grfica de UML, e portanto
no contm elementos como caixa e linha, um XMI DTD para UML no especifica o
formato da notao grfica contidas em diagramas UML.
Embora o suporte ao intercmbio de diagramas no seja obrigatrio, este
intercmbio seria til. Os arquitetos responsveis pela criao do metamodelo UML
2.0 tm como um dos objetivos criar este metamodelo de forma a suportar a
descrio de diagramas.
4.6.3 Anlise do JMI
O JMI (Java Metadata Interface) foi criado pelo Java Community Process
(JCP) da Sun, e viabiliza o mapeamento MOF-Java. O JMI define regras para a
representao de metadados como objetos Java. A definio da transformao
especifica como transformar a sintaxe abstrata de um metamodelo em interfaces
Java. Estas interfaces oferecem um meio de representar modelos como metaobjetos
Java, para o conjunto de modelos que esto em conformidade com o metamodelo
relacionado. O JMI no somente define a sintaxe das interfaces geradas, como
tambm define a sua semntica (FRANKEL, 2003).
4.7 Aplicaes Adicionais
Esta seo apresenta uma linguagem textual utilizvel por humanos que
baseada no MOF, e apresenta um novo recurso do XMI, o qual viabiliza
mapeamentos reversos.

73

4.7.1 HUTN (Human Usable Textual Notation)


H situaes onde ao analisar um modelo UML, no possvel ver todas as
suas propriedades olhando-se apenas para os diagramas. Algumas dessas
propriedades s so visveis ao selecionarem-se os respectivos dilogos de
propriedade. Portanto, h momentos em que pode ser conveniente exibir todas
essas propriedades de forma linear num texto legvel para os humanos. Assim,
haveria um modo de examinar detalhadamente todas as propriedades do modelo.
(FRANKEL, 2003)
A especificao do HUTN (Human Usable Textual Notation) pretende ento
fazer com que outras especificaes em termos de UML Profiles para Enterprise
Distributed Computing (EDOC) e seu companheiro UML Profile para CORBA.
Os trs principais benefcios oferecidos pelo HUTN so:

uma especificao genrica que oferece uma linguagem para uma


notao textual utilizvel por humanos para qualquer modelo MOF;

Esta linguagem, por ser bem-definida, pode ser completamente usada


para automatizar o processo de produo de documentos HUTN;

Esta linguagem pode ser configurada para melhor atender ao critrio da


usabilidade humana.

Atravs da futura criao de um mapeamento MOF-HUTN, um metamodelo


acompanhado de alguns parmetros de mapeamento poder ser utilizado por um
gerador para produzir uma linguagem HUTN para modelagem de acordo com o
metamodelo escolhido.
4.7.2 Mapeamento Reverso de XMI
Como h XML DTDs e Schemas que no so compatveis com o XMI, no
possvel realizar o intercmbio destes modelos atravs do XMI. Muitas indstrias
criaram dezenas destes documentos incompatveis com o XMI antes deste ltimo
ser criado. Uma maneira criada para tentar resolver este problema, e fazer com que
estes documentos possam ser usados pelo XMI, foi a criao de regras de
transformao para o mapeamento reverso de XML DTDs e Schema para um
metamodelo MOF. A partir deste metamodelo MOF gerado, possvel realizar uma
transformao deste para interfaces compatveis com MOF de qualquer tipo, e.g.,

74

pode-se utilizar o mapeamento MOF-DIL, MOF-Java, e inclusive o MOF-XML. Em


outras palavras, a criao destas regras de transformao reversa permite a gerao
direta de XML DTDs e Schemas compatveis com o XMI a partir de XML DTDs e
Schemas no compatveis com o XMI (FRANKEL, 2003).
Como os XML DTDs e Schemas no compatveis com XMI no conseguem
expressar toda a semntica que um metamodelo MOF poderia, este mapeamento
reverso precisa da interveno humana para preencher as lacunas referentes a
semntica no expressa nestes documentos. Portanto, tipicamente um metamodelo
MOF produzido por uma ferramenta de mapeamento reverso deve ser melhorado
por um modelador antes de ser utilizado por qualquer outro tipo de ferramenta. Para
tal, deve-se assumir que h documentao suficiente disponvel sobre a semntica
do DTD ou Schema originais.
4.8 Desvantagens
O MOF possui vrias fraquezas, e as principais delas sero abordadas nesta
seo.
4.8.1 Falta de Suporte a Notao Grfica
MOF no tem uma linguagem para a definio de uma notao grfica.
Assim, se voc precisa de uma notao grfica otimizada para um determinado tipo
de modelo definido por um metamodelo, na h uma maneira de associar possveis
construtores de notao grfica com os construtores definidos pelo metamodelo.
Conseqentemente, no h como existirem ferramentas de desenvolvimento MDA
que suportam novas notaes grficas atravs da leitura de um documento que
contenha definies de um tipo de notao grfica qualquer (FRANKEL, 2003).
4.8.2 Desalinhamento com UML
Nas atuais verses de MOF 1.X e UML 1.X ainda no h um completo
alinhamento do ncleo das suas sintaxes abstratas. Apesar do alinhamento
existente atualmente ser quase completo, ser quase completo no basta.
necessrio que o ncleo de ambos sejam completamente alinhados (FRANKEL,
2003).

75

4.8.3 Problemas de Mapeamento MOF-CORBA


O mapeamento MOF-IDL possui alguns problemas, e as interfaces
produzidas pelas regras de gerao atualmente existentes no so eficientes em
sistemas distribudos (FRANKEL, 2003).
Alguns destes problemas podem ser resolvidos aplicando-se algumas
alteraes ou na definio do mapeamento MOF-CORBA ou estendendo-se as
Interfaces MOF Reflexivas.
Outra deficincia do mapeamento que o suporte atualmente oferecido aos
parmetros de transformao limitado, e deve ser incrementado.
4.8.4 Problemas de Interoperabilidade
Em teoria, qualquer modelo exportado por uma ferramenta deveria poder ser
importado por outra ferramenta que tambm conhea o metamodelo do modelo em
questo. Entretanto, h problemas quanto a este tipo de operao devido
imaturidade dos padres atualmente existentes, j que os padres baseados em
MOF so relativamente novos (FRANKEL, 2003).
4.9 Vantagem Principal
Pode-se concluir sucintamente com o que foi apresentado neste captulo
sobre o MOF que uma das principais maneiras de tirar vantagens diretas e imediatas
desta nova tecnologia na gerao automtica de interfaces e XML DTDs e
Schemas, ao invs de ger-los manualmente (FRANKEL, 2003).
4.10 Futuro do MOF
Em 2001, a OMG editou trs RFPs (Request for Proposal) para o MOF 2.0.
No geral, estas requisies procuram resolver os problemas citados anteriormente.
Provavelmente em 2004 (o ano em que o presente trabalho foi escrito) as
especificaes do MOF 2.0 sero finalizadas. Porm, ainda h um longo caminho
pela frente para o completo e perfeito amadurecimento desta tecnologia.

76

5 CASO REAL DE USO DO MOF: PARLAY


Atualmente, a situao do mercado de telecomunicaes est rapidamente
mudando devido convergncia da Internet e de redes de telefonia, e tambm
devido derrubada do monoplio em diversos pases. Isto oferece grandes desafios
e

oportunidades

para

os

provedores

de

servios

de

telecomunicao

(FARSHCHIAN, 2004).
Um destes desafios a competio acirrada para oferecer os melhores
servios para os clientes. O abandono do mercado monopolista criou o positivo
surgimento de vrias tecnologias, porm cria uma barreira na interoperabilidade dos
servios das empresas.
Cada vez mais se cobra uma maior otimizao no processo de
desenvolvimento de aplicaes na rea de telecomunicaes. O abandono do
mercado monopolista fez com que muitos dos recursos da rede j existentes
tivessem que ser adaptados para serem usados por servios de terceiros e por
provedores de aplicaes.
Aplicaes na rea de redes convergentes cada vez mais possuem em sua
organizao software, diferente dos tradicionais servios de telecomunicao onde o
software desempenhava um papel mais modesto. Desenvolvedores de aplicaes
recorrem a freqentemente complexas solues de software para acesso e
utilizao de recursos de rede oferecidos por operadores de rede. Software tambm
usado para criar aplicaes inovadoras que fazem uso de uma mistura de recursos
de rede (e.g. aplicaes operando transparentemente tanto na Internet quanto nas
redes telefnicas e utilizando bancos de dados corporativos).
A grande competio e a natureza inovadora presente nas redes
convergentes cria a necessidade de processos de desenvolvimento que permitam
um rpido desenvolvimento de aplicaes, de modo que os desenvolvedores
possam utilizar-se de diferentes tipos de aplicaes sem ficarem dependentes de
muitos recursos. Muito do que vem sendo utilizado e considerado importante na rea
de engenharia de software, como reusabilidade e orientao a objeto, vem se
tornando cada vez mais importante no domnio das telecomunicaes.
Uma das principais barreiras nesta rea de desenvolvimento justamente a
reusabilidade.

Redes

de

telecomunicaes

pertenceram

tradicionalmente

77

empresas privadas, e foram desenvolvidas como um resultado de alianas


estratgicas entre produtores de equipamentos e operadores de rede. Aplicaes
similares tiveram que ser desenvolvidas repetidas vezes em cada plataforma
privada. Esta situao no deve mudar num futuro prximo, devido ao macio
investimento realizado sobre estas tecnologias privadas. Porm, o incrvel aumento
do nmero e das variaes dos servios oferecidos torna esta situao crtica. H
uma necessidade urgente de habilitar aos desenvolvedores de aplicaes o poder
de reusar suas aplicaes em plataformas privadas (FARSHCHIAN, 2004).
5.1 O Middleware Parlay
Importantes iniciativas esto sendo tomadas para abordar as questes
levantadas acima. Uma delas o prprio MDA, descrito neste trabalho, e a outra a
criao do Parlay. O Parlay uma especificao de middleware orientada a objeto e
independente de plataforma desenvolvida para o domnio de telecomunicaes, e foi
criada por uma organizao sem fins lucrativos como uma especificao aberta. O
Parlay promove independncia da rede para o desenvolvimento e para a
implantao de servios e aplicaes na rea de telecomunicaes, e permite que
operadores de rede compartilhem seus recursos de rede em uma maneira
sistemtica e padronizada. O reuso habilitado no nvel de componente. Embora o
Parlay permita que provedores de servios reusem seus servios em mltiplas
redes, h um pequeno suporte para reuso no campo de modelagem de aplicaes.
A importncia do MDA neste contexto a abordagem de reuso no nvel da
modelagem de domnio (FARSHCHIAN, 2004).
As tcnicas convencionais de desenvolvimento de servios em redes de
telecomunicaes permitem somente que os operadores de rede desenvolvam
aplicaes (e.g., mensagem de voz, funes de siga-me) baseados em seus
prprios servios. Estes servios so normalmente desenvolvidos especificamente
para uma rede privada, e no podem ser reusados em outro contexto, como mostra
a figura 23, ilustrando o tpico caso onde o operador de rede tambm o
desenvolvedor da aplicao, e onde os servios e interfaces so privados.

78

Figura 23 Desenvolvimento tradicional de aplicaes em redes de telecomunicaes


(FARSHCHIAN, 2004)

Atravs do uso do Parlay, a reusabilidade destas aplicaes aumentada, j


que o Parlay define uma interface padro entre o desenvolvedor da aplicao e o
provedor de servios, como pode ser visto na figura 24.

Figura 24 Desenvolvimento de aplicaes em redes de telecomunicaes usando o Parlay


(baseado em FARSHCHIAN, 2004)

Nas figuras ilustradas acima, o domnio dos recursos abrange recursos como
redes fixas e mveis. Atravs do uso das interfaces do Parlay, as aplicaes dos
desenvolvedores podem utilizar os servios invocando mtodos da interface, que por
sua vez fazem uso dos recursos da rede. Esta abordagem habilita o

79

desenvolvimento de aplicaes complexas que utilizam uma mistura de servios e


recursos (e.g., telefonia fixa e mvel, Internet, bancos de dados corporativos). Esta
abordagem tambm aumenta o nvel de reusabilidade fazendo com que a
especificao da aplicao seja independente da rede a ser utilizada.
A Interface Estrutural (Framework Interface) um componente de
autenticao e servio padronizado em qualquer implementao do Parlay. Ela
fornece mtodos padres para autenticao de aplicaes externas de terceiros que
desejam fazer uso dos servios de rede. A Interface Estrutural tambm oferece
mtodos padres para a descoberta de servios existentes em uma rede. A
arquitetura do Parlay pode ser vista na figura 25.

Figura 25 Arquitetura do Parlay (FARSHCHIAN, 2004)

Interfaces de servio oferecem mtodos de acesso padro aos servios de


telecomunicaes. A especificao do Parlay contm um grande nmero de tais
definies de servio (e.g., controle de chamada, controle de sesso, transmisso de
mensagem, gerenciamento de conta) mas permite que novos servios sejam
adicionados. Uma aplicao externa tem que ser autenticada antes que ela possa
referenciar os servios desejados. Uma vez que um contato seja estabelecido com
um servio, a aplicao pode usufruir deste servio (FARSHCHIAN, 2004). O Parlay
tambm especifica um mecanismo de retorno que permite que servios invoquem
mtodos da aplicao (e.g., notificar uma aplicao se uma chamada feita para um
nmero especfico).

80

O Parlay capacita o reuso alm do que est disponvel hoje nas redes de
telecomunicaes. Definies de servio podem ser reusadas. A mesma definio
de srvio pode ser usada em distintos tipos de recursos, e.g., um servio de
controle de chamada pode ser usado para conectar usurios usando telefones
mveis, fixos, ou de Internet, sem que a interface do servio seja alterada para cada
tipo de telefone. Alm disso, o Parlay habilita a reusabilidade no nvel da aplicao,
e este o seu ponto forte. Aplicaes precisam negociar somente com a interface do
Parlay. Desenvolvedores podem especificar suas aplicaes sem levar em
considerao em que tipo de rede essas aplicaes sero usadas.
Embora o Parlay permita o reuso de componentes (servios), ele no oferece
suporte ao reuso em alto-nvel, como reuso no nvel de modelo de aplicao. O que
acontece no nvel de modelo de aplicao, e.g., que modelos de domnio so
desenvolvidos e reusados, est fora do escopo do Parlay. a que entra a
abordagem do MDA (FARSHCHIAN, 2004).
5.2 Relao entre Parlay, MDA e MOF
Um dos objetivos da equipe de desenvolvimento do Parlay integr-lo com o
MDA,

aumentando consideravelmente

o nvel de

reusabilidade.

Um

PIM

representando uma aplicao para redes de telecomunicaes pode ser


transformado em um PSM pra uma plataforma de rede de telecomunicao
especfica, graas ao metamodelo Parlay construdo atravs do uso do MOF. A
relao entre estas entidades pode ser vista na figura 26.

81

Figura 26 Desenvolvimento baseado em MDA de aplicaes que usam Parlay


(baseado em FARSHCHIAN, 2004)

Para que esse processo possa ser utilizado necessrio definir um


metamodelo para o domnio da telecomunicao. Este metamodelo deve ser,
claro, uma instncia do metametamodelo MOF, e ir ter um enfoque nas
necessidades da indstria de telecomunicaes.
Desenvolver tal metamodelo um grande desafio. Ele deve conter um poder
de expresso suficiente para satisfazer tanto as necessidades da telecomunicao
quanto as necessidades do crescente nmero de servios e aplicaes que so
baseadas em redes convergentes. Tal metamodelo pode ser desenvolvido como
uma linguagem de modelagem completamente nova, ou como uma especializao
de UML (UML Profile). Em ambos os casos, a concordncia com MOF crucial para
permitir interoperabilidade atravs do uso de ferramentas MDA.
Vale frisar que dois metamodelos precisam ser construdos para habilitar o
processo de desenvolvimento baseado no Parlay e MDA. O primeiro metamodelo
o que oferece a capacidade de modelar conceitos referentes ao domnio da
telecomunicao, i.e., o metamodelo usado para a criao de PIMs. O segundo
metamodelo o que oferece a capacidade de modelar conceitos referentes
plataforma especfica sobre a qual o Parlay ser implantado, i.e., o metamodelo
usado para a criao de PSMs. Regras de transformao entre estes metamodelos
precisaro ento ser criadas para habilitar uma efetiva transformao entre estes
metamodelos. O segundo metamodelo citado acima, em particular, ter como ponto
de partida de seu desenvolvimento as prprias especificaes de interface do
Parlay, que j esto documentadas em UML.

82

6 CONCLUSES
Desde o princpio da era da informtica at hoje, muito se evoluiu na rea de
engenharia de software. Os prximos anos so de grandes expectativas para
aprimoramento destas tcnicas de desenvolvimento. Os problemas da produtividade,
portabilidade,

interoperabilidade,

documentao

manuteno

vm

sendo

abordados de diversas maneiras. A mais inovadora e recente abordagem foi a


criao da arquitetura MDA (Model Driven Architecture) pela OMG (Object
Management Group). O MDA uma arquitetura dirigida a modelos, e para tal
oferece conceitos e recursos necessrios para lidar com esses modelos. O conceito
fundamental do funcionamento desta arquitetura a utilizao de modelos
independentes de plataforma (PIMs) para a especificao e desenvolvimento do
sistema, e na sua subseqente transformao automatizada em modelos de
plataforma especfica (PSMs).
Uma

das

peculiaridades

do

MDA

sobre

os

demais

mtodos

de

desenvolvimento criados at hoje, que a linguagem de modelagem usada para


criar estes modelos uma linguagem de metamodelagem nica e geral, o MOF
(Meta Object Facility). Como o prprio nome diz, o MOF oferece facilidades para
lidar com metaobjetos, que nada mais so do que objetos que descrevem
metadados, i.e., objetos que descrevem elementos de um determinado modelo.
Para uma melhor organizao da abstrao de dados frente a um processo
de desenvolvimento de um sistema qualquer, o MDA baseado numa arquitetura de
quatro camadas (ou metalevels). A primeira camada, a M0, contm os dados do
mundo real de um sistema. A segunda camada, a M1, contm os modelos que
descrevem os dados do mundo real. Instncias de elementos da camada M1 criam
dados ou objetos do mundo real na camada M0. A terceira camada, a M2, contm os
modelos dos modelos, i.e., os metamodelos, os quais descrevem os modelos da
camada M1. A quarta e ltima camada, a M3, contm os modelos dos metamodelos,
i.e., os metametamodelos. No MDA, existe um nico metametamodelo, que a
linguagem de metamodelagem MOF. Sendo o MOF o predecessor de todos e
quaisquer outros modelos do MDA, o MOF o ncleo do MDA.
Este grau de parentesco em comum existente entre todos modelos, o MOF,
viabiliza a realizao de transformaes entre modelos escritos a partir de

83

metamodelos distintos. Tais transformaes so definidas atravs de uma definio


de transformao, que formada por um conjunto de regras de transformao. As
transformaes podem satisfazer a algumas caractersticas desejveis como
ajustabilidade, rastreabilidade, consistncia incremental e bidirecionalidade.
A propriedade mais marcante no MOF a auto-descrio. O MOF definido
atravs dos construtores de modelagem do prprio MOF. O metamodelo MOF que
contm a definio do MOF um metamodelo padronizado pela OMG, e chamado
por conveno de o Modelo MOF.
As trs tecnologias mais fortemente relacionadas com o MOF so CORBA
(Common Object Request Broker Architecture), XMI (XML Metadata Interchange) e
JMI (Java Metadata Interface). O CORBA permite que metamodelos sejam
mapeados para o IDL do CORBA, criando assim um artefato que contm a
representao estrutural de um metamodelo. Este artefato uma interface, e que
pode ser usada para garantir a consistncia dos elementos da camada M1, que so
instncias do metamodelo da camada M2. Analisando a especificao oficial do
MOF pode-se ter a impresso de que o MOF uma linguagem dependente do
CORBA, mais na verdade so independentes. Verses iniciais do MOF continham
certo grau de dependncia, mas este vnculo foi eliminado na ltima verso. Embora
o CORBA seja apto a ser utilizado em conjunto com o MOF, cada vez mais ele vem
perdendo espao no mercado, e novas tecnologias vm sobrepondo seu lugar.
O XMI permite o intercmbio de metadados atravs da linguagem XML. A
partir de um metamodelo, dois artefatos podem ser gerados atravs do XMI. O
primeiro deles a representao em XML do metamodelo, descrevendo todas as
propriedades de todos os elementos do metamodelo. O segundo artefato um DTD
(Document Type Definition), o qual armazena informaes estruturais do
metamodelo e pode ser usado para a validao de modelos que sejam instncias
destes respectivos metamodelos. Atravs do XMI, tambm possvel executar uma
transformao reversa a partir de um DTD para a obteno do documento XML que
representa o metamodelo original. O XMI atualmente muito utilizado para o
intercmbio de modelos UML, motivo pelo qual surgiu uma crena errnea de que o
propsito de funcionalidade do XMI executar somente tal funo. Apesar dos DTDs
gerados automaticamente pelo XMI atravs de um metamodelo serem mais
desorganizados e no to compreensveis quanto os DTDs gerados manualmente, a
gerao automtica compensa esta desvantagem pois o ganho em produtividade e

84

rapidez muito maior. Pesquisas vm sendo feitas neste campo para produzir
regras de transformao que produzam um DTD mais modularizado. Enfim, o XMI
atende s necessidades de intercmbio de modelos requeridas pelas empresas,
contudo melhoras na modularizao dos artefatos gerados so necessrias.
O JMI um padro independente de plataforma para modelagem, criao,
armazenamento, acesso, consulta e intercmbio de metadados usando UML, XML e
Java. Um metamodelo escrito na linguagem MOF pode ser transformado em dois
artefatos atravs do JMI, analogamente s transformaes do CORBA e do XMI. O
primeiro deles uma coleo de metaobjetos Java que descrevem todos as
propriedades de todos os elementos do metamodelo original, e o segundo uma
interface Java que pode ser usada para garantir que a estrutura de instncias deste
metamodelo esteja correta. Uma grande vantagem do JMI perante os demais
padres de interface o fato dele ser baseado em Java, pois Java uma das
linguagens mais populares da atualidade.
O principal cenrio de uso da linguagem MOF no suporte a repositrios de
modelos

em

geral,

possibilitando

transformao, criao, leitura,

uma

maneira

genrica

para

consulta,

atualizao e remoo destes metadados,

independentemente da linguagem em que estes modelos foram escritos. Atualmente


j existem vrias ferramentas que atuam como repositrios para modelos baseados
em MOF, porm muito precisa ser melhorado nas especificaes do MOF para que
estes repositrios possam conseqentemente oferecer melhores recursos.
O MOF ainda possui inmeras deficincias, como falta de suporte a uma
notao grfica, desalinhamento com o UML, problemas de mapeamento MOFCORBA e problemas de interoperabilidade. Todos estas deficincias decorrem
principalmente do fato de que o MOF uma tecnologia recente e que vem
recebendo constantes melhorias. A verso 2.0 do MOF promete inmeras correes
e considerveis melhoras.
O MOF promete ser um grande aliado em situaes que exigem grande
reusabilidade e independncia de plataforma, como demonstrado na apresentao
do middleware Parlay, que encontrou no MDA e no MOF uma forma de obter ganhos
considerveis no processo de desenvolvimento de software para a rea de
telecomunicaes. O middleware Paraly um exemplo de sistema de grande porte
que requer vasta interoperabilidade para uma maior produtividade, e o MDA, em

85

conjunto com o MOF, vem a abrir portas para um processo de desenvolvimento


produtivo numa rea onde a demanda por software cada vez maior.
Enfim o MOF uma linguagem inovadora que promete inmeros benefcios
em conjunto com o MDA. Cada vez mais empresas no mundo todo vm aderindo a
estas novas tecnologias em busca de melhorias na produtividade. Apesar do
potencial destas tecnologias ainda no estar completamente aprimorado e s poder
ser plenamente usufrudo a longo prazo, o panorama revolucionrio de produo
automtica de cdigo a partir de modelos independentes de plataformas e o de livre
intercmbio e manuseio de modelos de tecnologias distintas promete grandes
avanos para o futuro.

86

7 REFERNCIAS BIBLIOGRFICAS
Common Object Request Broker Architecture - a whatis definition. Disponvel
em: <http://whatis.techtarget.com/definition/0,,sid9_gci213865,00.html>. Acesso em:
19 jan. 2004.
CORBA
Webopedia.com.
Disponvel
em:
<http://www.webopedia.com/TERM/C/CORBA.html. Acessado em: 20 jan. 2004.
DTD Wikipedia. Disponvel em: <http://en.wikipedia.org/wiki/DTD>. Acesso em: 22
jan. 2004.
FARSHCHIAN, Babak A.; JAKOBSSON, Sune; BERG, Erik. Coupling MDA and
Parlay to increase reuse in telecommunication application development. In:
ECOOP2002 Workshop on Model-based Software Reuse, 2002, Mlaga. Disponvel
em: <http://www.metamodel.com/wisme-2002/papers/farshchian.pdf>. Acesso em:
17 jan. 2004.
FRANKEL, David. Model Driven Architecture: Applying MDA to Enterprise
Computing. John Wiley & Sons OMG Press, jan. 2003.
Java Community Process. Java Metadata Interface (JMI) v1.0. Especificao, JCP,
jun. 2002.
Sun
Microsystems.
JMI
FAQ.
Disponvel
<http://java.sun.com/products/jmi/faq.html>. Acesso em: 14 jan. 2004.

em:

MILLER, Joaquin; MUKERJI, Jishnu. MDA Guide Version 1.0. OMG, mai. 2003.
Object Management Group. Meta Object Facility (MOF) v1.4. Especificao, OMG,
abr. 2002.
Object Management Group. XML Metadata Interchange (XMI) v2.0. Especificao,
OMG, mai. 2003.
Object Management Group. Common Warehouse Metamodel (CWM) v1.1. Volume
1. Especificao, OMG, mar. 2003.
Unified
Modeling
Language

Wikipedia.
<http://en2.wikipedia.org/wiki/UML>. Acesso em: 18 jan. 2004.

Disponvel

em:

WARMER, Jos. KLEPPE, Anneke; BAST, Wim. MDA Explained: The Model Driven
Architecture: Practice and Promise. Addison Wesley, abr. 2003. 192p.

87

GLOSSRIO
CORBA - O CORBA (Common Object Request Broker Architecture) uma
arquitetura

que

possibilita

que

peas

de

programas,

chamadas

objetos,

comuniquem-se entre si independentemente de qual linguagem de programao


elas foram escritas ou em que sistema operacional elas esto sendo executadas.
O conceito essencial no CORBA o Object Request Broker (ORB), que
possibilita que um programa cliente (o qual pode ser um objeto), numa rede com
clientes e servidores em diferentes computadores, possa requisitar servios a um
programa servidor ou objeto sem ter que entender onde o servidor est localizado na
rede distribuda ou qual a interface que o programa servidor possui. Para realizar
estas requisies ou enviar respostas entre os ORBs, programas usam o General
Inter-ORB Protocol (GIOP) e, para a Internet, o Internet Inter-ORB Protocol (IIOP). O
IIOP mapeia requisies e respostas GIOP para o Transmission Control Protocol
(TCP) em cada computador.
O texto de especificao do MOF faz referncia ao CORBA em vrios
momentos, principalmente referindo-se a sua linguagem de definio de interfaces
(IDL).
CWM - O CWM (Common Warehouse Metamodel) padroniza um meio para
modelagem de dados em uma empresa baseado em bancos de dados. composto
por vrias linguagens de modelagem (metamodelos), todas escritas em MOF.
DTD - Um DTD (Document Type Definition) especifica restries na estrutura de um
documento SGML ou XML. Pose ser incluso no prprio documento, mas
normalmente armazenado separadamente. A sintaxe dos DTDs de SGML e do XML
similar, mas no idntica.
DTDs so geralmente empregados para determinar a estrutura de um
documento XML ou SGML. Um DTD tipicamente descrever cada elemento
permitido, seus possveis atributos, e opcionalmente os possveis valores para esses
atributos. Descrever tambm a estrutura e as ocorrncias destes elementos.
DTDs podem ser gerados automaticamente atravs da arquitetura MDA.
Como abordado neste trabalho, mapeamentos MOF-DTD so viabilizados atravs
do XMI (XML Metadata Interchange).

88

IDL - Uma IDL (Interface Definition Language) uma linguagem de definio de


interface, i.e., uma linguagem ou uma simples sintaxe para a descrio de
interfaces de um componente de software.
IDLs so usadas em situaes onde o software em ambos os lados no
podem compartilhar semnticas de chamada comuns, referindo-se a maneira com
que a linguagem de computador fala com as rotinas, e.g., C e Pascal chamam
rotinas cada um ao seu modo, e em geral no podem invocar cdigo escrito na outra
linguagem. IDLs so um subconjunto de ambas, uma linguagem geral com a qual
ambas esto capacitadas a gerar cdigo independente de linguagem.
IDLs so mais comumente encontradas em softwares que permitem que
rotinas sejam chamadas em outras mquinas. Este mecanismo conhecido como
RPC (Remote Procedure Call). Nestes casos a semntica de chamada pode variar
no somente entre as linguagens, mas tambm devido arquitetura dos prprios
mecanismos.
O CORBA possui a sua prpria IDL, disponibilizando assim uma interface
comum para objetos de plataformas distintas. Este trabalho faz referncia ao IDL do
CORBA em vrios momentos, principalmente referindo-se ao mapeamento MOFIDL.
OMG - A OMG (Object Management Group) uma organizao aberta, um
consrcio sem inteno de lucro que produz e mantm especificaes para a
indstria de computadores voltadas aplicaes interoperveis. Dentre os membros
da OMG tem-se virtualmente toda grande empresa do planeta, e centenas de
empresas menores tambm.
A OMG foi fundada em 1989 por um grupo de vendedores, e inicialmente
tinha o propsito de criar uma arquitetura para objetos distribudos em redes. A
arquitetura criada foi CORBA (Common Object Request Broker Architecture).
De l pra c vrias outras especificaes foram criadas. Dentre as mais
conhecidas tm-se a criao da famosa linguagem de modelagem UML (Unified
Modeling Language), a criao da inovadora arquitetura MDA (Model Driven
Architecture), e de tecnologias correlacionadas a esta como a linguagem de
metamodelagem MOF (Meta Object Facility) e o CWM (Common Warehouse
Metamodel).

89

UML - O UML (Unified Modeling Language) uma linguagem de modelagem de


terceira gerao. um mtodo aberto usado para especificar, visualizar, construir e
documentar artefatos de sistema de software orientado em desenvolvimento. O UML
representa uma compilao das melhores prticas de engenharia que provaram
serem eficazes na modelagem de sistemas complexos e de grande porte.
A linguagem UML est fortemente relacionada com a linguagem MOF, pois a
linguagem UML foi definida pela linguagem MOF. Esta relao entre ambas as
linguagens muito importante na arquitetura MDA.

90

ANEXO ARTIGO

Metamodelagem com Meta Object Facility


Felipe de Luca Medeiros
Departamento de Informtica e Estatstica Universidade Federal de Santa Catarina (UFSC)
felipelmd@inf.ufsc.br

Abstract. MDA (Model Driven Architecture) provides productivity gains for


software system development life cycle, allowing automatic generation of code from
plataform independent formal models. This process is enabled by the MDA core, the
metamodeling language MOF (Meta Object Facility), that offers facilities to cope
with metaobjects, that are objects that can represent metadata. This thesis
comprises a study of MOF, a analisys of its advantages and disadvantages, of its
major related technologies and of a real use case of MOF.
Resumo. O MDA (Model Driven Architeture) promove ganhos de produtividade
para o ciclo de vida de desenvolvimento de um sistema de software, agregando a
capacidade de gerao automtica de cdigo a partir de modelos formais
independentes de plataforma. Este processo viabilizado pelo ncleo do MDA, a
linguagem de metamodelagem MOF (Meta Object Facility), que oferece facilidades
para lidar com metaobjetos, que so objetos capazes de representar metadados.
Este trabalho compreende um estudo do MOF, uma anlise de suas vantagens e
desvantagens, das principais tecnologias relacionadas e de um caso real de uso do
MOF.

1. Introduo
Atualmente ainda h inmeros problemas no desenvolvimento de sistemas de software,
sendo que os principais deles so produtividade, portabilidade, interoperabilidade e manuteno.
Uma boa manuteno s viabilizada quando a documentao est sempre alinhada com o cdigofonte, o que dificilmente ocorre aps as etapas iniciais de desenvolvimento. Produzir documentao
que ser inutilizada aps as fases iniciais traz prejuzos produtividade. A volatilidade das
tecnologias favorece a falta de portabilidade e cria barreiras interoperabilidade.
Para tentar acabar com estes inconvenientes e oferecer tcnicas que auxiliem em todo o ciclo
de vida de um software, a OMG (Object Managament Group) uma organizao sem fins lucrativos
que tem como objetivo especificar padres voltados a aplicaes interoperveis para a indstria de
computadores desenvolveu uma nova arquitetura de desenvolvimento chamada MDA (Model Driven
Architecture). Esta arquitetura, como o prprio nome diz, dirigida a modelos, i.e., os modelos
compem o bloco fundamental de desenvolvimento de sistemas de software nesta arquitetura. Os
modelos a serem utilizados neste processo inovador satisfazem a algumas propriedades, as quais
viabilizam uma grande independncia tecnolgica na criao e manuteno do sistema. Alm disto,
os modelos so fortemente inter-relacionados e coesos porque as linguagens usadas para a criao
deles so definidas por uma linguagem nica e comum a todas as outras linguagens de modelagem,
chamada MOF (Meta Object Facility). Como o MDA uma arquitetura dirigida a modelos, e todos os
modelos possuem como ponto em comum o MOF, esta linguagem o ncleo do MDA.
A primeira parte deste artigo apresenta uma viso geral do MDA, mostrando os conceitos de
modelos, transformaes e camadas. A segunda parte fala sobre MOF, descrevendo suas
caractersticas principais, analisando algumas tecnologias correlatas, suas vantagens e
desvantagens, e mostrando onde ele pode ser usado. A terceira parte exibe um caso real de uso do
MOF, o middleware Parlay. Finalmente, a quarta parte apresenta as concluses finais obtidas.

91

2. MDA
A Arquitetura Dirigida a Modelo, ou MDA (Model Driven Architecture), uma arquitetura para
o desenvolvimento de software, possuindo como idia fundamental o uso de modelos neste processo,
como o prprio nome diz. Esta idia fundamental baseia-se no consenso bem estabelecido de que
ideal separar a especificao do funcionamento de um sistema dos detalhes de como este sistema
interage com a sua plataforma. No MDA, este princpio atingido atravs do uso de um modelo
escrito numa linguagem formal que contm a funcionalidade do sistema, e atravs da transformao
automtica deste modelo em um modelo que sabe como interagir com uma plataforma especfica.

2.1. Conceitos Bsicos


Os principais conceitos para o entendimento do MDA so:
Modelo: Um modelo de um sistema uma descrio ou especificao do sistema e de
sua funcionalidade. Um modelo geralmente composto por uma combinao de
diagramas e textos. O texto pode ser escrito em uma linguagem de modelagem ou uma
linguagem natural (MILLER, 2003).
Dirigido a Modelo (Model-Driven): MDA uma abordagem para desenvolvimento de
sistemas, e que incrementa o poder e influncia de modelos nesta funo. dirigido a
modelo porque oferece meios para usar os modelos de forma a dirigir a compreenso,
projeto, construo, implantao, operao, manuteno e modificao (MILLER, 2003).
Modelo Independente de Plataforma: O primeiro modelo que o MDA define um modelo
com um alto nvel de abstrao que independente de qualquer tecnologia. Este modelo
chamado de PIM (Platform Independent Model). Um PIM deve apresentar um grau de
independncia de plataforma que seja adequado para utiliz-lo com um variado nmero
de plataformas especficas (MILLER, 2003).
Modelo Especfico de Plataforma: Um PIM pode ser transformado em um ou mais
Modelos Especficos de Plataforma, chamados de PSM (Platform Specific Model), sendo
que cada PSM gerado para cada plataforma especfica. Como muitos sistemas
atualmente utilizam vrias tecnologias, comum ter vrios PSMs relacionados com um
nico PIM. Um PSM combina as especificaes contidas no PIM com os detalhes que
especificam como o sistema usa uma plataforma especfica.

2.2. Elementos Fundamentais do MDA


Os elementos fundamentais do MDA so:
Modelos de alto-nvel consistentes e precisos, escritos numa linguagem bem-definida,
i.e., uma linguagem com sintaxe e semntica bem-definida e automaticamente
interpretvel por um computador. Os modelos devem conter informaes suficientes
sobre o sistema;
Linguagens bem-definidas para a escrita destes modelos de alto-nvel;
Definies de transformao, que descrevem como um PIM deve ser mapeado para um
PSM de uma plataforma especfica;
Linguagens bem-definidas para a escrita de definies de transformao;
Ferramentas que executam a transformao de PIMs em PSMs baseadas nas definies
de transformao;
Ferramentas que executam a transformao de PSMs em cdigo.

2.3. Transformaes
O processo do MDA, como vem sendo descrito at agora, baseado em modelos e suas
transformaes, respectivamente de um PIM para seus PSMs. Em seguida, os PSMs so
transformados em cdigo. Estes dois tipos de transformaes podem ser realizados por ferramentas
distintas ou por uma mesma ferramenta.
Uma ferramenta de transformao composta por uma definio que descreve como um
modelo deve ser transformado. Esta definio chamada de definio de transformao. A figura 1
mostra a estrutura de uma ferramenta de transformao.

92

Figura 1. Definies de transformaes dentro das ferramentas de transformao


(WARMER, 2003)
A figura acima mostra a diferena entre uma transformao em si e a definio de
transformao. Uma definio de transformao define o mapeamento de elementos de uma
linguagem-fonte para elementos em uma linguagem-destino.
Pode-se afirmar que uma definio de transformao consiste em um conjunto de regras de
transformao, as quais so especificaes no-ambguas da maneira como um modelo (ou parte
dele) pode ser usado para criar um outro modelo (ou parte dele).
Baseado nas informaes acima, pode-se constatar trs definies.
Uma transformao a gerao automtica de um modelo-destino a partir de um modelofonte, de acordo com uma definio de transformao (WARMER, 2003);
Uma definio de transformao um conjunto de regras de transformao que
descrevem juntas como um modelo em uma linguagem-fonte pode ser transformado em
um modelo na linguagem-destino (WARMER, 2003);
Uma regra de transformao uma descrio de como um ou mais construtores na
linguagem-fonte pode ser transformado em um ou mais construtores na linguagemdestino (WARMER, 2003).
A caracterstica mais importante de uma transformao que ela deve preservar a semntica
entre o modelo fonte e o destino. Entretanto, a semntica de um modelo s pode ser preservada se
ela pode ser expressa de maneira equivalente tanto no modelo fonte quanto no destino.

2.4. As Quatro Camadas do MDA


A estrutura do MDA por definio composta por quatro camadas (ou metanveis) de
modelagem. Na terminologia prpria do MDA, estas camadas so chamadas de M0, M1, M2 e M3 (o
M que precede o nmero de cada camada deriva do termo em ingls que pode ser traduzido como
metanvel: metalevel).
Camada M0 (as instncias): Quando se est modelando um domnio e no software, as
instncias da camada M0 so os elementos do domnio, como por exemplo pessoas,
produtos, etc. Quando se est modelando software, as instncias so as representaes
de software dos itens do mundo real, como por exemplo a verso computadorizada das
pessoas e dos produtos;
Camada M1 (o modelo do sistema): A camada M1 composta por modelos, os quais
descrevem os elementos reais do sistema de software da camada M0. H uma relao
definida entre os elementos das camadas M1 e M0. Os elementos da camada M1 so
classificaes ou categorizaes das instncias da camada M0, assim como cada
elemento da camada M0 nada mais do que instncias de um elemento da camada M1;
Camada M2 (o modelo do modelo): O modelo que reside na camada M2 chamado de
metamodelo. Cada elemento de um metamodelo classifica ou categoriza um elemento da
camada M1. Como cada modelo criado na camada M2 um modelo para descrever
outros modelos (os modelos da camada M1), eles so chamados de metamodelos. Por
este motivo a camada M2 denominada de camada de metamodelagem;
Camada M3 (o modelo do M2): A ltima das definies de camadas do MDA, a camada
M3, composta por elementos que oferecem os recursos necessrios para lidar com os
elementos da camada M2. A mesma relao existente entre os elementos da camada M0
e M1, e entre os elementos da camada M2 e M1, existe entre os elementos da camada
M3 e M2, ou seja, cada elemento da camada M3 categoriza ou classifica cada elemento
da camada M2.
Um quadro comparativo das quatro camadas pode ser visualizado na tabela 1.

93

Tabela 1. Quadro comparativo das quatro camadas do MDA


Camada
Contedo
Descrio

M3

Metametamodelo

Linguagem para a construo


de metamodelos

M2

Metamodelo

Linguagem para a construo


de modelos

M1

Modelo

Descreve aspectos estruturais


e/ou dinmicos dos dados

M0

Dados

Dados do mundo real

Elementos
(exemplos)

MOF Class, MOF MOF


Attribute, MOF
Association, etc.
UML Class, UML
Association, UML
Attribute, UML State,
etc.
Classe Empregado,
Atributo Nome,
Atributo Endereo,
etc.
Empregado (Jos
Firmino, Joo da
Cunha, Blumenau),
etc.

2.5. Modelos e sua Terminologia


Os principais termos diretamente relacionados com modelos em geral so:
Metadado: significa estritamente dado sobre dado, ou seja, usado para referir-se a
dados cujo propsito descrever outros dados. Portanto, um metadado um modelo;
Metamodelo: refere-se a um modelo que descreve algum tipo de modelo;
Metametamodelo: refere-se a um modelo que descreve um metamodelo. Como na
arquitetura MDA s existe um nico metametamodelo, que o prprio MOF, e como o
termo metametamodelo pode causar confuso durante a sua leitura, convencionou-se
que o metametamodelo tambm pode ser chamado inequivocamente de Modelo MOF;
Metaobjeto: refere-se a um objeto que descreve um metadado, como por exemplo., um
objeto Java ou um objeto CORBA. O termo metaobjeto uma abreviao para objeto de
metadado. Foi a partir deste termo que o MOF ganhou o nome de Meta Object Facility.
Analisando os termos relacionados com o MDA, pode-se perceber uma equivalncia entre
alguns deles. A tabela 2 mostra a equivalncia de alguns termos, de forma que termos encontrados
numa mesma linha referem-se a conceitos iguais.
Tabela 2. Termos equivalentes (termos numa mesma linha referem-se a conceitos iguais)
Camada
Dados
Modelos
Linguagens

M0
M1
M2
M3

Dado
Metadado
Metametadado

Modelo
Metamodelo
Metametamodelo

Linguagem
Metalinguagem

3. MOF
O MOF (Meta Object Facility) um padro criado pela OMG que define uma linguagem para
a definio de linguagens de modelagem. Como o MOF uma linguagem para criao de linguagens,
ela pode ser considerada uma metalinguagem. O MOF reside na camada M3 da arquitetura MDA, e
como no h uma camada superior para definir o MOF, ele definido atravs dele mesmo. O MOF
a linguagem em que as definies de UML e CWM, ou seja, os metamodelos de UML e CWM so
escritos.

94

3.1. Ferramentas MOF


O MOF no somente usado para definir linguagens de modelagem, mas tambm para servir
como base para a construo de ferramentas para definio de linguagens de modelagem.
O MOF oferece um modelo de repositrio que pode ser usado para especificar e manipular
modelos, impulsionando a consistncia na manipulao de modelos em todas as fases do uso do
MDA (MILLER, 2003).

3.1.1. A Interface de Repositrio MOF


A definio do MOF inclui uma especificao da interface para um repositrio MOF,
permitindo assim o acesso a modelos da camada M1 de um repositrio atravs de uma interface
comum. Esta interface especifica operaes comuns para o acesso dos dados contidos neste
repositrio, e definida atravs de CORBA-IDL. Portanto, ela pode ser utilizada por vrias
plataformas. Especialmente para Java, h uma interface nativa que oferece esta funcionalidade, e
chamada de JMI (Java Metadata Interface).

3.2. Auto-Descrio
O prprio MOF precisa ser definido por alguma linguagem. Afinal, se os elementos da
camada M0 so instncias de elementos da camada M1, que so instncias de elementos da camada
M2, que por sua vez so instncias de elementos da camada M3, os elementos da camada M3
precisam ser instanciados por elementos oriundos de algum outro conjunto de elementos.
A soluo adotada pela OMG para descrever os elementos da camada M3 foi que os prprios
elementos da camada M3 so instncias dos elementos da camada M3. Em outras palavras, o MOF
usa o MOF para descrever a si prprio. Em termos tcnicos, o MOF considerado auto-descritivo. O
prprio MOF define um modelo que descreve o MOF utilizando para tal seus prprios construtores.
Este modelo chamado de Modelo MOF (MOF Model). O Modelo MOF distinto de qualquer outro
tipo de metamodelo, porque o metamodelo do MOF.

3.3. O Modelo MOF Construtores de Modelagem


Esta seo tem como objetivo apresentar os construtores de modelagem do MOF (i.e., a
linguagem abstrata de MOF) para a definio de metamodelos. A presente verso descrita do MOF
a 1.4. A metamodelagem baseada em MOF baseada na definio de modelos que descrevem
metadados. O MOF usa para tal uma estrutura de modelagem de objetos que essencialmente um
subconjunto do ncleo do UML. Os quatro principais conceitos relacionados com a metamodelagem
baseada em MOF so (OMG, 2002):
Classes: modelam os metaobjetos MOF;
Associaes: modela relaes binrias entre metaobjetos;
Tipos de Dados: modelam outros dados (e.g., tipos primitivos, tipos externos, etc);
Pacotes: modularizam os modelos.

3.4. Cenrios de Uso do MOF


Um cenrio tpico de uso para o MOF oferecer suporte ao desenvolvimento de softwares
distribudos orientados a objeto a partir de modelos de alto-nvel. Tal sistema ento consistiria de um
servio de repositrios para o armazenamento dos modelos e uma coleo de ferramentas
relacionadas. Estas ferramentas ofereceriam suporte importao e exportao de dados deste
repositrio. Os dados a serem importados seriam os prprios modelos, e as ferramentas poderiam
auxiliar no processo de exportar estes modelos em forma de cdigo, atravs da execuo de
transformaes bem-definidas.
Um repositrio MOF pode armazenar diversos tipos de modelos. Os metadados contidos
neste repositrio podem ser armazenados, por exemplo, pelo uso de metaobjetos Java ou CORBA,
sendo que estes metaobjetos podem ser acessados respectivamente por suas interfaces Java ou
CORBA. atravs destas interfaces que os clientes dos repositrios obtm acesso aos metadados,
podendo executar quatro tipos de operaes bsicas: criao, leitura, alterao ou remoo de
metadados. A este conjunto de quatro operaes bsicas d-se o nome de CRUD (create, read,
update, delete).

95

3.5. Anlise do CORBA frente ao MOF


Existe um falso consenso em relao ao MOF de que ele baseado e estritamente ligado ao
CORBA. Quando o MOF foi lanado em 1997, CORBA era considerado o modelo de programao
revolucionrio. Assim, havia um forte interesse na organizao em criar um forte elo de dependncia
entre MOF e CORBA, tanto que algumas das primeiras verses de MOF usaram como tipos de dados
primitivos os mesmos tipos do CORBA. A verso 1.4 do MOF mudou isto, definindo um conjunto de
tipos de dados primitivos mais neutro (FRANKEL, 2003).

3.5.1. Mapeamento alm da Sintaxe


O mapeamento MOF-CORBA no se limita em criar somente a sintaxe das interfaces
CORBA-IDL produzidas a partir da sintaxe abstrata de um determinado metamodelo. Se assim fosse,
saber-se-ia somente quais operaes CORBA foram geradas, mas no o que elas fazem, ou seja,
no se saberia qual a semntica destas operaes. Assim, o mapeamento tambm mapeia a
semntica destas interfaces, incluindo todos os seus correspondentes comportamentos, como o fato
de que uma implementao de uma operao de remoo de um metaobjeto deve tambm remover
todos os objetos pertinentes via agregao composta (FRANKEL, 2003).
Atravs da especificao da semntica das interfaces em combinao com a sua sintaxe, o
mapeamento torna possvel aos compiladores MOF gerar tambm as implementaes destas
interfaces. Isto promove interoperabilidade entre implementaes distintas de interfaces.

3.6. Anlise do XMI


XMI (XML Metadata Interchange) um padro de intercmbio de metadados, baseados em
MOF, atravs de documentos XML. A medida que XML comeou a ser usado para a representao
de metadados, ele passou a ser usado como um excelente meio para o intercmbio destes
metadados.
Como o MOF foi projetado para ser independente de qualquer tipo de plataforma, a criao
de um mapeamento MOF-XML foi simples de ser definida. Em 1998 a OMG padronizou este
mapeamento, criando ento o XMI.

3.6.1. Funcionamento do XMI


O XMI, como ferramenta de intercmbio de metadados, pode mapear um modelo qualquer
das camadas M3 e M2 em um DTD XML que armazenar a estrutura deste modelo. Pode tambm
mapear um modelo qualquer das camadas M2 e M1 para um documento XML que armazenar todas
as propriedades de todos os elementos deste modelo.
Os DTDs produzidos a partir da camada M3 validam documentos XML da camada M2, e os
DTDs produzidos a partir da camada M2 validam documentos XML da camada M1. A OMG criou
alguns DTDs padres, como o DTD do MOF, produzido a partir da camada M3, e o DTD do UML,
produzido a partir da camada M2. A figura 2 exibe um esquema do funcionamento do XMI sobre
todas as camadas, mostrando seu campo de atuao.

96

Figura 2. Esquema de funcionamento do XMI

3.6.2. Uma Falsa Crena sobre o XMI


UML o metamodelo MOF mais conhecido e utilizado atualmente. Como resultado, o XMI
DTD para UML que foi gerado a partir do metamodelo UML o XMI DTD mais conhecido. Muitas
ferramentas UML passaram ento a oferecer suporte a importao e exportao de modelos UML
atravs de documentos XMI que validam estes ltimos contra este DTD.
Devido a este fato, muitas pessoas na indstria encontraram no XMI a soluo para a
realizao de intercmbio de modelos UML entre ferramentas. Ento, h uma falsa crena de que o
XMI simplesmente um DTD especfico para o intercmbio de modelos UML, enquanto na verdade o
XMI uma ferramenta geral o intercmbio de quaisquer metadados baseados em MOF.

3.7. Anlise do JMI


O JMI (Java Metadata Interface) foi criado pelo Java Community Process (JCP) da Sun, e
viabiliza o mapeamento MOF-Java. O JMI define regras para a representao de metadados como
objetos Java, atravs de uma definio de transformao que especifica como transformar a sintaxe
abstrata de um metamodelo em interfaces Java. Estas interfaces oferecem um meio de representar
modelos como metaobjetos Java para o conjunto de modelos que esto em conformidade com o
metamodelo relacionado. O JMI no somente define a sintaxe das interfaces geradas, como tambm
define a sua semntica.

3.8. Desvantagens
As principais desvantagens do MOF so:
Falta de suporte a notao grfica: MOF no tem uma linguagem para a definio de uma
notao grfica. Assim, se voc precisa de uma notao grfica otimizada para um
determinado tipo de modelo definido por um metamodelo, na h uma maneira de associar
possveis construtores de notao grfica com os construtores definidos pelo
metamodelo. Conseqentemente, no h como existirem ferramentas de
desenvolvimento MDA que suportam novas notaes grficas atravs da leitura de um
documento que contenha definies de um tipo de notao grfica qualquer (FRANKEL,
2003);
Desalinhamento com UML: Nas atuais verses de MOF 1.X e UML 1.X ainda no h um
completo alinhamento do ncleo das suas sintaxes abstratas. Apesar do alinhamento
existente atualmente ser quase completo, ser quase completo no basta. necessrio
que o ncleo de ambos sejam completamente alinhados (FRANKEL, 2003);
Problemas de mapeamento MOF-CORBA: O mapeamento MOF-IDL possui alguns
problemas, e as interfaces produzidas pelas regras de gerao atualmente existentes no
so eficientes em sistemas distribudos. Alguns destes problemas podem ser resolvidos

97

aplicando-se algumas alteraes ou na definio do mapeamento MOF-CORBA ou


estendendo-se as Interfaces MOF Reflexivas. Outra deficincia do mapeamento que o
suporte atualmente oferecido aos parmetros de transformao limitado, e deve ser
incrementado (FRANKEL, 2003);
Problemas de interoperabilidade: Em teoria, qualquer modelo exportado por uma
ferramenta deveria poder ser importado por outra ferramenta que tambm conhea o
metamodelo do modelo em questo. Entretanto, h problemas quanto a este tipo de
operao devido imaturidade dos padres atualmente existentes, j que os padres
baseados em MOF so relativamente novos (FRANKEL, 2003).

3.9. Vantagens Principais


As principais vantagens do uso do MOF so:
Suporte ao gerenciamento de repositrios de metadados atravs de interfaces CORBA ou
Java geradas automaticamente pelo mapeamento MOF-CORBA ou atravs do JMI;
Gerao automtica via XMI de interfaces e XML DTDs;
Viabilizao de intercmbio de metadados.

3.10. Futuro do MOF


Em 2001, a OMG editou trs RFPs (Request for Proposal) para o MOF 2.0. No geral, estas
requisies procuram resolver os problemas citados anteriormente. Provavelmente em 2004 (o ano
em que o presente trabalho foi escrito) as especificaes do MOF 2.0 sero finalizadas. Porm, ainda
h um longo caminho pela frente para o completo e perfeito amadurecimento desta tecnologia.

4. Caso Real de Uso do MOF: Parlay


Atualmente, a situao do mercado de telecomunicaes est rapidamente mudando devido
convergncia da Internet e de redes de telefonia, e tambm devido derrubada do monoplio em
diversos pases. Isto oferece grandes desafios e oportunidades para os provedores de servios de
telecomunicao (FARSHCHIAN, 2004).
Um destes desafios a competio acirrada para oferecer os melhores servios para os
clientes. O abandono do mercado monopolista criou o positivo surgimento de vrias tecnologias,
porm cria uma barreira na interoperabilidade dos servios das empresas.
Aplicaes na rea de redes convergentes cada vez mais possuem em sua organizao
software, diferente dos tradicionais servios de telecomunicao onde o software desempenhava um
papel mais modesto. Desenvolvedores de aplicaes recorrem a freqentemente complexas solues
de software para acesso e utilizao de recursos de rede oferecidos por operadores de rede.
Software tambm usado para criar aplicaes inovadoras que fazem uso de uma mistura de
recursos de rede (e.g. aplicaes operando transparentemente tanto na Internet quanto nas redes
telefnicas e utilizando bancos de dados corporativos).
Uma das principais barreiras nesta rea de desenvolvimento justamente a reusabilidade.
Redes de telecomunicaes pertenceram tradicionalmente empresas privadas, e foram
desenvolvidas como um resultado de alianas estratgicas entre produtores de equipamentos e
operadores de rede. Aplicaes similares tiveram que ser desenvolvidas repetidas vezes em cada
plataforma privada. Esta situao no deve mudar num futuro prximo, devido ao macio
investimento realizado sobre estas tecnologias privadas. Porm, o incrvel aumento do nmero e das
variaes dos servios oferecidos torna esta situao crtica. H uma necessidade urgente de
habilitar aos desenvolvedores de aplicaes o poder de reusar suas aplicaes em plataformas
privadas (FARSHCHIAN, 2004).

4.1. O Middleware Parlay


Importantes iniciativas esto sendo tomadas para abordar as questes levantadas acima.
Uma delas o prprio MDA, descrito neste trabalho, e a outra a criao do Parlay. O Parlay uma
especificao de middleware orientada a objeto e independente de plataforma desenvolvida para o
domnio de telecomunicaes, e foi criada por uma organizao sem fins lucrativos como uma
especificao aberta. O Parlay promove independncia da rede para o desenvolvimento e para a
implantao de servios e aplicaes na rea de telecomunicaes, e permite que operadores de

98

rede compartilhem seus recursos de rede em uma maneira sistemtica e padronizada. O reuso
habilitado no nvel de componente. Embora o Parlay permita que provedores de servios reusem
seus servios em mltiplas redes, h um pequeno suporte para reuso no campo de modelagem de
aplicaes. A importncia do MDA neste contexto a abordagem de reuso no nvel da modelagem de
domnio (FARSHCHIAN, 2004).
Atravs do uso do Parlay, a reusabilidade destas aplicaes aumentada, j que o Parlay
define uma interface padro entre o desenvolvedor da aplicao e o provedor de servios, como pode
ser visto na figura 3.

Figura 3. Desenvolvimento de aplicaes em redes de telecomunicaes usando o


Parlay (baseado em FARSHCHIAN, 2004)
Na figura ilustrada acima, o domnio dos recursos abrange recursos como redes fixas e
mveis. Atravs do uso das interfaces do Parlay, as aplicaes dos desenvolvedores podem utilizar
os servios invocando mtodos da interface, que por sua vez fazem uso dos recursos da rede. Esta
abordagem habilita o desenvolvimento de aplicaes complexas que utilizam uma mistura de servios
e recursos (e.g., telefonia fixa e mvel, Internet, bancos de dados corporativos). Esta abordagem
tambm aumenta o nvel de reusabilidade fazendo com que a especificao da aplicao seja
independente da rede a ser utilizada.

4.2. Relao entre Parlay, MDA e MOF


Um dos objetivos da equipe de desenvolvimento do Parlay integr-lo com o MDA,
aumentando consideravelmente o nvel de reusabilidade. Um PIM representando uma aplicao para
redes de telecomunicaes pode ser transformado em um PSM pra uma plataforma de rede de
telecomunicao especfica, graas ao metamodelo Parlay construdo atravs do uso do MOF. A
relao entre estas entidades pode ser vista na figura 4.

99

Figura 4. Desenvolvimento de aplicaes em redes de telecomunicaes usando o


Parlay (baseado em FARSHCHIAN, 2004)
Para que esse processo possa ser utilizado necessrio definir um metamodelo para o
domnio da telecomunicao. Este metamodelo deve ser, claro, uma instncia do metametamodelo
MOF, e ir ter um enfoque nas necessidades da indstria de telecomunicaes.
Desenvolver tal metamodelo um grande desafio. Ele deve conter um poder de expresso
suficiente para satisfazer tanto as necessidades da telecomunicao quanto as necessidades do
crescente nmero de servios e aplicaes que so baseadas em redes convergentes. Tal
metamodelo pode ser desenvolvido como uma linguagem de modelagem completamente nova, ou
como uma especializao de UML (UML Profile). Em ambos os casos, a concordncia com MOF
crucial para permitir interoperabilidade atravs do uso de ferramentas MDA.
Vale frisar que dois metamodelos precisam ser construdos para habilitar o processo de
desenvolvimento baseado no Parlay e MDA. O primeiro metamodelo o que oferece a capacidade de
modelar conceitos referentes ao domnio da telecomunicao, i.e., o metamodelo usado para a
criao de PIMs. O segundo metamodelo o que oferece a capacidade de modelar conceitos
referentes plataforma especfica sobre a qual o Parlay ser implantado, i.e., o metamodelo usado
para a criao de PSMs. Regras de transformao entre estes metamodelos precisaro ento ser
criadas para habilitar uma efetiva transformao entre estes metamodelos. O segundo metamodelo
citado acima, em particular, ter como ponto de partida de seu desenvolvimento as prprias
especificaes de interface do Parlay, que j esto documentadas em UML.

5. Concluses
Os problemas da produtividade, portabilidade, interoperabilidade, documentao e
manuteno vm sendo abordados de diversas maneiras. A mais inovadora e recente abordagem foi
a criao da arquitetura MDA (Model Driven Architecture) pela OMG (Object Management Group). O
MDA uma arquitetura dirigida a modelos, e para tal oferece conceitos e recursos necessrios para
lidar com esses modelos. O conceito fundamental do funcionamento desta arquitetura a utilizao
de modelos independentes de plataforma (PIMs) para a especificao e desenvolvimento do sistema,
e na sua subseqente transformao automatizada em modelos de plataforma especfica (PSMs).
A linguagem de modelagem usada para criar estes modelos uma linguagem de
metamodelagem nica e geral, o MOF (Meta Object Facility). Como o prprio nome diz, o MOF
oferece facilidades para lidar com metaobjetos, que nada mais so do que objetos que descrevem
metadados, i.e., objetos que descrevem elementos de um determinado modelo.
A propriedade mais marcante no MOF a auto-descrio. O MOF definido atravs dos
construtores de modelagem do prprio MOF. O metamodelo MOF que contm a definio do MOF
um metamodelo padronizado pela OMG, e chamado por conveno de o Modelo MOF.
As trs tecnologias mais fortemente relacionadas com o MOF so CORBA (Common Object
Request Broker Architecture), XMI (XML Metadata Interchange) e JMI (Java Metadata Interface). O
CORBA permite que metamodelos sejam mapeados para o IDL do CORBA. Analisando a

100

especificao oficial do MOF pode-se ter a impresso de que o MOF uma linguagem dependente
do CORBA, mais na verdade so independentes.
O XMI permite o intercmbio de metadados atravs da linguagem XML, baseando-se em
MOF para tal. O XMI atualmente muito utilizado para o intercmbio de modelos UML, motivo pelo
qual surgiu uma crena errnea de que o propsito de funcionalidade do XMI executar somente tal
funo. Enfim, o XMI atende s necessidades de intercmbio de modelos requeridas pelas empresas,
contudo melhoras na modularizao dos artefatos gerados so necessrias.
O JMI um padro independente de plataforma para modelagem, criao, armazenamento,
acesso, consulta e intercmbio de metadados usando UML, XML e Java. Uma grande vantagem do
JMI perante os demais padres de interface o fato dele ser baseado em Java, pois Java uma das
linguagens mais populares da atualidade.
O principal cenrio de uso da linguagem MOF no suporte a repositrios de modelos em
geral, possibilitando uma maneira genrica para consulta, transformao, criao, leitura, atualizao
e remoo destes metadados, independentemente da linguagem em que estes modelos foram
escritos. Atualmente j existem vrias ferramentas que atuam como repositrios para modelos
baseados em MOF, porm muito precisa ser melhorado nas especificaes do MOF para que estes
repositrios possam conseqentemente oferecer melhores recursos.
O MOF ainda possui inmeras deficincias, como falta de suporte a uma notao grfica,
desalinhamento com o UML, problemas de mapeamento MOF-CORBA e problemas de
interoperabilidade. Todos estas deficincias decorrem principalmente do fato de que o MOF uma
tecnologia recente e que vem recebendo constantes melhorias. A verso 2.0 do MOF promete
inmeras correes e considerveis melhoras.
O MOF promete ser um grande aliado em situaes que exigem grande reusabilidade e
independncia de plataforma, como demonstrado na apresentao do middleware Parlay, que
encontrou no MDA e no MOF uma forma de obter ganhos considerveis no processo de
desenvolvimento de software para a rea de telecomunicaes. O middleware Paraly um exemplo
de sistema de grande porte que requer vasta interoperabilidade para uma maior produtividade, e o
MDA, em conjunto com o MOF, vem a abrir portas para um processo de desenvolvimento produtivo
numa rea onde a demanda por software cada vez maior.
Enfim o MOF uma linguagem inovadora que promete inmeros benefcios em conjunto com
o MDA. Cada vez mais empresas no mundo todo vm aderindo a estas novas tecnologias em busca
de melhorias na produtividade. Apesar do potencial destas tecnologias ainda no estar
completamente aprimorado e s poder ser plenamente usufrudo a longo prazo, o panorama
revolucionrio de produo automtica de cdigo a partir de modelos independentes de plataformas e
o de livre intercmbio e manuseio de modelos de tecnologias distintas promete grandes avanos para
o futuro.

6. Referncias
FARSHCHIAN, Babak A.; JAKOBSSON, Sune; BERG, Erik. Coupling MDA and Parlay to increase
reuse in telecommunication application development. In: ECOOP2002 Workshop on Modelbased Software Reuse, 2002, Mlaga. Disponvel em: <http://www.metamodel.com/wisme2002/papers/farshchian.pdf>. Acesso em: 17 jan. 2004.
FRANKEL, David. Model Driven Architecture: Applying MDA to Enterprise Computing. John
Wiley & Sons OMG Press, jan. 2003.
MILLER, Joaquin; MUKERJI, Jishnu. MDA Guide Version 1.0. OMG, mai. 2003.
Object Management Group. Meta Object Facility (MOF) v1.4. Especificao, OMG, abr. 2002.
WARMER, Jos. KLEPPE, Anneke; BAST, Wim. MDA Explained: The Model Driven Architecture:
Practice and Promise. Addison Wesley, abr. 2003. 192p.

Você também pode gostar