Monografia XDF - Extreme Driven Framework

FERNANDO MIGUEZ DIAS DA SILVA
XDF
eXtreme Driven Framework
'O Modelo é o Sistema'
"Uma implementação translacionista para um framework de desenvolvimento de

sistemas baseado em MDA (Modelling Driven Architecture)"
Brasília / DF
Novembro / 2007
FUNDAÇÃO GETÚLIO VARGAS
Fernando Miguez Dias da Silva
XDF
eXtreme Driven Framework
'O Modelo é o Sistema'
"Uma implementação translacionista para um framework de desenvolvimento de

sistemas baseado em MDA (Modelling Driven Architecture)"
Monografia apresentada no Curso de Pós-

Graduação Latu Sensu em Administração
Estratégica de Sistemas de Informação, como
pré-requisito para obtenção do grau de
especialista.
Orientador: Carlos André Reis Pinheiro DSC.
Brasília / DF
Novembro / 2007
Página 3 de 96
DEDICATÓRIA
“Dedico este trabalho a minha esposa Mácia Cirlene e aos meus filhos Breno e
Lucas que por tantas vezes foram compreensivos diante a necessidade de
dedicação aos estudos para meu aperfeiçoamento pessoal. Sem o apoio
incondicional de minha família, certamente não seria possível dilatar o pouco tempo
que nos sobra para os estudos na correria do dia a dia”.
Página 4/96
AGRADECIMENTOS
“Agradeço a todos que durante minha jornada pessoal pela vida até o momento
presente, me estimularam a ouvir mais do que falar, pensar serenamente antes de
tomar decisões, respeitar e procurar compreender posições divergentes, mas,
principalmente, que me ensinaram a manter o espírito crítico e a mente aberta para
reconsiderar posições e rever constantemente os paradigmas de nosso modo de
viver e trabalhar”.
Página 5/96
RESUMO
Em sua arrojada concepção, o framework XDF parte do "estado da arte" de

novas tecnologias, dentre as quais a MDA (Model Driven Architecture), para aplicá-
las ao desenvolvimento mais eficaz de sistemas. Representado por um consórcio
mundial de empresas multinacionais, o OMG (Object Management Group) define e
dissemina o conceito MDA (Model Driven Architecture). Este conceito, fazendo uso
da notação gráfica UML (Unified Modeling Language), objetiva em última instância,
dissociar radicalmente as regras de negócio (sob a forma de modelos) da
implementação tecnológica das mesmas (representadas pelos sistemas).
Seu mote, "o modelo é o sistema", anuncia uma nova era em que as aplicações
serão "à prova de futuro". Estarão então "blindadas" dos modismos e das inovações
tecnológicas que, ao tempo em que trazem inovação, geram também enormes
investimentos para conversão do Legado de Sistemas existentes, colocado sob
tecnologias que se cristalizaram e não atendem mais as necessidades do negócio.
O framework XDF, como parte de seu o próprio nome diz (eXtreme), leva ao
extremo o uso aplicado do conceito de MDA, uma vez que, usando uma abordagem
translacionista1, faz uso de componentes de código livre, de Orientação a Objetos e
da Prevalência de Objetos oferecendo, pela "desconstrução" da complexidade
tecnológica e o uso inovador da potencialidade dos novos hardwares e softwares
básicos, a singular condição de simplicidade compartilhada de uso, associada a uma
maior independência de toda a parafernália de softwares complementares para que
um sistema processe sob plataformas heterogêneas.
Palavras-Chave: XDF, eXtreme Driven Architecture, MDA - Model Driven

Architecture, Prevayler, Prevalência e Orientação a Objetos,
1
Translacionista: Conceito MDA para representar a geração automática de sistemas a partir de seus modelos
Página 6/96
ABSTRACT
In its bold design, the XDF framework part of the "state of art" of new
technologies, among which the MDA (Model Driven Architecture), to apply them to
develop more efficient systems. Designated by a global consortium of multinational
companies, the OMG (Object Management Group) defines the concept spreads and
MDA (Model Driven Architecture). This concept, making use of graphical notation
UML (Unified Modeling Language), aims ultimately, dissociate radically the rules of
business (in the form of models) of the implementation of the same technology
(represented by systems).
His motto, "the model is the system," announces a new era in which applications
will be "proof of the future." They then "armored" of fashion and technological
innovations which, in the time that bring innovation, generate also huge investments
to convert the existing Legacy Systems, which is placed under technologies focused
and do not meet the needs of most business.
The XDF framework, as part of its the name says (eXtreme), leads to the end
user application of the concept of MDA, since, using an approach translacionist2,
makes use of components of code free, Objects Orientation and Objects Prevalence
offering, the "deconstruction" of the technological complexity and the use of
innovative potential of the new hardware and basic software, the natural condition of
shared simplicity of use, coupled with greater independence of the whole
paraphernalia of complementary software for a system place under heterogeneous
platforms.
Keywords: XDF, eXtreme Driven Architecture, MDA, Model-Driven Architecture,

Prevayler, Prevalence and the Object Orientation.
2
Translacionist: The MDA concept represent the automatic generation of systems from its models
Página 7/96
ÍNDICE DE FIGURAS:
Figura 1 - O Iceberg Tecnológico ..............................................................................12

Figura 2 - Framework Genérico.................................................................................14
Figura 3 - Exemplo de Hype Cycle............................................................................16
Figura 4 - Resultados de Projetos .............................................................................21
Figura 5 – Tabela de formas de implementação de softwares ..................................22
Figura 6 - Model Driven Architecture .........................................................................33
Figura 7 - Transformações entre Modelos ................................................................33
Figura 8 – Abordagem Elaboracionista .....................................................................33
Figura 9 – Abordagem Translacionista......................................................................33
Figura 10 - O processo de desenvolvimento sob MDA .............................................33
Figura 11 - Exemplo de uma Arquitetura Tradicional (Persistente) ...........................33
Figura 12 - O problema da Impedância em SGBDs ..................................................33
Figura 13 - Os componentes teóricos da Prevalência...............................................33
Figura 14 - Usando a Prevalência .............................................................................33
Figura 15 – Tabela de Abordagens para o PIM.........................................................33
Figura 16 – Ciclo de Desenvolvimento e Produção sob XDF....................................33
Figura 17 – Edição de um Diagrama de Classes no XDFDesigner...........................33
Figura 18 – Tela Inicial do XDFObjectBrowser..........................................................33
Figura 19 – Navegação e edição de Objetos pelo XDFObjectBrowser .....................33
Figura 20 – Edição de uma Máquina de Estados no XDFDesigner ..........................33
Figura 21 – Permissões de segurança sendo atribuídas no XDFSecurity ................33
Figura 22 – Edição de um Workflow no XDFDesigner. .............................................33
Figura 23 – Diagramas UML .....................................................................................33
Página 8/96
SUMÁRIO:
1 INTRODUÇÃO....................................................................................................11
1.1 O Iceberg tecnológico....................................................................................................... 11
1.2 A Babel Tecnológica......................................................................................................... 13
1.3 A Teoria das Ondas.......................................................................................................... 15
1.4 Os especialistas especializados ..................................................................................... 17
1.5 O problema da Documentação ....................................................................................... 20
1.6 Do caos a ordem caótica. Porque Projetos de TI ainda falham tanto? .................... 20
1.7 O resumo da Ópera .......................................................................................................... 23
2 FUNDAMENTAÇÃO TEÓRICA ..........................................................................29
2.1 Orientação a Objetos (OO).............................................................................................. 29
2.1.1 Benefícios da OO ......................................................................................................... 30
2.1.2 Linguagens Procedurais X Orientada a Objetos ..................................................... 31
2.1.3 Linguagens Compiladas X Interpretadas.................................................................. 32
2.2 Arquitetura de Software (ou Framework de SI)............................................................ 33
2.3 Modelos e Metamodelos: Por que modelar software?................................................ 33
2.4 MDA - Model Driven Architecture ................................................................................... 33
2.4.1 Núcleo e Padrões ......................................................................................................... 33
2.4.1.1 CWM (Common Warehouse Metahouse Metamodel) ................................... 33

2.4.1.2 UML (Unified Modeling Language).................................................................... 33
2.4.1.3 MOF (Meta Object Facility)................................................................................. 33
2.4.2 Camada Intermediária.................................................................................................. 33
2.4.3 Pervasive Services (Serviços Universais) ................................................................ 33
2.4.4 Os Níveis de Abstração em MDA .............................................................................. 33
2.4.4.1 CIM (Computational Independent Model) ........................................................ 33

2.4.4.2 PIM (Platform Independent Model) ................................................................... 33
2.4.4.3 PSM (Platform Specific Model) .......................................................................... 33
2.4.5 Transformações entre modelos.................................................................................. 33
2.4.6 As duas abordagens da MDA..................................................................................... 33
2.4.7 Benefícios da utilização de MDA................................................................................ 33

Página 9/96
2.4.7.1 Produtividade........................................................................................................ 33
2.4.7.2 Portabilidade ......................................................................................................... 33
2.4.7.3 Manutenção e Documentação ........................................................................... 33
2.4.8 MDA e Linguagens de Modelagem............................................................................ 33
2.4.8.1 Os Critérios ........................................................................................................... 33

2.4.8.2 A Escolha da Linguagem.................................................................................... 33
2.5 OCL (Object Constraint Language) e AL (Action Language)..................................... 33
2.5.1 Object Constraint Language (OCL) ........................................................................... 33
2.5.1.1 Expressões ........................................................................................................... 33

2.5.1.2 Restrições (Constraints)...................................................................................... 33
2.5.2 A Semântica de Ações (Action Semantics) .............................................................. 33
2.5.3 A Linguagem de Ação (Action Language) ................................................................ 33
2.6 UML – Unified Modeling Language................................................................................ 33
2.6.1 Diagramas UML ............................................................................................................ 33
2.6.2 UML 2.0 – Motivações para revisão da UML ........................................................... 33
2.6.3 UML 2.0 e MDA............................................................................................................. 33
2.6.3.1 Expressividade ..................................................................................................... 33

2.6.3.2 Independência de aplicação............................................................................... 33
2.6.3.3 Alto nível de abstração........................................................................................ 33
2.6.3.4 Suporte para Aplicações N-tier .......................................................................... 33
2.6.3.5 Suporte para Aplicações Distribuídas............................................................... 33
2.6.3.6 Translacionismo em MDA................................................................................... 33
2.6.3.7 Gerenciamento de Modelos Complexos .......................................................... 33
2.6.3.8 Suporte Ferramental............................................................................................ 33
2.7 Prevalência de Objetos .................................................................................................... 33
2.7.1 O Prevayler .................................................................................................................... 33
2.7.2 Componentes da Prevalência..................................................................................... 33
2.7.2.1 A serialização ....................................................................................................... 33

2.7.2.2 A Restauração...................................................................................................... 33
2.7.3 A Prevalência em funcionamento .............................................................................. 33
3 ANÁLISE E PROPOSIÇÃO ................................................................................33
3.1 APRESENTAÇÃO DO DILEMA MDA............................................................................ 33
3.1.1 Para onde então, a partir daqui?................................................................................ 33

Página 10/96
3.2 XDF: UMA ALTERNATIVA DE SOLUÇÃO PARA O DILEMA MDA......................... 33
3.2.1 DIFERENCIAIS DO XDF............................................................................................. 33
3.2.2 O DESENVOLVIMENTO SOB XDF .......................................................................... 33
3.2.3 OS COMPONENTES DO FRAMEWORK XDF ....................................................... 33
3.2.3.1 XDFDesigner ........................................................................................................ 33

3.2.3.2 XDFObjectBrowser .............................................................................................. 33
3.2.3.3 XDFPrevalence .................................................................................................... 33
3.2.3.4 XDFStateMachine................................................................................................ 33
3.2.3.5 XDFObjectServer ................................................................................................. 33
3.2.3.6 XDFSecurity.......................................................................................................... 33
3.2.3.7 XDFWorkflow........................................................................................................ 33
3.2.3.8 XDFProxy .............................................................................................................. 33
4 DISCUSSÃO E INTERPRETAÇÃO ....................................................................33
5 CONCLUSÕES...................................................................................................33
6 REFERÊNCIAS BIBLIOGRÁFICAS ...................................................................33

Página 11/96
1 INTRODUÇÃO
A presente Monografia pretende conduzir a uma reflexão sobre a complexidade

tecnológica autotrófica3 uma vez que, na busca de resultados que objetivam oferecer
simplicidade, as tecnologias e métodos atualmente utilizados para conceber,
desenvolver e manter sistemas, desde os mais simples até os mais complexos,
ocultam do usuário final uma complexa teia de componentes inter-relacionados que
eleva sobremaneira os tempos de entrega (delivery) e os custos de
desenvolvimento, produção, manutenção e evolução, gerando inúmeros pontos de
falha que contribuem para a imagem negativa que se tem da informática atualmente.
“Seria então possível conceber, desenvolver e manter sistemas simples ou

complexos, com qualquer escala (tamanho), com garantias de documentação,
segurança e performance, em menos tempo e a custos menores, para que se
tornem à prova de futuro, dependendo menos de estruturas tecnológicas
complementares para funcionarem atendendo as expectativas do negócio?”.
Para construir uma resposta consistente a esse problema, que aponte para uma
solução com um escopo delimitado e que forneça um caminho de fato viável, faz-se
necessário contornar a complexidade do cenário tecnológico atual apresentando, de
forma objetiva e simplificada, os pontos entendidos como estruturantes para a
compreensão do contexto presente do ciclo de vida de sistemas informatizados.
1.1 O Iceberg tecnológico
Um brado de terror, ou algo parecido com isso, deve ter sido o que algum marujo
do Titanic disse ao avistar o imenso bloco de gelo, que o levou ao mais famoso
naufrágio da história da humanidade.
É quase certo que o timoneiro, ao ser informado e tomar consciência da situação,

temia a colisão do navio com aquele bloco de gelo, pela perspectiva de seu tamanho
sobre a superfície, desconhecendo talvez que, o que de fato levou ao naufrágio
aquele que era tido à época como insubmergível, foi a enorme ferida aberta no
casco submerso do navio, pela gigantesca força da parte submersa do iceberg.
3
Autótrofo – Bio: Organismo que a partir de seus componentes fabrica seu próprio alimento
Página 12/96
A correlação mental desta imagem com a complexidade tecnológica, bem

representa o cenário instaurado nos inúmeros ambientes de suporte tecnológico aos
negócios nos dias atuais. Assim como o timoneiro, o usuário de sistemas comum
desconhece a parte oculta do iceberg tecnológico, como também o esforço e o custo
para mantê-lo.
Sob a ótica do usuário comum, que quer se valer de recursos tecnológicos para
dinamizar seu negócio, sua visibilidade tecnológica dificilmente ultrapassa o que lhe
é apresentado em uma estação de trabalho, sob a forma de um ou mais sistemas,
desconhecendo toda a complexidade “submersa” e necessária para que este possa,
de fato, usufruir os benefícios esperados.
A imagem abaixo tenta representar o que de fato e em linhas gerais, separa o

visível do invisível a partir da ótica dos custos da tecnologia.
Figura 1 - O Iceberg Tecnológico

Fonte: Techlinks
<http://www.techlinks.net/CommunityPublishing/tabid/92/articleType/ArticleView/articleId/3718/On-Demand-
Business-Intelligence-Solution-Lowers-Total-Cost-of-Ownership-and-Risk.aspx >
Página 13/96
Se observada com cuidado, a imagem acima está orientada para os

componentes da infra-estrutura de TI (Tecnologia da Informação), quase todos
absolutamente necessários, em maior ou menor grau, dependendo da dimensão e
criticidade do negócio a ser sustentado tecnologicamente.
Desta forma, a imagem mental proposta só se torna completa quando são

oferecidos maiores detalhes sobre a composição do item Datacenter, que seria o
coração (ou core) da parte submersa do iceberg, notadamente em Arquiteturas de SI
(de Sistemas Informatizados) centralizadas.
4
1.2 A Babel Tecnológica
Na grande maioria dos casos, é no Datacenter que residem os principais

componentes que estabelecem a(s) Arquitetura(s) Tecnológica(s), também
denominada tecnicamente como frameworks, e onde são processados os sistemas a
serem utilizados pelos usuários.
Ao longo de mais de meio século de desenvolvimento da Tecnologia da

Informação, centenas, talvez milhares de componentes tecnológicos de hardware e
software, foram desenvolvidos e colocados em produção, para suporte da criação de
sistemas voltados aos mais variados tipos de negócios.
Arquiteturas, linguagens, protocolos, sistemas gerenciadores de dados,

geradores, interpretadores e gerenciadores de códigos, gerenciadores de filas,
ferramentas de integração como as utilizadas para extração e transformação de
dados (ETL5), Web Servers, Data Warehouse, Business Intelligence e os famosos
ERPs (sistemas integrados de gestão empresarial) são alguns dos muitos exemplos.
Para a maioria dos casos, deve-se considerar a necessidade de que sejam

criadas camadas de integração intra e/ou inter arquiteturais, como no caso de
frameworks complementares de segurança, e outros mais distintos para tratamento
entre canais de relacionamento on-line (Front-Office) e estruturas de retaguarda off-
line (Back Office).
4
Conceito idealizado pelo Autor
5
ETL: Extract and Transformation Languages
Página 14/96
É certo que, com o passar do tempo, muitos componentes simplesmente

deixaram de existir, seja por sua obsolescência técnica, seja pela falta de
investimentos, por problemas de timing ou marketing, pela sedução a novos
modismos ou mesmo pela falta de condições destes para atendimento ao futuro
imediato que a dinâmica dos negócios a estes impôs.
Nestes casos, caros processos de migração, conversão ou substituição

tecnológica foram e vem sendo empreendidos, em sua maioria, sem o devido
planejamento, com elevados custos e com resultados muitas vezes frustrantes. De
outro lado, também é certo considerar que outros componentes se tornaram padrões
de fato, seja por sua efetividade no atendimento ao negócio, seja pelos elevados
investimentos relacionados com a substituição, ou pelo poder econômico e de
marketing de seus fornecedores.
Nestes casos, observa-se a opção por sua manutenção, adicionando-lhes

camadas de integração ou de conversação com as novas tecnologias e novos
canais de relacionamento. Ainda que as novas partes a serem integradas pareçam
mais baratas, se observado o todo, vê-se uma enorme e cara complexidade. Abaixo
uma representação de Arquitetura Tecnológica genérica, que pode ser um exemplo
do que estaria contido no coração de um Datacenter.
Figura 2 - Framework Genérico

Fonte: FGV, Apostila da Disciplina de ASI - Arquitetura de Sistemas de Informações.
Página 15/96
Talvez o melhor exemplo recente a ser dado para o incremento da complexidade,

seja o advento e o impacto da Internet nos negócios e na vida das pessoas.
Trazendo a superfície um canal de relacionamento absolutamente inédito até o

