MAC0499-Trabalho de Formatura Monografia

USP - Universidade de So Paulo Instituto de Matemtica e Estatstica Bacharelado em Cincia da Computao

Tcnicas de Reuso de Software aplicados na elaborao de Arquiteturas Corporativas

Tipo de Trabalho: Estgio Supervisionado

Aluno: Alexandre Eiki Onishi Supervisor: Prof. Siang Wun Song

Sumrio
Parte I. Introduo ------------------------------------------------------------------ 4
Captulo 1 Introduo ---------------------------------------------------------------------------------- 4 1.1 Viso Geral ------------------------------------------------------------------------------------- 5 1.2 Objetivos ---------------------------------------------------------------------------------------- 6 1.3 Motivaes ------------------------------------------------------------------------------------- 6 1.4 Organizao do texto ------------------------------------------------------------------------ 7

Parte II. Conceitos, Tecnologias Estudadas e Resultados ------------------------- 8

Captulo 2 - Conceitos de Reuso de Software --------------------------------------------------- 9 2.1 Introduo -------------------------------------------------------------------------------------- 9 2.2 Definies -------------------------------------------------------------------------------------- 9 2.3 Benefcios e Desafios ----------------------------------------------------------------------- 10 2.4 Abordagens de Reutilizao -------------------------------------------------------------- 10 2.4.1 Reuso Vertical -------------------------------------------------------------------------- 11 2.4.2 Reuso Horizontal ---------------------------------------------------------------------- 11 2.4.3 Reuso Planejado ----------------------------------------------------------------------- 11 2.4.4 Reuso Composicional ---------------------------------------------------------------- 11 2.4.5 Reuso Baseado em Geradores de Cdigo --------------------------------------12 2.4.6 Reuso Caixa Branca -------------------------------------------------------------------12 2.4.8 Reuso Caixa Preta ---------------------------------------------------------------------12 2.4.9 Reuso de Cdigos Fontes ------------------------------------------------------------12 2.4.10 Reuso de Projetos --------------------------------------------------------------------12 2.4.11 Reuso de Especificao ------------------------------------------------------------13 2.5 Processos de desenvolvimento com Reuso de Software --------------------------13 2.5.1 Modelo Cascata com Reuso de Software ---------------------------------------13 2.5.2 Modelo Espiral com Reuso de Software -----------------------------------------14 Captulo 3 Frameworks: Reuso e Aplicaes -------------------------------------------------18 3.1 Introduo ------------------------------------------------------------------------------------- 18 3.2 o que um Framework? ------------------------------------------------------------------- 18 3.3 Pontos Fracos dos Frameworks --------------------------------------------------------- 21 3.4 Comparao com outras formas de reuso -------------------------------------------- 22 3.5 Tipos de Frameworks ---------------------------------------------------------------------- 23 3.6 Anlise do Framework Horizontal MVC: Java Server Faces --------------------- 26 3.6.1 Interfaces WEB ------------------------------------------------------------------------ 26

3.6.2 O padro Model View Controller(MVC) ------------------------------------------ 28 3.6.3 Frameworks WEB --------------------------------------------------------------------- 28 3.6.4 O Framework Java Server Faces(JSF) ------------------------------------------ 30 3.7 Anlise do Framework Horizontal de Persistncia: Hibernate -------------------- 33 3.7.1 O Paradigma OO x Relacional ---------------------------------------------------- 34 3.7.2 Um Exemplo com o Hibernate ---------------------------------------------------- 35 3.7.3 Hibernate e o problema do Grafo de Navegao ---------------------------- 39 3.7.4 Hibernate e o problema dos Relacionamentos ------------------------------- 40 3.8 Anlise do Framework Horizontal: Spring --------------------------------------------- 41 3.8.1 Inverso de Controle ---------------------------------------------------------------- 41 3.8.2 IoC com o Spring --------------------------------------------------------------------- 43 3.8.3 Outros Servios do Spring --------------------------------------------------------- 45 Captulo 4 Arquiteturas Orientadas a Servios (SOA) ------------------------------------- 48 4.1 Arquiteturas Orientadas a Servios (SOA) ------------------------------------------- 48 4.2 Arquitetura Tcnica de Web Services -------------------------------------------------- 51 4.3 Aplicao de SOA: EAI Enterprise Application Integration --------------------- 52 Captulo 5 Atividades realizadas, Resultados obtidos e Concluses ---------------- 54 5.1 Estudo de caso: Sistema Opus ibank ------------------------------------------------- 54 5.2 Desafios e Solues ----------------------------------------------------------------------- 55 5.3 Arquitetura tcnica do Servidor ibank ------------------------------------------------- 56 5.4 Arquitetura orientada a servios (SOA) e o ibank ---------------------------------- 58 5.5 Metodologias usadas durante o desenvolvimento da arquitetura do ibank -- 59 5.5.1 Prototipao -------------------------------------------------------------------------- 59 5.5.2 Programao orientada a aspectos com AspectJ -------------------------- 60 5.5.3 Geradores de cdigo --------------------------------------------------------------- 61 5.6 Resultados obtidos ------------------------------------------------------------------------- 61 5.7 Concluses ----------------------------------------------------------------------------------- 62

Parte III. Parte Subjetiva ----------------------------------------------------------------------------- 64

Captulo 6 BCC e o Estgio ------------------------------------------------------------------------- 65 6.1 Desafios e Frustraes ----------------------------------------------------------------- 65 6.2 O Relacionamento como os membros da Equipe ------------------------------- 66 6.3 Disciplinas que foram relevantes para o trabalho ------------------------------- 66 6.4 Prximos passos ------------------------------------------------------------------------ 67 6.5 Agradecimentos ------------------------------------------------------------------------- 67

Parte I Introduo
Captulo 1: Introduo

Captulo 1
Introduo
1.1 Viso Geral O avano da internet tem motivado o crescimento de uma nova gerao de aplicaes baseada na web, que combinam navegao e interatividade num grande espao de documentos heterogneos. A web se mostrou como um dos meios mais efetivos e atrativos meios de divulgao, negociao e disponibilizao de bens e servios. Independente de contexto, o projeto de aplicaes ainda no um processo totalmente definido, como se sabe fazer software um processo lento e custoso, somado a isso a demanda por software aumentou muito nas ultimas dcadas, necessita-se mais, com prazos de entrega cada vez mais curtos e exigentes, ao mesmo tempo em que se exige qualidade e confiabilidade no produto final, e dentro deste contexto que surge o processo de desenvolvimento baseado em reuso de software. A reutilizao de software uma das reas da engenharia de software que prope um conjunto sistemtico de processos, de tcnicas e de ferramentas para obter produtos com alta qualidade e que sejam economicamente viveis. A idia do reuso evitar retrabalho no desenvolvimento de um novo projeto, sempre levando em considerao trabalhos anteriores, fazendo com que solues previamente desenvolvidas sejam aproveitadas e implementadas em novos contextos. Dessa forma, tem-se melhores produtos em um menor intervalo de tempo e um aumento da qualidade, pois muitas dessas solues j foram testadas e validadas anteriormente. O termo reuso pode ser considerado uma denominao genrica para uma srie de tcnicas utilizadas, que vo desde a etapa de modelagem de um projeto at a implementao. Atualmente existem vrias tcnicas de reuso como frameworks, arquiteturas orientadas a servios (SOA), engenharia de software baseada em componentes, entre outras. Esta dissertao focar em apresentar somente as tcnicas de reuso no contexto de frameworks e arquiteturas orientadas a servios. Ao desenvolver sistemas, o desenvolvedor depara-se com inmeros desafios. Alm de ter que entender sobre regras de negcio do seu domnio de aplicao, ele tem que lidar tambm com aspectos ligados infra-estrutura da aplicao como segurana, servios remotos, persistncia de dados, validao entre outros. Desse modo desenvolver software j complicado por ter que entender o domnio da aplicao e no deveria ser mais difcil ainda por tais questes de infra-estrutura.

Os Frameworks so uma tcnica de reuso que surge como uma soluo para este problema, acelerando o desenvolvimento de software. A idia permitir que o desenvolvedor se foque mais nos aspectos funcionais do domnio da aplicao, cabendo ao frameworks a tarefa de fornecer a infra-estrutura tcnica necessria para o tratamento destas questes tcnicas, fornecendo ao desenvolvedor uma maneira de lidar com tais questes de baixo nvel como transaes, segurana, e servios remotos, a partir de uma viso de mais alto nvel, tornando o processo de desenvolvimento mais fcil e rpido ao desenvolvedor da aplicao. Arquiteturas orientadas a servios (SOA) tem como objetivo propor um novo padro arquitetural para projetar e construir softwares complexos a partir da reutilizao de componentes de software pr-construdos e testados, chamados de servios. Nesta abordagem, as aplicaes so vistas como um conjunto de pequenos blocos denominados servios, desenvolvidos sob um determinado padro a fim de prover maior reusabilidade, facilitar sua manuteno, e se encontram acessveis dentro de uma rede de computadores. Devem prover interfaces bem definidas por meio das quais os servios so integrados uns aos outros, formando um sistema de software baseado em servios.

1.2 Objetivos
Este trabalho tem como objetivo estruturar um conhecimento bsico na rea de reuso de software enfatizando tcnicas de reuso, mais especificamente frameworks e arquiteturas orientada a servios (SOA), a fim de que fornecesse os conhecimentos necessrios para melhorar o processo de desenvolvimento de um software de automao bancaria implementado em Java e em futuras aplicaes da empresa. Entende-se que o reuso de software aplicvel no desenvolvimento de sistemas a partir de solues previamente desenvolvidas e armazenadas, ao invs de desenvolver um projeto desde o incio como se costuma fazer em abordagens convencionais.

1.3 Motivaes
Quando se trabalha na indstria de software busca-se sempre uma maior qualidade e produtividade no processo de desenvolvimento do produto. Existem muitas solues existentes a fim de melhorar este processo de desenvolvimento, como mtodos orientados a objetos, engenharia reversa, ferramentas CASE, qualificao de software, entre outras. O alto dinamismo com que as tecnologias atuais vm apresentando, dificulta o desenvolvimento de software onde a rapidez de entrega juntamente com um produto de

qualidade cada vez mais exigida. Dessa forma, isto tudo faz com que o reuso de software seja uma opo para se manter gil com qualidade. Entretanto os ganhos de produo com a prtica do reuso no so imediatos e nem em curto prazo, pois desenvolver para reuso requer uma nova maneira de se trabalhar entre os desenvolvedores e requer mudanas tcnicas, que implicam em custos e tempo para que os efeitos de qualidade e produtividade almejados apaream.

1.4 Organizao do texto

Os captulos seguintes fazem uma descrio bsica do que o reuso de software, desafios, como aplicar o reuso em processos de desenvolvimento de software, e mostra tcnicas de reuso de software. As tcnicas de reuso de software consistem em basicamente no reaproveitamento de partes previamente desenvolvidas, qualificadas e armazenadas. Existem vrias tcnicas de reuso como programao orientada a objetos, padres de projeto, frameworks, engenharia de software baseada em componentes, entre outros. Entretanto esta monografia apresentar somente as tcnicas de reuso baseada em frameworks e arquiteturas orientadas a servios. O captulo sobre atividades realizadas descreve sobre como as tcnicas apresentadas nesta dissertao foram usadas no desenvolvimento de uma arquitetura de software modular e multicamadas, o sistema Opus ibank. A parte final desta monografia contm um relato pessoal de experincias obtidas no ambiente de trabalho do estgio, e sua relao com o curso do bcc.

Parte II Conceitos, Tecnologias Estudadas e Resultados

Captulo 2: Conceitos de Reuso de Software Captulo 3: Frameworks: Reuso e Aplicaes Captulo 4: Arquiteturas Orientadas a Servios (SOA) Captulo 5: Atividades realizadas, Resultados obtidos e Concluses

Captulo 2
Conceitos de Reuso de Software
2.1 Introduo
A preocupao e os esforos empregados para melhorar os processos de desenvolvimento de software, buscando aumento da produtividade, qualidade e reduo de custos e esforos evidenciam novas perspectivas para o processo de desenvolvimento de software. O reuso uma soluo a ser considerada, pois provoca um impacto na qualidade, produtividade e custo do software. O reuso de software surgiu inicialmente por uma necessidade de economizar recursos de hardware. H algumas dcadas atrs no havia memria suficiente nos dispositivos para armazenar muitas rotinas e ento, foi observado que era possvel executar tarefas similares atravs de uma nica sub-rotina parametrizada, e assim no desperdiar o uso da escassa memria disponvel. Com a evoluo dos componentes de hardware e a conseqente reduo de preo, o reuso de software mudou de foco. Desde ento o principal objetivo do reuso economizar recursos humanos no desenvolvimento e no mais de hardware, at porque recursos humanos se tornaram muito mais dispendiosos. Este captulo trata ento de apresentar os conceitos bsicos sobre reuso de software encontrados na literatura. Primeiramente, so revistas algumas definies sobre reuso de software. Logo aps so apresentados benefcios e desafios decorrentes da adoo de reuso no processo de desenvolvimento, abordagens de reuso e por fim o captulo termina com uma descrio de como o reuso pode ser inserido no processo de produo de um software atravs da anlise de dois modelos de processos, o modelo em cascata e o modelo espiral, na perspectiva de reuso de software.

2.2 Definies
Reuso de software o uso de conceitos, produtos ou solues previamente elaboradas ou adquiridas para criao de um novo software, visando melhorar significantemente a qualidade e a produtividade do software. Reusar um produto significa poder reusar partes de um sistema desenvolvido anteriormente como: especificaes, mdulos de um projeto, arquitetura e cdigo fonte.

Reusabilidade uma medida da facilidade em se utilizar os conceitos e produtos em novas situaes.

2.3 Benefcios e Desafios

A construo de solues flexveis, ou seja, solues capazes de se adaptar a novos contextos de utilizao, aliada a um processo de desenvolvimento com alta produtividade requer conhecimento e disciplina. Os principais benefcios da reutilizao aceita pela maioria dos autores, so destacados abaixo: Aumento da produo com a reduo no esforo do desenvolvimento. Reduo dos custos e do prazo de entrega, pois se o esforo de desenvolvimento diminui, logo o tempo de entrega tambm diminui e a quantidade de homens hora necessria a ser pago tambm. Como as solues aplicadas foram anteriormente testadas e validadas, a probabilidade de que esteja correta ainda maior, portanto temos um aumento da qualidade do produto final. Padronizao dos produtos desenvolvidos pela empresa, pois como as solues reusveis foram desenvolvidas segundo uma padronizao pr-definida, o reuso em um sistema provoca conseqente padronizao e agilidade na manuteno das aplicaes devido a esta padronizao da arquitetura.

