Escolar Documentos
Profissional Documentos
Cultura Documentos
FLORIANPOLIS
2004
Membros da Banca:
Prof. Ph.D. Frank Augusto Siqueira, INE/CTC/UFSC
Profa. Carla Adriana Barvinski Zanchett, CPGCC/UFSC
FLORIANPOLIS
2004
ocupao
com
este
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
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
tentar
acabar
com
estes
inconvenientes
no
processo
de
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:
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.
Anlise de requisitos;
Anlise funcional;
Modelagem;
Implementao;
Teste;
Implantao.
escrever
modelos
ou
documentao
uma
tarefa
no
produtiva,
num
Especificao de plataformas;
10
11
12
13
14
15
16
17
18
19
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.
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.
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
23
conjunto de regras
de
24
estrutura
do
MDA
so: modelos,
PIMs,
PSMs,
linguagens,
25
26
27
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.
29
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
representada
por
um
metamodelo
escrito
em
outra
metalinguagem.
32
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
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.
35
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
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
37
Num
processo
de
desenvolvimento
de
software,
maioria
dos
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
39
40
41
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
43
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,
45
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):
47
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
Comportamental)
super-classe
da
classe
Operation
48
49
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)
so
entidades
atravs
das
quais
se
pode
acessar
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
51
52
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)
54
Pelo contrrio, uma relao composta uma ligao mais forte entre
instncias, e possui as seguintes propriedades:
Quando
uma
instncia
composta
removida,
todos
os
seus
55
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:
56
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.
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:
padres
que
so
adequados
para
uma
metamodelagem
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:
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
60
de
cada
um
de
seus
Pacotes
agrupados
criado
automaticamente;
61
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
62
Um nome;
63
estruturais
so
realizadas
imediatamente,
outras
precisam
ser
especificao
do
MOF
oferece
uma
grande
flexibilidade
para
64
Um nome que pode ser usado para denotar a Etiqueta em seu recipiente
(container);
65
66
67
68
destas
interfaces.
Isto
promove
interoperabilidade
entre
69
70
71
72
73
74
75
76
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
78
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
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
81
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
das
peculiaridades
do
MDA
sobre
os
demais
mtodos
de
83
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
uma
maneira
genrica
para
consulta,
85
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,
88
89
90
ANEXO ARTIGO
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.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
93
M3
Metametamodelo
M2
Metamodelo
M1
Modelo
M0
Dados
Elementos
(exemplos)
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.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.
95
96
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
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.
99
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.