final da década de 1990, a Internet vem exigindo fortes movimentos para criação de
novas soluções, seja pela adaptação ou pela substituição do que se costuma
chamar de Legado.
Em linhas gerais, tudo que se encontra em produção pode ser considerado como
Legado, pelo simples fato de já não ser mais entendido como novo. Muitos vêem os
componentes tecnológicos e sistemas Legados como feudos particulares, outros os
percebem como ameaças, alguns como oportunidades e outros ainda, simplesmente
como “aquilo que de fato funciona”.
6
1.3 A Teoria das Ondas
Para exemplificar a dinâmica da gênese, consolidação e morte das tecnologias

na citada Babel Tecnológica, pode-se exercitar uma imagem mental representada
por um mar revolto (vulgarmente conhecido como “de ressaca”) que, ao chegar à
praia, pode fazer entender melhor, através do choque de suas ondas, a realidade da
convulsão tecnológica instaurada na área da Tecnologia da Informação.
O que se observaria nessa imagem mental seriam ondas “engolindo” ondas;

ondas em vários sentidos se chocando violentamente umas contra outras, ondas
que parecem à distância portentosas, mas que ao chegarem à praia, simplesmente
deslizam serenamente para a morte.
O melhor exemplo concreto de uma onda tecnológica é o conceito criado em

1995 pelo Gartner Group denominado Hype Cycle.
Um Hype Cycle é um gráfico (muito parecido com uma onda) que busca
representar a maturidade, adoção e aplicação ao negócio de uma tecnologia
específica.
6
Página 16/96
Desde 1995, o Gartner Group tem usado essa representação para caracterizar o
super entusiasmo (ou Hype) do mercado e o subseqüente desapontamento que
tipicamente acontece com a introdução de novas tecnologias. Um Hype Cycle típico
tem cinco fases, conforme o exemplo mostrado na figura 3.
Figura 3 - Exemplo de Hype Cycle

Fonte: Geospatial Semantic Web Blog
http://geospatialsemanticweb.com/2006/08/10/gartners-hype-cycle-for-emerging-technologies-2006
A primeira fase, denominada “Gatilho Tecnológico” corresponde ao lançamento

de uma nova tecnologia ou produto, ou ainda outro evento que gere significante
mídia ou interesse da comunidade de TI.
A segunda fase, denominada “Pico das Expectativas Infladas” corresponde a um

frenesi ou publicidade tipicamente gerada por um super entusiasmo ou expectativas
não realistas. Neste ponto encontram-se algumas aplicações da tecnologia que
terão sucesso, ao tempo em que outras são tipicamente fadadas a um rápido
descarte.
Página 17/96
A terceira fase, denominada “Vale das Desilusões” é o momento em que a

tecnologia tende a falhar no desafio de ir ao encontro das expectativas geradas na
fase anterior e rapidamente se tornam fora de moda. Conseqüentemente a mídia
especializada usualmente retira seu foco de interesse da mesma.
A quarta fase, denominada “Ladeira do Iluminismo” é o momento em que, ao

tempo em que a mídia especializada para de cobrir a tecnologia, alguns negócios
continuam empolgados com a mesma e, pela ampliação de seu entendimento,
experimentam benefícios e aplicações práticas daquela tecnologia.
A quinta e última fase, denominada “Platô de Produtividade”, corresponde ao

momento em que a tecnologia em questão alcança seus objetivos e benefícios
práticos, se tornando largamente demonstrada e aceita. A tecnologia torna-se
gradativamente mais estável e evolui para uma segunda e/ou terceira gerações. A
altura final do platô varia de acordo com o estágio de amplitude de aplicação ou dos
benefícios gerados para determinados nichos de mercado.
Isto uma vez colocado e entendido, o que se deve exercitar mentalmente são
centenas, talvez milhares de Hype-Cycles, evoluindo e/ou involuindo como ondas
interagindo entre si, seja de forma simbiôntica, seja de forma canibalesca,
convivendo ou se confrontando com estruturas Legadas consolidadas ou em
decomposição.
Cada onda busca impor-se como um novo padrão a ser adotado pelo (ou por
parte) do mercado, tornando cada vez mais complexo o ambiente de TI em nosso
tempo, ainda mais se for considerada a velocidade crescente dessas ondas e de
suas “fases”, como também a força embarcada em outras, as quais poderiam até ser
apelidá-las de tsunamis7.
8
1.4 Os especialistas especializados
A conseqüência direta e penosa do que foi até aqui apresentado é que, de

conformidade com a lógica da nova Era da informação, se torna literalmente
7
Tsumani: Termo de origem asiática que representa uma onda de proporções catastróficas
8
Página 18/96
impossível para uma única pessoa dispor de todo o conhecimento técnico sobre
cada parte componente das complexas soluções tecnológicas atualmente adotadas.
Há que se dividir; há que se fatiar.
Como as máquinas e os sistemas não atingiram a maturidade “hollywoodiana” de

auto-gestão, esta árdua tarefa fica para seres humanos, com todas as suas
imperfeições, que alimentam ainda mais toda essa complexidade. Para dispor de um
controle melhor, como o todo está sendo dividido em partes, cada uma destas se
especializa e exige, per si, profissionais altamente capacitados e caros, para atuar
na sua gestão operacional e tática. Daí, surgem os especialistas em cada tipo de
tecnologia que compõe o todo.
Já não existe mais espaço para o velho médico de família generalista que
atendia a domicílio e resolvia todos os problemas com ungüentos e pílulas mágicas.
Como os problemas se tornaram muito complexos, cada qual abre seu nicho de
especialização e seu caráter “proprietário”.
Por mais aberta que seja uma solução tecnológica, ela é em si proprietária,
possuindo seus códigos próprios e formas de manejo personalistas até mesmo para
garantir seu caráter aberto e comunicar-se com “as outras tecnologias”.
Mesmos os decantados ERPs9, amados por uns e odiados por outros tantos, que
prometem a partir da adoção de melhores práticas (de quem?), resolver todos os
problemas do negócio, uma vez em sendo adotados, criam em torno de si um
mundo tecnológico à parte, que escraviza seus usuários.
Minha abordagem aqui não se presta a condenar a especialização, vez que se

trata de uma saída eficiente para um mundo globalizado, mas tão somente,
reconhecer que esta é fruto da complexidade de nosso tempo e das soluções que
estão sendo construídas. São, portanto, inegáveis os avanços derivados da
especialização.
Desta forma, o que se pretende ressaltar neste ponto é a multiplicação do que se

observa - notadamente no cenário de TI - dos “especialistas especializados”.
9
ERP: Enterprise Resourcing Planning
Página 19/96
Explicando o termo cunhado, temos que hoje não basta ser especialista em uma
disciplina de TI, é necessário se especializar ainda mais em uma determinada
marca. Não basta saber programar, é necessário especializar-se em determinada
linguagem. É como ter que se render à clássica imagem de Charles Chaplin,
apertando parafusos como um autômato em “Tempos Modernos”, uma de suas mais
brilhantes obras cinematográficas.
Quando se associa esta abordagem a Teoria das Ondas, observa-se uma

espécie de convulsão, exigindo muitas vezes por questão de sobrevivência, que
todos corram atrás de se manterem sempre atualizados diante de novas ondas
tecnológicas que, potencialmente, se candidatam a substituir suas antecessoras
que, por sua vez, consomem a quase totalidade de tempo laboral das pessoas.
O desgaste humano dos profissionais de TI não é novidade. Os mais entusiastas

passam quase 24 horas do seu dia, de alguma forma, “plugados” e preocupados
com a tecnologia. Ora, mas esta não adveio para nos proporcionar mais conforto e
melhorar nossa qualidade de vida?
Inúmeros são os exemplos de técnicos que não suportam essa rotina por mais de
10 a 15 anos. Buscam aproveitar ao máximo os frutos de determinada onda
tecnológica, tentando alcançar determinado nível de independência financeira e
abandonar o barco, para se refestelarem à sombra de um coqueiro na praia,
satisfeito talvez em viver da venda de sanduíches naturais ou coisa parecida.
Aqueles que não conseguem chegar à praia tendem a se submeter à rotina do

turnover10, pulando de empresa de em empresa, por não mais suportar a
complexidade que os oprime, ou procuram uma nova empresa que lhes garanta a
continuidade da onda tecnológica que os acomoda. Outros profissionais são
simplesmente descartados por outros (normalmente mais jovens), que estejam mais
afinados com a nova onda ou disponham de energia para dar continuidade ao que
se deve manter atualizado ou converter ou desenvolver ou ainda redesenvolver.
Sem dúvida, com base nas tecnologia que de fato “vingam” uma enormidade de
conhecimento é gerado sob a forma de regras de negócios, mas seriam essas
10
Termo de origem inglesa que representa a constante substituição de profissionais
Página 20/96
regras não redundantes? Estariam atomizadas (ou componentizadas) com a melhor

performance possível? Estariam as mesmas regras devidamente catalogadas e
documentadas para a compreensão dos outros?
1.5 O problema da Documentação
Diante de tanta complexidade, pressões pelo cumprimento de prazos muitas

vezes mal dimensionados, mudanças tardias de escopo que devem ser acatadas
estourando os orçamentos; como garantir que os sistemas contem com
documentação de qualidade e que a mesma se mantenha atualizada durante todo o
ciclo de vida dos mesmos?
A importância da documentação sempre tem sido relegada ao segundo (às vezes

ao último) plano, no processo de desenvolvimento e manutenção de sistemas. São
inúmeros os exemplos de sistemas construídos sem a observância de métodos
consistentes, contando com uma documentação limitada ao que os programadores
registram nos códigos fontes.
A conseqüência da falta de uma documentação adequada se reflete em projetos

mal construídos e de difícil manutenção. Assumir um projeto em sua fase de
desenvolvimento ou a manutenção de um sistema, sem adequada documentação é
como adentrar a uma caverna escura, úmida e desconhecida, munido apenas de
uma caixa de fósforos. É preciso organizar esse caos. Mas como?
1.6 Do caos a ordem caótica. Porque Projetos de TI ainda falham tanto?
A indústria de software, desde o seu início, sofreu e ainda sofre diversos

problemas que deram início a um contínuo processo de descrédito da área de
Informática. Essa crise foi denominada desde o seu início como “A Crise do
Software”. Esse termo é aceito por uns e contestado por outros que preferem dizer
que o que ocorreu e ainda ocorre é uma “Aflição Crônica” na indústria de software
[PRESMAN02]. Independente do termo empregado, os problemas com a indústria
de software ainda estão presentes nos dias atuais, sendo que os motivos é que
foram alterados com o passar dos tempos.
Para tentar reduzir esses problemas, e atender a disciplina de Engenharia de

Software, organismos internacionais iniciaram movimentos visando à criação de
Página 21/96
normas e padrões para auxiliar as empresas produtoras de software, no objetivo de

conseguirem criar seus produtos dentro do prazo e custo estipulados, com um
padrão de qualidade que atenda às expectativas do usuário e cliente do software.
Dentre esses organismos destacam-se:
International Organization for Standardization – ISO (Organização

Internacional para Padronização);
International Electrotechnical Commission – IEC – Software Engineering

Institute - que se inspirou no livro “Quality is Free” [Crosby1979] para a
criação do Capability Maturity Model for Software (CMM) [Paulk1995].
Project Management Institute – PMI;
Institute of Electrical and Eletronics Engineers – IEEE.
Esses organismos criaram normas que serviram de referência para as empresas

de software e que servem também para os clientes dessas empresas.
Nas Empresas que passaram a utilizar normas mais pertinentes à produção de

software e melhoria contínua da qualidade, a qualidade e o sucesso dos produtos
tiveram, de fato, um aumento registrado. Conforme o gráfico verifica-se na Figura 4
sobre Formas de Implementação de Software, nota-se uma melhoria dos resultados
nos últimos anos. Os dados foram coletados e analisados pelo Standish Group em
2004 [STA2004].
Figura 4 - Resultados de Projetos

Fonte: Standish Group em <http://www.standishgroup.com/benchmark/performance.php>
Página 22/96
Com os dados demonstrados na Figura 4, conclui-se que, apesar da melhora

obtida com a utilização das normas e de um Gerenciamento mais efetivo dos
projetos, a indústria de software ainda está com um grau de eficiência muito aquém
do desejado e muito inferior a outras áreas de negócios, onde projetos com êxito
representam um percentual muito mais alto.
Por outro lado, na tabela da Figura 5, tem-se que a maioria do desenvolvimento

(36%) ainda é realizada utilizando linguagens e métodos tradicionais.
Figura 5 – Tabela de formas de implementação de softwares

Fonte: Standish Group em <http://www.standishgroup.com/benchmark/performance.php>
O que explicaria então uma evolução tão tímida ao longo de tantos anos com a
aplicação de normas de qualidade para o desenvolvimento de softwares?
Recorrendo ao pensamento de Domenico De Masi [DEMASI], pode-se perceber

claramente que “as máquinas mudam (ou evoluem) muito mais velozmente que os
hábitos, as mentalidades e as normas”. Quanto mais complexo se torna o trabalho,
mais complexas se tornam as normas para organizá-lo, e existe uma complexidade
intrínseca também em absorver e aplicar as novas normas que competem entre si
para demonstrar maior eficiência ou efetividade. Daí surge toda uma indústria de
certificações de qualidade.
Apesar dos avanços da sociedade pós-industrial, as organizações e mesmo as

atitudes humanas que ainda imperam, são aquelas da era industrial. As dificuldades
se agigantam quando novas técnicas e métodos moldam algo para o qual, ou não se
dispõe de perfis preparados ou, de fato, não existe suporte realístico para sua
Página 23/96
execução. O fato é que a tecnologia evolui com a velocidade da luz enquanto os

seres humanos andam a passos de tartaruga.
Reduzir a complexidade no cenário de TI adotando novos paradigmas é, então,

uma das chaves para minimizar os efeitos das frustrações modernas relacionadas
ao não atendimento a prazos e orçamentos em projetos de TI.
1.7 O resumo da Ópera
Observa-se, no dia a dia prático e na grande maioria das vezes, que o negócio
corre atrás dos concorrentes, enquanto que a TI corre atrás do negócio, sem dispor
de especificações claras. Feito um sistema e colocado em produção, via de regra o
negócio não se reconhece em sua “versão tecnológica” e com isso aumentam as
falhas, o retrabalho, o turnover e o custeio. A TI “resolve” o problema oferecendo
muitas vezes mais complexidade. Diante de novos fracassos diminuem a
credibilidade, os recursos e as receitas. O negócio, querendo se perpetuar anseia
por sistemas à prova de Futuro!
Apesar de existirem muitos outros pontos que poderiam ser abordados para
caracterizar o contexto que envolve o problema alvo desta Monografia, a questão
central reside em separar o negócio de suas formas de implementação da forma
mais radical possível.
De outro lado, essa separação só se faz possível ao aproximar usuários e

técnicos pelo uso de uma linguagem mais natural e conceber um framework de SI
mais simples, capaz de promover a “desconstrução” da complexidade, gera a
expectativa que esse movimento derive num ciclo virtuoso de simplificações a ponto
de tornar os processos mais automáticos, ágeis e baratos, colocando o ser humano
no seu devido lugar, o de conceber e criar.
Para fazer isso, o espírito do que será demonstrado nesse trabalho deve
enfrentar e romper com paradigmas estabelecidos e entranhados na indústria de
software há décadas.
As hipóteses a serem apontadas nesta Monografia deverão permitir a

apresentação de uma alternativa de solução objeto de exploração científica, visando
estabelecer um escopo delimitado de atuação para o desenvolvimento do trabalho,
Página 24/96
como forma de contribuir para a redução da complexidade tecnológica que acaba

por formar uma teia de inter-relacionamentos que elevam sobremaneira os esforços,
os tempos e os custos para produzir e manter sistemas. Desta forma segue o
conjunto de hipóteses, entendidas como a base para o alcance de uma solução de
fato inovadora para o problema até aqui apresentado:
A UML (Unified Modeling Language) [UML04] vem demonstrando ser uma

alternativa extremamente viável para a descrição de problemas de forma mais
compreensível tanto para os especialistas em tecnologia como para os
usuários responsáveis pela descrição do negócio;
O uso aplicado e disciplinado da metodologia e das técnicas de Orientação a

Objetos no desenvolvimento de sistemas traduz de forma mais simples a
realidade dos negócios, contribuindo para uma representação mais natural e
compreensível do mesmo;
O ferramental atualmente existente para suporte à composição de Modelos

expressos em notação UML e Orientação a Objetos podem permitir que a
documentação dos sistemas seja a gênese e o arcabouço final para a
geração automática de sistemas, sendo que sua manutenção não seria
realizada no código fonte gerado, mas tão somente, em uma abordagem
translacionista, nos modelos construídos;
O conceito de MDA – Model Driven Architecture (Arquitetura Orientada a

Modelos) [MDA04] separa a lógica fundamental entre uma especificação do
negócio, das configurações técnicas de uma determinada tecnologia que as
implementará. Isto permite o rápido desenvolvimento e entrega de novas
especificações interoperáveis que usam novas técnicas de desenvolvimento,
baseadas nas comprovações de modelos de negócios já testados;
O Conceito de Prevalência de Objetos em memória volátil, em substituição a

utilização da Persistência de dados em SGBDs (Bancos de Dados), reduz
dramaticamente a necessidade de transformações objeto-relacionais,
contribuindo para redução do sizing (tamanho) das bases a serem
armazenadas, simplificando sua administração e contribuindo para ganhos de
até duas ordens de grandeza no que concerne a performance dos sistemas;
Página 25/96
O contínuo barateamento das plataformas de hardware e a introdução da

tecnologia de 64 bits, associado aos novos parâmetros de endereçamento de
memória voláteis (RAM) das novas versões dos Sistemas Operacionais (já na
ordem de PetaBytes), viabilizam a implementação de modelos Orientados a
Objetos, escritos em UML, para geração automática de Servidores de Objetos
Prevalentes que são capazes de dispensar o uso intensivo de
armazenamento magnético;
Os conceitos e técnicas de Workflow (Fluxos de Trabalho) orientado a

processos (Business Process Management), uma vez aplicados na
construção de modelos, são capazes de conduzir os usuários a uma
execução padronizada de suas rotinas de trabalho, simplificando
sobremaneira a forma como os negócios são conduzidos;
A funcionalidade de uso dos sistemas por intermédio de interfaces (Browsers)

polimórficas padronizadas (que se adaptam aos perfis dos usuários) reduz
dramaticamente os tempos de aprendizagem dos usuários e podem contribuir
– notadamente sob um modelo de processamento de dados centralizado –
para a redução do Custo Total de Propriedade (TCO), seja na parte servidora,
seja na parte cliente;
O compartilhamento de modelos, classes e objetos revolucionam a forma de

desenvolver e manter sistemas pela imposição do reuso de componentes e
pela condição de atuação concorrente e simultânea de vários
desenvolvedores nas tarefas relacionadas com a construção de um mesmo
modelo ou de modelos associados;
Linguagens e compiladores de código livre podem gerar sistemas a partir de