Embora os benefcios sejam muitas, muitos tambm so os desafios encontrados na adoo do reuso, como por exemplo: A implantao de prticas de reuso requer mudana de mentalidade das pessoas com relao ao processo de desenvolvimento deve-se desenvolver para o reuso e com o reuso. A indiferena com relao a reutilizar tem origem em razes como falta de incentivo, dvida com relao aos benefcios da reutilizao, falta de apoio por parte da gesto, entre outros. O fato da no existncia de partes previamente elaboradas para a reutilizao ou no um dos principais fatores para o impedimento. Dificuldade em compreender uma parte reusvel, seja pela falta de documentao ou complexidade do mesmo, tambm um fator para desconsiderao do reuso.

2.4 Abordagens de Reutilizao

No processo de desenvolvimento de um sistema, pode se aplicar o reuso de software em vrios momentos. Existe a possibilidade de se reusar idias, especificaes, projetos, cdigos-fonte e outros produtos nas diversas fases do processo de desenvolvimento, conforme pode ser visto na figura 1 abaixo:

Figura 1 Tipos de reuso

2.4.1 Reuso Vertical Reuso vertical o que ocorre dentro de um mesmo domnio de aplicao. O objetivo derivar um modelo genrico para ser usado dentro de um nico domnio de aplicao na criao de novos sistemas, este tipo de reuso o que ocorre em fbricas de software.

2.4.2 Reuso Horizontal O reuso horizontal tem como meta, a utilizao de partes dentro de diferentes domnios de aplicao. Como exemplo temos bibliotecas funes matemticas e manipulao de string, bibliotecas para construo de interfaces grficas, entre outras. A caracterstica principal a sua utilizao em diferentes domnios, diferente do que ocorre no reuso vertical.

2.4.3 Reuso planejado O reuso planejado a prtica sistemtica e formal do reuso onde diretrizes e procedimentos so definidos e seguidos Requer um alto grau de investimento e comprometimento gerencial, exigindo uma mudana significativa no processo de desenvolvimento de software. O exemplo que caracteriza este reuso so os modelo de maturidade de software (Capability Maturity Model - CMM) que algumas fbricas de software buscam visando uma prova de qualidade de seus softwares produzidos.

2.4.4 Reuso Composicional O reuso composicional a utilizao de componentes existentes como blocos para a construo de um novo sistema. A caracterstica principal que um novo sistema

construdo a partir da composio de componentes existentes, como exemplo temos os frameworks de componentes como Java Server Faces que apresentam um conjunto de componentes para construo de interfaces com o usurio e a tecnologia de componentes EJB para sistemas distribudos.

2.4.5 Reuso Baseado em Geradores de Cdigo Esta abordagem consiste no reuso no nvel de especificao de um sistema, atravs do emprego de geradores de cdigo ou de aplicaes. Como exemplos temos as ferramentas CASE e ferramentas UML.

2.4.6 Reuso Caixa Branca No reuso caixa branca existe a necessidade que a implementao do componente de software a ser reusado seja exposta de alguma forma. Em linguagens orientadas a objetos como Java e C++, muito comum o uso de herana para se atingir o reuso, modificando e adaptando o componente. Neste tipo de reuso preciso conhecer a implementao de algum componente de software que far parte do reuso.

2.4.7 Reuso Caixa Preta O reuso caixa-preta visa eliminar a necessidade do desenvolvedor de um conhecimento da implementao de algum componente de software que far parte do processo de reuso. Em vez disso, o reuso caixa-preta se d atravs da descrio de interfaces ou contratos bem definidos que devem ser respeitados pela implementao a ser elaborada. O esforo sempre usado na nova implementao e nunca ocorre um desperdcio tentando entender implementaes de terceiros.

2.4.8 Reuso de Cdigos Fonte Este o tipo de reuso mais utilizado na prtica, o reuso de cdigo. A maioria das ferramentas de reuso e mtodos so voltados para este tipo de reuso.

2.4.9 Reuso de Projetos Reuso de projetos oferecem um retorno maior que o reuso de cdigo. Quanto maior o nvel do componente, maior ganho se obtm, dado que os subprodutos gerados tambm sero componentes. Neste sentido, ao se reusar projetos, o reuso de cdigo ou de mdulos executveis uma conseqncia direta. O reuso de projetos realizada com bastante freqncia em orientao a objetos, os vrios trabalhos de padres de projetos refletem a praticidade deste reuso.

2.4.10 Reuso de Especificao Da mesma maneira que ocorre com projetos, quando se reutiliza uma especificao, temse, como conseqncia direta o reuso de projeto e do cdigo fonte.

2.5 Processos de desenvolvimento com reuso de software

Aps visto os princpios bsicos de reuso de software e os principais tipos de reuso existentes, resta saber como aplicar o reuso em processos de desenvolvimento de software. A seguir dois modelos de processos o modelo cascata e o modelo espiral so analisados com a perspectiva de reuso de software.

2.5.1 Modelo Cascata com Reuso de Software

O modelo cascata tem como caracterstica principal a seqencialidade das atividades, cada etapa transcorre completamente e seus produtos so vistos como entrada para a etapa seguinte, de forma que uma etapa s poder ter incio quando a anterior tiver terminado e o software entregue ao final desta seqncia linear.

- Anlise e Definio de Requisitos Nesta etapa, estabelecem-se os requisitos do produto que se deseja desenvolver, quais so suas funcionalidades, limitaes e objetivos do software. A reutilizao nesta primeira etapa do modelo por meio da utilizao de patterns pode facilitar e agilizar o ciclo, partes importantes como documentao e estudos de viabilidade podem ser comparados com os j existentes e utilizados com sucesso em projetos anteriores. Vale ressaltar nesta etapa um tipo de reuso de software que pode auxiliar, o reuso de projeto, com foco em utilizao de conhecimentos em desenvolvimentos anteriores.

Figura 2 Mostra o modelo Cascata.

- Projeto de Sistema O projeto de sistema a etapa em que se define como vai ser a arquitetura do software e a caracterizao das interfaces do sistema. A etapa de projeto representa os requisitos de uma forma que permita a codificao do produto na etapa seguinte. Nesta etapa podemos utilizar vrios tipos de reuso abordados anteriormente neste trabalho, como o reuso de arquiteturas relacionado com a arquitetura de software, reuso de projetos e reuso de especificaes, pois nesta etapa de projeto ir ser especificado o requisito de uma forma que permita a codificao do produto.

- Implementao Esta a etapa em que so criados os programas. Nesta fase onde a nfase est na codificao seguida de testes, pode se utilizar o reuso de cdigo. O reuso de cdigo pode ser em muitos dos casos onde conseguimos a maior produtividade no reuso de software. Testes j utilizados anteriormente so tambm importantes nesta fase, pois certificam mais rapidamente os mdulos gerados pelos componentes. Reuso caixa preta e reuso caixa branca podero ser aplicados nesta fase tambm.

- Teste de Sistema Concluda a etapa de codificao e de testes unitrios, comea a fase de teste do sistema. Nesta fase os patterns de testes sero muitos importantes nesta fase, pois os patterns de testes dentro de um reuso sistemtico tornam-se, com o decorrer do tempo, cada vez mais eficazes, pois existe uma reciclagem aumentando a cada projeto o nvel de maturidade dos componentes reusveis.

- Manuteno Esta etapa consiste na correo de erros que no foram previamente detectados. Vale ressaltar nesta etapa que a reviso e a modificao, aumentam a qualidade de um componente voltado para o reuso, este ciclo importante, pois assim podemos melhorar os componentes num ciclo de vida evolutivo.

2.5.2 Modelo Espiral com Reuso de Software O modelo em espiral um modelo de processo de software que prev prototipao, desenvolvimento evolutivo e cclico. Sua principal caracterstica guiar o processo de desenvolvimento com base em anlise de riscos e um planejamento que realizado durante toda evoluo do desenvolvimento. So exemplos de riscos: pessoas que

abandonam a equipe de desenvolvimento, ferramentas que no podem ser utilizadas, entre outras. O modelo espiral descreve um fluxo de atividades cclico e evolutivo constitudo de quatro quadrantes. Vamos descrev-los utilizando uma abordagem voltada ao reuso de software.

- Primeiro quadrante No primeiro quadrante devem ser determinados os objetivos, solues alternativas e restries. Temos neste primeiro ciclo a possibilidade de implementao e utilizao de reuso de software, a busca de solues e restries podem ser obtidas atravs de experincias de projetos anteriores ou mesmo de projetos em desenvolvimento, portanto podemos aplicar neste primeiro quadrante o reuso de projetos.

- Segundo quadrante No segundo quadrante devem ser analisados devem ser analisados os riscos de das decises do estgio anterior. Durante este estgio podem ser construdos prottipos ou realizarem simulaes de software. Os Prottipos podem ser construdos a partir de procedimentos realizados anteriores, entretanto a importncia deste quadrante porque podemos alimentar o processo de desenvolvimento com novas e atualizadas informaes.

- Terceiro quadrante O terceiro quadrante consiste nas atividades da fase de desenvolvimento, incluindo especificao, design, codificao e verificao. Nesta fase podemos utilizar vrios tipos de reuso de software. O reuso de idias para uma busca de solues genricas para uma classe de problemas, reuso de cdigo para auxiliar a fase de implementao, reuso composicional para desenvolver partes de software a partir da composio de componentes desenvolvidos e validados anteriormente e o reuso baseado em geradores de cdigo que consiste basicamente na utilizao de geradores de cdigos e aplicaes.

Figura 3 Modelo espiral

- Quarto quadrante Por ultimo o quarto quadrante compreende as etapas anteriores e o planejamento da prxima fase. Neste planejamento, dependendo dos resultados obtidos nos estgios anteriores como decises, anlise de riscos e verificao, pode-se optar por seguir o desenvolvimento num modelo cascata. Por exemplo, se j no primeiro quadrante, os requisitos forem completamente especificados e validados pode-se optar por seguir o modelo cascata, caso contrrio, pode-se optar pela construo de novos prottipos, incrementando-o, avaliando novos riscos e re-planejando o processo.

Este captulo abordou a importncia do reuso de software, alm de apresentar os vrios tipos de abordagens de reuso existentes, e apresentou como o reuso pode ser integrado no processo de desenvolvimento de um produto de software. Apesar de apresentados dois modelos de desenvolvimento, no existe um modelo para o qual possamos dizer ser o modelo ideal, porm pelo estudo do tema o reuso de software pode ser associado como

uma maneira complementar ao desenvolvimento de software independente do modelo, provendo qualidade e agilidade. O prximo captulo trata de mostrar uma tcnica de reuso, que so a utilizao de frameworks e padres para construo de arquiteturas de software. O captulo sobre frameworks tratar ento de mostrar em maiores detalhes um pouco de teoria sobre frameworks, alm de mostrar uma parte prtica tambm sobre alguns frameworks como o Java Server Faces, Hibernate e Spring.

Captulo 3
Frameworks: Reuso e Aplicaes
3.1 Introduo
Um componente representa reuso de cdigo, um texto representa reuso de design ou reuso de projeto, comparando-se essas duas abordagens de reuso, o reuso de projeto mais importante que reuso de cdigo, uma vez que pode ser aplicada em um nmero maior de contextos e mais comum. A idia de reuso tem muitas motivaes, as principais so diminuir custos, tempo e esforo de programao, no processo de desenvolvimento de um software. Neste contexto os frameworks surgem como uma tcnica de reuso intermediria, ela parte reuso de cdigo e parte reuso de projeto, ou seja, com os frameworks, reutilizam-se no somente linhas de cdigo, mas tambm a arquitetura do domnio de aplicao ao qual ele atende. Frameworks so utilizados em diversas reas como em interfaces grficas com usurio (GUI), editores de texto, sistemas operacionais, sistemas distribudos, software para avies, entre outros. Este captulo visa, por meio de uma pesquisa bibliogrfica, apresentar reuso no contexto de frameworks, conceituando o que so frameworks, apresentando suas caractersticas gerais, formas de classificao, benefcios e desvantagens envolvendo o uso deles e apresenta tambm uma comparao com outras formas de reuso. Depois de apresentada um pouco de teoria, este captulo finaliza mostrando uma parte mais prtica, atravs da apresentao de trs exemplos de frameworks orientado a objetos open-source, que so o framework MVC Java Server Faces, o framework de persistncia Hibernate e o framework de inverso de controle Spring, descrevendo os principais conceitos computacionais envolvendo eles, os problemas aos quais pretendem resolver e um pouco de sua funcionalidade atravs de exemplos.

3.2 O que um Framework?

Um Framework orientado a objetos um conjunto de classes e interfaces que incorpora um projeto abstrato. Ele prov uma infra-estrutura genrica para construo de aplicaes dentro de uma famlia de problemas semelhantes, de forma que esta infra-estrutura genrica deve ser adaptada para a gerao de uma aplicao especfica. O conjunto de classes que forma o framework deve ser flexvel e extensvel para permitir a construo

