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ósGraduaçã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

2

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

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

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

3

MDA e Linguagens de Modelagem............................................................................ 33

A Prevalência em funcionamento .............................................................................. 33

ANÁLISE E PROPOSIÇÃO ................................................................................33 3.1 3.1.1

APRESENTAÇÃO DO DILEMA MDA............................................................................ 33 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

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

A Babel Tecnológica

4

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 offline (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”. 1.3

A Teoria das Ondas

6

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

Conceito idealizado pelo Autor

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

Os especialistas especializados

8

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

Conceito idealizado pelo Autor

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

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

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, chegase 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 A dinâmica de um sistema é representada por pré e póscondições de suas operações

Visão do comportamento

Método para modelar o Pré e Pós-condições nas definições de classes comportamento Linguagem utilizada

Object Constraint Language (OCL)

TRANSLACIONISTA O comportamento de um sistema é dirigido pelo movimento dos objetos de um estágio de seu ciclo de vida para outro sempre em resposta a eventos Máquinas de Estados e Atividades Action Language (AL)

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 infraestrutura 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 | XDF Object Server XDFSecurity

XDFWorkflow

Prevalence

StateMachine

XDF

Produção XOS1

XDF

Modelos

XOS2

XOSn

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); Na Figura que se segue é apresentado um snapshot que exemplifica o funcionamento deste componente no framework XDF.

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. Na Figura que se segue é apresentado um snapshot que exemplifica o funcionamento deste componente no framework XDF.

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. Na Figura que se segue é apresentado um snapshot que exemplifica o funcionamento deste componente no framework XDF.

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. Na Figura que se segue é apresentado um snapshot que exemplifica o funcionamento deste componente no framework XDF.

Figura 21 – Permissões de segurança sendo atribuídas no XDFSecurity (usando o XDFObjectBrowser) 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. Na Figura que se segue é apresentado um snapshot que exemplifica o funcionamento deste componente no framework XDF.

Figura 22 – Edição de um Workflow no XDFDesigner. (usando o XDFObjectBrowser) 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. Society Press, Los Alamitos, CA, USA, 2003.

IEEE Computer

[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 . Acesso em: 10/03/07

Página 95/96

[MDA03] Object Management Group. MDA Guide. Version 1.0.1, 2003. Disponível em . 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/0204-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 . 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 . Acesso em: 10 de junho de 2007.

Página 96/96

[STA2004] The Standish Group. The official homepage of OMG. , Performance Report 2004. Acesso em: 15 de abril de 2007.

Disponível em Benchmark

[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 . 2001. Acesso em: 15 de maio de 2007.