seus modelos para processarem sob a forma de código nativo em mais de
dez plataformas de hardware distintas, sem a necessidade de interpretadores
ou gerenciadores de código, contribuindo ainda mais para a performance dos
mesmos;
A conjunção das hipóteses apresentadas até este ponto contribui

sobremaneira para a redução da quantidade de artefatos a serem gerados e
mantidos no ciclo de vida dos sistemas, reduzindo os tempos de
Página 26/96
documentação dos artefatos requeridos pelas metodologias para gestão de

projetos de desenvolvimento de sistemas tal como, por exemplo, aquela mais
difundida no mercado e denominada RUP (Rational Unified Process®).
É a partir da manipulação coordenadas das hipóteses citadas que se objetiva

uma Alternativa de Solução conforme abaixo descrita de forma resumida:
“Conceber e construir um framework autônomo para desenvolver, automatizar a

geração, manter e processar sistemas informatizados que, adotando novos
paradigmas de Orientação a Modelos (MDA) sob a abordagem Translacionista,
Orientação a Objetos (OO), Diagramas UML e Prevalência de Objetos, contribua
para a redução da complexidade da TI, separando radicalmente as regras dos
negócios das escolhas tecnológicas de plataformas heterogêneas para sua
implementação”.
Entende-se que, quanto maior for o êxito no alcance da solução proposta, maior
será o número de elementos a colaborarem na aceleração e uso aplicado do “ciclo
virtuoso” que se espera gerar. Um framework conforme anteriormente resumido
deverá, portanto:
Contribuir para a melhoria do entendimento e representação do negócio,

aproximando técnicos e usuários através de uma linguagem mais
compreensível a ambas as partes (UML);
Fazer da documentação, sob a forma de Modelos Gráficos, a gênese do

processo de desenvolvimento de sistemas e o único mecanismo para se
promover alterações visando mantê-los e evoluí-los, contribuindo
sobremaneira para a Gestão do Conhecimento e a Gestão do Portfólio;
Permitir o desenvolvimento colaborativo e simultâneo dos Modelos e seus

artefatos componentes (classes, objetos e atributos), seja sob ambiente de
rede local, seja pela Internet;
Contribuir para a criação de Modelos Corporativos de Negócios que facilitem

o reuso de componentes de forma mais natural, compreensível e pragmática;
Página 27/96
Reduzir ou eliminar a intervenção humana nos processos hoje reconhecidos

como Projeto Lógico, Projeto Físico e Construção (ou codificação);
Eliminar os erros decorrentes do esforço de codificação;
Eliminar a necessidade de utilização de Sistemas Gerenciadores de Banco de

Dados, Application Servers, Queue Servers e Web Servers;
Ter como variáveis dependentes e exógenas ao framework (premissas e

restrições) apenas o Sistema Operacional e sua capacidade de
endereçamento de memória volátil;
Permitir a criação instantânea de protótipos funcionais em processos

interativos, gerando resultados mais rápidos, sem descartes do que for
construído;
Representar a dinâmica das regras dos negócios por intermédio de

orientação a processos e fluxos de trabalho (workflow);
Reduzir os esforços relacionados com os ciclos de testes funcionais e

integrados;
Oferecer uma interface para desenvolvedores e usuários com recursos

gráficos, padronizada e polimórfica que possa funcionar em modelos de
processamento distribuídos ou centralizados;
Oferecer nativamente gerador de relatórios, scheduller (para agendamento de

rotinas batch), segurança integrada ao sistema operacional (single-logon),
ferramental para importação e exportação de arquivos e APIs11 para
interoperar com outros frameworks;
Gerar os sistemas automaticamente a partir de seus Modelos por intermédio

de compiladores de código aberto (livre), com menor foot-print (tamanho) dos
executáveis e para mais de dez plataformas distintas, compatíveis com
arquiteturas de 32 e 64 bits;
11
API: Application Program Interface
Página 28/96
Reduzir os tempos e os custos de construção e manutenção de sistemas

assim como o esforço relacionado com a aprendizagem do usuário final;
Contribuir para a redução do TCO (Total Cost of Ownership) das instalações

de TI pela indução de um ciclo virtuoso de redução da complexidade derivada
das práticas e alternativas atuais.
Página 29/96
2 FUNDAMENTAÇÃO TEÓRICA
Este tópico é destinado à explicitação do domínio da área do conhecimento

científico acerca da teoria de suporte ao atendimento dos objetivos da Monografia.
Trata-se, portanto, de uma resenha da fundamentação teórica que embasa a análise
a ser efetuada.
2.1 Orientação a Objetos (OO)
Antes de falar realmente sobre determinada linguagem orientada a objetos é

necessário que se disponha dos conceitos básicos da Orientação a Objetos. Desta
forma, são eles:
Classe: É qualquer estrutura modular que faz parte de um produto. As

janelas, por exemplo, fazem parte de uma casa, de um carro ou de um
software com interface gráfica para o usuário.
Atributos: São características da classe, como cor e tamanho, uma janela,

por exemplo, tem atributos como o modelo, tamanho, abertura simples ou
dupla, entre outros.
Ações: São as operações efetuadas pela classe, que determinam sua

interface. Todas as janelas, por exemplo, podem controlar a iluminação e
temperatura ambiente, dependendo do seu design.
Objeto: É uma instância de uma classe. Por exemplo, a janela da sala de

estar de uma determinada casa é um objeto distinto da janela do quarto do
casal embora possam pertencer à mesma classe, ou seja, têm os mesmos
atributos e ações.
Encapsulamento: Mecanismos inerentes à classe, que oculta suas

características internas do usuário, através de uma interface simples. Uma
pessoa pode abrir uma janela girando a tranca sem precisar saber o que há
dentro dela.
Página 30/96
Herança: Uma classe nova nem sempre é criada do zero. Ela pode "herdar"
atributos e ações de outras já existentes. Um basculante herda atributos das
janelas e das persianas.
Polimorfismo: É a capacidade dos objetos de classes diferentes, com

ancestral comum, reagirem segundo a sua função a uma ordem padrão. O
comando "abrir", por exemplo, faz um objeto entrar em ação, seja ele uma
janela, uma porta ou uma tampa de garrafa.
Ligação: É quando um objeto conecta a sua ação a outro. Um sensor de

claridade, por exemplo, ativa o acendimento automático da iluminação da rua.
A Orientação a Objetos em computação já completou seus 40 anos, apesar de

ter surgido fortemente apenas nos últimos 10 anos. Sua força reside ainda, de forma
mais contundente, na área acadêmica. Abaixo, algumas iniciativas nesse sentido:
1967: Simula (Noruega);
1980: Small Talk com objetivos comerciais e acadêmicos;
1990's: Objective C (Cox), C++ e Eiffel.
2.1.1 Benefícios da OO
Anos 60 e 70 - Época das linguagens não estruturadas, dados e códigos

emaranhados.
Anos 80 - Época das linguagens estruturadas, dados separados de códigos

(modulares).
Anos 90 - Época da OO, onde dados e códigos começam a serem

organizados sob a forma de objetos.
A partir dos anos 80, as principais linguagens estruturadas incluíram conceitos de

OO. São exemplos: Pascal, C, Lisp, Cobol, depois evoluíram com a inclusão de
classes C++ que foi um marco para aplicações em todos os níveis.
Os principais ganhos para o desenvolvedor, caso este troque a Metodologia

Tradicional pela Orientada ao Objeto devem se refletir conforme se segue:
Página 31/96
Exatidão: Devido à característica do desenvolvimento estruturado ser em

cascata (waterfall), onde se elabora um projeto e depois se fazem os
programas, pode derivar, ao final, em um sistema que não atenda
perfeitamente seus objetivos depois de implementado. Nas metodologias de
desenvolvimento OO, devido ao fato destas serem feitas de maneira quase
que interativa com o usuário, este risco é significativamente diminuído. A
menor quantidade de código programável, obtida através do reuso
proporcionado pelos conceitos de herança e polimorfismo, também reduz os
problemas inerentes às mudanças das especificações durante o
desenvolvimento do projeto.
Potencialidade: É a forma como o programa reage aos erros imprevistos

como uma falha na impressora, ou a um disco cheio. Quanto maior for a
potencialidade, maior a capacidade do programa em causar o menor estrago
possível aos dados e evitar uma saída drástica do sistema.
Extensibilidade: Dize-se que quanto maior for a extensibilidade do software,

maior será sua capacidade em adequar-se as especificações definidas pelos
analistas.
Reutilização: A capacidade de se otimizar a produtividade do programador

depende diretamente da maneira como o software disponibiliza a reutilização
do código gerado. De fato, a maioria dos programadores profissionais, já
reutiliza código anteriormente gerado, porém a perfeita reutilização consiste
na utilização completa de um código gerado para algum sistema sem
qualquer outra adaptação prévia.
2.1.2 Linguagens Procedurais X Orientada a Objetos
Mesmo as linguagens procedurais oferecem hoje alguma característica funcional

Orientada a Objetos.
Seu conjunto de primitivas, porém permite que você digite comandos para que o
computador execute. A organização e a manipulação dos dados vêm depois. A
linguagem OO é projetada para permitir a definição dos objetos que compõe os
Página 32/96
programas e as propriedades que estes objetos contém. O código é tido como

secundário.
Pode-se programar na forma procedural com estilo OO quando o programa tem

um nível tal de sofisticação em que se comece a criar seus próprios tipos e
estruturas de dados. A linguagem OO pura tem como um parâmetro de referência
que todos os dados sejam representados na forma de objetos. Exemplos de
linguagens OO puras: SmallTalk, Eiffel e Java.
Alguns exemplos de linguagens híbridas, ou seja linguagens procedurais com

extensões OO, são: C++, Object Pascal do ambiente Delphi, Perl e Objective C que
implementam tipos simples de dados (integer, real, char) como o C, não sendo
objetos mas tudo o mais lida com objetos. O código e os dados residem em classes
e objetos.
2.1.3 Linguagens Compiladas X Interpretadas
Linguagem Compilada - código gerado tem alta performance pois é ajustado

para um tipo específico de processador. Código Objeto em binário para
aquele processador. Ex. Pascal (entenda-se também no Delphi).
Linguagem Interpretada - só existe em código fonte. Durante a execução o

interpretador pega o fonte e vai executando as ações. Facilita o uso em
múltiplas plataformas. Ex. Basic.
Um caso de linguagem Compilada/Interpretada ou pseudo compilada é o Java.

Em Java o código fonte é pseudo compilado, produzindo um arquivo intermediário
chamado arquivo de classe que não é executado de forma direta.
Este código intermediário chama-se bytecode que são instruções para uma
máquina virtual (a JVM - Java Virtual Machine). Por fim a JVM, que é o interpretador
Java, executa os arquivos de classe.
A OO tem a filosofia de implementar uma abstração do mundo real facilitando a

reutilização de código, denominado de caixas pretas de softwares ou ainda
softwares IC's (Integrated Circuits) que estão sendo utilizados aqui como uma
analogia de chip com objeto.
Página 33/96
Apesar da técnica de Orientação a Objetos (OO) estar sendo difundida, como

demonstrado na Figura 5, somente um quinto dos sistemas atualmente
desenvolvidos utilizam essa abordagem. A compreensão e utilização intensiva da
OO são fundamentais para a utilização das novas ferramentas de desenvolvimento
que estão sendo lançadas no mercado além de representar, o mais fielmente
possível, as situações do mundo real nos Sistemas Computacionais.
Com isso os Gestores de Negócios e usuários de TI passam a ter uma visão

mais nítida do que um sistema informatizado pode oferecer para auxiliar os seus
trabalhos.
2.2 Arquitetura de Software (ou Framework de SI)
Há aproximadamente quatro décadas, o componente software constituía uma

pequena, senão ínfima, parcela de importância nos sistemas computacionais
quando comparado ao hardware.
Os custos de desenvolvimento e manutenção de software podiam ser

considerados desprezíveis com relação à exorbitância dos gastos feitos com
hardware. Hoje, porém, o software é um elemento de fundamental importância – e
custo - no contexto dos sistemas computacionais, sobretudo em se tratando de
sistemas de grande complexidade.
A Arquitetura de Software enfatiza o modo de se obter resultados com menor

custo e maior qualidade para sistemas grandes e complexos. Projetar a estrutura
global de um sistema emerge como um problema novo, ou seja, o desenvolvimento
de software passa a ser fortemente influenciado pela arquitetura escolhida.
“Arquitetura de software é a estrutura dos componentes de um programa ou

sistema, seu inter-relacionamento, princípios e diretrizes guiando o projeto e a
evolução ao longo do tempo” [MENDES02].
Arquitetura de software refere-se à “estrutura global do software e aos modos

pelos qual essa estrutura fornece integridade conceitual para um sistema”
[PRESMAN02].
Página 34/96
A idéia básica da Arquitetura de Software é a de que um sistema de software em

elevado nível de abstração pode ser analisado e descrito através de subsistemas ou
componentes distintos (responsáveis pelo comportamento do sistema), de
conectores (interligando os componentes) e de padrões de conexão (possibilitando
vários tipos de interação e compartilhamento de informações entre esses
componentes), sendo esses inter-relacionados.
Esses componentes podem ser generalizados para representar os principais

elementos do sistema e suas interações. As possíveis alternativas de arquitetura
disponíveis podem formular regras para indicar boas e más opções de projeto.
Essas regras podem ser norteadas por requisitos funcionais e não-funcionais.
Em um projeto arquitetural de software, os esforços concentram-se na

organização do sistema, distribuição dos componentes, protocolos de comunicação,
mecanismos de sincronização e acesso a dados, dentre outros.
Um bom projeto arquitetural de software é capaz de facilitar a identificação de

estruturas comuns utilizadas em sistemas já desenvolvidos a fim de compreender as
relações existentes e desenvolver novos sistemas com base em variações de
sistemas antigos, além de possibilitar a tomada de decisão sobre várias possíveis
alternativas de projeto.
Uma descrição arquitetural do sistema também é essencial, a fim de analisar e

descrever propriedades de um sistema complexo. O conhecimento de notações
formais para descrição de paradigmas arquiteturais permite a apresentação de
novos projetos de sistemas para outras pessoas e instituições.
Um dos principais aspectos do projeto arquitetural é o uso de padrões de

organização de um sistema. Muitos desses padrões, também chamados de estilos
arquiteturais, têm sido desenvolvidos ao longo do tempo e cada um descreve uma
categoria de sistema que inclui um conjunto de conectores que permitem
comunicação, coordenação e cooperação entre componentes; restrições que
definem como os componentes podem ser integrados para formar o sistema; e
modelos semânticos que permitem ao projetista entender as propriedades globais de
um sistema.
Página 35/96
Os estilos mais relevantes são: arquiteturas centradas em fluxo de dados,

arquiteturas orientadas a objeto, arquitetura em camadas e arquiteturas orientadas
por modelos, objeto principal desta Monografia.
Na prática dos dias atuais, a arquitetura de um sistema quase nunca é obtida a

partir de um único estilo. Assim, o arquiteto de software necessita compreender
possíveis relacionamentos existentes entre eles gerando combinações de estilos.
O arquiteto de software deve reunir um conjunto de habilidades, como ter

conhecimento profundo do domínio no qual o sistema a ser desenvolvido será
utilizado, das tecnologias relevantes e dos processos de desenvolvimento.
É sua função construir modelos para o problema, buscando achar uma solução e
explorando abordagens alternativas. A documentação, neste caso, torna-se
imprescindível.
A Arquitetura de Software atua como um elo entre os requisitos e a

implementação. Uma escolha inadequada pode acarretar resultados insatisfatórios
em termos de desempenho, confiabilidade, interoperabilidade e outros requisitos
não–funcionais, diretamente relacionados à arquitetura de software do sistema.
2.3 Modelos e Metamodelos: Por que modelar software?
Um modelo é uma simplificação de algum objeto ou processo do mundo real, que

se pode visualizar e manipular de forma a se obter auxílio no entendimento e
comunicação de aspectos complexos do objeto em modelagem.
Há muito tempo, Analistas de Negócio, Engenheiros, Cientistas e outros

profissionais responsáveis por atividades que envolvam a construção de sistemas ou
estruturas complexas, constroem modelos do produto real a ser construído.
Os modelos podem representar conceitos concretos, como uma casa ou um

automóvel, ou mesmo conceitos menos tangíveis como simulações para o mercado
de ações.
Em todos os casos, um modelo é uma visão aproximada (abstração) da realidade

a ser representada.
Página 36/96
Os sistemas atualmente são dotados de considerável complexidade e, muito

freqüentemente, são integrados com outros sistemas para prover as funcionalidades
desejadas pelos usuários e automatizar processos de negócio de naturezas
diversas.
Sistemas de missão crítica devem oferecer margens ínfimas de erros devido à

vital importância das funções que desempenham em um dado contexto, requerendo
cuidados especiais nas atividades de desenvolvimento, manutenção e testes.
Em um mercado altamente competitivo, erros em determinados sistemas podem

causar além de vultosos prejuízos financeiros, danos irreparáveis à imagem de uma
organização.
O desenvolvimento de software por essas e outras razões já não pode prescindir

da modelagem como ferramenta essencial para tratamento da complexidade dos
sistemas a serem modelados, para que todos os envolvidos no processo de
construção do software tenham, a priori, a compreensão necessária acerca do que
se pretende construir.
Já um metamodelo é um modelo da linguagem de modelagem. Define a

estrutura, a semântica, e as restrições para uma “família” de modelos (modelos que
compartilham sintaxe e semântica comuns).
Um modelo é capturado por um metamodelo particular. Por exemplo, o MOF –

Meta Object Facility, [MOF03], um padrão do OMG – Object Management Group, é
um metamodelo da UML - Unified Modeling Language [UML04], pois expressa em
UML como modelos UML podem ser estruturados.
Esse metamodelo (MOF) descreve aspectos estruturais e comportamentais dos

modelos UML, mas não especifica como os modelos UML são armazenados,
representados graficamente, ou como eles poderiam ser editados por múltiplos
usuários concomitantemente.
Página 37/96
2.4 MDA - Model Driven Architecture
Figura 6 - Model Driven Architecture

Fonte: OMG em www.omg.org/mda
A MDA – Model-Driven Architecture (Arquitetura Orientada a Modelos) [MDA04] é

um framework para o desenvolvimento de softwares definido pelo OMG - Object
Management Group (Grupo de Gerenciamento de Objetos).
É, atualmente, vide Figura 6, a arquitetura baseada no paradigma MDD – Model

Driven Development (Desenvolvimento Orientado a Modelos) mais amplamente
conhecida e adotada no mercado de tecnologia.
As principais características da MDA são: o desenvolvimento fortemente baseado

nas atividades de modelagem e as transformações automáticas de modelos. Em
linhas gerais, evolui-se de um modelo abstrato do sistema – com foco
essencialmente negocial - para um modelo gradativamente mais concreto,
culminando, finalmente, com a geração do código-fonte.
2.4.1 Núcleo e Padrões
No núcleo do MDA [MDA04], padrões importantes do OMG [OMG04]: UML -