de vrias aplicaes com pouco esforo, especificando apenas as particularidades de cada aplicao. Por exemplo, um framework para se construir diversos editores de texto poderia ser abstrado. Primeiramente toma-se o que eles tm em comum e produz-se um sistema abstrato. O framework um conjunto de classes, de uma linguagem especfica, que implementa este sistema abstrato de edio de texto. Se admitirmos que todas as classes deste sistema so abstratas, no se pode ento instanciar objetos desta classe abstrata, logo este conjunto de classes abstratas, o framework editor de texto, no um programa. Entretanto pode ser transformado em um criando-se subclasses e classes auxiliares. Como o framework uma abstrao de um editor de textos genrico, ele flexvel a mudanas, e, portanto vrios editores de texto podem ser derivados dele apenas criando-se classes, subclasses e compondo objetos de classes do framework. Como se pode ver no exemplo, um framework visa gerar diferentes aplicaes dentro de um domnio, e ele contm, portanto, uma descrio dos conceitos deste domnio. As classes abstratas do framework do exemplo servem para representar as partes de um framework que variam, que servem para ser adaptados s necessidades da aplicao, ele poderia ser, por exemplo, um mtodo de uma classe abstrata que foi deixado incompleto para que sua definio seja acabada na gerao de uma nova aplicao. Tais partes so chamadas de pontos de especializao ou Hot-Spots. Uma caracterstica fundamental dos frameworks quanto ao seu grau de reutilizao. Um desenvolvedor que utiliza linguagem C, por exemplo, usa biblioteca de funes para construir aplicaes, logo isto poderia ser classificado como reuso de rotinas. J um programador que usa a linguagem Smaltalk utiliza classes para compor suas aplicaes. Reusar classes possui, portanto, um grau de reutilizao maior que o reuso de rotinas, uma vez que com classes se reutiliza um conjunto de rotinas, bem como uma estrutura de dados(atributos). Uma caracterstica comum ao reuso de classes e rotinas que cabe ao desenvolvedor implementar como os elementos do programa se relacionam entre eles, e qual o fluxo de execuo da aplicao. Outra caracterstica comum que a reutilizao se d por reuso de componentes (rotinas ou classes) isolados, cabendo ao desenvolvedor estabelecer relaes entre eles no sistema. J o grau de reuso promovido pelo uso de frameworks superior ao grau de reuso promovido pelo reuso de rotinas e classes, por reusar um conjunto de classes interligadas ao invs de isoladas, alm de que com o uso de frameworks os mtodos especializados pelo usurio so chamados de dentro do prprio framework ao invs de ser chamado de dentro do cdigo da aplicao do usurio. Esta caracterstica presente nos frameworks chamada de inverso de controle. As figuras 4, 5 e 6 abaixo representam essas diferenas, e os objetos em cinza representam componentes implementados pelo

desenvolvedor, enquanto que os objetos em branco representam o reuso de um componente.

Figura 4 Aplicao desenvolvida totalmente

Figura 5 Aplicao desenvolvida reutilizando classes e rotinas

Figura 6 Aplicao desenvolvida utilizando um framework.

Como se pode notar na figura 6, o framework impe um modelo de colaborao, o resultado de anlise e projeto, entre os objetos ao qual deve-se adaptar. Ele prov reuso de cdigo, anlise e design, sendo que o reuso de anlise e projeto vem do fato de que, um framework representa um projeto de um sistema abstrato, previamente analisado e projetado para capturar todos as caractersticas comuns de um domnio de problema. Um framework tem por objetivo ser estendvel pela criao de subclasses e parametrizado pela aceitao de objetos de outras classes. Estas caractersticas esto presentes nos padres de projeto Template method e Strategy.

No padro de projeto Template Method, um mtodo redefinido em uma subclasse e automaticamente modifica o comportamento de um outro mtodo herdado e no redefinido. Por exemplo, um mtodo de uma superclasse abstrata poderia ter como parte de sua implementao, uma chamada a um mtodo abstrato a ser definido na subclasse e desse modo esse mtodo definido na superclasse se comportaria de maneira diferente de acordo com a implementao dada a este mtodo abstrato, por cada uma de suas subclasses. Esta tcnica utilizada para produzir sistemas em frameworks denominados caixa-branca (White-Box), onde produzimos subclasses redefinindo alguns mtodos e com isso criamos um programa concreto que pode ser executado, ou seja, em frameworks caixa-branca o reuso provido por herana. O padro Strategy permite configurar um objeto utilizando-se de um outro objeto que encapsula um algoritmo. Um objeto editor de textos ,por exemplo, pode delegar a tarefa de busca de uma palavra em um texto para outro objeto. O ponto importante que eu posso passar, em tempo de execuo ou compilao, um outro objeto que implementa um algoritmo de busca melhor sem precisar alterar o cdigo do editor de textos, ou seja, eu construo um programa a partir da composio de objetos. Esta caracterstica de composio de objetos utilizada para criao de frameworks denominados caixa-preta. O instanciador define classes, cria objetos a partir delas e os passa ao framework parametriando-o. Este tipo de framework mais fcil de ser utilizado do que os de caixa branca, pois no h herana envolvida, somente composio de objetos. O problema da herana que ela introduz dependncias entre mtodos herdados que diminui a legibilidade do cdigo.

3.3 Pontos fracos dos Frameworks

Alm dos benefcios como reuso, inverso de controle, capacidade de extenso e modularidade, vantajosos como tcnica de construo de software, ele possui tambm algumas desvantagens: Custo de aprendizagem alto : A aprendizagem de um framework leva um tempo considervel. No fcil desenvolver um framework: A construo de um framework no simples, e deve ser planejada para que o objetivo de reuso seja alcanado. Difcil depurao: A remoo de erros em um framework pode ser complicada, pois o uso de classes genricas na composio de um framework no s auxilia a abstrair os detalhes da aplicao como dificultam o processo de depurao de cdigo, pois no podem ser depurados separadamente da parte especifica da aplicao.

Documentao: No chega a ser um grave problema desde que o framework possua uma boa documentao. Uma documentao deficiente representa um verdadeiro desafio na utilizao do framework.

A figura abaixo ilustra um resumo das vantagens e desvantagens. Ainda que se tenha algumas desvantagens, as vantagens so ainda maiores o que justia o seu uso como tcnica de construo de software.

Figura 7 Custo x Benefcios do uso de frameworks. (Fonte: Sauv, [15])

3.4 Comparao com outras formas de reuso

Comparando-se frameworks com bibliotecas de rotinas, nas bibliotecas os componentes se apresentam isolados, eles so independentes uns dos outros, enquanto que num framework o conjunto de classes que forma o framework se coopera entre si. Outra diferena que em uma biblioteca, cabe ao desenvolvedor a chamada de rotinas e determinar com ser o fluxo de execuo do programa, enquanto que num framework h inverso de papis, ele quem determina a estrutura geral do programa e qual o fluxo de execuo dele, cabe ao desenvolvedor especializar somente os componentes que contm regras de negcio especificas ao domnio de aplicao do problema.

Figura 8 Comparao entre um framework e biblioteca de rotinas. (Fonte: Sauv, [15])

Comparando-se padres de projeto com frameworks, os padres se caracterizam por serem mais abstratos do que os frameworks, pois um framework um software, possui uma implementao, enquanto que um padro representa conhecimento e experincia sobre um projeto (Um framework possui uma forma fsica, j um padro representa uma forma abstrata, uma idia, uma soluo). Outra diferena que um padro menor do que um framework, pois geralmente a implementao de um padro composta por duas ou trs classes, j um framework engloba um conjunto bem maior de classes e formado por um conjunto de padres. Padres de projeto so menos especializados que frameworks, pois os frameworks so desenvolvidos para um domnio de aplicao especfico, j os padres podem ser usados em diversos domnios.

3.5 Tipos de Frameworks

Frameworks podem ser classificados em dois grupos: framework de aplicao orientado a objetos e framework de componentes. Frameworks de aplicao orientado a objetos geram aplicaes orientadas a objetos. Seus pontos de extenso so definidos como classes abstratas ou interfaces, que podem ser estendidas ou implementadas para compor uma instancia da aplicao. Alm disso, frameworks de aplicao orientada a objetos so classificados quanto ao seu escopo em

frameworks de infra-estrutura de sistemas, frameworks de integrao de middleware e frameworks de aplicao corporativa.

Frameworks de infra-estrutura de sistemas visam simplificar o processo de desenvolvimento de sistemas dando uma infra-estrutura bsica e modular para compor aplicaes como sistemas operacionais e ferramentas de processamentos de linguagens, so exemplos de frameworks de infra-estrutura o Java Server Faces, Spring e o Hibernate. Tambm so conhecidos como frameworks horizontais, a figura 9 ilustra esta categoria onde o enfoque maior ocorre na parte da generalizao, isto significa que este tipo de framework visa atender a um nmero de domnios de aplicaes maior, resolvendo apenas uma parte do problema da aplicao.

Figura 9 Framework de infra-estrutura ou Horizontal (Fonte: Sauv, [15]).

Frameworks de integrao de middleware so usados para integrar aplicaes e componentes distribudos. Estes frameworks escondem o baixo nvel da comunicao entre componentes distribudos, possibilitando que os

desenvolvedores trabalhem em um ambiente distribudo de forma semelhante a que trabalham em um ambiente no distribudo. So exemplos de frameworks de integrao de middleware Java RMI e frameworks ORB (Object Request Broker).

Frameworks de aplicaes corporativas, ao contrrio dos frameworks de infraestrutura e de integrao de middleware, so voltados para um domnio de aplicao mais especfico, como por exemplo, os domnios da aviao,

telecomunicaes e financeiro. Tambm so conhecidos como frameworks verticais, a figura 10 ilustra esta categoria. Enquanto que nos frameworks horizontais se busca a generalidade do domnio, os verticais buscam o detalhe ao nvel das aplicaes, correspondendo uma parte maior do framework utilizado, como pode se analisar na figura 10 abaixo.

Figura 10 Framework de aplicao corporativa ou Vertical (Fonte: Sauv, [15]).

Finalmente, um framework de componentes uma entidade de software que prov suporte a componentes que seguem um determinando modelo e possibilita que instncias destes componentes sejam plugadas no framework de componentes. Ele estabelece as condies necessrias para um componente ser executado e regula a interao entre as instncias destes componentes. So exemplos de frameworks de componentes temos o Tapestry e o Java Server Faces. A principal diferena entre frameworks de aplicao orientado a objetos e framework de componentes que, enquanto frameworks de aplicaes definem uma soluo inacabada que gera uma famlia de aplicaes, um framework de componentes estabelece um contrato para plugar componentes. A figura 11 mostra como pode ser feita a combinao de frameworks para criar uma aplicao, a idia que frameworks do tipo infra-estrutura, middleware e componentes sirvam de base sobre a qual se apiam os verticais, uma vez que os primeiros tm uma preocupao maior na generalidade de domnio visando atender a um nmero maior de

aplicaes, enquanto que os verticais so especialistas em um domnio e usam da infraestrutura provida pela base.

Figura 11 Combinao de frameworks

3.6 Anlise do Framework Horizontal MVC: Java Server Faces

A camada de apresentao em uma aplicao multicamadas tem como objetivo expor a lgica de negcios ao usurio, alm de fornecer uma interface para interao do usurio com a aplicao. Em aplicaes que utilizam o navegador como interface de interao com o usurio esta camada costuma ser chamada de camada web. Atualmente muitos frameworks existentes para a camada web implementam o padro de arquitetura Model View Controller (MVC), um exemplo o framework Java Server Faces, que tambm um framework de componentes e de infra-estrutura. Framework web um bom estudo de caso, pois um excelente exemplo da aplicao de vrios Design Patterns (como Command, Template Method, Factory Method, Adapter, Composite), desse modo seu estudo se mostra interessante do ponto de vista computacional. Para se entender o motivo da adoo do padro MVC em frameworks web, deve-se entender primeiramente as vantagens e desafios decorrentes do uso de interfaces HTML.

3.6.1 Interfaces WEB

As interfaces web utilizam a linguagem HTML no desenvolvimento de interface com o usurio para aplicaes web. Algumas das principais vantagens do uso de interfaces web so as seguintes: As aplicaes web so instaladas no servidor e o usurio usa o navegador instalado em seu computador e, portanto, no necessita que novas aplicaes sejam instaladas na mquina do cliente. Na maioria das empresas firewalls so configurados para liberar o trafego de rede na porta utilizada pelo servidor de paginas HTML, diminuindo o esforo para configurao. Impe restries de configurao de hardware mais modestas nas maquinas dos clientes j que a maior parte do processamento ocorre no lado servidor.

Contudo tambm so impostos uma serie de desafios, dentre eles: Interfaces com o usurio costumam mudar freqentemente sem que a lgica de negcios mude necessariamente. O modelo de requisio e resposta impede que a camada de apresentao seja notificada de mudanas no modelo, diferentemente do que ocorre em interfaces para aplicaes desktop onde um componente de interface pode ser

imediatamente atualizado assim que ocorra uma mudana no modelo. necessrio separar o cdigo de layout esttico do cdigo gerado

dinamicamente. Requisies http carregam parmetros do tipo String que precisam ser convertidos em tipos mais especficos da aplicao, alm de necessitarem de validao. HTML oferece um conjunto limitado e no expansvel de componentes de interface. Questes de desempenho e concorrncia devem ser consideradas, pois impossvel prever o nmero de usurios acessando uma aplicao web simultaneamente.

O desenvolvimento de aplicaes em camadas contribui para a soluo de alguns destes desafios, pois como uma camada s depende de outra imediatamente inferior, com isso a camada de apresentao pode ser alterada sem que a de negcios sofra modificaes, alem do que cada camada pode ser testada, depurada e otimizada isoladamente.

Contudo apenas a diviso em camadas no basta para solucionar estes problemas. Para que isto ocorra necessrio que a camada de apresentao seja limpa, isto , o fluxo de controle e a chamada a mtodos de negcios so separados da viso, pois se o cdigo

para a interface grfica muito acoplado ao cdigo de negcios da aplicao,

construo de uma nova interface de apresentao implicaria na replicao de cdigo das regras de negcios, uma vez que tais regras estavam acopladas a interface de apresentao anterior. Para que a camada de apresentao seja separada da camada de negcios, ou seja, para que o fluxo de controle da aplicao e a chamada a mtodos de negocio seja separada da viso usa-se o padro de arquitetura Model View Controller (MVC) apresentado na prxima seo.

3.6.2 O padro Model View Controller (MVC)

O padro de arquitetura MVC divide os elementos da camada de apresentao em viso (View), que recebe a entrada do usurio e exibe o resultado da operao, Controlador (Controller), que acessa a camada de negcios manipulando o modelo e selecionando a viso apropriada, e o Modelo (Model) objeto que contm a lgica de negcios do domnio da aplicao e que prov dados para a viso. A figura 13 abaixo ilustra como esta caracterizada o modelo MVC no framework Java Server Faces.

Figura 13 MVC no Java Server Faces

Embora seja possvel implementar uma soluo que implante o MVC, h vrios frameworks que trazem esta estrutura alm de tratarem de alguns dos desafios da seo 3.6.1, dentre eles o Java Server Faces (JSF) utilizado no sistema Opusibank, estes frameworks que trazem esta estrutura de MVC so comumente chamados de frameworks MVC ou frameworks web.

3.6.3 Frameworks Web

Figura 14 Caracterstica Geral de Execuo dos Frameworks web