Unified Modeling Language [UML04], MOF - Meta Object Facility [MOF03] e CWM -
Página 38/96
Common Warehouse Metamodel [CWM03] alicerçam o framework e contribuem

sobremaneira na atividade de modelagem de sistemas.
2.4.1.1 CWM (Common Warehouse Metahouse Metamodel)
É um conjunto de interfaces padrão que podem ser utilizadas para possibilitar

metadados contendo a inteligência do negócio interoperar com ferramentas e
plataformas de DW (Datawarehouse) em ambientes heterogêneos. O CWM é um
padrão para integração de repositório de dados.
2.4.1.2 UML (Unified Modeling Language)
Unified Modeling Language (UML) – notação padrão na indústria para

representação gráfica de modelos de softwares orientados a objetos. A UML é
bastante indicada para a criação dos modelos em MDA, embora não seja a única
linguagem possível.
2.4.1.3 MOF (Meta Object Facility)
Meta Object Facility (MOF) – um framework para gerenciamento de metadados

usado na definição de vários metamodelos propostos pelo OMG, incluindo a UML e
o próprio MOF. O MOF foi mapeado para tecnologias de amplo uso na atualidade,
como o Java Metadata Interface (JMI) e o XML Metadata Interchange (XMI).
2.4.2 Camada Intermediária
Na camada intermediária do framework MDA estão os ambientes de middleware,

objetos de grandes esforços do OMG, atualmente: o ambiente webservice, CORBA
[CORBA04] principalmente, o CORBA Component Model ou CCM; Java, incluindo
EJB; C#, .NET, XML/SOAP. A proposta é de que, caso alguma plataforma específica
não esteja nessa lista ou caso novas plataformas surjam, os membros do OMG
deverão adicioná-la com a maior brevidade possível.
2.4.3 Pervasive Services (Serviços Universais)
As aplicações, independentemente do contexto em que se inserem, dependem

de um conjunto de serviços essenciais que variam de acordo com as características
de cada sistema, e normalmente incluem serviços de diretórios, segurança,
Página 39/96
manipulação de eventos, persistência e transações. Esses serviços são

representados na arquitetura no anel mais externo ao núcleo.
No framework MDA, os pervasive services são representados no mais alto nível

de abstração. A maneira com que esses serviços serão implementados na
plataforma específica ficará a cargo do framework, deixando transparente o
funcionamento para o desenvolvedor.
2.4.4 Os Níveis de Abstração em MDA
O framework MDA utiliza vários níveis de abstração que norteiam o processo de

desenvolvimento orientado a modelos. A idéia central é a concepção de um modelo
abstrato do sistema, com foco explícito nos aspectos negociais. A partir desse
modelo serão efetuados vários processos de refinamentos, acrescentando detalhes
específicos da plataforma escolhida para o desenvolvimento do sistema
[KLEPPE03].
2.4.4.1 CIM (Computational Independent Model)
O CIM representa uma visão do sistema sob um ponto de vista independente do

uso de computadores, descrevendo apenas os requisitos gerais de funcionamento
do sistema. Também denominado modelo de domínio (domain model) ou modelo de
núcleo (core model).
O CIM pode também ser chamado de Modelo de Negócio. Este modelo é

totalmente independente de implementações tecnológicas.
2.4.4.2 PIM (Platform Independent Model)
Um PIM é um modelo abstrato de um sistema de software que não incorpora

nenhuma escolha de implementação descrevendo o sistema independentemente da
tecnologia escolhida para a sua execução, porém já se admitindo que o sistema fará
uso de computadores. O PIM é um modelo declarativo formal da estrutura funcional
do sistema e o primeiro a ser gerado [MDA01], com alto nível de abstração,
representando uma futura aplicação de forma independente da implementação
tecnológica.
Página 40/96
O PIM descreve toda a aplicação que dará suporte a algum negócio, sem se
preocupar com qual plataforma ou tecnologia a utilizar. Uma vez concebido,
mantém-se intacto, mudando apenas quando o negócio sofrer modificações. Para
efetuar a modelagem do PIM, os projetistas podem utilizar várias notações de
modelagem, embora a UML seja a notação mais utilizada para a produção desses
modelos.
2.4.4.3 PSM (Platform Specific Model)
Outro modelo especificado em MDA é o PSM ou modelo específico de

plataforma. Um PSM é um modelo relativamente concreto de um sistema de
software e incorpora características de uma dada tecnologia. Deve-se ressaltar que
é muito provável que um processo de desenvolvimento de software consista de mais
de uma etapa de transformação. Como um PIM, um PSM poderia ser tanto a
entrada quanto a saída em uma transformação.
O PSM é resultado do refinamento de algum PIM. O PSM recebe detalhes de

construção do sistema baseado na tecnologia escolhida. Durante o processo de
mapeamento, as informações e configurações projetadas serão convertidas para
formatos específicos, requeridos pela plataforma escolhida [KLEPPE03].
2.4.5 Transformações entre modelos
Uma transformação é a geração de um modelo a partir de outro modelo. De

acordo com a visão MDA, as transformações devem ser executadas de forma
automatizada.
Tradicionalmente, as transformações entre os modelos em um processo de

desenvolvimento de software são realizadas de forma manual, resultando, não raro,
em incorreções e inconsistências entre a modelagem e a implementação.
Na arquitetura MDA, os modelos deverão ser usados para geração automática da

maior parte do sistema [SIEGEL01]. No processo de transformação de modelos
ocorrem, essencialmente, três etapas conforme ilustrado na Figura 7:
Primeiramente, constrói-se um modelo com um nível elevado de abstração,

independente de qualquer tecnologia de execução, denominado PIM.
Página 41/96
Em seguida, o PIM é transformado em um ou mais modelos específicos de

plataforma (PSM). O PSM é desenvolvido para especificar o sistema nos
termos das construções de execução disponíveis em uma tecnologia
específica. Como exemplo, um modelo com detalhes específicos de EJB
(Enterprise Java Beans).
A etapa final é transformar o PSM em código. Esta transformação é

considerada sob um prisma conceitual, a mais trivial de todo o processo.
Figura 7 - Transformações entre Modelos

Fonte: McNeyle, Ashley. Do Artigo "MDA: The Vision with the Hole?". 2003
Um ponto central sobre a abordagem MDA é que a automatização é usada para

produzir o PSM e o Código a partir de artefatos de nível superior, como indicado
pelas engrenagens simbólicas da Figura 7. Esta automação não apenas acelera o
processo de desenvolvimento, mas também garante que o código seja uma
representação fiel dos modelos mais alto nível, ao tempo em que os modelos são
também uma representação fiel do código gerado.
O benefício alegado pela MDA é que o PIM, sendo tecnologicamente

independente, é a melhor maneira de captar e preservar o investimento, intelectual e
financeiro feito no desenvolvimento de uma aplicação. Se o sistema precisa ser
implantado em várias plataformas, ou migrado de uma plataforma para outra, como
Página 42/96
tecnologia muda, o código pode ser regerado a partir do PIM. Acredita-se ser essa
abordagem, é mais rápida e mais barata do que migrar o código legado.
2.4.6 As duas abordagens da MDA
Um olhar mais próximo no que os desenvolvedores e metologistas estão

fazendo, revela que há duas interpretações bastante diferentes da forma como a
MDA pode ser alcançada.
Estas duas correntes de pensamento têm sido denominadas respectivamente

como "Elaboracionista" e "Translacionista" (termos que foram, inicialmente cunhados
por Stephen Mellor [STEPHEN01]). Um exemplo esquemático da primeira
abordagem, a Elaboracionista, é apresentado na Figura 8.
Figura 8 – Abordagem Elaboracionista

Fonte: McNeyle, Ashley. Do Artigo "MDA: The Vision with the Hole?". 2003
Na abordagem elaboracionista, a aplicação é construída gradualmente, à medida

que os refinamentos evoluem do PIM para o Código através dos PSMs.
Uma vez que o PIM tenha sido criado, uma ferramenta específica deve gerar um
esqueleto ou primeira versão do PSM a qual o desenvolvedor pode, em seguida,
"aperfeiçoar", acrescentando novas informações ou pormenores técnicos.
Página 43/96
Do mesmo modo, esta ferramenta deve gerar o código final do PSM final no
processo de elaboração. Este código admite ainda aperfeiçoamentos técnicos antes
da geração do executável.
Como resultado da elaboração, é possível que modelos de nível mais baixo

fiquem “descasados” dos modelos de mais alto nível. Por esse motivo, as
ferramentas geralmente buscam dispor da capacidade de regerar o nível mais alto a
partir de modelos de níveis mais baixos.
Tal capacidade é demonstrada no Diagrama pelas setas apontando para cima. A

capacidade de geração de baixo, modificar, e re-sincronizar para cima é conhecida
como Engenharia Reversa (round-trip engineering).
É evidente que, nesta abordagem, os artefatos produzidos (PSMs e Código)

devem ser compreensíveis para o desenvolvedor, de outra forma novas
modificações elaboracionistas não seriam possíveis. Isto aumenta a complexidade e
a dependência humana no processo de desenvolvimento.
A abordagem elaboracionista da MDA provavelmente representa o caminho mais

utilizado até o momento.
É essencialmente uma mecanização da abordagem já conhecida do

desenvolvimento OO, onde primeiro um modelo de análise (OOA) é produzido,
seguido pelo modelo de design (OOD) chegando-se finalmente ao código.
Na abordagem tradicional, porém, não se observa uma automatização da

produção dos modelos, quer para frente ou para trás. MDA traz esta automatização.
A segunda interpretação do MDA é a chamada Translacionista.
Um exemplo esquemático desta abordagem é mostrado na Figura 9.

Página 44/96
Figura 9 – Abordagem Translacionista

Fonte: McNeyle, Ashley. Do Artigo "MDA: The Vision with the Hole?”. 2003
Nesta abordagem, o PIM é traduzido diretamente para o código final do sistema

por geração automatizada.
A transformação do PIM em código final é executada por um sofisticado código

gerador, as vezes chamado de "Compilador de Modelos", simbolizado no diagrama
pela grande seta. Ele é dirigido por um Gerador de Regras que descrevem como os
elementos do PIM serão representados no código final.
Nesta abordagem o PSM é, de fato, uma etapa intermediária na geração de

código. Ele geralmente não é visível ou editável pelo desenvolvedor, e é por essa
razão que o mesmo é mostrado de forma tracejada no esquema anterior.
A característica central da abordagem translacionista reside no fato de que os

artefatos (PSM e Código) não se submetem a sucessivas elaborações ou mesmo
alterações por mãos humanas.
O PIM (acrescido do Gerador de Regras) é a fonte plena do sistema gerado e

não há necessidade de analisar ou alterar os artefatos produzidos, da mesma forma
que não há necessidade de analisar ou alterar a saída de compilação de uma
determinada linguagem de programação.
Página 45/96
Como as mudanças são realizadas diretamente no PIM e propagadas pela

geração automática de código, nesta abordagem não se fazem necessários
mecanismos de Engenharia Reversa (round-trip engineering) visando garantir
sincronismos de modelos intermediários.
A MDA considera a existência dos seguintes tipos de transformações diferentes:
PIM para PIM: Utilizada para o aperfeiçoamento ou simplificação dos

modelos, sem a necessidade de se levar em conta aspectos dependentes de
plataforma. Via de regra esta transformação é feita manualmente, ou seja
sem mapeamento automatizado;
PIM para PSM: Transformação “padrão” do modelo independente de

plataforma para um modelo tecnológico específico durante o ciclo de
desenvolvimento típico de aplicações (abordagem Elaboracionista);
PSM para Código: Após sucessivos refinamentos nos PSMs realiza-se a

transformação final para o código executável que representará o sistema em
produção;
PSM para PIM. Quando é necessário obter-se uma representação neutra em

termos de tecnologia de soluções específicas. Esse tipo de transformação
permite a aplicação efetiva de conceitos de Engenharia Reversa.
PIM para Código: Transformação típica na escola (ou abordagem)

translacionista onde o PIM é transformado automaticamente na Aplicação (ou
sistema) a ser colocada em produção sob uma determinada plataforma
tecnológica. Para tanto faz uso de compiladores especializados para cada
tipo de tecnologia.
Embora ainda não haja, em âmbito comercial, um número razoável de

ferramentas capazes de realizar completamente as transformações de PIM para
PSM e do primeiro ou do segundo para código, muitas já são capazes de gerar
protótipos funcionais, embora simplificados, acelerando o ciclo de desenvolvimento
[KLEPPE03].
Página 46/96
Em linhas gerais, tanto os PSMs quanto os PIMs são definidos a partir de

extensões ou especializações da linguagem UML, chamadas UML profiles. Como
conseqüência, existem duas grandes diferenças entre o processo de
desenvolvimento de software baseado em MDA e as abordagens “tradicionais”.
A primeira é a natureza dos artefatos produzidos. Nos processos baseados em

MDA, os artefatos são modelos formais e precisos (PIMs, PSMs e Código), ou seja,
entendidos por computadores, ao tempo em que no desenvolvimento tradicional os
artefatos são meramente documentacionais e norteadores do desenvolvimento,
dispensando precisão.
A segunda é a eliminação de fases inteiras do processo de desenvolvimento,

obtida pelas transformações automatizadas.
Espera-se que essas transformações – sobretudo, PIM >> PSM e PSM >>
Códigos Fonte – se tornem cada vez mais ricas e automáticas, aumentando assim
os ganhos em produtividade, portabilidade, interoperabilidade e manutenção.
2.4.7 Benefícios da utilização de MDA
Os principais benefícios do MDA de acordo com o OMG são:
2.4.7.1 Produtividade
MDA permite que o desenvolvedor priorize o desenvolvimento do PIM,

concentrando-se nos aspectos relativos ao negócio. A produtividade, em tese, se
torna maior porque os programadores e/ou desenvolvedores não precisam gastar
tempo com a fase de projeto. Os detalhes técnicos específicos de plataforma são
acrescentados ao PIM pela transformação automática PIM >> PSM. Em uma
situação ideal, a maior parte do código será também gerada automaticamente pela
transformação PSM >> Código Fonte.
2.4.7.2 Portabilidade
Como um mesmo PIM pode ser transformado em diferentes PSMs, possibilitando

que um sistema possa operar em diferentes plataformas, a solução modelada no
Página 47/96
PIM é portável para qualquer plataforma para a qual exista a definição da

transformação PIM para PSM especificamente envolvida.
2.4.7.3 Manutenção e Documentação
Após alterações no PIM são possíveis a geração de novos PSMs e código

correspondente muito rapidamente, agilizando e barateando os procedimentos de
manutenção do sistema. Com isto, correções, adaptações ou mesmo a adição de
novas funcionalidades se tornam tarefas mais simples de serem realizadas,
prolongando a vida útil do sistema.
A MDA é baseada na construção de modelos formais, que sob muitos aspectos

correspondem a uma importante documentação do sistema. O PIM é o artefato mais
importante, pois corresponde a uma documentação de alto nível.
Em um contexto ideal de MDA, as alterações efetuadas nos PSMs podem ser

refletidas nos seus PIMs de origem, mantendo PIM, PSM e a documentação sempre
atualizada até o final do projeto, o que, indubitavelmente, não acontece em um
processo tradicional de desenvolvimento de software.
2.4.8 MDA e Linguagens de Modelagem
A modelagem de sistemas é uma atividade de fundamental relevância no

desenvolvimento de sistemas computacionais. Trata-se, em linhas gerais, de
representar no universo computacional aspectos e conceitos do mundo real, com o
objetivo de compreender e comunicar detalhes acerca do conceito modelado. Como
o próprio nome sugere, a atividade de modelagem de dados é o cerne do
desenvolvimento orientado a modelos e a escolha da linguagem de modelagem
mais adequada ao paradigma MDD é um fator a ser contemplado com atenção.
Existe atualmente no mercado de tecnologia um número razoável de linguagens

de modelagem, dentre as quais a UML se destaca, indubitavelmente, como a
notação mais conhecida e amplamente adotada. No entanto, nem todas as notações
encontradas no mercado suportam os conceitos de MDA. Há vários pré-requisitos
que devem ser satisfeitos para que uma linguagem possa ser considerada
compatível com esse paradigma.
Página 48/96
2.4.8.1 Os Critérios
Alguns critérios podem ser utilizados para se determinar a melhor linguagem de

modelagem a ser utilizada para a confecção de artefatos MDA.
O desenvolvimento orientado a modelos representa uma verdadeira quebra de

paradigmas no universo do desenvolvimento de software, de um formato direcionado
à codificação para um fortemente orientado a modelos.
A capacidade de transformação automática desses modelos em código é

condição imprescindível desse processo, logo, um critério implícito.
O desafio mostrado na Figura 9 está em reduzir ao máximo a intervenção

humana em procedimentos de refinamento técnico, no esforço de codificação e de
integração com diversas camadas distintas que, na maioria das vezes representam
os principais pontos de falhas dos projetos, simplesmente por gerarem novas
expectativas, alterações de escopo com reflexos diretos da arquitetura de
implementação escolhida na construção do sistema.
Figura 10 - O processo de desenvolvimento sob MDA

Fonte: Projeto XDF
MDA tenta manter a intervenção humana no processo criativo de concepção e

aperfeiçoamento contínuo dos modelos criados.
Com o passar dos anos, as linguagens de modelagem foram amadurecendo e

características como adaptabilidade, flexibilidade, escalabilidade, tornaram-se
Página 49/96
componentes primários nesse novo contexto, e por serem básicos não serão
utilizados como critério de avaliação para a escolha da linguagem ideal para MDA.
[KLEPPE03] elencou uma série de características minimamente desejáveis para

que uma linguagem de modelagem possa ser considerada recomendável para o
desenvolvimento orientado a modelos, quais sejam:
Deve ser abrangente o bastante para possibilitar a especificação completa de

um sistema - tanto dos aspectos estáticos quanto dos dinâmicos – de tal
forma que os desenvolvedores não tenham que recorrer a uma linguagem
auxiliar.
Deve ser de propósito geral e não específica a uma determinada plataforma

ou ambiente.
Deve permitir um alto nível de abstração.
Deve ser capaz de modelar sistemas n-tier (múltiplas camadas). Em outras

palavras, o número de camadas não pode ser um fator restritivo para a
atividade de modelagem.
Deve suportar o desenvolvimento de aplicações distribuídas.
Deve ser capaz de garantir uma migração efetiva e transparente

(seamlessness) entre modelo e implementação.
Deve ser capaz de permitir o gerenciamento de modelos complexos,

suportando, por exemplo, modelagem orientada a aspectos.
Deve possuir um bom suporte ferramental no mercado.
2.4.8.2 A Escolha da Linguagem
Atualmente, dentre as linguagens de modelagem que poderiam ser consideradas

adequadas para o desenvolvimento com MDA, de acordo com os critérios elencados
no item anterior, a UML é a escolha mais racional. Como alternativas tem-se: a
Executable and Translatable UML (XT UML), Specification and Description Language
Página 50/96
(SDL) [SDL04] ou Architectural Description Languages (ADL), como a Acme

[ACME04].
Nessa seção, o enfoque principal foi a UML. A principal razão para isso é o fato
de o OMG, criador da MDA (e da própria UML), declarar essa notação como um dos
padrões estruturais do framework MDA. Um outro aspecto a ser considerado é a sua
aceitação em nível mundial como linguagem padrão para modelagem de sistemas. A
UML provê também adaptabilidade (através dos mecanismos de extensão),
flexibilidade (através dos diversos profiles UML), escalabilidade (generalização,
especialização, decomposição) etc.
A mais nova versão da UML (2.0), reprojeta a notação exclusivamente para

prover um suporte mais adequado ao paradigma MDA [UML04]. Uma das principais
características da nova versão da UML é prover suporte, com igual nível de
eficiência, aos aspectos estruturais e comportamentais da modelagem. Assim
sendo, novos diagramas foram incorporados e os conceitos de OCL (Object
Constraint Language) e AL (Action Language) foram inseridos como parte da nova
especificação.
2.5 OCL (Object Constraint Language) e AL (Action Language)
O fenômeno dos modelos executáveis não é recente na indústria de software.

[MOSSES92] introduziu o conceito de semântica de ações (action semantics) na
mesma época em que os métodos para análise e projeto orientados a objetos
vieram à tona. Os modelos executáveis se tornaram um fato, entretanto, com a
introdução da OCL (Object Constraint Language) e da AL (Action Language).
Incorporar a OCL [OCL03] e AL [AS02] nas especificações da UML foi uma decisão
importante para que a UML realmente se tornasse uma linguagem executável.
As linguagens de modelagem não oferecem os mesmos recursos que as

linguagens de programação e vice-versa. Combinando esses dois conceitos, chega-
se ao melhor dos mundos no desenvolvimento de sistemas: modelos que podem ser
executados, elevando substancialmente o nível de abstração no desenvolvimento de
sistemas.
Página 51/96
2.5.1 Object Constraint Language (OCL)
A OCL é uma linguagem de consulta padrão e a partir da versão 2.0 é parte da

UML. É uma linguagem notacional que auxilia nas disciplinas de análise e projeto
em um processo de desenvolvimento de software. Como parte da UML, permite
documentar restrições e consultas no modelo de objetos, não passíveis de serem
registradas em se utilizando apenas os recursos da UML. A utilização de OCL
permite a criação de um conjunto de regras bem definidas que controlam os
atributos de um objeto ou mesmo de um processo de negócio.
De acordo com [KLEPPE03], a OCL é uma linguagem que permite a descrição

de expressões e restrições em modelos de sistemas orientados a objetos.
2.5.1.1 Expressões
Uma expressão é uma indicação ou especificação de um valor. Em um modelo

UML as expressões podem ser utilizadas para:
Especificar o valor inicial de um atributo.
Especificar regras de derivação para um atributo.
Especificar o corpo de uma operação.
Indicar uma instância em um diagrama dinâmico.
Indicar uma condição em um diagrama dinâmico.
Indicar valores de parâmetros em um diagrama dinâmico.
2.5.1.2 Restrições (Constraints)
É uma restrição em um ou mais valores de um sistema ou modelo orientado a

objetos. Existem quatro tipos de restrições:
Uma invariante é um tipo de restrição que determina que uma condição deva
sempre ser atendida por todas as instâncias de uma classe. Invariantes
devem ser sempre verdadeiras.
Página 52/96
Uma pré-condição é uma restrição que deve ser sempre verdadeira antes da
execução de uma operação ser iniciada.
Uma pós-condição é uma restrição que deve ser sempre verdadeira depois
da execução de uma operação ser finalizada.
Uma guarda é uma restrição que deve ser verdadeira para que ocorra a
transição entre um estado e outro.
2.5.2 A Semântica de Ações (Action Semantics)
AS é um framework para descrever a semântica formal de uma linguagem de

programação para valores, funções etc. Desde o seu surgimento em 1992
[MOSSES92], AS tem sido utilizada para descrever as principais linguagens de
programação, tais como Pascal e Java.
Uma AS pode ser empregada também em linguagens de modelagem para torná-

las executáveis. O OMG adotou esse conceito e desenvolveu sua própria AS para a
UML, de forma a torná-la executável [AS02]. Embora o OMG tenha definido a AS,
não existe ainda uma linguagem padrão compatível com a semântica criada. Uma
linguagem que implemente os conceitos semânticos definidos em uma AS é
denominada Action Language (AL) – Linguagem de Ação.
2.5.3 A Linguagem de Ação (Action Language)
A AL é uma linguagem de especificação para definir ações e atividades em uma

máquina de estados e operações em um diagrama de classes. Idealmente, uma AL
deve ser uma linguagem independente de implementação e deve permitir um alto
nível de abstração. Uma linguagem de ação deve ser também abrangente e
completamente executável. Uma linguagem deve estar em conformidade com a AS
definida pelo OMG [AS02] para que possa ser de fato considerada uma AL. Embora
o OMG tenha definido suas especificações para AS, são apenas orientações e não
padrões. Atualmente, existe poucas AL compatíveis, ainda que parcialmente, com as
especificações do OMG, tais como a Action Specification Language (ASL)
[WILKIE01], BridgePoint Object Action Language (OAL) [OAL03] e Kabira Action
Semantics (Kabira AS).
Página 53/96
2.6 UML – Unified Modeling Language
A UML surgiu da união de três metodologias: o Método de Booch, o método OMT

(Object Modeling Technique), de Rumbaugh e o método OOSE (Object-Oriented
Software Engineering), de Jacobson. Essas eram, até meados da década de 90, as
três metodologias de modelagem orientada a objetos mais populares entre os
profissionais da área de Engenharia de Software.
A UML é uma linguagem visual utilizada para modelar sistemas computacionais

por meio do paradigma de Orientação a Objetos e foi adotada como uma linguagem
padrão de modelagem em 1997 pelo OMG - Object Management Group (Grupo de
Gerenciamento de Objetos). Encontra-se atualmente na versão 2.0 e é adotada em
âmbito internacional pela indústria de Engenharia de Software. A documentação
oficial da UML pode ser consultada no site www.omg.org/uml.
2.6.1 Diagramas UML
O objetivo dos diferentes diagramas da UML é fornecer múltiplas visões do

sistema a ser modelado. Cada diagrama da UML analisa o sistema, ou parte dele,
sob um determinado prisma. Alguns diagramas enfocam o sistema de uma forma
mais geral, apresentando uma visão externa - muitas vezes direcionada ao
entendimento de stakeholders não-técnicos do sistema - como é o caso do
Diagrama de Casos de Uso. Outros oferecem uma visão mais aprofundada e com
enfoque mais técnico, voltado para aspectos arquiteturais ou mesmo para
características específicas do sistema ou de um determinado processo.
A utilização criteriosa dos diversos diagramas da UML ajuda a minimizar a

incidência de erros na fase de implementação propriamente dita. Faz-se importante
ressaltar que embora todos os diagramas da UML tenham, indubitavelmente, a sua
importância, nem sempre o desenvolvimento de um sistema irá requerer a utilização
de todos eles. A escolha dos diagramas a serem utilizados depende de uma gama
de fatores como complexidade do sistema a ser desenvolvido, tamanho da equipe
de desenvolvimento, tempo de duração do projeto etc.
Página 54/96
2.6.2 UML 2.0 – Motivações para revisão da UML
A versão 2.0 é a primeira grande revisão da UML após uma série de revisões
menores. A principal motivação para essa revisão foi à necessidade de prover um
maior suporte ao paradigma MDD. Para suportar um nível cada vez maior de
automatização no processo de desenvolvimento de software, sobretudo no que se
refere às transformações de modelos e geração de código, era necessário que se
redefinisse a linguagem de uma forma mais precisa que nas versões anteriores.
Adicionalmente, após dez anos de utilização da UML e com o surgimento e

ascensão, durante esse período, de importantes tecnologias – como aplicações
baseadas em web (web-based applications) e Arquitetura Orientada a Serviços
(SOA - service-oriented architecture) – essas novas soluções de modelagem foram
identificadas.
Embora se pudessem modelar essas soluções através da combinação

apropriada de conceitos já existentes na UML, tornou-se cada vez mais evidente a
necessidade de se tratar essas “soluções” como elementos fundamentais da
linguagem, através da criação de novos diagramas ou através da reformulação de
artefatos já disponíveis em versões anteriores.
Nesse ínterim, a indústria de tecnologia evoluiu bastante no que se refere ao uso,

estruturação e definição de linguagens de modelagem. Como exemplo, pode-se citar
a evolução do conhecimento sobre meta-modelagem e transformações de modelos.
2.6.3 UML 2.0 e MDA
Essa seção avalia a UML 2.0 quanto a seu suporte aos conceitos MDA, de
acordo com os critérios já elencados.
2.6.3.1 Expressividade
A UML não podia ser considerada expressiva o bastante até a inserção da OCL
(Object Constraint Language) como parte integrante da linguagem. A OCL é uma
poderosa linguagem textual que permite a descrição de propriedades e restrições de
um sistema de software. A UML, associada a uma linguagem executável baseada
Página 55/96
em OCL, tem o potencial necessário para permitir a modelagem de qualquer função

computacional.
Os novos diagramas apresentados na versão 2.0 também contribuem

significativamente para o aumento da expressividade da linguagem.
2.6.3.2 Independência de aplicação
Como é sabido, UML não é uma linguagem de modelagem para aplicações

específicas. Pelo contrário, trata-se de uma linguagem capaz de modelar qualquer
tipo de sistema, desde aplicações stand-alone até complexos sistemas real-time. A
UML é também atualmente bastante utilizada para modelar processos não
relacionados a softwares (modelagem de processos de negócio, por exemplo).
2.6.3.3 Alto nível de abstração
A UML 2.0 se encontra em um nível de abstração mais alto que as suas

predecessoras (UML 1.x), sobretudo devido à capacidade de executar modelos e de
expressar comportamento e restrições através de OCL e AL.
2.6.3.4 Suporte para Aplicações N-tier
A semântica executável provida pela UML 2.0 traz grandes benefícios para o
suporte de aplicações n-tier, garantindo, entre outras coisas, a possibilidade de se
testar os artefatos de projeto antes da sua implementação propriamente dita. O
OMG continua empreendendo esforços para estender a UML com elementos de
domínios específicos através da utilização do conceito de profiles.
2.6.3.5 Suporte para Aplicações Distribuídas
A técnica de modelagem baseada em componentes e a capacidade de testar

artefatos (executáveis) antes do processo de implementação propriamente dito
fazem da UML 2.0 uma linguagem mais adequada para o desenvolvimento de
aplicações distribuídas que as versões anteriores. Um aspecto bastante considerado
quando da revisão da UML que culminou com a versão 2.0, foi prover melhor
suporte para middlewares, como CORBA, por exemplo.
Página 56/96
2.6.3.6 Translacionismo em MDA
O conceito de seamlessness é a habilidade da linguagem de gerar modelos

executáveis que podem ser automática e efetivamente transformados em código
com o auxílio de uma ferramenta. A especificação correta e precisa dos modelos e a
escolha da ferramenta mais adequada serão aspectos-chave desse processo. Aqui
reside o cerne da abordagem translacionista da MDA.
2.6.3.7 Gerenciamento de Modelos Complexos
[BJORKANDER03] afirma que o desenvolvimento baseado em componentes é

uma das principais características da UML 2.0. A UML permite a decomposição de
modelos complexos em modelos menores. O Diagrama de Interação Geral provê a
adequada interação entre os diversos modelos gerados. O Diagrama de Estrutura
Composta, introduzido na versão 2.0, também possibilita a especificação de
arquiteturas complexas através da utilização do conceito de subsistemas [GURD03].
2.6.3.8 Suporte Ferramental
Com o uso de ferramental adequado, os modelos UML 2.0 podem ser

transformados automaticamente em código. Por se tratar de um padrão, a UML 2.0 é
fortemente suportada pelas principais ferramentas do mercado.
2.7 Prevalência de Objetos
A arquitetura mais utilizada atualmente para desenvolvimento de softwares é a

que utiliza o conceito de “três camadas” conforme mostrado na Figura 9. Essas
camadas constituem a separação funcional da arquitetura dos softwares em:
Camada de Apresentação – camada que cuida da interface com o usuário;
Camada de Negócio – camada que cuida das classes e regras de negócio;
Camada de Persistência – camada que cuida do armazenamento das

informações é ela que persiste os dados em um Sistema Gerenciador de
Banco de Dados (SGBD).
Página 57/96
Figura 11 - Exemplo de uma Arquitetura Tradicional (Persistente)

Fonte: Projeto XDF
A camada de persistência apresenta algumas necessidades para ser utilizada,

como por exemplo:
Os analistas precisam conhecer os recursos do Banco de Dados a ser

utilizado;
É necessário manter pessoal qualificado em suporte para o Banco de Dados

utilizado (DBA);
Servidores com bastantes recursos de hardware para comportarem os

Bancos de Dados;
Além da licença do Banco de Dados, são necessárias licenças para acessar o

mesmo (clientes do Banco de Dados);
Ocupação de mais espaço em disco devido à utilização do modelo relacional

pelo SGBD (duplicação de chaves nas tabelas ou chaves estrangeiras).
Sistemas projetados utilizando o conceito de Orientação a Objetos enfrentam

o problema de descasamento do modelo orientado a objetos do modelo
relacional implementado em SGBD, tal problema é chamado “Impedância”.
Para resolver tal problema é necessário um mapeamento Objeto/Relacional, que

é implementado através de uma camada de persistência conforme é apresentado na
Figura 12. Como conseqüência observa-se forte aumento da complexidade do
software bem como a perda de sua performance;
Página 58/96
Figura 12 - O problema da Impedância em SGBDs

Fonte: Projeto XDF
Com essas necessidades, ao se calcular os custos de uma aplicação, deve-se

levar em consideração esses custos existentes para a manutenção de objetos
dentro de um sistema de Banco de Dados.
Um conceito diferente da Camada de Persistência é o conceito de “Camada de

Prevalência”. Esse é um termo novo na área de TI para definir a gravação direta dos
objetos sem uso de:
Banco de Dados relacional, ex: Oracle e MySQL;
Camada de Persistência, ex: Hibernate e Bamboo;
Camada de Acesso a Dados, ex: ODBC, DAO e ADO.
2.7.1 O Prevayler
A investigação sobre a prevalência e seu potencial de simplificação tem seu

início com a criação de um software denominado Prevayler que é uma
implementação do conceito de Prevalência em Java, desenvolvido pelo brasileiro
Klaus Wuestefeld [Prevayler], objetivando fornecer uma camada de persistência de
objetos em memória para o uso em aplicações, cujas características são:
Página 59/96
Ser baseada na serialização de Transações;
Primeiro serializa depois executa;
Permite utilização de qualquer collection da Java API;
Cada transação deve ser uma classe com um método execute;
Não padroniza ou impõe qualquer constraint (restrição) do modelo de classes.
A prevalência é um modelo de persistência de objetos em memória que pode ser

empregado para construção de um Servidor de Objetos em memória para
aplicações. Ela difere de outros mecanismos, como linguagens persistentes e
BDOO, principalmente pelo fato da cópia primária dos objetos residir
permanentemente em memória (em um sistema tradicional, a cópia primária reside
em disco e blocos são temporariamente trazidos para memória).
Os principais conceitos de prevalência, como logs e snapshots (backup), já foram

empregados por diversos sistemas, como em gerenciadores de bancos de dados,
bancos de dados em memória e outros sistemas de persistência de dados.
A prevalência é um modelo de persistência transparente de objetos em memória.

Em um sistema prevalente, todos os objetos são mantidos em memória. Alterações
em objetos prevalentes são representadas por classes que, seguindo um padrão,
garantem que essas alterações não sejam perdidas.
Consultas são executadas recuperando objetos em memória, tornando seu

acesso mais rápido do que em sistemas que requerem acesso a disco.
2.7.2 Componentes da Prevalência
Na prevalência, assim como em bancos de dados em memória, o

armazenamento principal dos objetos é feito em memória.
Por essa razão, dois mecanismos devem ser utilizados para garantir a
persistência dos objetos: um log de transação e um backup, ou snapshot, do estado
dos objetos.
Página 60/96
O log de transação é implementado pela utilização de classes que representam

alterações em objetos. Para essas alterações persistirem, as classes são
serializadas e gravadas em disco.
O snapshot é responsável por salvar o estado de todos os objetos da memória

principal para o disco, tirando uma fotografia do estado dos objetos em um dado
momento. O esquema apresentado na Figura 13 ilustra a dinâmica de
funcionamento da Prevalência
Figura 13 - Os componentes teóricos da Prevalência

Fonte: Projeto XDF
2.7.2.1 A serialização
A serialização consiste no processo de transformação da estrutura de um objeto

em memória para um formato seqüencial. A seqüência de bytes resultante é o
estado serializado do objeto e contém todas as informações necessárias para a
reversão do processo (algo como des-serialização).
O objeto não é acessado em seu estado serializado, pois a sua estrutura não é
mais a de um objeto, mas uma seqüência de bytes. Os mecanismos de log e
Página 61/96
snapshot são complementares e empregados em conjunto para que a persistência

seja garantida.
A maioria dos sistemas que utiliza um log para garantir a durabilidade de suas
transações emprega um backup para limitar o volume de log a ser processado
quando o sistema se recupera de uma falha ou reinicia. O log de transação é
gravado pelo próprio sistema de prevalência. O snapshot deve ser invocado pela
aplicação, em períodos de pouca utilização da mesma.
2.7.2.2 A Restauração
No caso da restauração de uma falha ou reinício da aplicação, o sistema de

prevalência procura pelo último snapshot gravado e restaura o estado do sistema
para o momento em que a gravação foi feita. A seguir, são reexecutados todos os
logs das alterações que foram efetuadas no sistema, posteriores ao snapshot
gerado, para que o sistema volte ao estado anterior à falha ou ao desligamento do
sistema.
Figura 14 - Usando a Prevalência

Fonte: Projeto XDF
Embora esses mecanismos utilizem o disco rígido, o armazenamento principal do

modelo de prevalência ainda é a memória principal do computador, pois os objetos
residem e são manipulados nela. O formato de gravação do objeto em disco é
resultante da serialização de seu estado, não podendo ser acessado ou alterado
enquanto estiver nesse formato.
Página 62/96
Enquanto em um sistema de bancos de dados o esquema de recuperação está

relacionado à ocorrência de falhas, na prevalência, o log de transação e o snapshot
funcionam tanto no caso de falhas, quanto no caso de reinício do sistema.
2.7.3 A Prevalência em funcionamento
Em um sistema prevalente, a persistência não influi na modelagem dos objetos