Consultando a web pode se ver que existem aproximadamente cerca de 54 frameworks open-source existentes para o desenvolvimento web em plataforma Java atualmente (http://www.manageability.org/blog/stuff/how-many-java-web-frameworks/view), isso sem levar em conta os frameworks comerciais que existem tambm. As maiorias destes frameworks implementam o modelo MVC de forma muito similar e tm caractersticas comuns que visam solucionar alguns dos problemas listados na seo 3.6.1. Este comportamento comum descrito a seguir. Estes frameworks usualmente trazem o controlador do MVC pronto, implementado atravs de um servlet (Servlets so classes/objetos que funcionam como programas CGI) que deve ser configurado ao instanciar o framework. O controlador implementado geralmente atravs do padro de projeto Front Controller(Fowler, 2002) e sua funo mapear requisies para classes de instancia que implementam o padro de projeto Command (gamma et al., 1994). Esta instancia do Command responsvel pela construo da viso com a ajuda de componentes fornecidos pelo framework. J o modelo utilizado pela instncia e no deve possuir nenhum tipo de dependncia com o framework escolhido, pois ele utilizado em outras camadas, dessa forma aumentamos a modularidade da aplicao e facilitamos a manuteno uma vez que alteraes de cdigo esto localizados em um nico ponto de extenso. Cabe ao Controlador extrair os parmetros da requisio, que so do tipo String e converte-los para tipos mais especficos da aplicao que podem ser desde tipos primitivos como inteiros e boleanos a objetos do modelo, e valid-los. Em caso de erro de validao, o controlador exibe novamente a viso que causou o erro. Quando no ocorre erro de validao, o controlador chama o comando que aciona a camada de negcios

para modificar o modelo. Terminada a operao, o comando sinaliza para o controlador qual a viso deve ser exibida e este finaliza a requisio montando a viso. A figura 14 ilustra o funcionamento descrito acima, na figura esto presentes muito dos padres de projeto aplicados na camada de apresentao e na camada de negcios.

3.6.4 O Framework Java Server Faces (JSF)

Java Server Faces um framework MVC que difere dos outros existentes por ser tambm um framework de components, pois define um modelo de componentes para serem usados na camada de apresentao. Existem trs tipos principais de componentes no JSF: Componentes de Interface, usados para compor a interface com o usurio, como caixas de texto e campos de seleo de valor.

Figura 15 Componente calendrio

Figura 16 Componente Menu

Componentes de converso de dados, chamados de Converter. Componentes para validao de dados, usados para validar a entrada do usurio, chamados de Validator.

Os comandos (padro Command conforme descrito na figura acima) recebem o nome de backing beans ou managed beans em jsf. Estes no precisam implementar interfaces especificas ou estender classes, bastando que o mtodo do comando seja publico e no receba parmetros. A cada componente de interface de usurio associado um backing bean que manipula o estado deste componente e acessa a camada de negcios. Em jsf o controlador do mvc j vem implementado como um servlet conforme descrito na listagem 1 abaixo, o servlet controlador est declarado entre as linhas 2-5:

01: <web-app> 02: <servlet> 03: <servlet-name>Faces Servlet</servlet-name> 04: <servlet-class>javax.faces.webapp.FacesServlet</servlet-class> 05: </servlet> 06: <servlet-mapping> 07: <servlet-name>Faces Servlet</servlet-name> 08: <url-pattern>*.jsf</url-pattern> 09: </servlet-mapping> 10: </web-app>
Listagem 1 Arquivo web.xml contendo definies do controlador do jsf

A listagem 2 mostra um exemplo de uma pagina jsf.

11: 12: 13: 14: 15: 16: 17: 18: 19: 20: 21: 22: 23: 24: 25: 26: 27: 28: 29: 30: 31: 32: 33: 34: 35: 36: 37: 38: 39: <%@taglib uri="http://java.sun.com/jsf/core" prefix="f" %> <%@taglib uri="http://java.sun.com/jsf/html" prefix="h" %> <f:view> <html> <head> <title>Pagina Envio de Formulrio</title> </head> <body> <h:form> <h:messages/><br> Curso: <h:selectOneListbox value="#{CursoBean.idCategoria}" required="true"> <f:selectItem itemLabel="BCC" itemValue="1"/> <f:selectItem itemLabel="MAC" itemValue="2"/> <f:selectItem itemLabel="MAT" itemValue="3"/> </h:selectOneListbox><br> Assunto: <h:inputText value="#{CursoBean.message.subject}" size="83" maxlength="100" required="true"> <f:validateLength minimum="10"/> </h:inputText><br> Mensagem: <br> <h:inputTextarea value="#{CursoBean.message.text}" rows="15" cols="60" cols="65" rows="16" required="true"/> </h:form> </body> </html> </f:view>

Listagem 2 Exemplo Pgina de Envio De Formulrio (JSF)

Na listagem 2 acima expresses delimitadas por #{ e } demarcam o uso da linguagem de expresses do JSF e servem para criar vnculos de um componente com uma classe Java que trata de manipular o estado deste componente. O item entre as linhas 22 e 27 delimita um componente do tipo lista onde apenas um item pode ser selecionado. O

atributo value na linha 22 vincula o valor do item selecionado a propriedade idCategoria do backing bean CursoBean. Ainda na linha 22, o atributo required=true demarca que o atributo requerido, gerando regras de validao automaticamente. A linha 31 indica uma validao de tamanho mnimo, indicando que o campo associado a esta s ser vlido se tiver um tamanho mnimo de 10 caracteres. atravs do arquivo XML de configurao do JSF que so configurados casos de navegao, backing beans, componentes de validao e de converso de tipos. A Listagem 3 exibe um exemplo deste arquivo, que tem como nome padro facesconfig.xml.

40: <faces-config> 41: <navigation-rule> 42: <from-view-id>/formulario.jsp</from-view-id> 43: <navigation-case> 44: <from-outcome>success</from-outcome> 45: <to-view-id>/formularioSuccess.jsp</to-view-id> 46: </navigation-case> 47: <navigation-case> 48: <from-outcome>failure</from-outcome> 49: <to-view-id>/formularioFailure.jsp</to-view-id> 50: </navigation-case> 51: </navigation-rule> 52: <managed-bean> 53: <managed-bean-name>CursoBean</managed-bean-name> 54: <managed-bean-class>CursoBean</managed-bean-class> 55: <managed-bean-scope>request</managed-bean-scope> 56: </managed-bean> 57: </faces-config>
Listagem 3 arquivo de configurao faces-config.xml

Entre as linhas 41 e 51 so declarados dois casos de navegao a partir da pgina /formulario.jsp. O caso entre as linhas 43 e 46 executado quando a operao executada com sucesso enquanto que o caso entre as linhas 47 e 51 executado quando ocorre algum erro durante a execuo da operao. O backing bean declarado entre linhas 52 e 57. Na linha 53 o nome do backing bean definido, enquanto que na linha 54 configurada a classe. A Listagem 4 exibe o cdigo fonte deste backing bean.

58: public class CursoBean { 59: private String idCategoria; 60: private Message message; 61: 62: public void setIdCategoria (String newValue) {this.idCategoria = newValue; } 63: public String getIdCategoria () { return idCategoria; } 64: public void setMessage(Message message) { message = newValue; } 65: public Message getMessage() { return message; } 66: 67: public String postMessage() { 68: try { 69: CursoFacade facade = new CursoFacadeImpl(); 70: FacesContext ctx = FacesContext.getCurrentInstance(); 71: String curso = ctx.getExternalContext().getRemoteUser(); 72: facade.postMessage(curso, idCategoria, message); 73: } catch (Exception e) { 74: return "failure"; 75: } 76: return "success"; 77: } 78: }
Listagem 4 Backing Bean

3.7 Anlise do Framework Horizontal de Persistncia: Hibernate

A maior parte dos sistemas existentes hoje requer em alguma fase de implementao do projeto que seus dados sejam persistidos de alguma forma. A forma mais comum de realizar isto persistir dados atravs de um sistema de gerenciamento de banco de dados (SGBD) relacional. Em Java o modo mais baixo nvel de se enviar comandos ao SGBD atravs da API Java Database Connectivity (JDBC). Com o JDBC uma aplicao Java consegue enviar comandos SQL para o SGBD e assim efetuar operaes de consulta, atualizao, remoo e insero de dados. A fim de separar os comandos SQL do cdigo que realiza alguma lgica de negcio com os dados provenientes de uma consulta, o cdigo JDBC (o que realiza operaes de

consulta ao SGBD) fica responsvel por realizar a converso de dados provenientes do SGBD em classes orientadas a objeto escritas em Java, fornecendo um modo OO de ver entidades do banco de dados relacional. Entretanto escrever cdigo de acesso ao banco de dados, realizando as converses necessrias do paradigma relacional para o paradigma OO uma tarefa desgastante, repetitiva e algumas vezes propensa a erros devido a diferena entre estes dois paradigmas. nesse contexto que entra o framework de mapeamento objeto/relacional Hibernate. O termo mapeamento objeto relacional um nome dado para frameworks capazes de realizar a persistncia automtica e transparente de classes de uma aplicao em tabelas de banco de dados relacionais, transformando a representao de dados de um paradigma para outro. Para melhor entendermos o Hibernate preciso entender primeiro o conflito entre os paradigmas OO e relacional, que ele se prope a mediar.

3.7.1 O Paradigma OO x Relacional

Ao mudar de um paradigma para outro surgem problemas que devem ser resolvidos. Dentre eles, temos: a questo dos relacionamentos e a questo do grafo de navegaes. A questo dos relacionamentos surge a partir da diferena entre estas duas de se representar relacionamentos. Relacionamentos em orientao a objetos so expressos atravs de referncias a objetos ou colees de objetos. J no paradigma relacional os relacionamentos so expressos atravs de chave estrangeira. Outra diferena que em OO os relacionamentos so direcionais, ou seja, so definidos de uma classe para outra. Para criar um relacionamento bidirecional preciso definir dois relacionamentos unidirecionais, um em cada uma das classes envolvidas. A noo de direo no existe no paradigma relacional. Alm disto, classes em OO podem ser definidas tendo relacionamento entre objetos de 1 para 1, 1 para n e m para n, enquanto que no paradigma relacional relacionamento para n so feitos atravs de uma tabela extra, que no aparece no modelo OO. E finalmente a questo do grafo de navegaes. Na figura abaixo temos um diagrama UML representando uma associao de unidirecional de 1 para 1 entre a classe Endereo e a classe Usurio.

Figura 17 Diagrama de classes para exemplificar o problema do grafo de navegaes

A questo do grafo de navegao vem do fato de que no paradigma OO, a forma natural de acessar dados em objetos relacionados atravs da tcnica onde se navega de um objeto para outro atravs de mtodos get, por exemplo, para se obter o endereo de um usurio sobre um objeto do tipo Endereo eu tenho que fazer

endereo.getUser().getNome(). Apesar de simples esta no a forma mais eficiente de obter dados em um SGBD relacional e pode levar ao problema do n + 1 select problem (King & Bauer, 2005) onde para cada navegao no grafo de objetos realizada uma consulta na base de dados. medida que os relacionamentos entre objetos se tornam mais complexos e a quantidade de dados aumenta, recuperar o grafo de objetos de uma vez s implicar em problemas de performance e escalabilidade. A questo do grafo de navegaes envolve ento determinar qual poro do grafo deve ser recuperada imediatamente e qual deve ser recuperada sob demanda. Portanto como pode se ver so muitas as questes envolvidas quando se quer converter um objeto em tabelas, esta tarefa repetitiva e independente do domnio de aplicao, logo favorvel aplicao de frameworks. Nos itens seguintes ento veremos como o Hibernate trata destas questes.

3.7.2 Um Exemplo com o Hibernate

Para melhor entender o Hibernate esta seo apresenta um exemplo que ilustra o funcionamento deste framework. O modelo de objetos a ser persistido escolhido o apresentado na figura 18 abaixo.

Figura 18 Diagrama de classes do exemplo entre Funcionrio e Empresa.

A implementao das classes Funcionrio e Empresa so feitas como Java beans sem quaisquer dependncias com classes ou API do Hibernate. As listagens abaixo exibem o cdigo fonte das classes Funcionrio e Empresa.

01: public class Funcionario { 02: 03: 04: 05: 06: 07: 08: }
Listagem 5 Classe Funcionrio

09: public class Empresa { 10: 11: 12: 13: 14: 15: private Long idEmpresa; private String nome; private String informacoes; /* Mtodos get/set */ () }

private Long idFuncionario; private String nome; private String dados; private Empresa empresa; /* Mtodo get/set */ ( )

Listagem 6 Classe Empresa

A configurao com do Hibernate deve ser feita em um arquivo chamado hibernate.cfg.xml e este arquivo definido conforme a listagem abaixo.

16: (.. ) 17: <hibernate-configuration> 18: <session-factory> 19: <property name="connection.datasource"> (.) </property> 20: <property name="dialect">org.hibernate.dialect.MySQLDialect</property> 21: <mapping resource="Funcionario.hbm.xml"/> 22: <mapping resource="Empresa.hbm.xml"/> 23: </session-factory> 24: </hibernate-configuration>
Listagem 7 Arquivo hibernate.cfg.xml de Configurao do Hibernate

Neste arquivo a linha 18 inicia a seo que configura um SessionFactory responsvel pela criao de sesso no Hibernate, que so objetos do tipo Session. A sesso de Hibernate, tambm chamada de gerenciador de persistncia, pode ser vista como um gerenciador de objetos relacionados a uma mesma unidade de trabalho. Uma sesso capaz de inserir, consultar, atualizar e remover objetos assim como detectar mudanas nos objetos pertencentes a unidade, atualizando seus estados persistentes quando a sesso fechada. A sesso um objeto leve, ou seja, no ocupa muito espao em memria e no leva muito tempo para ser criado e destrudo.Geralmente objetos sesso possuem um tempo de vida curto. Na linha 19 configurado um DataSource, que um objeto que prov conexes com o banco de dados. A linha 20 define um dialeto, que define para qual banco de dados o Hibernate deve gerar comandos SQL, e justamente esta uma das caractersticas principais de Hibernate o suporte a diversos tipos de banco de dados relacionais, ou seja, com o Hibernate eu obtenho um sistema independente de banco de dados atravs deste

framework, e conforme veremos adiante as consultar ao SGBD so feitas via uma sintaxe padro do Hibernate, o HQL (Hiberntae Query Language). Por ltimo, nas linhas 21-22 definido o nome dos arquivos de metadados de mapeamento para, respectivamente, as classes Funcionrio e Empresa. Atravs destes arquivos o Hibernate realiza o mapeamento de objetos em tabelas. As listagens 8 e 9 seguintes mostram estes mapeamentos.
25: (..) 26: <hibernate-mapping> 27: <class name="Empresa" table="EMPRESA"> 28: <id name="idEmpresa" column="ID_EMPRESA" type="long"> 29: 30: </id> 31: <property name="nome" type="string" column="NOME" length="50" 32: not-null="true"/> <generator class="native"/>

33: <property name="informacoes" type="string" column="INFORMACOES" 34: 35: </class> 36: </hibernate-mapping>
Listagem 8 Arquivo Empresa.hbm.xml de Mapeamento Objeto Relacional

length="100"/>

A linha 27 indica que este arquivo se refere ao mapeamento da classe Empresa na tabela EMPRESA. Entre as linhas 28-30 so definidas as caractersticas do identificador do objeto, de modo similar a propriedade idEmpresa da classe Empresa associada chave primaria ID_EMPRESA da tabela EMPRESA. Entre as linhas 31-34 continuado o mapeamento entre atributos de uma classe e campos de uma tabela, no caso dos atributos nome e informaes da classe Empresa para os campos NOME e INFORMACOES da tabela EMPRESA.
37: <hibernate-mapping> 38: <class name=Funcionario" table="FUNCIONARIO"> 39: <id name="idFuncionario" column="ID_FUNCIONARIO" type="long"> 40: <generator class="native"/>

41: </id> 42: <property name="nome" type="string" column="NOME"/> 43: <property name="dados" type="string" column="DADOS"/> 44: <many-to-one name="empresa" class="Empresa" column="ID_EMPRESA" 45: 46: </class> 47: </hibernate-mapping> Listagem 9 - Arquivo Funcionario.hbm.xml de Mapeamento Objeto Relacional not-null="true" cascade="save-update"/>

Neste arquivo a classe Funcionrio mapeada para a tabela FUNCIONARIO. Cada uma das propriedades de Funcionrio como idFuncionario, nome e dados so mapeados para, respectivamente, as colunas ID_FUNCIONARIO, NOME e DADOS. O trecho entre as linhas 44-46 define o relacionamento entre as classes Funcionrio e Empresa. O relacionamento entre as duas classes definido como muitos para um no sentido de Funcionrio para Empresa, sendo que o campo ID_EMPRESA definido na linha 44 indica que este o nome da chave estrangeira armazenada na tabela FUNCIONARIO que referencia a tabela EMPRESA. O atributo not-null configurado como true para indicar que o relacionamento obrigatrio e o atributo cascade configurado como save-update na linha 45 para indicar que as operaes de insero e atualizao de entidades devem ser realizadas tambm para as instancias relacionadas. Feitas todas as configuraes, o prximo passo usar a API do Hibernate para realizar operaes de insero, consulta, atualizao e remoo. Na listagem abaixo irei mostrar apenas a operao de insero.

48: public class OperacaoInsercao { 49: public static void main(String[] args) { 50: SessionFactory sfactory = null; 51: Session sess = null; 52: Transaction tx = null; 53: try { 54: sfactory = new Configuration().configure().buildSessionFactory(); 55: sess = sfactory.openSession(); 56: tx = sess.beginTransaction(); 57: Empresa empr = new Empresa(); 58: empr.setNome(Empresa X); 59: Funcionario func = new Funcionrio(); 60: func.setNome(Alexandre ); 61: func.setEmpresa(empr); 62: sess.save(funcionario); 63: tx.commit(); 64: sess.close(); 65: } catch (Exception e) { 66: try { 67: tx.rollback(); 68: sess.close(); 69: } catch (HibernateException e1) { } 70: e.printStackTrace(); 71: } 72: } 73: }
Listagem 10 Operao de Criao com o Hibernate

As linhas 52 e 56 definem e inicializam uma varivel do tipo Transaction. A interface Transaction representa uma abstrao de transaes, atravs desta podem ser usadas transaes JDBC ou JTA. As transaes podem ser configuradas via o arquivo hibernate.cfg.xml mostrado anteriormente.

Entre as linhas 57 e 61 um objeto Empresa e um objeto Funcionario so criados e inicializados. Na linha 61, o relacionamento entre os dois objetos configurado. Na linha 62 o objeto salvo na sesso. Finalmente, a transao confirmada na linha 63 e a sesso fechada na linha 64. Como o atributo cascade do relacionamento definido como save-update (linha 45 da listagem 9), o objeto Empresa associado classe Funcionario tambm salvo. O trecho de cdigo entre as linhas 65 e 71 trata eventuais erros que podem ocorrer durante a operao. Para realizar operaes de consulta Hibernate possui uma linguagem chamada HQL (Hibernate Query Language). O HQL de certa forma similar ao SQL, mas agrega conceitos de OO, possibilitando a seleo de objetos em vez de tabelas. Um trecho de cdigo que exemplifica essa linguagem de consulta HQL mostrado abaixo, onde todos os funcionrios com o primeiro nome Alexandre so selecionados.

74: Session sess; 75: // operacoes de inicializacoes como mostradas na listagem 2.3.6

76: String queryStr = "from Funcionario f where f.nome like ?"; 77: Query qry = sess.createQuery(queryStr); 78: qry.setString(0, "Alexandre%"); 79: Collection usrs = qry.list(); 80: System.out.println(usrs.size() + " funcionarios selecionados!"); 81: for (Iterator i = usrs.iterator(); i.hasNext(); { 82: 83: 84: } 85: sess.close();
Listagem 11 Operao de Consulta com o Hibernate Usando HQL

Funcionario func = (Funcionario) i.next(); System.out.println (func.getName());

A string com o comando HQL executado criado na linha 76. Um parmetro usado no lugar para a propriedade nome, de modo a tornar a consulta mais genrica. Na linha 77 um objeto Query criado a partir da sesso. O parmetro configurado na linha 78 para que apenas os funcionrios com nome comeando com Alexandre sejam selecionados e a consulta realizada na linha 79. O trecho de cdigo entre as linhas 81 e 84 imprime o resultado da consulta.

3.7.3 Hibernate e o problema do Grafo de Navegao

O principal desafio dos mapeadores objeto-relacional fornecer acesso eficiente a uma base de dados relacional atravs da representao na forma de um grafo de objetos. A questo determinar qual poro do grafo deve ser recuperada imediatamente e qual deve ser recuperada sob demanda. Para lidar com esta questo, Hibernate define quatro

estratgias de busca que podem ser usadas em quaisquer relacionamentos: busca imediata (immediate fetching), busca tardia (lazy fetching), busca antecipada (eager fetching) e busca em lote (batch fetching). A estratgia de busca imediata(immediate fetching) age logo que uma entidade recuperada do banco de dados, a entidade do relacionamento recuperada atravs de uma consulta base de dados ou ento ao cache de entidades. Esta estratgia no costuma ser eficiente a no ser que as entidades relacionadas estejam quase sempre no cache. A estratgia de busca tardia (lazy fetching) permite que a entidade do relacionamento seja recuperada sob demanda, apenas quando for necessria consulta-la. Com a estratgia de busca antecipada(eager fetching), as entidades relacionadas so recuperadas em uma mesma consulta atravs do uso do comando SQL OUTER JOIN. Otimizaes em uma aplicao que usa Hibernate geralmente envolvem a configurao de relacionamentos, escolhendo a estratgia de busca antecipada para classes que quase sempre so usadas em conjunto. A estratgia de busca em lote (batch fetching) uma tcnica que pode aumentar a performance de relacionamentos com a estratgia de busca tardia ou imediata. Usualmente, ao recuperar um objeto da base de dados, uma consulta SQL realizada com uma clusula WHERE especificando o identificador do objeto a ser recuperado. Se a estratgia da busca em lote for usada, sempre que uma consulta for realizada, o Hibernate procura por outros objetos na mesma unidade de trabalho da sesso usando a mesma consulta, mas com valores mltiplos para a clusula WHERE. Quase sempre a estratgia de busca tardia mais eficiente que esta estratgia, porm a busca em lote mais adequada para usurios do Hibernate que no desejam ou no podem usar seu tempo para ajustar a aplicao com uma combinao de busca tardia e antecipada. Infelizmente esta seo no mostra um exemplo contendo configuraes de busca, porm o objetivo principal era apenas mostrar como o Hibernate oferece meios para resoluo da questo do grafo de navegao, cabe ao desenvolvedor da aplicao configurar os atributos do relacionamento no arquivo de mapeamento de tabelas do Hibernate para obter uma performance satisfatria.

3.7.4 Hibernate e o problema dos relacionamentos

O Hibernate possibilita o uso de relacionamentos unidirecionais ou bidirecionais, com cardinalidade 1-1, 1-m e m-n. H vrias formas de se mapear relacionamentos com o Hibernate e descrever todas seria excessivamente complexo e fugiria ao escopo desta dissertao. Contudo, o exemplo da seo 3.7.2. exemplifica o uso de relacionamentos direcionais 1-1.

O Hibernate impe uma limitao em classes com relacionamentos no lado m da relao: a varivel do relacionamento deve ser determinada em funo da interface da coleo em vez da classe concreta. Por exemplo, a interface java.util.List deve ser usada em vez da classe java.util.LinkedList. O Hibernate usa sua prpria implementao de colees, que oferece recursos como, por exemplo, busca tardia, vista na seo anterior. Esta limitao, contudo no um problema j que programar para interfaces conhecida como sendo uma boa prtica de programao.

3.8 Anlise do Framework Horizontal: Spring

Spring um framework de infra-estrutura adotado no nosso estudo de caso, o sistema Opus Ibank, para complementar o Hibernate fornecendo controle de transaes, alm de oferecer outros servios como a exposio de servios remotos. Este framework pode ser considerado como de infra-estrutura uma vez que oferece servios ao nvel de sistema, como gerenciamento de transaes, e se integra tambm com outros frameworks de persistncia, MVC entre outros. Alm disso, o Spring definido como um container leve (lightweight container) de inverso de controle. O termo container usado no sentido de que ele gerencia o ciclo de vida dos objetos configurados nele, e leve, pois as classes da aplicao tipicamente no possuem dependncias com o framework, como por exemplo, elas no precisam estender nenhuma classe especfica para que sejam inseridas ao framework. O Spring um framework dividido em vrios mdulos funcionais usados de acordo com as necessidades da aplicao. Os mdulos de injeo de dependncia, servios remotos e programao orientada a aspectos foram usados no estudo de caso do captulo 4. As subsees seguintes descrevem os conceitos de inverso de controle e injeo de dependncias, que so os principais conceitos por trs do Spring.

3.8.1 Inverso de Controle

Quando estamos desenvolvendo nossas aplicaes seguindo o paradigma OO, dividimos a responsabilidade em diversos objetos. Nessa diviso de responsabilidades, terminamos por ter objetos que delegam um certo servio a outro objeto. A figura abaixo mostra um diagrama de classes onde mostra a classe ForumFacade, representando o Faade (GOF, 1995) dos servios de um frum de mensagens e a classe MensagemDAOImpl e sua interface, que implementam o padro Data Access Object responsvel por efetuar as operaes de persistncia na base de dados. Note que apesar da classe ForumFacade

referenciar a interface MensagemDAO, ela dependente da implementao da interface, pois precisa instanci-la para poder usa-la. Para este exemplo, as coisas parecem simples, mas com o crescimento do Frum novas dependncias de objetos podem ser inseridas futuramente, ele poderia precisar enviar e-mails, acessar servios remotos, entre outros. Desse modo no seria muito interessante manter todas estas dependncias sendo inseridas manualmente no cdigo, e nesse contexto que entra ento a inverso de controle.

Figura 19 Dependncias configuradas sem injeo de dependncias

O princpio de inverso de controle (Inversion of Control - Ioc) tem como objetivo oferecer uma maneira simples de prover dependncias de objetos em forma de componentes e gerenciar o ciclo de vida dessas dependncias. Containeres de IoC, como o Spring, servem para fazer a ligao entre dependentes e dependncias, fazendo isso de vrias maneiras diferentes. A IoC se subdivide em injeo de dependncias (Dependency Injection) e busca por dependncias (Dependency Lookup). A busca por dependncias a maneira mais conhecida de IoC, nela os objetos procuram ativamente por suas dependncias, como, por exemplo, quando fazemos busca em um contexto de nomes como o JNDI. A injeo de dependncias uma nova abordagem recente da IoC, onde os objetos no procuram por suas dependncias, elas so inseridas neles pelo container de IoC. Atravs da injeo de dependncia, um terceiro objeto denominando Montador (Assembler) esta presente e sua responsabilidade instanciar e configurar as dependncias das classes relacionadas. Este montador injeta dependncias de duas maneiras diferentes, atravs do construtor do objeto, passando dependncias como argumentos do construtor, ou atravs

de mtodos get e set da especificao javabean. A injeo de dependncias considerada a melhor maneira de se trabalhar com IoC, pois ela no polui o cdigo com chamadas para um container, como ocorre na busca por dependncias. Os objetos no ficam presos a uma implementao especfica porque eles no sabem como as dependncias foram parar ali, eles apenas as usam. A figura 20 abaixo exemplifica o mesmo modelo da figura 19, mas desta vez usando injeo de dependncias.

Figura 20 - Dependncias configuradas com injeo de dependncias

Com a introduo do montador a classe ForumFacade passa a depender apenas da interface MensagemDAO. O montador responsvel por instanciar a implementao adequada da interface e configurar a dependncia da classe ForumFacade, desta forma consegue-se um baixo acoplamento entre o componente MensagemDAO e a classe que o usa. O mdulo injeo de dependncias do framework Spring entra no lugar do montador, gerenciando a criao de componentes e a configurao de dependncias que so descritos em um arquivo em formato XML.

3.8.2 IoC com o Spring

Para entender melhor a descrio feita na seo anterior vejamos um exemplo ilustrativo, utilizando o modelo de classes citado anteriormente. A classe ForumFacade precisa de uma instancia para enviar mensagens ao frum ao qual ela gerencia, o modo tradicional de fazer isso seria conforme ilustrado na listagem 12.

public class ForumFacade { private MensagemDAO dao; public void postarMensagem() { dao = new MensagemDAOImpl(); (...) } }
Listagem 12 Classe ForumFacade

Apesar da abordagem acima no ser ruim, ns gostaramos de abstrair MensagemDAO caso sua implementao mude, nesse caso utilizando talvez um objeto fbrica por exemplo.
public class ForumFacade { private MensagemDAO dao; public void postarMensagem() { dao = ApplicationFactory.getMensagemDAO(); (....) } }
Listagem 13- Classe ForumFacade refatorada

Em qualquer uma das duas abordagens acima a classe ForumFacade tem que saber como adquirir uma referencia a uma implementao de MensagemDAO. A IoC segue uma abordagem diferente, com Ioc a classe ForumFacade declararia sua necessidade por um objeto MensagemDAO e o framework de IoC seria o responsvel por injetar a dependncia nesta classe. Isto significa que a classe ForumFacade no precisa nunca mais saber como adquirir uma referencia a um objeto que implementa MensagemDAO, resultando em um cdigo mais limpo e mais flexvel. A listagem 14 abaixo ilustra uma injeo de dependncia via mtodo set. Neste tipo de IoC um arquivo de metadados usado para resolver as dependncias entre os objetos, e conforme dito anteriormente em spring este arquivo de metadados um arquivo em formato xml de configurao.
public class ForumFacade { private MensagemDAO dao; public void setDAO(MensagemDAo dao) { this.dao = dao; } public void getDao() { return dao; } public void postarMensagem() { // faz algo com do sem precisar instancia ou pega referencia com //outro } } Listagem 14 ForumFacade sem precisar instanciar uma referencia

Note que com o uso de IoC a classe se parece com um bean normal. Para inserir a referencia primeiro deve-se definir o bean MensagemDAO no arquivo xml de configurao.
01: <?xml version="1.0" encoding="UTF-8"?> 02: <!DOCTYPE beans PUBLIC "-//SPRING//DTD BEAN//EN" "http://www.springframework.org/dtd/spring-beans.dtd"> 03: <beans> 04: 05: 06: 07: 08: 09: 10: </bean>
Listagem 15 Arquivo de configurao de beans do spring

<bean id="mensagemDAO" </bean> <bean id="ForumFacade"

class="MensageDAOImpl">

class="ConferenceFacade">

<property name=dao"> <ref local="mensageDAO"/> </property>

O trecho entre as linhas 4 e 5 define o bean mensagemDAO. O id, definido na linha 4, identifica unicamente este bean no contexto da aplicao Spring. A propriedade class, definida na linha 4 e 6, especifica a classe do bean. O trecho entre as linhas 6 e 10 declaram o bean ForumFacade. A dependncia com o bean mensagemDAO configurada no trecho entre as linhas 7 e 9. Na linha 7 descrito que a propriedade que armazena a dependncia se chama dao e na linha 8 descrito que esta propriedade recebe o bean mensagemDAO, definido anteriormente no mesmo arquivo. Como se pode ver, o mdulo de Dependency Injection promove o acoplamento fraco entre componentes. Graas a este fraco acoplamento as classes so mais fceis de testar unitariamente. As dependncias so explicitadas e podem ser substitudos por mock objects, objetos que imitam objetos reais e os substituem em testes, dessa forma promove tambm um ambiente propicio ao desenvolvimento baseado em testes.

3.8.3 Outros Servios do Spring

Alm de promover o acoplamento fraco entre classes atravs do mdulo de injeo de dependncias, o Spring tambm fornece servios de infra-estrutura como servios remotos, e suporte a programao orientada a aspectos. Eventualmente uma aplicao necessita expor as funcionalidades da camada de negcios de uma aplicao remotamente para outras aplicaes e para outros clientes.Spring permite a exposio de seus beans de varias formas dentre elas RMI e Servios Web. RMI ou Remote Method Invocation uma tecnologia que possibilita a chamada a mtodos de componentes remotos, tambm usada no Enterprise JavaBeans. Sua principal vantagem que ela eficiente quando a comunicao feita entre duas plataformas

Java. Modelos complexos de objetos podem ser enviados atravs do mecanismo de serializao da plataforma Java. Sua principal desvantagem que ela usa portas arbitrrias para se comunicar, o que exige esforo extra de configurao em firewalls, e no possibilita a comunicao de Java com outras plataformas. A tecnologia de servios web possibilita a chamada de mtodos remotos atravs da troca de arquivos XML, a descoberta automtica de servios dentre outras vantagens. Esta tecnologia executada sobre o HTTP ento firewalls no costumam ser um empecilho e, como utiliza um padro bem conhecido, vivel realizar a comunicao entre diversas plataformas. Por outro lado, das duas tecnologias para exposio de servios remotos citados, a mais pesada e sua performance pode no ser adequada em alguns cenrios. Spring possibilita que servios sejam expostos sem que seja necessrio alterar o cdigo fonte da aplicao. Para expor um servio usando RMI, preciso configurar o Proxy adequado no arquivo de configurao. A exposio de servios como servios web mais trabalhosa, pois envolve tambm a criao do arquivo descritor do servio WSDL. Para fins de demonstrao, a Listagem 16 apresenta o arquivo de configurao do Spring onde o servio Conferncia exposto utilizando a tecnologia RMI.
01: <beans> 02: <!-- Declarao de Outros Beans --> 03: <bean id="ForumFacade" class="ForumFacadeImpl"> 04: 05: </bean> 06: <bean class="org.springframework.remoting.rmi.RmiServiceExporter"> 07: 08: 09: 10: <property name="serviceName" value="Forum"/> <property name="service" ref="forumFacade"/> <property name="serviceInterface" value="ForumFacade"/> <property name="registryPort" value="1199"/> <property name=dao" ref="mensagemDAO"/>

11: </bean> 12: </beans>

Listagem 16 - Arquivo de Configurao do Spring: Exposio de Servios Remotos.

O bean do frum declarado entre as linhas 03 e 05. Neste caso, considera-se que ForumFacadeImpl a classe do frum que implementa a interface ForumFacade. O uso de interfaces obrigatrio quando se lida com Proxys do Spring. O trecho entre as linhas 06 e 11 declara o Proxy dinmico responsvel por expor o servio Conferncia remotamente usando RMI. Na linha 07 associado um nome ao servio que ser usado para cadastr-lo no registro RMI. Na linha 08 especificado o bean cujos servios so expostos pelo Proxy, no caso, o bean ForumFacade. Na linha 09 declarada a interface que este Proxy dinmico implementa e na linha 10, a porta em que o servio e exposto.

O framework Spring possibilita que servios sejam expostos declarativamente, sem que seja necessrio alterar o cdigo fonte. Como conseqncia, pode-se trocar o mecanismo de comunicao sem alterar o cdigo, aumentando o reuso. Finalmente, o mdulo de programao orientada a aspectos do Spring compreende um framework de gerao de aspectos bem integrado com o mdulo de injeo de dependncias. A programao orientada a aspectos um paradigma que prope uma forma de tratar interesses transversais, os aspectos, que costumam se espalhar pelo cdigo em outros paradigmas como o da orientao a objetos. Um aspecto implementado no estudo de caso do captulo 4 foi o log de atividades, usado para fins de depurao do sistema e registro de atividades de um usurio no sistema.

Captulo 4
Arquiteturas Orientadas a Servios (SOA)
4.1 Arquiteturas Orientadas a Servios (SOA)
SOA a denominao dada a um novo tipo de arquitetura onde softwares e rotinas so disponibilizadas como servios numa rede de computadores, e que podem ser utilizados por diferentes aplicaes e para vrios propsitos. Idealmente, com este tipo de arquitetura, o desenvolvimento de novas aplicaes se resumiria em selecionar os servios disponveis e encaix-los numa determinada seqncia de execuo, de acordo com as regras de negcio a serem atendidas. O conceito mais importante em SOA o conceito de servios. Uma analogia que se pode fazer para auxiliar a compreenso sobre o conceito de servios o brinquedo Lego. Cada pea do Lego representa um servio, onde a partir da combinao de peas eu consigo montar casas, navios, entre outras coisas. A montagem do Lego consiste em reunir diversas peas de diferentes formatos, encaixalos entre si e obter no final uma figura totalmente nova. Existem peas que provavelmente sero utilizadas em qualquer uma das montagens, como as peas retangulares que costumam vir em maior nmero no brinquedo, outras peas, entretanto, tm funes mais especificas e sero utilizados dentro de sua especialidade, dificilmente se adaptando a outros contextos, como por exemplo, um eixo de automvel ser utilizado na construo de carros e caminhes, mas com certeza no ser usado na montagem de casas. Apesar de simples podem se extrair algumas caractersticas bsicas do que so servios: (1) servios so reutilizveis, (2) alguns so mais especficos outros de uso mais geral, e (3) servios podem interagir com outros servios. Tendo a idia de peas de Lego em mente, o principio que rege SOA de que uma aplicao grande e complexa deve ser evitada e substituda por um conjunto de aplicaes pequenas e simples. Ou seja, uma aplicao passa a ser fisicamente composta por vrios e pequenos mdulos de software especializados, distribudos, podem ser acessados remotamente, interoperveis e reutilizveis, que podem ser reunidos para formar o processo desejado. Em arquiteturas orientadas a servios esses pequenos mdulos que so chamados de Servios. Um servio um modulo de software que possui uma interface que descreve quais as funes que ele oferece e permite que ele possa invocar um servio assim como possa ser invocado.

Todas as funes em SOA so, portanto agregadas como servios reutilizveis; SOA o contrato para identificao de servios contendo regras sobre como acess-los. Todas as informaes sobre requisies e respostas, condies de exceo e funcionalidades so definidas como parte de uma interface. A interface contm informaes necessrias para que um servio possa ser acessado sem a necessidade de conhecer sua implementao, linguagem ou plataforma de implementao. A figura 21 abaixo ilustra como fica a arquitetura de um sistema com a utilizao de SOA.

Figura 21 Arquitetura em camadas com SOA

A idia de arquiteturas orientadas a servios no nova, desde os anos 80 houve vrias tentativas de implementar sistemas baseados em SOA. Entretanto nenhuma das implementaes realmente foi frente, principalmente devido a trs fatores: (1) No havia softwares para integrao de aplicativos (middleware) padronizados e abertos (no-proprietrios); (2) No existiam definies de interfaces padronizadas para permitir a conexo entre os mdulos; (3) No havia compatibilidade e integrao entre os produtos dos diferentes fornecedores. Na busca por novas formas de utilizar a arquitetura orientada a servios, foi criado, em setembro de 2000, o grupo de trabalho W3C. Formado por membros das maiores empresas de software do mundo, tais como Microsoft, IBM, Oracle e Sun, o grupo definiu uma nova arquitetura computacional, com condies de melhorar o suporte e aprimorar e agilizar a interao entre processos de negcio, e, por conseguinte, entre empresas. Essa arquitetura, denominada Web Services, baseada no conceito de distribuio e modularidade, adotando protocolos abertos e padronizados para promover a integrao de aplicaes com baixo acoplamento. Um web service pode ser entendido como um componente que possui suas funcionalidades acessveis pela rede atravs de mensagens baseadas em XML. A

disponibilizao das operaes e a descrio do servio tambm ocorrem atravs do padro XML. O arquivo descritor do servio possui todas as informaes necessrias para que outros componentes possam interagir com o servio, incluindo o formato das mensagens (para as chamadas aos mtodos do servio), protocolos de comunicao e as formas de localizao do servio. Um dos maiores benefcios dessa interface a abstrao dos detalhes de implementao do servio, permitindo que seja acessado independente da plataforma de hardware ou software na qual foi implementado. Como as mensagens trocadas para a comunicao so baseadas no padro XML, tambm temos a flexibilidade com relao linguagem de programao tanto na implementao do servio quanto no componente que acessar o web service. Estas caractersticas permitem e motivam a implementao de SOA uma vez que a tecnologia de web services ajuda a superar muitos dos obstculos necessrios para elaborao de arquiteturas orientadas a servios. Resumidamente em uma arquitetura SOA, uma camada de servios agrega componentes e funcionalidades relacionadas a um ou mais processos. Essa camada publicada em rede e pode ser invocada de forma remota por aplicaes clientes ou outros servios de software. A composio dos servios oferecidos por essa camada caracteriza uma aplicao SOA. Os principais benefcios de uma arquitetura orientada a servios implementada atravs de web services so: 1) Interoperabilidade: as aplicaes clientes de uma aplicao SOA podem estar implementadas em qualquer plataforma de software e hardware, distinta da plataforma onde a camada de servios foi implementada. 2) Reusabilidade: os servios e funcionalidades oferecidos por uma aplicao SOA so altamente reutilizveis, pois podem ser usadas em mais de uma aplicao. 3) Mobilidade: uma aplicao SOA acessada remotamente e sua localizao deve ser descoberta de forma dinmica e transparente por aplicaes clientes, dessa forma possvel realocar uma aplicao SOA sem comprometer a disponibilidade da aplicao.

Entretanto o uso de SOA no aplicvel em casos onde: - Para aplicaes stand-alone naturalmente no so distribudas, como um processador de textos por exemplo. - Para aplicaes que no necessitam fazer uso de outros servios ou que no tm servios a oferecer, a serem reutilizados. - Para aplicaes que requerem complexas interfaces grficas onde o volume de busca por informaes seja grande, pois SOA uma arquitetura para sistemas distribudos com baixo tempo de respostas.

- Para aplicaes cujo fluxo de execuo no estruturado.

4.2 Arquitetura Tcnica de Web Services Uma definio tcnica de web services poderia ser como um servio disponibilizado na Internet, descrito via WSDL, registrado via UDDI, acessado utilizando SOAP e com os dados transmitidos sendo representados em XML. A seguir, encontra-se uma breve explicao de algumas tecnologias que compem servios web. SOAP (Simple Object Access Protocol) um protocolo para troca de informaes em ambiente distribudo. baseado em definies XML e utilizado para acessar web services. Esse protocolo encapsula as chamadas e retornos aos mtodos dos web services, sendo utilizado, principalmente, sobre HTTP. WSDL (Web Services Description Language) a linguagem de descrio de web services baseada em XML. Ela permite, atravs da definio de um vocabulrio em XML, a possibilidade de descrever servios e a troca de mensagens. Mais especificamente responsvel por prover as informaes necessrias para a invocao do web service, como sua localizao, operaes disponveis e suas assinaturas. UDDI (Universal Description, Discovery and Integration) uma das tecnologias que possibilitam o uso de web services. Uma implementao de UDDI corresponde a um Web Service registry, que prov um mecanismo para busca e publicao web services. Um UDDI registry contm informaes categorizadas sobre os servios e as funcionalidades que eles oferecem, e permite a associao desses servios com suas informaes tcnicas, geralmente definidas usando WSDL. Como dito anteriormente, o arquivo de descrio em WSDL descreve as funcionalidades do web service, a forma de comunicao e sua localizao. Devido ao modo de acesso, um UDDI registry tambm pode ser entendido como um web service. A especificao UDDI define uma API baseada em mensagens SOAP, com uma descrio em WSDL do prprio web service do servidor de registro. A maioria dos servidores de registro UDDI tambm prov uma interface de navegao por browser. A arquitetura de web services se baseia na interao de trs entidades: provedor do servio (service provider), cliente do servio e servidor de registro (service registry). De uma forma geral, as interaes so para publicao, busca e execuo de operaes. A figura 22 ilustra estas operaes, os componentes envolvidos e suas interaes.

Figura 22 Arquitetura de web services, operaes e interao entre entidades.

O provedor do servio (service provider) representa a plataforma que hospeda o web service permitindo que os clientes acessem o servio. O cliente do servio a aplicao que est procurando, invocando ou iniciando uma interao com o web service. O cliente do servio pode ser uma pessoa acessando atravs de um browser ou uma aplicao realizando uma invocao aos mtodos descritos na interface do web service. O service registry representa os servidores de registro e busca de web services baseados em arquivos de descrio de servios que foram publicados pelos service providers. Os clientes (service requestor) buscam por servios nos servidores de registro e recuperam informaes referentes a interface de comunicao para os web services durante a fase de desenvolvimento ou durante a execuo do cliente, denominados static binding e dinamic binding, respectivamente.

4.3 Aplicao de SOA: EAI Enterprise Application Integration

Figura 23 Arquitetura de acesso a sistemas legados

Uma das reas onde arquitetura orientada a servios mais vem sendo empregada a integrao de aplicaes corporativas (EAI Enterprise Application Integration), onde as aplicaes legadas j constitudas esto executando em diversas plataformas, desde linux em micro computadores at OS/390 em mainframes. Muitas vezes, os sistemas legados so antigas aplicaes de software existentes nas organizaes que so vitais para o funcionamento do negcio. No entanto, o uso de sistemas legado gera dificuldades para a adaptao da infraestrutura de TI a novas demandas do negcio. Muitas vezes, as regras de negcio embutidas nestes sistemas no so inteligveis nem para analistas mantenedores do cdigo, devido s inmeras alteraes que o software sofre ao longo de seu ciclo de vida. Assim, uma tecnologia que possa adicionar novas funcionalidades a sistemas legados, sem que seja necessrio retir-los de produo ou decifrar milhares de linhas de cdigo de difcil manuteno, pode aumentar a adaptabilidade e agilidade de uma empresa, e, ao mesmo tempo, reduzir significamente o custo do desenvolvimento e manuteno de sistemas. Para tanto, criam-se adaptadores que acessam as aplicaes legadas e se comuniquem atravs do protocolo definido pelo sistema. A cada nova funcionalidade desejada bastaria adicionar um novo servio sem ter que alterar as funcionalidades do sistema legado. A figura 23 ilustra a explicao dada nesta seo.

Captulo 5
Atividades realizadas, Resultados obtidos e Concluses
5.1 Estudo de caso: Sistema Opus Ibank

Figura 24 Viso Macro de processos do Sistema Opus Ibank

O sistema opus ibank um software de automao bancria que visa o gerenciamento operacional entre todos os terminais da agncia e suas funes. Um terminal em um banco todo dispositivo de atendimento presente em um banco, como terminais de caixa, de auto-atendimento e de atendimento ao cliente, cuja principal funo permitir que um cliente realize operaes de movimentao financeira ou consulta, auxiliado por funcionrios do banco ou no. Esta diversidade de dispositivos na rede, torna a integrao difcil entre eles, pois cada um deles possui formas particulares de comunicao. E justamente esta integrao entre os diversos dispositivos, alm do gerenciamento de todas as informaes operacionais de um banco, como transao bancria, cadastro de funcionrios e gerenciamento de equipamentos da rede, que o opus ibank se prope a resolver. A soluo proposta modular, cuja localizao dos componentes que integram o sistema, funciona distribudo em cada um dos equipamentos terminais e servidor da rede. O

terminal ibank, que correspondem a cada um dos terminais da agncia, um dispositivo que tem instalado os mdulos transacionais, auditoria, gerenciamento e distribuio de verso. J o servidor ibank um equipamento que tem em sua instalao o conjunto formado pelos mdulos cadastros, monitorao, estatstica e controle de verso. Foi utilizado na implementao um conjunto amplo de tecnologias e ferramentas opensource Java: frameworks Hibernate, Java Server Faces e Spring, API Java reflection, APIs de criptografia, EJB, Web Services, Log4J, apache Commons Chain e Commons BeanUtils, e programao orientada a aspectos. Como meu trabalho se deu no lado servidor do ibank desde a fase inicial de elaborao da arquitetura at a fase de implementao, neste captulo apresentarei como a arquitetura do servidor ibank foi implementada atravs da agregao dos frameworks citados no captulo 3, alm de descrever outras atividades realizadas durante a fase de desenvolvimento do sistema. A figura 24 ilustra uma viso macro de processos do ibank.

5.2 Desafios e Solues

Alguns dos desafios com relao ao desenvolvimento deste sistema incluam: Alto desempenho Curto perodo de desenvolvimento e implantao Mltiplos canais de atendimento como agncias, Atms, internet banking, Pabs entre outros. Necessidade de infra-estrutura de segurana incluindo controle de acesso e criptografia de dados. Controle de transao da movimentao bancria Arquitetura distribuda com comunicao via Terminal-Servidor e ServidorServidor. Necessidade de um mecanismo de auditoria Gerenciamento remoto de equipamentos, por exemplo, eu gostaria de poder desativar um equipamento da rede caso algum funcionrio tente fazer uma tentativa ilegal de acesso, ou gostaria de poder fazer testes remotos de funcionamento de equipamentos, tudo isto atravs de interface web.

Alm disso, o desenvolvedor necessitava entender todas as regras do domnio da aplicao, dessa forma os desafios principais com relao ao projeto deste sistema era o entendimento do domnio e como lidar com questes de infra-estrutura. O projetista do sistema deveria se concentrar mais nos aspectos funcionais do domnio da aplicao, utilizando uma infra-estrutura que tratasse de questes tcnicas que so independentes de domnio.

A soluo foi a elaborao de uma arquitetura tcnica multicamada, que faz uso do padro model-view-controller e que integra frameworks para fornecer a infra-estrutura necessria para tratar destas questes tcnicas. A utilizao de frameworks de infraestrutura proporcionaria uma maneira de lidar com questes de baixo nvel como persistncia de dados, segurana, servios remotos, controle de transaes, entre outros, a partir de uma viso mais alto nvel, alm de tornar a aplicao modularizada e dessa forma o desenvolvedor poderia se focar mais nos aspectos funcionais do domnio da aplicao, deixando o tratamento de aspectos de infra-estrutura para outros frameworks especialistas.

5.3 Arquitetura Tcnica do Servidor ibank

Figura 25 Arquitetura tcnica do Servidor ibank com os frameworks

A arquitetura do servidor ibank foi implementada segundo uma arquitetura tcnica que usa uma abordagem em trs camadas e tambm o padro MVC, sendo ilustrada conforme na figura 25 acima. As setas indicam o fluxo de controle da aplicao,

retngulos representam classes e crculos representam interfaces, alm disso, linhas pontilhadas representam a diviso entre as camadas. A camada de recursos relaciona os recursos externos necessrios para a execuo da aplicao. Na arquitetura do ibank os recursos externos incluam um banco de dados, um

servidor ldap (no mostrada na figura acima) para se realizar autenticao de usurios e um sistema legado. O Spring e o Hibernate formam a base dos frameworks de infra-estrutura que oferecem suporte ao desenvolvido de componentes da camada de negcios, fornecendo servios de infra-estrutura como persistncia de dados, controle de transaes, servios remotos, entre outros. Na camada de apresentao, a viso construda com paginas JSP compostas por componentes JSF. Estes podem ser componentes de validao, de converso de dados e de interface com o usurio. O Servlet JSF Controller usado como controlador do MVC, sendo que cada vez que ao receber uma requisio o controlador chama o backing bean que acessa a camada de negcios. A camada cliente pode interagir diretamente com os servios disponibilizados pela camada responsvel por implementar a lgica de negcios, entretanto esta interao direta expe a API destes servios, tornando a camada de apresentao mais vulnervel a mudanas efetuadas nos mtodos de negcio, dessa forma desejvel reduzir o acoplamento entre essas duas camadas, escondendo ao mximo detalhes de implementao. O padro para resolver este problema o Business Delegate que age como uma abstrao, no lado cliente, para mtodos de negcio. A utilizao deste padro em conjunto com o padro Service Locator, cuja funo esconder detalhes de busca de beans de servio no spring, tornava transparente camada de apresentao detalhes de busca de servios, alm de poder realizar um tratamento de excees lanadas pelos servios de negcio, onde caso um problema ocorra em uma chamada a mtodos de negcio, uma mensagem mais amigvel pode ser produzida e repassada a camada de apresentao. A entrada na camada de negcios feita atravs do Proxy do Spring. Como o Proxy implementa a mesma interface do Faade(interface IFaade) o cdigo cliente no precisa ser modificado para usar o Proxy em vez da implementao direta do Faade. Outra caracterstica do Proxy do spring a agregao de servios como controle de transao e servio de log, em cada classe que implementa o Faade gerada pelo Proxy dinmico do spring. Por fim o acesso base de dados encapsulado atravs de classes que realizam o padro de projetos Data Transfer Object(DAO), desta forma a maneira de persisitir pode variar trocando componentes, sem que seja preciso reescrever cdigo cliente. Os DAOs foram construdos usando o Hibernate, que possibilita o mapeamento de objetos em base dados relacionais, e deixando aberta a possibilidade de se construir daos a partir de uma base de consultar de sistemas legados, essa soluo somente ocorreria caso a empresa que comprasse a soluo exigisse isto como requisito.

A arquitetura do ibank precisava expor alguns beans de servio, que continham lgica de negcios, ao Terminal do ibank, como o servidor e o terminal eram aplicaes distintas que precisam conversar remotamente, a soluo encontrada foi o uso de servios web como soluo para servios distribudos. Conforme se viu no captulo 3, o Spring possibilita a exposio de servios de diversas formas. A forma escolhida a princpio por servios web(Web Services), pois possibilitam a integrao com clientes escritos em diversas linguagens de programao alm do Java, alm disso, como o spring possibilita que outros proxys remotos sejam acrescentados, dando suporte a outros tipos de protocolos, como o RMI, por exemplo, sem precisar alterar o cdigo do bean que eu quero expor remotamente, a soluo provida pelo spring se mostrou muito interessante, aumentando em muito o reuso ao nvel de reuso de cdigo, pois a arquitetura no sofre mudanas substrancias com o acrscimo de servios remotos. A principal desvantagem do uso de servios web que se pode notar na pratica, foi com relao ao desempenho, o uso de um protocolo como SOAP para trocar dados entre cliente e servidor ser mostrava muito lento mesmo em ambientes de rede intranet, fator que em algumas ocasies incomodou alguns usurios do sistema.

5.4 Arquitetura orientada a servios (SOA) e o ibank

O ibank era um sistema no qual o terminal e o servidor eram aplicaes distintas que conversavam entre si, como exemplo o terminal precisava realizar operaes de movimentao financeira via uma chamada ao servidor ibank, que acessava o sistema legado com as devidas regras de negcio necessrias ao acesso, encapsuladas pelo servidor, de forma que este servio era apenas um de uma coleo de servios independente, que em certos casos se comunicava com outros servios a fim de gerar uma resposta final, e que funcionava em uma arquitetura distribuda. A partir dessa viso imaginou-se ento a elaborao de parte da arquitetura do ibank, como uma coleo de servios publicveis, que poderiam ser consumidos e combinados para gerar resultados, dessa forma o ibank comeou a migrar para um sistema com uma arquitetura parcialmente orientada a servios (SOA), e a tecnologia escolhida para implementar esta coleo de servios foi a tecnologia de web services, por suas caractersticas de fcil integrao, interoperabilidade entre sistemas e um protocolo de comunicao

independente de especificaes proprietrias de um fornecedor de tecnologia especfico. Um web service pode ser entendido como um componente que possui suas funcionalidades acessveis pela rede atravs de mensagens baseadas em XML (SOAP), cuja disponibilizao das operaes e a descrio do servio tambm ocorrem atravs do padro XML. O arquivo descritor do servio possui todas as informaes necessrias para que outros componentes possam interagir com o servio, incluindo o formato das

mensagens, protocolos de comunicao e as formas de localizao do servio. Como as mensagens trocadas para a comunicao so baseadas em XML, temos flexibilidade com relao linguagem de programao tanto na implementao do servio quanto no componente que acessar o web service. Dessa forma um web service implementado para disponibilizar uma determinada funcionalidade visando a reusabilidade do servio e a interoperabilidade com outros sistemas. Nesse contexto que se imaginou o ibank com a possibilidade de um sistema que utilizasse um ou mais web services para realizar consultas a regras de negcios a sistemas legados, dessa forma como a consulta ao legado era uma operao necessria a ser executada por varias aplicaes distintas que se props uma modelagem de acesso a legado nos moldes de SOA.

5.5 Metodologias usadas durante o desenvolvimento da arquitetura do ibank

Durante o perodo de modelagem do sistema at a fase de implementao foram usadas algumas metodologias de desenvolvimento que merecem destaque, dentre elas a tcnica de prototipao durante a fase inicial de projeto de interfaces do sistema, o uso de geradores de cdigo para modelagem relacional do banco de dados do sistema, e o uso de programao orientada a aspectos para lidar com alguns problemas.

5.5.1 Prototipao
Antes da fase de elaborao do design de software, era importante se projetar como seria a interface do sistema, para isso foram realizados prottipos em PowerPoint para fins de discusso e comunicao de idias. Geralmente se diz que os usurios no conseguem transmitir o que querem, mas quando vem algo e comeam a utiliza-lo, logo sabem o que no querem, foi pensando nisso que foram feitos prottipos da interface do sistema, eles se mostraram muito teis para esclarecer alguns requisitos vagos, para se verificar se o rumo que a equipe de desenvolvimento do ibank tomou no design da interface compatvel como o resto do desenvolvimento do sistema e ele se mostrou muito til como ferramenta para realizao de estudos de caso. Esta com certeza foi a fase que mais me surpreendeu na empresa, geralmente desenvolvedores costumam delegar o projeto de interfaces para a fase de

implementao, sem levar em considerao um estudo da melhor forma de interao com o usurio, esse aspecto de desenvolvimento no qual se desenvolve primeiro em como vai ser a interao com o usurio, para depois pensar em como vai ser a parte tcnica do sistema, facilitou muita a compreenso de como era o domnio da aplicao. A figura 26 abaixo ilustra uma pequena amostra de um dos prottipos feitos.

Figura 26- Prottipo de interface do ibank

5.5.2 Programao orientada a aspectos com AspectJ

A programao orientada a aspectos um paradigma que prope uma forma de tratar interesses transversais, os aspectos, que costumam se espalhar pelo cdigo em outros paradigmas como o da orientao a objetos. A ferramenta escolhida para gerao dos aspectos no ibank foi o AspectJ do projeto eclipse. Um aspecto implementado no ibank foi o log de atividades, usado para fins de depurao do sistema, registro de atividades de um usurio e auditoria no sistema. Esse um caso bem comum de uma funcionalidade que se espalha por todos os cdigos das classes de uma aplicao, desse modo o uso de programao orientada a aspectos contribui pela facilidade de melhora da legibilidade do cdigo e alteraes na poltica de log. Duas variaes de aspectos do log foram implementadas o log de atividades, que nada mais era a exibio no log do servidor de aplicao de cada chamada de mtodo efetuada pelo usurio, e o log de auditoria que era o registro do movimento financeiro efetuado em cada um dos terminais de caixa do ibank. As figuras 27 e 28 ilustram esse caso. Outro aspecto implementado foi a questo da autorizao e autenticao, em determinadas classes da aplicao era necessrio que antes de uma chamada a um mtodo de negcios o usurio tivesse feito a autenticao e possusse as credencias necessrias para efetuar a chamada de mtodo, como por exemplo, em classes que efetuavam operaes financeiras era necessrio verificar antes de realizar a operao, se

o usurio havia se autenticado e possua as permisses necessrias para poder efetuar a operao.

Figura 27 Registro de log do modo convencional

Figura 28 Registro de log baseada em aspectos

5.5.3 Geradores de cdigo

Os geradores de cdigo foram muito importantes na fase de modelagem relacional da base dados, foi utilizado um gerador de cdigo, o PowerDesigner da Sybase. A partir da especificao de alto nvel do modelo relacional da aplicao, o gerador de cdigo permitia o tratamento de um problema sem a preocupao de para qual base de dados eu precisaria deveria gerar o SQL, pois o gerador faria isso para min, dessa forma o reuso provido pelos geradores de cdigo deu um grande impulso inicial na fase inicial de implementao, permitindo o tratamento de um problema a partir de uma viso mais alto nvel.

5.6 Resultados Obtidos

A meta de todo desenvolvedor de sistema conseguir elaborar uma arquitetura que seja o mais flexvel e extensvel possvel, modular e de fcil manuteno. Tanto frameworks como padres e outras abordagens de reuso se mostraram muito importantes tanto na fase de implementao, quanto na fase de elaborao e modelagem do sistema, para o alcance das metas almejadas. O resultado foi um sistema bem flexvel, com perodo de desenvolvimento bem curto por mdulo de desenvolvimento e com caractersticas funcionais como independncia de

banco de dados, flexvel com relao aos vrios protocolos de servios remotos, extensvel para insero de novos servios, fcil manuteno e com uma arquitetura padronizada e com possibilidade de reutilizao para futuros projetos da empresa.

5.7 Concluses
O objetivo deste trabalho, conforme dito anteriormente, abordar o reuso de software no processo de desenvolvimento do produto, baseado em conceitos fundamentais da rea e em tcnicas a serem aplicadas no processo de desenvolvimento. Para se atingir este objetivo, foi feito um estudo das principais abordagens de reuso de software, apresentado tcnicas, e finalizado com uma anlise de dois modelos de desenvolvimento, os modelos cascata e espiral, aplicando o reuso em cada uma das suas etapas do processo e mostrando que independente do modelo de desenvolvimento o reuso de software pode ser inserido no processo, ajudando desenvolvedores a entregar com mais rapidez e qualidade o produto de desenvolvimento. O objetivo do reuso de software o aumento da produtividade e reduo no esforo de desenvolvimento de novos produtos, por parte dos desenvolvedores. Entretanto apesar de ser um objetivo de fcil entendimento, fatores como desconhecimento de tcnicas de reuso, falta de ferramentas especializadas, infra-estrutura para reuso e fatores humanos so problemas adicionais que tornam complexa a realizao de um processo de desenvolvimento com base em reuso. Dessa forma as principais contribuies desse trabalham foram dar um panorama inicial geral do que o reuso de software e apresentado tcnicas que podem ser aplicadas visando atingir os objetivos do reuso, para isso foi apresentada a tcnica de reuso com base em frameworks. Framework uma tcnica de reuso que incorpora uma infra-estrutura de um sistema, que a abstrao de vrios sistemas relacionados entre si, englobando um conjunto de funcionalidades comuns a este conjunto de sistemas. Com o uso de frameworks se obtm no s reuso de cdigo, mas reuso de anlise e projeto, alm de ser um sistema formado por um conjunto de padres em sua arquitetura. O reuso provido pelos frameworks, quando comparados a outras tcnicas de reuso, como padres e biblioteca de rotinas, se mostra mais eficiente, pois sua funcionalidade mais especfica para domnio que os padres(que so estruturas mais genricas que os frameworks) e que as bibliotecas de rotinas(bibliotecas so reutilizadas, mas com todo o controle da aplicao nas mos do desenvolvedor, o que ocasiona uma maior propenso a erros que no uso de frameworks). Apesar das vantagens, os frameworks apresentam como desvantagens, custo inicial de treinamento e desenvolvimento e sua depurao e correo de erros mais difcil. Porm todas as desvantagens so superadas pelas vantagens, pois uma vez que se aprende um

framework novos projetos so desenvolvidos com maior produtividade por parte do desenvolvedor. A arquitetura orientada a servios uma tcnica de reuso mais atual, que tem como principal objetivo o reuso intenso dos seus componentes (servios), para que em mdio prazo, a tarefa do desenvolvimento de uma aplicao seja primordialmente a tarefa da composio e coordenao dos servios j implementados, aumentando o reuso e diminuindo o dispndio de recursos, uma forma de se ver SOA como uma nova proposta para o desenvolvimento orientado a componentes. Apesar desta monografia apresentar somente duas tcnicas de reuso com base em frameworks e SOA, a verdade que em qualquer projeto o desenvolvimento de sistemas feito a partir de uma serie de tcnicas de reuso que vo desde a fase de modelagem e especificao do sistema at a fase de implementao, como foi o caso do estudo de caso do sistema opus ibank, sempre com o objetivo principal do aumento da produtividade dos desenvolvedores. Como futuras extenses do trabalho podem ser vistas outras tcnicas de reuso como um aprofundamento maior em arquiteturas orientadas a servios, engenharia de software baseada em componentes entre outras. Podem ser vistas o caso de uma criao de estrutura de banco de dados para catalogao, classificao e recuperao de solues de reuso previamente estudadas, projetadas e aplicadas melhorando dessa forma o ciclo de desenvolvimento. Atravs deste trabalho espero que desenvolvedores possam ter um maior esclarecimento dos conceitos bsicos em questo e que sirvam de motivao para estudo e pesquisas sobre o tema de reuso de software.

Parte III Parte Subjetiva

Captulo 6: BCC e o Estgio

Captulo 6
BCC e o Estgio
6.1 Desafios e Frustraes
O estgio realizado na empresa Opus no decorrer deste ano de 2006, me proporcionou um grande amadurecimento profissional. Quando entrei na empresa um dos desafios do trabalho foi com relao parte tecnolgica, foi necessrio se aprender um conjunto grande de tecnologias em prazo pequeno de tempo, a plataforma Java J2EE muito rica com muitas solues e projetos open-source para o desenvolvimento de aplicativos voltados para servidores. Outro desafio que tive foi com relao a como modelar um projeto como o opus ibank, para se ter uma idia foram gastos cerca de trs meses somente na modelagem do sistema. Durante a fase de modelagem fazamos muitas reunies semanais com nosso chefe, reunies que duravam cerca de trs a quatro horas, alm disso, como o projeto foi feito em conjunto com outras duas empresas (sibis software e amatera) era preciso estar em sintonia com o que eles estavam fazendo, apesar de um enorme tempo gasto com reunies acredito que foi nesse perodo que desenvolvi melhor minha comunicao verbal e aprendi mais sobre como desenvolver um software real na prtica. Vale ressaltar que desenvolver um sistema na prtica bem diferente do que quando fazemos um exerccio programa no IME, aspectos como levantamento de requisitos, mudanas de prazo e escopo do projeto, documentao do sistema, entre outros, sem dvida so desafios que surgem em projetos grandes e que aparecem em maior grau de dificuldade quando comparado a fazer um programa no IME, sem dvida muito enriquecedor formao e complementa o conhecimento acadmico que adquirimos no IME, alm de presenciar como acontece a engenharia de software na prtica. Sinceramente no acho que tenha havido frustraes no decorrer do estgio, meu chefe sempre deu muita liberdade equipe com relao ao desenvolvimento da arquitetura e estudo de tecnologias, alm de sempre me liberar em semanas de prova ou mesmo para poder fazer trabalhos da faculdade.

6.2 O Relacionamento com os Membros da Equipe

O ambiente de trabalho da opus muito bom, descontrado, mas srio o suficiente para desenvolver um trabalho de qualidade. A equipe de

desenvolvimento da opus era composta por min e mais trs membros. Dois membros da equipe inclusive eram ex-alunos do bcc do IME, Thiago Lourenoni e Adriano Saturno, graas a eles consegui me integrar muito bem a empresa e ao projeto. O que diferencia o trabalho em grupo feita no IME da realizada no estgio a presena de terceiros. Quando fazemos um trabalho em equipe na faculdade, o objetivo o aprendizado de algum assunto com a cobrana sendo feita por professores. J em um ambiente de trabalho h um grau de responsabilidade maior, pois a cobrana feita pelo cliente, dessa forma atrasos de entrega comprometem a equipe como um todo, todos so responsveis, alm de prejudicar os negcios da empresa, nesse contexto ser gil uma necessidade para no prejudicar o grupo e a empresa.

6.3 Disciplinas que foram relevantes para o trabalho

MAC 323 Estrutura de dados e MAC 122 Princpios de desenvolvimento de algoritmos: disciplinas fundamentais a todo programador, a base para se desenvolver algoritmos. MAC 242 Laboratrio de programao II: foi nessa disciplina que tive meu primeiro contato com a linguagem Java e com a orientao a objetos. MAC 426 Sistemas de Banco de Dados: o projeto em que trabalhei exigiu a necessidade de se realizar a modelagem relacional do sistema a fim de persistir dados em banco. MAC 332 Engenharia de software: em qualquer projeto de sistemas conhecer processos de desenvolvimento de software fundamental saber como projetar sistemas. MAC 441 Programao orientada a objetos: esta matria importante para se aprender como programar orientado a objetos. MAC 440 Sistemas de objetos distribudos: o projeto opus ibank exigiu a necessidade de se lidar com servios remotos, esta matria foi importante para

meu trabalho, pois da uma base muito boa para se entender como trabalhar com sistemas distribudos. MAC 446 Princpios de Interao Homem Computador: de todas as disciplinas esta com certeza merece destaque, pois mostra uma nova abordagem de desenvolvimento de software, a partir do modo como o usurio vai lidar com a interface do sistema. Mritos ao professor Hitoshi, pois a disciplina foi muito bem ministrada quando eu fiz.

6.4 Prximos passos

O sistema opus ibank esta em desenvolvimento ainda, mas com vrios mdulos j implementados, a meta que a partir de maio de 2007 esteja concluda e seja instalado no banco ibi do grupo C&A. Como prximos passos gostaria de realizar um estudo na rea de

componentizao de software a fim de melhorar processos de desenvolvimento, a rea de engenharia de software baseada em componentes muito aplicada na pratica e bem vista com bons olhos pela empresa onde trabalho, com certeza esse ser o caminho de estudo que seguirei aps a graduao.

6.5 Agradecimentos
Agradeo ao IME pela tima formao dada aos seus alunos; empresa Opus pelo apoio financeiro e pela oportunidade de trabalhar como estagirio; ao prof. Siang Wun Song ter me orientado na escrita da monografia. Finalmente agradeo minha famlia e amigos que sem eles com certeza no teria conseguido seguir em frente nesse puxado curso que o bcc do IME.

Bibliografia
[1] Bauer, C. & King, G. (2004): Hibernate in Action. Manning Publishing Co., 2004. [2] Fayad, Mohamed C.; Schmidt, Douglas C.; Johnson, Ralph E. Building Application Frameworks Object Oriented foundations of framework design. Wiley , 1999. [3] Fowler, M. (2002): Patterns of Enterprise Application Architecture. AddisonWesley, 2002

[4] Fowler, M. (2004): Inversion of Control Containers and the Dependenc Injection pattern: Artigo disponvel em http://martinfowler.com/articles/injection.html. [5] Frakes, W.; Terry, C. Software Reuse and Reusability Metrics and Models, 1996. [6] Gamma, E., Helm, R., Johnson & R., Vlissides, J. (1995): Design patterns: elements of reusable object-oriented software. Addison-Wesley, Reading, MA, 1995. [7] Geary, D. & Horstmann, C. (2005): Core JavaServer Faces, Sun Microsystems, Inc, 2005. [8] Gustavo Alonso, Fabio Casati, Harumi Kuno e Vijay Machiraju, Web Services Concepts, Architectures and Applications, Springer-Verlag, 2004. [9] Hibernate (2006): Pgina oficial do framework Hibernate disponvel em http://www.hibernate.org [10] Johnson, Ralph. E. Components, Frameworks, Patterns. Communications of the ACM, V. 40, n 10, p. 39-42, 1997. [11] Monday, Paul. Web Services Patterns: Java Edition, Apress-2005 [12] MyFaces (2005): Pgina oficial do MyFaces disponvel em http://myfaces.apache.org/. [13] Pressman, Roger S. (2002) . Engenharia de Software. McGrawHill. [14] Prieto-Diaz, R. Reuse as a New Paradigm for Software-Development. Proceedings of the International Workshop on Systematic Reuse, 1996 [15] Sauv, Jacques Philipe. Frameworks. Universidade federal da Paraba. Notas de aula http://www.dsc.ufcg.edu.br/~jacques/cursos/map/html/frame/oque.htm [16] Walls, C.; Breidenbach, R. Spring em Ao. (2006) Editora Cincia Moderna.