de negócio, podendo ser inserida após o processo de modelagem. Somente as
operações em objetos persistentes requerem ser modelada através de classes.
Todos os objetos de negócio precisam ser referenciados por um objeto raiz para
que a persistência seja garantida. O objeto raiz pode representar o banco de dados
do sistema, pois contém a referência a todos os objetos que devem ser persistidos
na aplicação. A persistência dos objetos de negócio é garantida através da ligação
entre o objeto raiz e o sistema de prevalência, realizada antes de qualquer acesso
aos objetos.
Em uma aplicação orientada a objetos que utiliza um banco de dados relacional

como camada de persistência, os métodos que persistem objetos devem ser
implementados invocando comandos SQL.
Em um sistema prevalente, esses métodos são substituídos por classes que

representam alterações nos objetos. Essas classes são serializadas e gravadas em
disco antes de serem executadas, assegurando a persistência das alterações e
implementando o log de transação.
Tais classes recebem o nome de command ou transaction conforme a

implementação. O funcionamento de um sistema prevalente pode ser resumido,
então, pelos seguintes passos:
Uma vez iniciado o sistema, todos os objetos são criados ou carregados em

memória, disponibilizando o sistema para uso;
Todas as consultas a objetos são feitas em memória;
As alterações efetuadas nos objetos são representadas por classes

serializáveis (transaction ou command);
Página 63/96
Cada objeto command submetido ao sistema é gravado em um arquivo de log

antes de ser ativado;
Quando o sistema é reiniciado, todas as alterações previamente gravadas em

arquivos de log são re-executadas, de forma a restaurar o estado dos objetos;
Periodicamente, o estado completo dos objetos em memória é armazenado

em disco (snapshots).
Página 64/96
3 ANÁLISE E PROPOSIÇÃO
A fundamentação teórica apresentada oferece os elementos necessários para

que, de forma crítica e objetiva, seja então abordado o âmago do problema original
levantado para, de forma pragmática, manipulando as variáveis apresentadas sob
um novo paradigma tornar viável uma alternativa de solução objetiva.
3.1 APRESENTAÇÃO DO DILEMA MDA
Sob o paradigma MDA a abordagem utilizada na modelagem de determinado

PIM sempre deve endereçar o comportamento do seu respectivo sistema. O OMG
tem a seguinte declaração em seu site (http://www.omg.org/mda):
"Modelos completamente independentes de plataformas específicas (incluindo o

comportamento), podem permitir que o conhecimento mantenha-se afastado de uma
tecnologia de código específica, ajudando a isolar aplicações comerciais de
evolução tecnológica e ainda permitir a interoperabilidade".
Isto nos leva à questão fundamental de saber como o comportamento deve ser
especificado em um PIM, e se um PIM pode, efetivamente, tornar-se um código
executável e testável. Embora haja um acordo geral no seio da comunidade MDA
que os aspectos estruturais de um sistema são capturados utilizando técnicas de
modelagem estrutural da UML, existem opiniões diferentes sobre a forma como o
comportamento ou dinâmicas de um sistema deve ser representado.
DEFINIÇÃO DO COMPORTAMENTO DO PIM

ABORDAGEM ELABORACIONISTA TRANSLACIONISTA
A dinâmica de um sistema é O comportamento de um
representada por pré e pós- sistema é dirigido pelo
Visão do condições de suas operações movimento dos objetos de
comportamento um estágio de seu ciclo de
vida para outro sempre em
resposta a eventos
Método para modelar o Pré e Pós-condições nas Máquinas de Estados e
comportamento definições de classes Atividades
Object Constraint Language Action Language (AL)
Linguagem utilizada (OCL)
Figura 15 – Tabela de Abordagens para o PIM

Fonte: McNeyle, Ashley. Do Artigo "MDA : The Vision with the Hole?", 2003
Página 65/96
Esta divergência de opinião é a fonte de uma espécie de buraco negro. As

declarações, mostradas na tabela da Figura 15, ilustram estas diferenças de pensar.
Na opinião dos Elaboracionistas, o comportamento é especificado, definindo as

condições (pré-condições), que deve uma operação realizar, bem como os efeitos
(pós-condições), que resultam da sua execução. Pré e pós-condições são
especificadas na Object Constraint Language (OCL), que é uma linguagem para
especificar afirmações (formalmente, uma "expressão lingüística").
A atual operação em si não é especificada no PIM, embora em alguns casos

pode-se inferir. Para operações relativamente simples a semântica pode ser gerada
a partir de pré e pós-condições, mas na maior parte do tempo tais operações devem
ser escritas no PSM. Isto significa que, em geral, o PIM não é um artefato
executável.
Na opinião Translacionista, o comportamento é especificado como Máquinas de

Estados e Action Language. As máquinas de Estados especificam os estados que
um objeto pode ter em sua vida, e como um objeto se desloca de um Estado para
outro, quando eventos ocorrem. Atividades (definidos pela Action Language)
especificam o que um objeto faz quando seu estado muda. Action Language, ao
contrário da OCL, é uma linguagem imperativa. Esta abordagem resulta em modelos
que são executáveis e, portanto, verificáveis.
Para resumir. Como visto no marco teórico desta monografia, o comportamento

de um PIM é especificado diferentemente nas abordagens Elaboracionistas e
Translacionistas. PIMs construídos segundo a primeira abordagem não são
executáveis ou verificáveis, ao tempo em que aqueles construídos de acordo com a
última abordagem o são a ponto de serem capazes de serem transformados
diretamente em código executável (sistema).
A abordagem Translacionista mais comumente observada deriva de experiências

e aplicações em sistemas tipo real-time. A utilização de Máquinas de Estados para
especificar comportamentos neste tipo de sistema tem uma longa história, anterior
até mesmo a UML.
Página 66/96
Em sistemas transacionais, é fato que Máquinas de Estados raramente são

utilizadas. Neste domínio, o comportamento é normalmente modelado utilizando Use
Cases e Diagramas de Colaboração UML. Estes diagramas, porém, não são
adequados para gerar código ou modelos executáveis e não figuram como artefatos
principais na MDA, embora possam, evidentemente, continuarem a serem
produzidos. Para as pessoas que trabalham neste domínio, é provável que a
abordagem translacionista seja vista como alienígena.
Pelo menos no curto em médio prazo, é provável que as abordagens e

ferramentas associadas serão posicionados pelos vendedores para abordar os
domínios que representam as suas origens históricas: Elaboracionistas para
sistemas corporativos e Translacionistas para sistemas real-time. Para construtores
de sistemas empresariais, isso significaria que a MDA irá frustrar um dos seus
principais objetivos, vez que não será possível executar, testar ou simular um PIM.
3.1.1 Para onde então, a partir daqui?
Se esse prognóstico estiver correto e os desenvolvedores de sistemas

empresariais não forem capazes de executar e testar os seus PIMs, algo ainda está
por vir. A noção de que o "PIM possa ser testável e simulável" é aguardada como
um recurso da MDA ainda por ser alcançado. Mas isto é necessário por duas
razões:
A capacidade de verificar um PIM é valiosa. Ela não só fornece aos

desenvolvedores, a garantia de que as dinâmicas modeladas são coerentes, mas,
mais importante, fornece aos usuários não técnicos e outros interessados um meio
de interação com o modelo durante o seu desenvolvimento. Isto proporcionaria
benefícios reais onde os requisitos funcionais são complexos ou incertos, permitindo
que mais verificações possam ser realizadas no contexto do PIM onde fazer as
correções são mais fáceis, baratas e rápidas.
Se não é possível executar o PIM, o processo MDA, na abordagem

Elaboracionista, torna-se uma espécie de “waterfall” mecanizada. É claro que o
desenvolvimento será iterativo, mas apesar da disponibilidade de bons recursos de
engenharia reversa a tendência dos desenvolvedores será de não retornar ao PIM a
cada iteração.
Página 67/96
Um esforço constante de sincronização dos comportamentos modelados em

PIMs não executáveis com o executável – através dos sucessivos refinamentos
representados pelos PSMs – tenderá a comprometer a confiança no PIM como uma
verdadeira representação do que foi construído e, dessa forma o mesmo perderá
valor gradativamente, a ponto de ser até mesmo descartado. Isto fará MDA presa
fácil para os defensores da Agile Modelling, que argumentam que há excesso de
trabalho inútil sendo modelado na ferramenta CASE e que se deve voltar ao uso do
quadro branco.
Se a noção de PIM verificável e executável, defendida na abordagem

translacionista, tornar-se uma realidade para todos os usuários da MDA, os
translacionistas demonstrarão que a sua abordagem funciona bem para as
aplicações comerciais, através da criação de um histórico de projetos bem
sucedidos. Até que isso aconteça os elaboracionistas continuarão a dizer, como vem
fazendo, que a abordagem translacionista só é indicada para áreas especializadas.
3.2 XDF: UMA ALTERNATIVA DE SOLUÇÃO PARA O DILEMA MDA
O framework denominado XDF (eXtreme Driven Framework) é apresentado a

seguir, como uma alternativa prática e disponível para geração automática de
sistemas a partir de modelos sob uma abordagem totalmente translacionista.
Para tanto se apresentam seus componentes básicos para, em seguida, efetuar

uma discussão crítica sob o confronto de suas propostas e potencialidades frente às
tecnologias que se pretende simplificar e/ou substituir, interpretando os resultados
que já foram alcançados até o momento em que se encontra o framework em seu
estado da arte mais atual.
Os paradigmas que nortearam a construção do framework XDF podem ser

resumidos conforme se segue:
A Orientação a Objetos e Workflow representam o mundo realisticamente;
UML como metalinguagem é mais compreensível para ambos os “lados da

mesma moeda” (usuários e técnicos);
Página 68/96
MDA enquanto metodologia torna a documentação a gênese e o resultado de

soluções de fato “a prova de futuro” (PIM ou Modelo Independente de
Plataforma);
A Prevalência de Objetos substitui com vantagens a Persistência dos Dados

por oferecer melhor performance e a possibilidade de implementar modelos
orientados a objeto sem nenhum tipo de impedância;
Packages de Negócio orientados a serviços (SOA) e independentes da infra-

estrutura de TI (Produção);
Em sua essência, XDF foi idealizado a partir de um contínuo exercício de

“desconstrução” da complexidade tecnológica que cerca todas as instalações e
profissionais de TI. Tendo como norte os fundamentos da MDA, cada componente
tecnológico inserido no processo de desenvolver, implantar, produzir e manter
sistemas, foi depurado e dissecado de forma a tornar-se o mais simples e ágil
possível.
Também as metodologias mais amplamente utilizadas no mercado foram alvo de

avaliação e reducionismo.
Já a viabilidade técnica do framework XDF tem como sustentáculo principal o

conceito aplicado e aperfeiçoado da prevalência a serviço da orientação a objetos
dirigida por modelos.
O framework XDF é, portanto, totalmente orientado a Objetos e dirigido por

Modelos, sendo de fato uma inovação no campo da Engenharia de Software. É uma
nova forma para desenvolver e gerar automaticamente sistemas onde o modelo é a
chave. No framework XDF diz como em MDA que o “Modelo é o Sistema”.
Em XDF o processo de desenvolvimento e manutenção é totalmente visual,

exigindo menor conhecimento técnico que as abordagens tradicionais. O usuário
participa ativamente da fase de especificação que é, em última instância, o
desenvolvimento efetivo.
A documentação já é inerente ao processo de construção, eliminando a

dependência de programadores para interpretar as regras de negócio no interior de
Página 69/96
códigos fonte, contribuindo para a manutenção da gestão do conhecimento sob

controle da Instituição.
Sistemas construídos em XDF dispensam a aquisição de licenças de softwares

complementares tais como Compiladores, Banco de Dados, Servidores de
Aplicação, de Filas e até mesmo Web Servers. A nova arquitetura contribui para a
manutenção e/ou redução do tamanho de máquinas em ambiente de produção
(Servidores e Estações). XDF elimina fases inteiras no processo de
desenvolvimento, facilitando o reuso de classes e suas operações associadas.
O framework XDF fornece aos seus usuários maior liberdade de escolha da

Plataforma Tecnológica (sistemas operacionais e processadores). A partir de um
Browser padronizado, o esforço de suporte técnico é minimizado. O ciclo se fecha
com a geração de sistemas mais estáveis e robustos onde as manutenções
evolutivas são realizadas de maneira rápida e menos onerosa sob o próprio modelo
do sistema.
Como resultado final, observam-se sistemas gerados automaticamente com

elevada performance aliada a uma dramática redução do custo total de propriedade
(TCO), que torna XDF um Framework único no mercado.
3.2.1 DIFERENCIAIS DO XDF
Em XDF estão disponíveis as seguintes características principais:
Por ser visual e não exigir conhecimentos de uma linguagem de programação

específica permite a participação direta do usuário no processo, diminuindo o
retrabalho e elevando a produtividade na construção de sistemas;
Oferece drásticas reduções de custos e prazos unificando e automatizando as

fases de Projeto e Construção, eliminando fases inteiras dos processos
tradicionais de desenvolvimento;
Os sistemas são modelados em UML usando o XDFDesigner, um módulo do

XDF que consiste em uma ferramenta CASE que armazena todos os
elementos do modelo em prevalência e que permite o trabalho colaborativo e
on-line de todos os desenvolvedores via Internet ou Intranet.
Página 70/96
Modelos, feitos em outras ferramentas CASE, podem ser importados para o

XDFDesigner desde que a ferramenta CASE de origem possa gerar XMI 1.1
(XML Metadata Interchange). A XDF já está homologada para Enterprise
Architect (EA) e Together;
Como o código gerado é Object Pascal, é possível compilá-lo com FreePascal

2.2 (software livre, disponibilizado no próprio XDF), Delphi 7 ou superior;
Permite a criação instantânea de protótipos funcionais em processos

interativos, gerando resultados mais rapidamente;
Dispensa a aquisição e uso de Gerenciador de Banco de dados bem como de

Application Servers, Queue Servers e Web Servers;
Os sistemas gerados são multi-usuário e multi-plataforma, um recurso

herdado do FreePascal:
Ambiente de desenvolvimento: (Windows, Linux, FreeBSD e Mac OS X)
Ambiente do cliente: (Windows, Linux, FreeBSD, Mac OSX e Windows CE);
Ambiente do servidor: Intel/AMD 32 bits (Windows, Linux, FreeBSD,

Solaris ou FreeBSD); Intel/AMD 64 bits (Windows e Linux); Sparc (Linux e
Solaris); PowerPC (Mac OS, Linux e AIX), PowerPC64 (Linux);
A elevada performance é garantida através do acesso em memória

(prevalência) e pela execução de código nativo;
Os sistemas gerados contam com a facilidade de operação pelo usuário final

por meio de um Browser genérico e pelo uso de workflows que o conduzem
nos processos de negócio automatizados;
No XDF para efetuar uma manutenção, basta alterar o modelo e regerar o

sistema com resposta imediata a uma necessidade. Na forma tradicional, a
mesma ação implica, muitas vezes, em diversas atividades com tempo de
resposta e custos sempre muito elevados;
Página 71/96
A documentação do sistema é imediatamente atualizada na alteração de seu

modelo, situação bem diferente da encontrada nas formas tradicionais de
trabalho;
3.2.2 O DESENVOLVIMENTO SOB XDF
Em XDF, os analistas modelam seus sistemas com base em dois diagramas da

UML: DC e DME usando o XDFDesigner.
O DC é a parte relativa aos Objetos do Negócio, apresenta as classes que

definem a semântica do negócio do usuário sem detalhes de implementação
ou de projeto;
O DME descreve o comportamento dos objetos do negócio (Operações do

Negócio) pertencentes às classes de negócio. Para cada operação há uma
máquina de estados;
Máquinas de Estado podem gerar workflows que podem ainda seqüenciar outras
máquinas de estados (mais primitivas), incluindo as funções de controle do tempo,
de trabalho cooperativo e de alçadas (direitos e permissões de negócios), gerando
Processos do Negócio (wizards) que aumentam a produtividade dos usuários finais;
Concluído o Modelo na ferramenta CASE, concluído está o sistema, que é

gerado automaticamente para código nativo e acessado por intermédio de uma
interface padronizada e embarcada de diversas funcionalidades parametrizáveis.
Na Figura 16, um exemplo esquemático do ciclo de desenvolvimento e uso de

sistemas sob XDF é demonstrado. Sua compreensão plena deve, entretanto, ser
mais claramente apreendida quando do entendimento dos componentes formadores
do XDF que serão descritos no próximo tópico.
Página 72/96
Desenvolvimento | Produção
XOS1
XDF Object Server XOS2
XDFSecurity XDFWorkflow
XDF XDF
Prevalence StateMachine XOSn
Modelos Us o
XDF Object Browser
Desenvolvedores Usuário
Figura 16 – Ciclo de Desenvolvimento e Produção sob XDF

Fonte: Projeto XDF
Ainda na Figura 16 destaca-se à esquerda, o domínio relacionado com o

desenvolvimento e manutenção dos sistemas a partir de seus modelos. Já à direita,
destaca-se a presença do usuário final utilizando uma (ou várias) dos sistemas
gerados sob XDF. Merece destaque ainda nesta representação esquemática:
A interface de desenvolvimento e de operação do sistema é o mesmo

browser que com sua característica polimórfica se adapta a quem o utiliza;
As setas vermelhas que parte do XDFObjectServer em ambiente de

desenvolvimento para os seus pares já sob a forma de sistemas executáveis
representam a geração automática de código (translacionismo) para cada
plataforma tecnológica de produção
3.2.3 OS COMPONENTES DO FRAMEWORK XDF
Os recursos embarcados no framework XDF são componentes interconectados

de forma a garantir independência e atomicidade de funcionamento associada com
Página 73/96
elevada performance e robustez pelo uso intensivo do principal paradigma: o

reducionismo e a simplificação. São pois componentes do XDF:
3.2.3.1 XDFDesigner
O XDFDesigner é a ferramenta CASE do XDF, totalmente integrada (embutida)

ao XDFObjectBrowser, que utiliza o XDFPrevalence como repositório central e
compartilhado para todos os modelos UML criados pelas equipes de
desenvolvimento.
O XDFDesigner possui métodos de mapeamento por translação MDA, que

convertem os modelos diretamente em código fonte e os compila usando
FreePascal, gerando um sistema completo com:
Interface do usuário dinâmica (XDFObjectBrowser);
Modelo de Objetos em memória (XDFPrevalence), no lugar de Base de

Dados;
Regras de negócio em máquinas de estado (XDFStateMachine);
Application Server (XDFObjectServer);
Segurança (XDFSecurity);
Workflow (XDFWorkflow).
API genérica para interoperabilidade com programas escritos em outras

tecnologias ou linguagens (XDFProxy).
Na Figura que se segue é apresentado um snapshot que exemplifica o

funcionamento deste componente no framework XDF.
Página 74/96
Figura 17 – Edição de um Diagrama de Classes no XDFDesigner

Fonte: Projeto XDF
3.2.3.2 XDFObjectBrowser
O XDFObjectBrowser é o client padrão do XDF. Um arquivo binário que se

conecta a um XDFObjectServer e que monta automática e dinamicamente a
interface (GUI-Graphical User Interface) do Sistema, baseado nos metadados do
Modelo publicados pelo XDFObjectServer. Essa interface padronizada permite a
navegação por todo modelo (classes), seus inter-relacionamentos (associações)
bem como o acionamento de suas operações e workflows, sem a necessidade de
programação.
O XDFObjectBrowser pode ser invocado pela WEB sem a necessidade de Web

Server, pelo desktop do usuário (instalação local) ou através de um servidor remoto
com tecnologia Terminal Services (Windows) ou NX-Window (Linux);

Página 75/96
Figura 18 – Tela Inicial do XDFObjectBrowser

Fonte: Projeto XDF
O polimorfismo embarcado no XDFObjectBrowser busca suprir por completo a

necessidade de codificar as interfaces (telas) dos sistemas aplicativos (GUI) para:
Navegar e manipular (inclusão, alteração, exclusão e consulta) os dados

(objetos e atributos) e seus relacionamentos;
Criar e emitir relatórios, padronizados ou não;
Filtrar, totalizar, agrupar, ordenar e alterar layout das informações;
Executar operações (métodos) em classes, objetos ou grupo de objetos.
Executar workflows.
A interface do XDFObjectBrowser oferece hints (dicas) e helps (ajuda)

previamente cadastrados no modelo, transferindo-os automaticamente para o
Página 76/96
aplicativo on-line, mantendo, desta forma a documentação do usuário sempre

atualizada.

Figura 19 – Navegação e edição de Objetos pelo XDFObjectBrowser

Fonte: Projeto XDF
3.2.3.3 XDFPrevalence
A XDFPrevalence é o repositório de objetos central da aplicação gerada,

totalmente implementado em RAM com código nativo e eliminando a necessidade
de um Gerenciador de Banco de Dados. Suas principais características são a
velocidade e a segurança das informações, sendo totalmente orientada a objetos e
gerada a partir do modelo, utilizando-se de um novo conceito: a Prevalência, que
abole o problema da impedância.
Este novo conceito mantém todos os dados (objetos, operações e processos do

negócio) em memória volátil (RAM). Para memória não volátil (disco), são
transferidas apenas as alterações sofridas nas propriedades dos objetos. Desta
Página 77/96
forma, aliado aos algoritmos de pesquisa e atualização em alta velocidade, é

possível alcançar elevada performance. A prevalência do XDF chega a ser, pelo
menos, mil vezes mais rápida, em queries, que os melhores bancos de dados
relacionais.
Os principais conceitos implementados na XDFPrevalence são:
Totalmente orientada a objetos;
Transacional (commit e rollback);
Isolamento transacional;
Execução de transações em multithread;
Versionamento de objetos (sem lock de objetos e sem risco de deadlock);
Zero Administration;
Todo tipo de integridade de dados das associações desenhadas no modelo

(referencial, composite, shared, unidiretional, bidiretional, etc.);
XDFEvolve: Evolução e involução de versão do modelo UML, com conversão

de classes, dados e associações aplicadas nos dados já existentes,
contemplando: mudanças de nome de classe, atributo e associação,
mudanças de tipo de atributo, mudanças de multiplicidade das associações,
mudanças de posição dentro da classe e na hierarquia de classes, inclusão e
exclusão de atributos, classes e associações;
Backup e Recover de dados.
3.2.3.4 XDFStateMachine
A XDFStateMachine, implementa o ambiente de execução nativa das Máquinas

de Estado descritas no PIM. Como dito anteriormente, as Máquinas de Estado
dispensam o uso de linguagens de programação específicas para representação da
lógica do fluxo das regras de negócio e workflows usando, para tanto, apenas
notação gráfica UML. Implementa ainda:
Página 78/96
A depuração gráfica da lógica das suas regras de negócio dentro do

XDFDesigner mostrando, em tempo de execução, as mudanças de transições
e estados no diagrama.;
Um ambiente de execução multithread com controle transacional para as

máquinas de estado;
Os métodos são publicados no XDFObjectServer como WebServices,

tornando as aplicações geradas orientadas a serviços e facilmente acessíveis
por outros Frameworks e sistemas legados.

Figura 20 – Edição de uma Máquina de Estados no XDFDesigner

(usando o XDFObjectBrowser)
Fonte: Projeto XDF
Página 79/96
3.2.3.5 XDFObjectServer
O XDFObjectServer é o servidor de objetos do XDF. Ele é o executável gerado a

partir do PIM pelo XDFDesigner. No seu interior rodam a XDFPrevalence e a
XDFStateMachine. Ele roda como um “service” no Windows ou como um “deamon”
no Linux, Solaris ou FreeBSD.
É através deste módulo que as requisições são recebidas do cliente

(XDFObjectBrowser ou outros aplicativos) e encaminhadas para a XDFPrevalence e
daí para a XDFStateMachine. Por ser genérico, ele disponibiliza uma API ou um
conjunto de WebServices para que clientes em qualquer tecnologia possam acessá-
lo.
3.2.3.6 XDFSecurity
A XDFSecurity é o módulo de segurança do XDF e parte constituinte da

XDFPrevalence. Sendo integrada à segurança do sistema operacional (seus
usuários e grupos), abrange todo leque necessário para assegurar a necessária
restrição ao acesso às informações, tais como:
Permissões no acesso a usuários e a grupos de usuários;
Permissão de inclusão, alteração, exclusão, consulta, execução e

ocultamento, além das combinações possíveis entre elas; no nível de
Packages;
Permissão de inclusão, alteração, exclusão, consulta, execução e

ocultamento, além das combinações possíveis entre elas; no nível de classes
de negócio;
Permissão de inclusão, alteração, exclusão, consulta e ocultamento, além das

combinações possíveis entre elas; no nível de atributos e relacionamentos
das classes de negócio;
Permissões de execução e ocultamento no nível de operações e workflows de

classes ou de instâncias de objetos;
Página 80/96
Permissões do que pode ser acessado no nível de valor de atributo, com a

combinação dos filtros definidos para todos os atributos da classe;
Log de auditoria para rastreabilidade das operações.

Figura 21 – Permissões de segurança sendo atribuídas no XDFSecurity

Fonte: Projeto XDF
3.2.3.7 XDFWorkflow
O XDFWorkflow é uma extensão da XDFStateMachine capaz de orquestrar uma

seqüência de trabalho, conduzindo o usuário por uma rotina (WorkFlow).
O Workflow no XDF é totalmente definido graficamente pelo usuário, através de

máquinas de estado e gerando verdadeiros Wizards que conduzirão usuário final à
realização de uma tarefa do início ao fim, sem possibilidade de esquecimento de
passos ou falhas no trajeto.
Página 81/96
O XDFWorkflow cobre desde rotinas básicas de uma ferramenta de WorkFlow

até as mais complexas como delegação de tarefas para um ou mais executantes;
envio de notificações; controle de tempo de execução, com disparo de ações para o
não cumprimento de prazos; controle de pendências; editor, templates e controle de
versão de documentos.
O XDFWorkflow é uma ferramenta capaz de controlar o fluxo de trabalho e de

informações na empresa, com controle de tarefas em execução, já concluídas ou
pendentes.

Figura 22 – Edição de um Workflow no XDFDesigner.

Fonte: Projeto XDF
Nota Técnica: Observe-se que Workflows diferem graficamente de Máquinas de

Estados comuns pela presença do símbolo ”–“ (fork ou join) que indicam a mudança
do papel de execução (contexto transacional), ou seja, outro usuário irá conduzir o
fluxo a partir daquele fork.
Página 82/96
3.2.3.8 XDFProxy
É uma API genérica que pode ser “ligada” (linked) estática ou dinamicamente
com uma aplicação escrita usando outra tecnologia ou linguagem: Java, C++, .Net,
Delphi, VB, etc. Permitindo interoperabilidade de uma aplicação do mundo externo
seja Client de uma aplicação XDF atuando como Server. Para que o caminho oposto
(XDF >> mundo externo) seja implementado é necessário que a aplicação Server
disponibilize suas interfaces como uma API para a aplicação XDF que atuará como
Client.
4 DISCUSSÃO E INTERPRETAÇÃO
A UML 2.0 possui 13 diagramas divididos em duas categorias principais.

Diagramas Comportamentais e Estruturais. Como mostrado na figura abaixo:
Figura 23 – Diagramas UML

Fonte: OMG em www.omg.org/uml
Os diagramas estruturais descrevem a composição de um sistema através de

elementos mais básicos tais como objetos, classes, atributos, métodos e
relacionamentos. Os diagramas comportamentais se prestam a descrever o
comportamento de métodos ou classes através da apresentação gráfica da
seqüência ou fluxo de ações a serem tomadas a partir de inputs, eventos ou
condições.
Página 83/96
A maioria dos diagramas é, entretanto, semanticamente redundantes e

raramente usados. A razão disso advém da pressão e da argumentação dos vários
representantes que compõem o board de empresas que estabelecem o padrão
UML, cada uma defende seus padrões internos o que reflete numa UML de
“consenso”, menos concisa do que o desejável.
Para uma implementação factível de MDA, os fabricantes de ferramentas têm

optado por um conjunto conciso, representativo e semanticamente suficiente de
diagramas, de acordo com a escola (Elaboracionista ou Translacionista) adotada.
Normalmente um ou dois diagramas. Aqui surge uma feliz unanimidade. Devido à
sua alta expressividade o Diagrama de Classes (DC) é adotado por todas as
ferramentas MDA, independentemente de escola, para modelagem estrutural.
Entretanto, quando a escola da ferramenta é Elaboracionista a modelagem

comportamental fica por conta de OCL e de uma linguagem OO de terceira geração,
por exemplo: Java, C# ou Object Pascal. Como é sabido OCL é apenas uma
linguagem de consulta, dependendo de outros recursos, como uma linguagem OO,
para que o comportamento seja completamente descrito. Em resumo a modelagem
comportamental deixa de ser gráfica para ser textual, perdendo parte dos benefícios
pregados pela MDA.
Já as ferramentas translacionistas usam normalmente Diagramas de Máquinas

de Estado (DME) ou Diagramas de Atividades (DA) com o acréscimo de uma AL
(Action Language) para a modelagem comportamental.
XDF é uma ferramenta MDA translacionista. Como discutido anteriormente, a

escola Elaboracionista, que é a escola MDA original, tradicional e defendida pela
própria OMG, não resolve o Dilema MDA. A escola Translacionista, mais jovem, que
faz o contraponto, é a única solução teórica atualmente disponível para o Dilema
MDA e que é capaz de salvaguardar as regras do negócio de sua implementação
tecnológica, ou seja; blindar o PIM. Por isso o XDF se envereda na seara
Translacionista, assumindo os riscos de um caminho mais desafiador e inovador.
Dentro deste cenário XDF adota o diagrama de Máquinas de Estado (DME), na

forma de diagramas de Harel [HAREL1984], em detrimento ao Diagrama de
Atividades (DA), pelos seguintes motivos:
Página 84/96
O DME é notacionalmente muito mais simples que o DA. As vantagens

decorrentes são:
a. Mais fácil de ser aprendido pelos analistas e usuários.
b. Mais fácil de ser construído.
c. Diagramas menores, mais concisos e mais rapidamente entendidos.
d. Mais fácil de ser transformado em código.
e. Mais fácil de ser verificado visualmente e corrigido.
O DME é tão expressivo quanto o DA para realizar modelagem

comportamental.
O DA é na verdade um variante do DME com extensões.
O DME é matematicamente um Grafo Dirigido (Digraph), para o qual existe

imenso legado acadêmico chamado “Teoria dos Grafos”. Isso abre vastas
possibilidades de estudo e experimentação matemática e computacional,
quando os comportamentos dos seus negócios estão modelados usando
DME. Uma dessas possibilidades, já exploradas pelo XDF, é a medição da
Complexidade Ciclomática v(G), desenvolvida por Thomas McCabe
[McCABE1976], ou seja, uma métrica de software automaticamente obtida,
permitindo auditagem, melhoria de qualidade, controle de riscos, gastos e
outros. Outra possibilidade é o teste automatizado do software sem a
necessidade de criação de scripts como derivação da própria v(G).
A própria ferramenta CASE pode detectar facilmente alguns erros de lógica e

semântica durante a feitura do DME. Tais erros não poderiam ser tão
facilmente detectados se a modelagem fosse baseada em código.
Como complemento ao DME as ferramentas translacionistas devem usar uma AL

que dê acesso aos comandos imperativos (chamadas de métodos, procedimentos e
funções) da camada de persistência, permitindo que o DME possa:
Selecionar objetos do modelo, invocar seus métodos;

Página 85/96
Alterar seus atributos (estado interno);
Navegar em seus relacionamentos;
Criar, alterar e deletar objetos etc.
Adicionalmente essa AL deve permitir acesso a APIs (chamadas de métodos,

procedimentos e funções) multiplataforma, ou seja o comando imperativo usado
para se invocar qualquer tarefa que não atue sobre objetos do modelo, tais como:
acesso a periféricos, arquivos, troca de mensagens e etc., devem ser iguais em
qualquer sistema operacional (Windows, Linux, Unix, MacOS, Symbian, etc.). E
mais, deve permitir interoperabilidade com executáveis e DLLs criadas em outras
tecnologias (ex. Java, C#, C++, etc.)
Infelizmente, como visto anteriormente, não há um padrão universalmente aceito

para a AL (Action Language). A maioria das propostas submetidas ao OMG não
passa de novas linguagens baseadas em C ou Java, com o mesmo nível de
abstração que qualquer outra linguagem de 3ª geração não justificando sequer a
proposta apresentada. E pior, por serem baseadas em código são filosoficamente
opostas a MDA.
Em suma as propostas apresentadas partem do princípio de que uma AL deve

possui estruturas de controle tais como comandos de loop: for, while, repeat e de
decisão tais como: if, case, switch, try/catch e outros o que se considera um passo
atrás em tudo o que foi conquistado e proposto pela UML e pela MDA.
O X (eXtreme) do XDF é exatamente uma proposta nova, que se faz contra esta
indefinição, tornando implementação de PIMs de qualquer domínio de negócio
factível sob o paradigma MDA Translacionista. Baseados nisso aplicam-se os
seguintes pressupostos:
XDF usa o conceito original do DME estabelecido por Harel [HAREL1984], em

que workflows e flowcharts são modelados naturalmente em DME, ampliando
a interpretação restrita dada pela UML, onde um DME só se presta para
modelar o ciclo de vida de um objeto.
Página 86/96
Usando um DME como um Diagrama de Harel, obtém-se a mesma

expressividade de um DA com muito mais simplicidade. Ou seja, os estados
representam os passos de execução do método e as transições representam
as condições a serem atendidas para que o próximo estado seja executado.
Em seu trabalho, o Dr. Harel demonstra porque a abordagem tradicional do
DME usado pela UML é caótica e ineficiente para modelar sistemas e porque
essa outra abordagem mais abrangente deve ser adotada;
O DME já é suficientemente expressivo para dispensar o uso de todas as

estruturas de controle e decisão (for, while, repeat, if, case, switch, try/catch e
etc.). Qualquer algoritmo pode ser expresso com um DME;
A AL deve ser conforme já especificado. Apenas invocação de métodos,

comandos imperativos, expressões booleanas e nada mais. Ou seja, apenas
uma biblioteca multiplataforma e orientada a objetos;
Os estados do DME irão conter os comandos imperativos da AL;
As transições do DME irão conter expressões booleanas formadas por

chamadas de funções da AL;
Toda e qualquer declaração de métodos, atributos e relacionamentos deve

estar no DC e não na AL;
Declarações de objetos locais podem ser feitas no DME;
Um debugger visual pode ser construído baseado em DMEs interpretados

como Diagramas de Harel;
A AL precisa ter um compilador nativo, rápido, gratuito e multiplataforma.
A necessidade de código nativo advém do fato que XDF nasceu em um cenário

onde aplicações de missão crítica de altíssima performance eram absolutamente
necessárias e experiências anteriores com Java e .Net falharam.
Linguagens interpretadas ou scriptadas tais como: Perl, PHP, ASP, Tcl, Python,
Forth, Lisp, Smalltalk ou Ruby não oferecem a performance necessária para serem
consideradas. Já outras linguagens orientadas a objeto com compiladores de código
Página 87/96
nativo como C++, Delphi, FreePascal, Eiffel, Oberon e Ada são opções melhores ao
se avaliar sob este prisma.
Um PIM de média complexidade precisa ser compilado rapidamente, na ordem

de segundos, pois uma compilação lenta desencorajaria a experimentação, baixaria
a produtividade, exigiria processadores muito poderosos e tornaria o framework
desconfortável e pouco amigável.
O compilador precisaria ser de um passo para obter uma compilação

suficientemente rápida. Os compiladores criados por Niklaus Wirth para as suas
linguagens de linhagem Pascal (Object Pascal, Modula e Oberon) têm essas
características.
A necessidade de um compilador de código aberto advém do fato de que XDF

não poderia, por premissa, ter dependências de um compilador pago o que oneraria
o framework e reduziria sua difusão.
A necessidade de multiplataforma advém do fato de que este é um dos

pressupostos da MDA, ou seja, levar o seu negócio para hardwares e sistemas
operacionais diferentes aproveitando sempre as opções que forem mais econômicas
ou disponíveis sem necessidades de mudanças no código ou na modelagem.
Ao juntar todas essas características, chega-se a escolha da FCL (Free

Component Library, http://community.freepascal.org:10000/docs-html/rtl/index.html e
http://community.freepascal.org:10000/docs-html/fcl/index.html) como a AL do XDF
com seu respectivo compilador o FreePascal.
Essa biblioteca é licenciada como LGPL (Library GNU Public License) e o

compilador como GPL (GNU Public License). Esses projetos estão em forte e
crescente atividade desde 1998.
A FCL tem ainda algumas vantagens adicionais:
Emula a VCL (Visual Component Library) do Delphi, isto significa que existe
um vasto legado de programas, sistemas, bibliotecas e componentes
disponíveis livremente pela Internet que podem ser diretamente usados pelo
XDF com pouca ou nenhuma modificação;
Página 88/96
Muitos desenvolvedores conhecem a VCL o que facilita o seu uso;
A VCL foi criada em 1995 sendo bastante madura e experimentada na

construção de sistemas de variados domínios e tamanhos;
O criador da VCL e do Delphi, o engenheiro de software Anders Hejlsberg,

criou posteriormente em 2002 na Microsoft, a BCL (Base Class Library) e o
framework .Net que incorporam uma grande parte da filosofia da VCL;
Além do atendimento dos pré-requisitos anteriores (compilação rápida, código

nativo, gratuito e multiplataforma) o FreePascal tem em sua defesa os seguintes
argumentos:
É o único compilador nativo e gratuito, atualmente, para a plataforma

Windows de 64 bits, portanto o único capaz de explorar a potencialidade do
endereçamento de 64 bits (uso de mais de 4GB de memória RAM) em
servidores Windows, o que é indispensável para uso com Prevalência;
Gera executáveis que consomem a menor quantidade de memória RAM entre

todos os compiladores e interpretadores o que é extremamente importante
para a viabilização de um framework baseado em Prevalência, que precisa de
toda a memória possível para armazenamento dos objetos.
Usa Object Pascal, uma linguagem orientada a objeto, com toda a

expressividade necessária para receber a translação de um PIM via
mapeamento MDA, e com recursos de introspecção (RTTI - Run Time Type
Information) similares aos existentes em Java e C#, permitindo fácil e
transparente implementação de uma camada de Prevalência no framework.
O uso aplicado do Object Pascal como alternativa para geração de código nativo
(sistemas) a partir de um modelo de negócio (PIM) que se expressa por meio de
DCs e DMEs viabilizou através do uso especializado e aperfeiçoado da Prevalência
para criação de Servidores de Objetos de elevada performance e confiabilidade.
Esses Servidores de Objetos, assim como URLs (ou páginas da Internet), podem
estar localizados em qualquer parte do mundo e serem invocados por um Browser
(interface) polimórfico, porém padronizado, que permite ao usuário “navegar” sob os
Página 89/96
modelos seja de forma orientada a objetos (OO), seja de forma orientada a tarefas
(Workflow).
Em seu estado da arte atual XDF permite que o desenvolvimento dos modelos
seja colaborativo, seja sob uma rede local, seja via Internet, uma vez que o próprio
framework reside em um Servidor de Objetos específico onde modelos podem ser
construídos simultaneamente, compartilhados e reaproveitados, ampliando-se o
conceito de componentização para outro que se denomina “pacotes de negócios”.
Essa última potencialidade anunciada contribui para que o conceito de Fábricas

de Software Virtuais seja estendido além das fronteiras atuais, uma vez que
ferramentas de colaboração virtual (messenger, email, tele ou video-conferencia)
Página 90/96
5 CONCLUSÕES
O framework XDF foi desenvolvido no biênio 2005/06 sob a forma de um

Programa (ou seja, uma coleção de Projetos) como uma alternativa estratégica de
ferramental para desenvolvimento, produção e manutenção de sistemas aplicativos
transacionais que diminuísse a dependência tecnológica de seus patrocinadores
frente as inúmeras tecnologias que – seja em regime de produção, seja em regime
de projeto – apontavam para a continuidade do aumento da complexidade, do
custeio e do investimento em TI.
Ao redor de um núcleo central de aproximadamente 5 (cinco) especialistas,

responsáveis pelo desenvolvimento do XDF, um anel concêntrico de mais 6 (seis)
especialistas cuidaram dos aspectos relacionados com os testes do framework,
construção de modelos corporativos, documentação, suporte e capacitação dos
desenvolvedores que em número não superior a 10 (dez) profissionais, se
revezaram na tarefa de construir os sistemas transacionais alvo do interesse
estratégico dos patrocinadores.
Os primeiros sistemas piloto tiveram sua construção efetivamente iniciada a partir

do final do primeiro semestre de 2006. Aproximadamente 10 (dez) projetos foram
iniciados simultaneamente com visada de entrada em produção para o primeiro
semestre de 2007.
Os resultados práticos, em regime de homologação funcional e técnica, foram

confirmando gradativamente ao longo de 2006, a capacidade do XDF em atender
com sucesso tanto o Objetivo Principal como aqueles listados como acessórios
nesta Monografia, considerando o círculo virtuoso proporcionado pela manipulação
coordenada das variáveis escolhidas como estruturantes para adoção de novos
paradigmas (principalmente MDA, OO e Prevalência).
É fato, entretanto, que o processo de desenvolvimento dos sistemas piloto se

submeteu a atrasos com a natural necessidade de ajustes no novo framework, de
forma a atender ao máximo as expectativas dos patrocinadores sem que seus
conceitos básicos fossem corrompidos.
Página 91/96
A despeito desse fato, durante o processo pode-se perceber claramente um

envolvimento e compreensão muito maior dos Key-users (ou gestores dos negócios)
na elaboração dos modelos e na geração imediata de protótipos de eram refinados
em iterações sempre a partir do PIM uma vez incorporados os devidos ajustes no
motor translacionista (no caso o gerador de código).
Os pontos centrais de aperfeiçoamento do XDF, em tempo de construção dos

sistemas piloto foram, de um lado, a necessidade de robustecimento, confiabilidade
e performance da camada de prevalência (XDFPrevalence) e, de outro, a
incorporação de funcionalidades na interface polimórfica (XDFObjectBrowser) e nos
“motores” de workflow (XDFWorkflow) para garantia de total isolamento do sistema
gerado da intervenção humana, refletindo portanto de forma coerente o PIM sobre
uma abordagem de fato translacionista.
Adicionalmente, muitos dos sistemas transacionais escolhidos e colocados em

regime de redesenvolvimento sob XDF apontaram para a necessidade de
endereçamento superior a 4GB de memória RAM, fato esse que antecipou o
tratamento de questões infra-estruturais complexas, que passaram a envolver a
manipulação dos novos parâmetros de sistemas 64 bits, seja sob uma visada
tecnológica de hardware ou de software básico.
Outro ponto central a ser comentado nesta conclusão diz respeito a uma questão
cultural, notadamente sob dois aspectos principais:
O primeiro relaciona-se com a dificuldade humana de aplicação prática dos

conceitos de orientação a objeto por desenvolvedores acostumados a uma cultura
relacional ou até mesmo pré-relacional. Como quem desenvolve os sistemas não
são aqueles que desenvolvem o framework, abre-se um abismo que só treinamento
e experiência são capazes de resolver e ambos exigem tempo, variável essa que
fugiu ao controle do planejamento estratégico.
O segundo diz respeito a resistência cultural frente a não utilização de

Gerenciadores de Bancos de Dados e Servidores de Aplicação. Essa resistência ao
paradigma de Servidores de Objetos prevalentes, se refletiu na instauração de um
manto de desconfiança quanto a viabilidade técnica do framework e os riscos em
adotá-lo.
Página 92/96
Tais questões, entendidas notadamente como infra-estruturais, transcendendo a

equipe de desenvolvedores, envolveram os projetos de ceticismo e incredulidade
junto a comunidade técnica, quanto a sua futura estabilidade em regime de
produção, considerando os elevados volumes de dados a serem manipulados e em
se tratando muitos desses sistemas, de aplicações do tipo “missão crítica”.
Este contexto foi minando a confiança dos patrocinadores para continuidade dos
projetos ainda que muitos destes já estivessem com sua homologação funcional e
técnica concluídas a espera da autorização para entrada em produção.
O resultado observado foi a interrupção do processo de colocação dos sistemas

em regime de produção no final do primeiro semestre de 2007, a dispersão da
equipe original com conseqüente paralisia do Programa XDF.
O resgate e a continuidade de desenvolvimento do framework XDF e de seus

sistemas derivados depende atualmente de fatores políticos-institucionais que fogem
ao controle dos idealizadores do Programa XDF.
A despeito do desfecho relatado na Conclusão desta Monografia, é fato

inconteste a existência tanto do framework XDF em plenas condições de uso, bem
como farta documentação técnica sobre como utilizá-lo para construir aplicações a
partir de modelos sob uma abordagem MDA Translacionista. Existem também
técnicos capacitados (além dos desenvolvedores do framework), como também
outros potenciais patrocinadores entusiastas frente as potencialidades prometidas e
demonstradas até o momento.
Uma vez que venha a ser vencido o problema relacionado com direitos autorais
ou ainda que seja revertida a posição político-institucional dos atuais patrocinadores
para um retorno de sua utilização, sugere-se a adoção de um novo modelo de
negócios para a disseminação do framework, com base nas lições aprendidas
durante o ciclo de vida do Programa XDF até o momento presente:
Que forte atenção seja dada formação básica e adequada aos desenvolvedores
nos conceitos de Orientação a Objetos, uma vez que a experiência do Programa
XDF e seus diversos Projetos componentes demonstraram ser esse um grande
entrave a adoção dos novos paradigmas;
Página 93/96
Que seu uso aplicado seja orientado a sistemas com complexidade crescente,
partindo de aplicações menores e menos críticas para outras mais complexas e
transacionais;
Que o XDF seja empacotado sob a forma de um produto para livre distribuição
nos meios acadêmicos, com algumas restrições técnicas que preservem a condição
de manter seu potencial comercial (p.exe: número limitado de acessos simultâneos a
um mesmo XDFObjectServer);
Que seja construído um Site específico para divulgação e compartilhamento de

experiências XDF na Internet de forma a estimular a criação de comunidades e
entusiastas da tecnologia em apoio a sua constante depuração e atualização de
seus elementos e artefatos;
Que a comunidade acadêmica seja estimulada a construir, permutar e otimizar a

representação de negócios sob a forma de Máquinas de Estados gerando “pacotes
de negócios” cada vez mais abstraídos de implementações tecnológicas;
Que sejam aplicadas técnicas de marketing viral como forma de divulgação e

venda de versões comerciais sem restrições.
Página 94/96
6 REFERÊNCIAS BIBLIOGRÁFICAS
[ACME04]
Carnegie Mellon University. The Acme Architectural Description Language. 2004.
Disponível em <www-2.cs.cmu.edu/~acme>. Acesso em: 15 de maio de 20076.
[AS02]
Object Management Group. Action semantics for UML, Action semantics
specification document. 2002. Disponível em <www.omg.org/docs/ptc/02-01-09.pdf>.
Acesso em: 15 de maio de 2007.
[BJORKANDER03]
Björkander M, Kobryn C. Architecting Systems with UML 2.0. IEEE Computer
Society Press, Los Alamitos, CA, USA, 2003.
[CORBA04]
Common Object Requested Broker Architecture. The official homepage of CORBA.
Disponível em <www.corba.org>. Acesso em: 15 de abril de 2007.
[CROSBY1979]
Crosby, Philip. Quality is Free. New York: McGraw-Hill. 1979.
[CWM03]
Common Warehouse Metamodel (CWM). Common Warehouse Metamodel
Specification, 2003. Disponível em <www.omg.org/docs/formal/03-03-02.pdf>.
Acesso em: 25 de abril de 2007.
[DEMASI]
DE MASI DOMENICO, O Futuro do Trabalho. Rio de Janeiro, RJ. José Olympio.
1999.
[GURD03]
Gurd A. Using UML 2.0 to Solve Systems Engineering Problems. White Paper,
Telogic AB, July 2003.
[HAREL1984]
D. Harel and D. Peleg, Static Logics, Dynamic Logics and Complexity Classes,
Information and Control 60 (1984), 86-102.
[KLEPPE03]
KLEPPE, A.; WARMER, J.; BAST, W. MDA Explained: The Model Driven
Architecture - Practice and Promise. Addison-Wesley, Reading, MA, 2003.
[McCABE1976]
McCabe, Thomas J.; Watson, Arthur H. Structured Testing: A Testing Methodology
Using the Cyclomatic Complexity Metric. Computer Systems Laboratory, National
Institute of Standards and Technology, 1996
[MDA01]
Object Management Group Architecture Board. Model Driven Architecture 2001.
Disponível em <http://www.omg.org/docs/ormsc/01-07-01.pdf>. Acesso em: 10/03/07
Página 95/96
[MDA03]
Object Management Group. MDA Guide. Version 1.0.1, 2003. Disponível em
<http://www.omg.org/docs/omg/03-06-01.pdf>. Acesso em: 15 de março de 2007.
[MDA04]
Model Driven Architecture. The official homepage of MDA. 2004. Disponível em
<www.omg.org/mda>. Acesso em: 25 de março de 2007.
[MOF03]
Meta Object Facility. Document. 2003. Disponível em <www.omg.org/docs/formal/02-
04-03.pdf >. Acesso em: 18 de março de 2007.
[MOSSES92]
Mosses P, Action Semantics. Number 26 in Cambridge Tracts in Theoretical
Computer Science. Cambridge University Press, 1992.
[MENDES02]
MENDES, Antônio. Arquitetura de Software: Desenvolvimento Orientado para
Arquitetura. Campus, Rio de Janeiro, 2002.
[OAL03]
Object Action Language. Object Action Language Manual V 1.4. 2003. Disponível em
<www.projtech.com/pdfs/bp/oal.pdf>. Acesso em: 25 de maio de 2007.
[OCL03]
Object Constraint Language. OCL 1.6 Specification Document. 2003. Disponível em
<www.omg.org/docs/ad/03-01-07.pdf>. Acesso em: 25 de maio de 2007.
[OMG04]
Object Management Group. The official homepage of OMG. Disponível em
www.omg.org , 2004. Acesso em: 15 de maio de 2007.
[PAULK1995]
PAULK, M. C. The Capability Maturity Model: Guidelines for improving the software
process. U.S.A: Addison Wesley, 1995. (SEI Series).
[PRESMAN02]
PRESSMAN, Roger S. Engenharia de Software. Mc Graw Hill, 5º ed. Rio de Janeiro,
2002.
[Prevayler]
The Open Source Prevalence Layer. The official homepage of Prevayler. Disponível
em <http://prevayler.org/wiki/>. Acesso em 28 de outubro de 2007.
[SDL04]
SDL Fórum Society. Specification and Description Language. Disponível em
<www.sdl-forum.org>. Acesso em: 8 de junho de 2007.
[SIEGEL01]
SIEGEL, J & OMG Staff Strategy Group. Developing in OMG’s Model-Driven
Architecture. 2001. Disponível em <ftp://ftp.omg.org/pub/docs/omg/01-12-01.pdf>.
Acesso em: 10 de junho de 2007.
Página 96/96
[STA2004]
The Standish Group. The official homepage of OMG. Disponível em
<http://www.standishgroup.com/benchmark/performance.php>, Benchmark
Performance Report 2004. Acesso em: 15 de abril de 2007.
[STEPHEN01]
Mellor, j. Stephen; Balcer J. Mark. Executable UML, A Foundation for Model-Driven
Architecture, Addison Wesley, 2002.
[UML04]
Unified Modeling Language. The official homepage of UML. 2004. Disponível em
www.uml.org. Acesso em: 15 de junho de 2007.
[WILKIE01]
Wilkie I; King A; Clarke M; Weaver C; Rastrick C. UML ASL Reference. Disponível
em <http://www.irit.fr/~Ralph.Sobek/neptune/03-03-12.pdf>. 2001. Acesso em: 15 de
maio de 2007.

Monografia XDF - Extreme Driven Framework

Enviado por

Dados do documento

Título original

Direitos autorais

Formatos disponíveis

Compartilhar este documento

Compartilhar ou incorporar documento

Opções de compartilhamento

Você considera este documento útil?

Este conteúdo é inapropriado?

Direitos autorais:

Formatos disponíveis

Monografia XDF - Extreme Driven Framework

Enviado por

Direitos autorais:

Formatos disponíveis

FERNANDO MIGUEZ DIAS DA SILVA

eXtreme Driven Framework

'O Modelo é o Sistema'

"Uma implementação translacionista para um framework de desenvolvimento de

Fernando Miguez Dias da Silva

eXtreme Driven Framework

'O Modelo é o Sistema'

"Uma implementação translacionista para um framework de desenvolvimento de

Monografia apresentada no Curso de Pós-

Orientador: Carlos André Reis Pinheiro DSC.

Em sua arrojada concepção, o framework XDF parte do "estado da arte" de

Palavras-Chave: XDF, eXtreme Driven Architecture, MDA - Model Driven

Keywords: XDF, eXtreme Driven Architecture, MDA, Model-Driven Architecture,

Figura 1 - O Iceberg Tecnológico ..............................................................................12

1.1 O Iceberg tecnológico....................................................................................................... 11

1.2 A Babel Tecnológica......................................................................................................... 13

1.3 A Teoria das Ondas.......................................................................................................... 15

1.4 Os especialistas especializados ..................................................................................... 17

1.5 O problema da Documentação ....................................................................................... 20

1.7 O resumo da Ópera .......................................................................................................... 23

2 FUNDAMENTAÇÃO TEÓRICA ..........................................................................29

2.1 Orientação a Objetos (OO).............................................................................................. 29

2.1.1 Benefícios da OO ......................................................................................................... 30

2.1.2 Linguagens Procedurais X Orientada a Objetos ..................................................... 31

2.1.3 Linguagens Compiladas X Interpretadas.................................................................. 32

2.2 Arquitetura de Software (ou Framework de SI)............................................................ 33

2.3 Modelos e Metamodelos: Por que modelar software?................................................ 33

2.4 MDA - Model Driven Architecture ................................................................................... 33

2.4.1 Núcleo e Padrões ......................................................................................................... 33

2.4.1.1 CWM (Common Warehouse Metahouse Metamodel) ................................... 33

2.4.3 Pervasive Services (Serviços Universais) ................................................................ 33

2.4.4 Os Níveis de Abstração em MDA .............................................................................. 33

2.4.4.1 CIM (Computational Independent Model) ........................................................ 33

2.4.6 As duas abordagens da MDA..................................................................................... 33

2.4.7 Benefícios da utilização de MDA................................................................................ 33

2.4.8.1 Os Critérios ........................................................................................................... 33

2.5.1 Object Constraint Language (OCL) ........................................................................... 33

2.5.1.1 Expressões ........................................................................................................... 33

2.5.3 A Linguagem de Ação (Action Language) ................................................................ 33

2.6 UML – Unified Modeling Language................................................................................ 33

2.6.1 Diagramas UML ............................................................................................................ 33

2.6.2 UML 2.0 – Motivações para revisão da UML ........................................................... 33

2.6.3 UML 2.0 e MDA............................................................................................................. 33

2.6.3.1 Expressividade ..................................................................................................... 33

2.7.1 O Prevayler .................................................................................................................... 33

2.7.2 Componentes da Prevalência..................................................................................... 33

2.7.2.1 A serialização ....................................................................................................... 33

3 ANÁLISE E PROPOSIÇÃO ................................................................................33

3.1 APRESENTAÇÃO DO DILEMA MDA............................................................................ 33

3.1.1 Para onde então, a partir daqui?................................................................................ 33

3.2 XDF: UMA ALTERNATIVA DE SOLUÇÃO PARA O DILEMA MDA......................... 33

3.2.1 DIFERENCIAIS DO XDF............................................................................................. 33

3.2.2 O DESENVOLVIMENTO SOB XDF .......................................................................... 33

3.2.3 OS COMPONENTES DO FRAMEWORK XDF ....................................................... 33

3.2.3.1 XDFDesigner ........................................................................................................ 33

6 REFERÊNCIAS BIBLIOGRÁFICAS ...................................................................33

A presente Monografia pretende conduzir a uma reflexão sobre a complexidade

“Seria então possível conceber, desenvolver e manter sistemas simples ou

1.1 O Iceberg tecnológico

É quase certo que o timoneiro, ao ser informado e tomar consciência da situação,

A correlação mental desta imagem com a complexidade tecnológica, bem

A imagem abaixo tenta representar o que de fato e em linhas gerais, separa o

Figura 1 - O Iceberg Tecnológico