Your SlideShare is downloading. ×
Relatório de Estágio da Graduação
Upcoming SlideShare
Loading in...5
×

Thanks for flagging this SlideShare!

Oops! An error has occurred.

×

Introducing the official SlideShare app

Stunning, full-screen experience for iPhone and Android

Text the download link to your phone

Standard text messaging rates apply

Relatório de Estágio da Graduação

1,667
views

Published on

Texto completo do relatório de estágio da minha graduação em Tecnologia para Sistemas na Internet

Texto completo do relatório de estágio da minha graduação em Tecnologia para Sistemas na Internet


0 Comments
0 Likes
Statistics
Notes
  • Be the first to comment

  • Be the first to like this

No Downloads
Views
Total Views
1,667
On Slideshare
0
From Embeds
0
Number of Embeds
1
Actions
Shares
0
Downloads
19
Comments
0
Likes
0
Embeds 0
No embeds

Report content
Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
No notes for slide

Transcript

  • 1. CENTRO FEDERAL DE EDUCAÇÃO TECNOLÓGICA DA PARAÍBACoordenação do Curso Superior de Tecnologia em Sistemas para a Internet RELATÓRIO FINAL DE ESTÁGIO Report Center e Phrame UIDesenvolvimento da ferramenta de relatórios Report Center e do framework de interface Phrame UI Maurício Linhares de Aragão Junior João Pessoa - PB Julho/20071
  • 2. 2
  • 3. Centro Federal de Educação Tecnológica da ParaíbaCoordenação do Curso Superior de Tecnologia em Desenvolvimento de Softwares para a Internet Report Center e Phrame UIDesenvolvimento da ferramenta de relatórios Report Center e do framework de interface Phrame UI Maurício Linhares de Aragão Junior3
  • 4. Relatório de Estágio Supervisionado apresentado ádisciplina Estágio Supervisionado da Coordenação do CursoSuperior de Tecnologia em Sistemas para a Internet doCentro Federal de Educação Tecnológica da Paraíba comorequisito parcial para obtenção do grau de Tecnólogo emSistemas para a Internet. Orientador: Frederico Guedes Pereira Maurício Linhares de Arag…, 9/7/07 21:30 Deleted:Supervisor: Clóvis Mattos Garcia de SáCoordenador do Curso de D.S.I.: Heremita Brasileiro LiraPresidente da CESUT: Heremita Brasileiro LiraEmpresa: Phoebus TecnologiaPeríodo: 01/04/2006 até 01/10/2006 4
  • 5. SUMÁRIO1.   INTRODUÇÃO ..................................................................................................... 11   1.1.   ESTRUTURA DO RELATÓRIO............................................................................. 11   1.2.   APRESENTAÇÃO ............................................................................................. 11   1.3.   OBJETIVO ...................................................................................................... 12   1.4.   A EMPRESA .................................................................................................... 13   1.5.   REPORT CENTER ........................................................................................... 14   1.6.   PHRAME UI .................................................................................................... 14   1.7.   ATIVIDADES REALIZADAS ................................................................................. 15  2.   METODOLOGIA E EMBASAMENTO TEÓRICO ................................................ 16   2.1.   INTRODUÇÃO .................................................................................................. 16   2.2.   RATIONAL UNIFIED PROCESS .......................................................................... 17   2.3.   UML.............................................................................................................. 21   2.4.   GESTÃO DE MODIFICAÇÕES ............................................................................. 26   2.4.1.   CVS – Concurrent Versions System ........................................................ 27   2.4.2.   PhElips ..................................................................................................... 30   2.4.3.   Maven ...................................................................................................... 32   2.5.   A PLATAFORMA JAVA ...................................................................................... 35   2.5.1.   JavaServer Faces .................................................................................... 38   2.6.   O PROJETO ECLIPSE ...................................................................................... 43   2.6.1.   SWT – Standard Widget Toolkit e JFace ................................................. 45   2.7.   INVERSÃO DE CONTROLE ................................................................................ 45   2.7.1.   Busca por dependências (Dependency Lookup) ..................................... 47   2.7.2.   Injeção de dependências – (Dependecy Injection) .................................. 48   2.7.3.   O framework Spring ................................................................................. 49  3.   ATIVIDADES REALIZADAS ................................................................................ 54   3.1.   REPORT CENTER ........................................................................................... 54   3.1.1.   Requisitos funcionais ............................................................................... 55  5
  • 6. 3.1.2.   Requisitos não funcionais ........................................................................ 56   3.1.3.   Seleção de tecnologias ............................................................................ 56   3.1.4.   Modelagem e implementação do sistema ............................................... 57   3.1.5.   Arquitetura do sistema ............................................................................. 59   3.1.6.   Problemas encontrados ........................................................................... 60   3.1.7.   Resultados e futuro .................................................................................. 62   3.2.   PHRAME UI .................................................................................................... 62   3.2.1.   Requisitos Funcionais .............................................................................. 63   3.2.2.   Requisitos Não funcionais ....................................................................... 63   3.2.3.   Seleção de tecnologias ............................................................................ 64   3.2.4.   Modelagem e implementação do framework ........................................... 65   3.2.5.   Problemas encontrados ........................................................................... 67   3.2.6.   Resultados e futuro .................................................................................. 68  4.   CONSIDERAÇÕES FINAIS ................................................................................. 70  5.   REFERÊNCIAS BIBLIOGRÁFICAS .................................................................... 73  6
  • 7. RESUMO O estágio representa a participação no processo de desenvolvimento daferramenta Report Center, um visualizador de relatórios para a web escrito nalinguagem Java e a tecnologia JavaServer Faces, e a construção do frameworkde componentes visuais Phrame UI, que tem por objetivo abstrair, de formaque não seja necessário decidir se uma aplicação deve ser criada para odesktop ou web, baseado nas bibliotecas Standard Widget Toolkit (SWT) paraos componentes desktop, Echo 2 Web Framework e Thinwire para oscomponentes web. 7
  • 8. 8
  • 9. AGRADECIMENTOS À minha família, à minha namorada e aos meus amigos, pela confiançae incentivo que sempre depositaram em mim. Dando força nos momentosdifíceis, nas noites de sono perdidas e, acima de tudo, demonstrando queninguém está sozinho no mundo. A todas as pessoas que formam a equipe da Phoebus Tecnologia, queme receberam muito bem e foram de extrema importância para o meucrescimento pessoal e profissional, graças a tudo o que eu pude aprender juntocom eles. Aos meus amigos de curso, começamos como 25 alunos e terminamoscomo 10. Todos vocês foram importantes durante esses anos de turmaCOBAIA. Além deles, gostaria de agradecer também aos alunos das outrasturmas de DSI, especialmente os P4 e P5 da época, que também deram forçapara a conquista de mais este degrau. A todos os professores da COINFO, em especial ao professor FredericoGuedes Pereira, não apenas pelos cinco períodos que passamos juntos, porestar me orientando neste trabalho e pelos conhecimentos que forampassados, mas pelos ensinamentos fora de sala de aula, como pessoa, que mefizeram pensar de forma diferente e reavaliar os meus valores. Aos membros da lista de discussão do PBJUG e dos fóruns do GUJ,pelas grandes dicussões e referências, que fizeram com que todo o trabalhodesenvolvido fosse baseado no que havia de melhor na indústria, além deajudar na resolução das várias dúvidas que surgiram no decorrer do trabalho. 9
  • 10. 10
  • 11. 1. Introdução 1.1. Estrutura do relatório Este relatório foi organizado de acordo com a seguinte divisão emcapítulos: • Capítulo 1: Introdução – Trata da apresentação do estágoi e da empresa, resumo das atividades e dos entregáveis que foram gerados através das atividades. • Capítulo 2: Metodologia e embasamento teórico – descreve a metodologia empregada para execução do trabalho e seu respectivo embasamento teórico. • Capítulo 3: Atividades Desenvolvidas – apresenta um resumo das atividades mais significativas realizadas. • Capítulo 4: Considerações Finais – tece as conclusões obtidas ao final da realização do estágio. • Capítulo 5: Referências Bibliográficas – publicações científicas que deram suporte ao trabalho. 1.2. Apresentação Neste documento foram descritas as tarefas realizadas durante o estágiona Phoebus Tecnologia, que é uma empresa paraibana de tecnologiaespecializada em soluções de integração entre aplicações, desde aimplementação de thin-clients como dispositivos POS, Point Of Service ou Pont 11
  • 12. de Serviço, que são pequenos dispositivos que implementam serviços simples,até as aplicações servidoras responsáveis pela integração dos serviços. Oestagio representou o desenvolvimento da aplicação web Report Center, que éum visualizador de relatórios utilizando a tecnologia JavaServer Faces e oframework de componentes visuais Phrame UI, que tem por objetivo abstrair acriação de aplicações que sejam ao mesmo tempo desktop e web, sem queseja necessário o desenvolvedor preocupar-se diretamente com isso. Tambémserão descritos por este documento as técnicas de desenvolvimento, padrõesde projeto e decisões tomadas na construção da ferramenta e do framework. 1.3. Objetivo O objetivo do estágio foi de proporcionar uma experiência mais próximacom as disciplinas que foram vistas e praticadas ao longo do curso, nele foramdesenvolvidas práticas em análise e arquitetura de sistemas, implementaçãode software orientado a objetos e extensão de frameworks. Utilizando comoferramenta a plataforma Java EE e a linguagem Java como um todo, paraaproximar os conhecimentos teóricos formados durante o curso das aplicaçõespráticas do dia a dia de desenvolvimento de aplicações. O foco maior foi aimplementação de interfaces gráficas, tanto para aplicações desktop como paraaplicações web e o desenvolvimento de código arquitetural para suportar os x 9/7/07 07:51 Deleted: ,usos que ambas as ferramentas teriam. 12
  • 13. 1.4. A empresa A Phoebus Tecnologia é uma empresa especializada em integração deaplicações através de sistemas de trocas de mensagens, é uma das únicasempresas do Brasil com experiência no desenvolvimento de soluções paradispositivos clientes de captura como POS, trabalhando com uma gamagigantesca de fornecedores e sistemas operacionais distintos. A empresa sedefine como: “Uma empresa que alinha tecnologia, dinamismo e funcionalidade naaplicação e desenvolvimento de soluções multiplataformas para terminaisPOS`s (point-of-service), aplicativos como Palm`s, cartões inteligentes emicrocontroladores.Atua no mercado nacional e internacional implantando soluções para redes dearrecadação de contas, distribuição e venda de crédito digital, correspondentesbancários e postos de serviços para atendimento ao usuário/consumidor,envolvendo o aplicativo do terminal, as retaguardas de comunicação e gestão,e a conectividade dentre os diversos componentes de rede. Ao dominar a tecnologia de modelos de vários terminais, a Phoebusdisponibiliza sistemas flexíveis, oferecendo excelente rentabilidade.” [PHO07] Com base nessa premissa, diversas aplicações de suporte foram criadaspara possibilitar o funcionamento dos sistemas nos diversos clientes que aempresa tem por todo o país. 13
  • 14. 1.5. Report Center O Report Center é uma ferramenta de filtragem e visualização derelatórios para a web. Ele surgiu da necessidade de se evitar que cada clienteinstalasse uma aplicação desktop na sua máquina para poder visualizar osrelatórios e fazer o acompanhamento do funcionamento dos sistemas. Com oadvento do Report Center a única coisa que o usuário necessita em suamáquina é um navegador web comum com suporte a XHTML e JavaScript. A aplicação foi desenvolvida utilizando-se a linguagem Java e atecnologia JavaServer Faces de desenvolvimento web baseado emcomponentes. 1.6. Phrame UI O Phrame UI faz parte do conjunto de frameworks para a renovação daarquitetura de aplicações da Phoebus, o projeto Phrame. O Phrame UI temcomo objetivo abstrair para o desenvolvedor a necessidade de se escreveruma mesma aplicação para a web e para o desktop, através dele é possívelescrever uma única aplicação que vai ser executada igualmente na web e nodesktop bastando alterar apenas alguns parâmetros de configuração. O códigoque foi desenvolvido não precisa ser alterado para que uma aplicação webexecute em um ambiente desktop, nem o contrário. 14
  • 15. 1.7. Atividades realizadas Durante o estágio foram realizadas atividades na fase dedesenvolvimento do Report Center de do Phrame UI. Essas podem serresumidas em: • Análise e projeto da aplicação web Report Center em Java; • Estudos preliminares para escolha da ferramenta web para o Report Center; • Implementação da ferramenta Report Center; • Estudos de diversas bibliotecas de componentes visuais; • Estudos sobre o desenvolvimento de código arquitetural para frameworks; • Definição da arquitetura e API padrão e implementação da API padronizada para desktop e para a web; 15
  • 16. 2. Metodologia e embasamento teórico 2.1. Introdução Ambos os projetos foram desenvolvidos tomando como base umapersonalização do Rational Unified Process (RUP) desenvolvida pela própriaempresa através de uma equipe que estava responsável pela definição deprocessos de qualidade e um consultor externo. As ferramentas utilizadas no decorrer do trabalho foram o ambiente dedesenvolvimento Eclipse, em sua versão 3.2 (Callisto), a ferramenta deautomatização de build e gerencia de projetos Maven 2, o sistema de controlede versionamento de software CVS e a ferramenta de gerenciamento de casos(Issue Tracker) PhElips. O Report Center foi desenvolvido sob a plataforma Java EnterpriseEdition (Java EE), utilizando as especificações das tecnologias Servlet,JavaServer Pages e JavaServer Faces para a camadas de visualização econtrole. Para a camada de persistência foi utilizada a ferramenta demapeamento objeto/relacional Hibernate em sua versão 3. O relacionamentoentre as três camadas foi provido pelo framework de inversão de controlebaseado em injeção de dependências Spring, em sua versão 2. O Phrame UI foi desenvolvido sob as plataformas Java Standard Edition(Java SE) em sua versão desktop e Java Enterprise Edition (Java EE) em suaversão web. Os frameworks utilizados na criação dos componentes visuaisforam o Standard Widget Toolkit (SWT), o Echo 2 Framework e o Thinwire. 16
  • 17. 2.2. Rational Unified Process O RUP é um processo iterativo de desenvolvimento de software quesurgiu da fusão de duas grandes empresas que trabalhavam na definição deprocessos de desenvolvimento de software, a Rational Software Corporation ea Objectory AB. Com essa fusão eles também criaram um novo processo, queunificava as práticas dos dois processos que elas haviam criado, surgia então oRational Objectory Process, que mais tarde foi rebatizado de Rational UnifiedProcess. Ele surgiu como uma reunião das boas práticas encontradas nosprocessos mais tradicionais de desenvolvimento e comprovadas através deseu uso com as novas tendências encontradas, como desenvolvimentoiterativo, preocupação com a comunicação e foco constante no cliente dasolução. O RUP é definido por [PHK03] como sendo: “(...) um processo de engenharia de software. Ele provê um mododisciplinado de designar tarefas e responsabilidades dentro de umaorganização de desenvolvimento de software. Seu interesse é garantir aprodução de software de alta qualidade que atinja as espectativas de seususuários dentro de um prazos e custos previsíveis. O Rational Unified Processé um ‘processo produto’. Ele é desenvolvido e mantido pela Rational Softwaree integrado com a sua suíte de ferramentas de desenvolvimento. (...) Ele étambém um framework de processos que pode ser adaptado e estendido paraas necessidades de uma organização que o está adotando. (...) Ele captura 17
  • 18. muitas das boas práticas no desenvolvimento de software da atualidade emuma forma aceitável para a maioria dos projetos e organizações”. Em 2005, o RUP teve os seus seis princípios atualizados para arealidade atual das empresas e das necessidades dos projetos de software,segundo [PKW05]: “Nossas seis boas práticas, testadas e garantidas, tem sido a base paraa evolução de nossas ferramentas e processos por mais de uma década. Hoje,enquanto vemos mais companhias buscando o desenvolvimento de softwarecomo uma capacidade essencial de negócio, nós vemos estas práticasamadurecendo dentro do contexto mais abrangente do desenvolvimento‘direcionado ao negócio’. Nós acreditamos que é o momento de rearticularnossas boas práticas para um ciclo mais amplo na contínua evolução desistemas, onde o elemento primário da evolução é o software”. Na atualização, os seis princípios chave do RUP tornaram-se: • Adaptar o processo; • Balancear as prioridades entre os interessados no projeto; • Colaborar soluções entre as equipes; • Demonstrar valor iterativamente; • Elevar o nível de abstração; • Foco em qualidade contínua; Comparando com os seis princípios anteriores, que eram mais focadosna implementação dos produtos, pois tratavam de características de baixonível, o novo grupo de princípios tem um foco mais direcionado aos resultadosque a solução desenvolvida vão trazer para a empresa. 18
  • 19. O RUP é dividido em quatro fases seqüenciais onde todas as disciplinassão aplicadas de forma paralela e com freqüências diferentes, comodemonstrado na figura abaixo: Figura 1 – Fases e disciplinas do RUP Durante o início do projeto, na fase de concepção (Inception), asdisciplinas que são mais exercidas são as que têm por objetivo formar umaarquitetura sólida para o projeto, que são a de modelagem de negócios(Business Modeling), requisitos (Requirements) e análise e projeto (Analysis &Design). Nas fases de elaboração (Elaboration) e contrução (Construction) ofoco é nas disciplinas de implementação (Implementation), testes (Test),implantação (Deployment) e gerenciamento de configuração e mudanças(Configuration & Change Management). Ao entrar na fase de transição osesforços estão direcionados mais fortemente à implantação e aogerenciamento de configuração e mudanças. 19
  • 20. É importante lembrar que mesmo que uma ou outra disciplina seja o focoda fase corrente, as outras disciplinas nunca devem ser “congeladas”, pois oRUP baseia-se em um processo iterativo de desenvolvimento de software enão nos clássicos processos seqüenciais, também conhecidos como processosem cascata. Ainda segundo [PHK03] algumas das vantagens dos processositerativos são: • Riscos são atacados mais cedo; • É mais fácil de se introduzir mudanças; • Há um aumento no reuso de software; • A equipe de desenvolvimento pode aprender sobre o negócio e as ferramentas que utiliza enquanto desenvolve; • A qualidade geral do produto é maior do que a encontrada em produtos não desenvolvidos através de métodos não iterativos; Com todas as suas vantagens, o RUP ainda enfrenta críticasprincipalmente nas áreas de personalização do processo. A quantidade deartefatos padrão é tão grande que para pequenas equipes ou equipes que nãotem conhecimento suficiente, o início de um projeto e a seleção dos artefatosque são realmente necessários é lenta e trabalhosa, aumentando ainda mais opeso do processo sobre a equipe. [JAC07] apresenta uma crítica à dificuldadede se remover artefatos dos processos: “The desire to provide a complete process also makes the processheavier as more and more information is added to cover all of the disciplinesinvolved. As the process evolves, no one ever takes anything out because 20
  • 21. someone somewhere might need it some day (a day that never seems tocome). If a process is successful, then the desire to keep it up to date andextend its market leads it to become even heavier as more information is addedto expand its scope, add new techniques, and address new challenges. Thisleads to the need for organizations, practitioners, and methodologists to starttrimming to get a lighter, more-focused process. We dont think this is the wayto go. You shouldnt need to spend time deselecting the things you dont want.You should be able to start from a small, useful kernel of information, then addthe guidance you need.” Todos os papéis, atividades, guias e artefatos disponíveis fazem comque a escolha por quais são realmente necessários no projeto seja penosa eesse também não é, de forma alguma, o produto final que se espera dele. Oartefato que é esperado é um produto que funcione a contento para o usuário,que seja de fácil manutenção e que possa evoluir gradativamente assim comoo conhecimento do domínio do problema vai evoluir. 2.3. UML A Unified Modelling Language (UML) é uma linguagem de modelagemde propósito geral que parte dos pressupostos da orientação a objetos paradesenvolver os seus diagramas. Sendo uma linguagem de propósito geral, aUML é mais comumente utilizada na definição de sistemas de softwareorientados a objetos. Assim como o RUP, a UML também foi desenvolvida pela fusão daRational e Objectory, de qualquer forma, a UML não tem relacionamento direto 21
  • 22. com o RUP ou com qualquer outro processo de desenvolvimento, a linguagemé agnóstica ao tipo de processo onde ela está inserida. No início dos anos 90, haviam três grandes notações para linguagens demodelagem de sistemas orientados a objetos, a Object-Oriented SoftwareEngineering (OOSE, [WOOSE07]) de Ivar Jacobson, o “Booch method”([WBO07]) de Grady Booch e o Object-modeling Technique (OMT, [WOMT07])de James Rumbaugh. Cada um dos três métodos tinha características ondeeram fortes e outras onde necessitavam de melhorias e foi com a fusão dostrês que foi possível desenvolver a linguagem de modelagem que conhecemoshoje, como afirma [PEN03]: “Object-Oriented Software Engineering (OOSE), developed by IvarJacobson is based around the use-case concept that proved itself by archievinghigh levels os reuse by facilitating communication between projects and users,a key sucess factor for IT projects. James Rumbaugh developed the Object-Modeling Technique (OMT) with an emphasis on the analysis of business anddata intensive systems for defining a target problem, a second key sucessfactor for IT projects. The Booch method, developed by Grady Booch, hadparticular strenghts in design and implemenation, defining and mapping asolution to the target problem, a third key to sucessful IT projects. Thesesignificant contributions are like the legs on a three-legged stool: thecombination of the three methods and ther notations supported the entire rangeof requirements needed to reate a single, comprehensive software-modellingstandard.” A UML contém 13 tipos diferentes de diagramas, conforme a imagem aseguir: 22
  • 23. Imagem 2 – Tipos de diagramas UML – Retirada de [FOWUML03]Diagrama PropósitoAtividade (Activity) Comportamento procedural ou paralelo 23
  • 24. Classe (Class) Classes, atributos e relacionamentosComunicação Interações entre objetos(Communication)Componente (Component) Estrutura e relacionamentos entre componentesEstrutura (Composite Decomposição em tempo de execução de umaStructure) classeImplantação (Deployment) Implantação de artefatos em seus locaisInteração (Interaction Junção dos diagramas de seqüência eoverview) atividadesObjeto (Object) Estados de exemplo das instâncias no sistemaPacote (Package) Estrutura hierárquica dos objetosSeqüência (Sequence) Interações entre objetos, ênfase na seqüência das açõesEstado (State Machine) Alterações do estado dos objetos durante a sua existênciaTempo (Timing) Interações entre objetos, ênfase nos momentos quando elas acontecemCaso de uso (Use Case) Como os usuários interagem com um sistema Legenda da Imagem 2 – Retirada de [FOWUML03] Além de ser agnóstica ao processo no qual ela está inserida, a UMLtambém é agnóstica à linguagem na qual o sistema vai realmente serconstruído. Baseando-se nas premissas da orientação a objetos que já existemhá década no mercado, a linguagem contém praticamente todos os constructoscomuns do paradigma como definidos por [MPJ97]: 24
  • 25. “Considero que as seguintes propriedades são fundamentais àorientação a objeto: encapsulamento, ocultamento de informação e deimplementação, retenção de estado, identidade de objeto, mensagens, classes,gerança, polimorfismo e genericidade.” A linguagem conta com transformadores baseados no padrão detransformações Query/View/Transformations (QVT, [WQVT07]) definidos peloObject Management Group, que também é responsável hoje por darmanutenção na especificação da UML. Transformações QVT tornam possívelque um modelo UML seja facilmente transformado em outro artefato, como porexemplo código fonte. Mesmo com estas facilidades, as transformações ainda encontramalguns problemas, como o caso da herança múltipla. Enquanto é possívelmodelar diagramas que apresentam herança múltipla em UML, algumaslinguagens, como Java e C#, não tem suporte a esta construção do paradigmaorientado a objetos, então a transformação pode seguir por caminhosdiferentes do esperado. Em alguns momentos, também é necessário se prender a característicasespecíficas dos ambientes que nós estamos trabalhando para desenvolver osdiagramas UML, para estes casos existem os estereótipos que adicionamnovas qualidades a um modelo já existente sem que seja necessário alterardiretamente a modelagem atual. Um caso de uso para estereótipos é quandoestá se utilizando a especificação Enterprise Java Beans (EJB, [EJB07]) para adefinição das entidades do sistema. As entidades modeladas em si nãonecessitam saber que vão tornar-se EJBs, mas o modelo deve informar isso 25
  • 26. para que o gerador de código que vai gerar o código Java crie as classes deforma correta e correspondendo ao que a especificação EJB afirma. Além dos estereótipos também existe a possibilidade de se desenvolvermodelos com restrições embutidas dentro deles próprios, através do uso daObject Contraint Language (OCL, [WOCL07]) que foi uma das primeirasextensões à linguagem UML. Com ela é possível definir pré e pós-condiçõespara os modelos, através da definição de contratos e restrições, além detambém ser possível navegar entre os objetos do diagrama na forma de umalinguagem de consulta. 2.4. Gestão de modificações A gestão de modificações (Change Management, CM), tambémconhecida como gestão de configuração de software (Software ConfigurationManagement, SCM), é a atividade responsável por garantir a rastreabilidadedas mudanças sofridas por um artefato de software. Ela vem definir critériosque possam realizar tais modificações mantendo a consistência e a integridadedo software com os requisitos identificados e com as pessoas envolvidas noprocesso. Segundo [PRE06]: “Como modificações podem ocorrer em qualquer época, as atividadesde SCM são desenvolvidas para (1) identificar modificações, (2) controlarmodificações, (3) garantir que as modificações sejam adequadamenteimplementadas e (4) relatar as modificações a outros que possam terinteresse”. 26
  • 27. Através desse controle, é possível diminuir os problemas e gargaloscriados através de problemas de comunicação entre as equipes ou pessoasque trabalham alterando um mesmo artefato de software. Ainda segundo[PRE06] “... A SCM pode ser vista como uma atividade de garantia dequalidade de software, que é aplicada ao longo de todo o processo desoftware”. Para garantir essa qualidade, ferramentas são utilizadas paraautomatizar estes processos seguindo um plano de gerência de configuraçãoque consiste em estabelecer normas, ferramentas e modelos que permitamgerenciar de maneira satisfatória os itens de configuração (código fonte,diagrama de classe e etc.) de um sistema. 2.4.1. CVS – Concurrent Versions System O CVS ou Concurrent Versions Systems é um dos mais utilizadossoftwares de controle de versão (Version Control) em projetos de software. Umsoftware de controle de versão, segundo [WRC07] é: “Revision control (also known as version control, source control or(source) code management (SCM)) is the management of multiple revisions ofthe same unit of information. It is most commonly used in engineering andsoftware development to manage ongoing development of digital documentslike application source code, art resources such as blueprints or electronicmodels and other critical information that may be worked on by a team ofpeople. Changes to these documents are identified by incrementing anassociated number or letter code, termed the "revision number", "revision level", 27
  • 28. or simply "revision" and associated historically with the person making thechange.” Ele é responsável pela manutenção e controle de alteração de códigosfonte e arquivos necessários para a geração dos artefatos de software, comoscripts de build, documentações externas ao código, definições de testes econfigurações para ferramentas de avaliação de código. O CVS baseou-se em uma ferramenta anterior, o Revision ControlSystem, que fazia o controle de revisões (alterações) em arquivos comuns detexto. Como apenas controlar as alterações no nível de arquivos não era osuficiente em projetos de software, o CVS criou o conceito de controle deprojetos e módulos, onde todo um conjunto de artefatos de software queformavam um projeto são versionados em conjunto. Em um ambiente sem uma ferramenta de controle de versão de códigofonte, todas as alterações dos arquivos teriam que ser salvas pelos própriosdesenvolvedores e dois desenvolvedores nunca poderiam alterar o mesmoarquivo ao mesmo tempo. Ter que salvar cada alteração em um arquivodiferente é trabalhoso e também poderia fazer com fosse utilizado espaço emdisco demais para desenvolver até mesmo a mais simples das aplicações,evitar que dois desenvolvedores alterem o mesmo arquivo também podeaumentar o tempo necessário para fazer uma alteração de software, mesmoque os dois estejam trabalhando em partes diferentes do arquivo (em funçõesdiferentes, por exemplo), porque enquanto um estiver alterando o outro não vaiser capaz de acessar o arquivo. Através do uso do CVS estas preocupações já não existem mais, poisquando um arquivo é alterado, ele guarda apenas a diferença entre o arquivo 28
  • 29. original e o alterado de forma que a quantidade de espaço utilizada é a mínimapossível. Ele também conta com ferramentas automáticas de resolução deconflitos que evitariam que os desenvolvedores fossem bloqueados de fazer oseu trabalho porque alguém já está alterando o arquivo. Quando duas ou maispessoas estão alterando o mesmo arquivo e enviam a modificação para ocontrole de versão, ele verifica se é capaz de fazer o “merge” (fusão) dos doisarquivos sem a necessidade de intromissão do usuário. Se ele não for capazde fazer isso sozinho, ele avisa ao usuário para que ele tome a decisão de oque deve ser enviado como alteração ou não, garantindo assim que osarquivos não vão ser corrompidos nem transformados em inválidos poralterações mal planejadas. Além destas características, ele também tem esquemas de marcação dearquivos através de “tags”, onde o usuário pode marcar um arquivo ou umconjunto deles com uma identificação para controles futuros, como por exemploquando uma versão é liberada para um cliente. Todo aquele código deve sermarcado com uma tag indicando a versão que está sendo liberada (1.0.0.0,por exemplo) para que no futuro se houverem problemas no software elespossam rastrear exatamente quais são os arquivos que fizeram parte dela. Nele também existe o mecanismo de “branches” que são utilizados paracriar linhas de desenvolvimento alternativas de um projeto, comuns quando énecessário adicionar novas funcionalidades que podem entrar em conflito oucausar alguma quebra no comportamento atual do produto. O CVS anda perdendo muito espaço no mercado de sistemas decontrole de versão de código fonte para a ferramenta Subversion (SVN,[WSVN07]), que nasceu com o propósito de substituir e resolver alguns dos 29
  • 30. problemas mais comuns de uso do CVS. Entre estes problemas está aincapacidade do CVS de renomear ou mover arquivos e manter o histórico dealterações deles e a falta de “commits” atômicos, se enquanto você estiverenviando dados para o servidor CVS ocorrer algum problema de qualquer umdos lados, o envio de informações é parado mas as informações que já haviamsido enviadas, mesmo que incompletas, são colocadas no repositório docontrole de versão, ele não garante transações no formato “all-of-nothing”, oque pode causar problemas de informações inconsistentes ou desatualizadasno servidor. Segundo estatísticas coletadas pela [CIA07] o Subversion hoje jáultrapassou o uso do CVS para projetos open-source no mundo. 2.4.2. PhElips O PhElips é uma ferramenta interna da Phoebus Tecnologia quefunciona como um gerenciador de casos (Issue Tracker), tanto para cadastrarbugs e problemas nas aplicações como também para controlar as atividadesdos desenvolvedores e das equipes envolvidas no projeto. A ferramenta é baseada em uma antiga ferramenta open sourceconhecida como Elips ([ELP07]), que não se encontra mais emdesenvolvimento e o seu projeto no SourceForge ([SFN07]) está desativado,portanto não há mais manutenção para o seu código. Isso fez com que aprópria empresa começasse a personalizar a aplicação conforme as suasnecessidades, o que vem acontecendo até os dias de hoje. 30
  • 31. Ela funciona controlando os casos e as atividades que cada pessoadesignada para o caso fazem, contando assim com um histórico de quantotempo e recursos foram gastos para resolver um devido problema. Imagem 3 – Lista de casos do PhElips Estruturalmente, a aplicação web que é a interface para o PhElips éconstruída através de scriptlets JSP e classes Java que geram código HTML,técnicas que vão contra os modelos que pregam a separação em camadas dasaplicações, pois elas misturam a lógica da aplicação com a lógica davisualização, complicando a manutenção do sistema como um todo. 31
  • 32. 2.4.3. Maven O Maven é uma ferramenta de gerência e compreensão de projetos. Elegerencia projetos desde a sua criação (com a geração do esqueleto inicial dosistema) até a sua implantação em um servidor (remoto ou não). O Maven mantém todas as informações do projeto em um único lugar, oProject Object Model (POM), que é o arquivo de configuração do projeto ondesão definidas todas as suas características. No POM são definidas desdeinformações básicas do projeto, como nome, desenvolvedores, repositórios decódigo fonte (sistemas de controle de versão, como CVS e Subversion), comosuas dependências em bibliotecas externas e até mesmo plugins do próprioMaven que são utilizados para facilitar a vida dos desenvolvedores, como umservidor web embutido que executa diretamente de dentro do projeto. Além de tudo isso, ele é uma ferramenta que prega a padronização dosprojetos. Se você conhece a estrutura de um projeto básico do Maven, não vaiter problemas para entender outro projeto que também siga a mesma estruturae isso diminui drasticamente o tempo que o desenvolvedor vai levar para“entrar” no novo sistema, pois ele não vai precisar entender uma nova estruturaou aprender novos conceitos. O Maven também segue a premissa da “convenção sobre configuração”([CoC07]), onde se você segue o padrão, não é necessário dizê-lo que vocêestá fazendo isso. Um exemplo clássico desta característica é a estrutura dediretórios, se você segue toda a estrutura de diretórios padrão no seu projeto,não vai precisar dizer ao plugin do compilador Javac onde ficam os seus 32
  • 33. arquivos de código fonte nem pra onde ele deve copiar os arquivos “.class”resultantes, ele já sabe exatamente onde procurar por tudo. A estrutura padrão de diretórios para projetos Java e a seguinte: • pom.xml -- Arquivo de configuração do projeto • src/ -- pasta raiz – main/ -- tronco principal • java/ -- código fonte Java • resources/ -- recursos (arquivos de configuração, imagens, etc) • webapp/ -- aplicação web Java – test/ -- tronco de testes unitários e de integração • java/ -- código fonte dos testes do JUnit • resources/ -- recursos dos testes – site/ -- tronco principal da documentação Ele foi desenvolvido originalmente pela equipe do projeto JakartaTurbine com o objetivo de simplificar os “build files” do Ant utilizados no projeto.Eles estavam procurando por uma maneira de deixar todos os projetosseguindo uma mesma estrutura padronizada e também queriam não ter maisque enviar os arquivos “.jar” das dependências para os sistemas de controle deversão, foi então que surgiu a primeira versão da ferramenta, que em 2005 foicompletamente reescrita, resultando no Maven 2, que foi construído sobre todaa experiência dos desenvolvedores e usuários da primeira versão. Em [BBM07] as funcionalidades que o Maven provê são: • Abstrair o ato de construir um software, de forma que o desenvolvedor não precise se preocupar com os detalhes de invocar um compilador, gerar um artefato executável e etc; 33
  • 34. • Definir uma estrutura padronizada para todos os projetos, de forma que se um desenvolvedor é capaz de entender a estrutura de um, pode entender a estrutura de todos os outros; • Remover a dependência de que o software esteja em uma máquina específica para que o artefato seja gerado, através do uso do Maven um artefato pode ser gerado por qualquer máquina que tenha acesso ao repositório de dependências; Projetos gerenciados por ele são facilmente reproduzíveis em qualquermáquina que tenha acesso ao código fonte e aos mesmos repositórios ou arepositórios que contenham os artefatos que o projeto necessita. Desse modoas pessoas responsáveis pelos “builds” não precisam sempre utilizar umamáquina específica ou configurar um ambiente específico para gerar versõesdos projetos, qualquer uma das máquinas que tenha o Maven instalado écapaz de fazer todas as operações sobre o projeto. Além das vantagens de padronização e da facilidade de se reproduzir osbuilds, ele também contém diversos plugins que ajudam na garantia dequalidade de código, como os que fazem engenharia reversa do código paramodelos UML, avaliadores de métricas de qualidade de software, execução detestes unitários, funcionais e não funcionais, avaliadores de estilo de código egeradores automáticos de documentação através do código fonte. Trabalhandosempre de forma distribuída e acessando apenas os recursos que sãonecessários naquele momento, o Maven garante que o uso de recursos (comodisco e rede) serão sempre racionalizados, pois ele nunca vai requisitardependências externas que não sejam absolutamente necessárias para osprojetos em questão. 34
  • 35. 2.5. A Plataforma Java A linguagem de programação orientada a objetos Java ([SJAVA07]) éhoje uma das mais utilizadas linguagens de programação do mundo, nodesenvolvimento de aplicações servidoras, em aplicações para celulares,smartphones e PDAs e em uma pequena parte também para aplicaçõesdesktop. Da mesma forma que ela se subdivide no mercado, também ésubdividida em partes para aplicações desktop, o Java Standard Edition,aplicações servidoras, o Java Enterprise Edition e para aplicações paradispositivos móveis ou com pouco poder de processamento, o Java MicroEdition. A linguagem e as especificações são definidas por um consórcio deempresas e pessoas físicas que trabalham no Java Community Process (JCP,[JCP07]), definindo especificações e implementações de referência para asmesmas, de forma que qualquer pessoa pode participar da criação eimplementação das características da linguagem. O JCP funciona através devotações para as especificações, quando uma nova especificação é enviadapra o grupo, ela recebe uma avaliação geral e em uma votação com os seusmembros é definido se ela deve ou não começar a ser produzida. Apenasespecificações que são aceitas na votação são aceitas pelo JCP e podem fazerparte oficialmente da plataforma Java. Mesmo com toda esta estrutura formal, a linguagem conseguiu formaruma comunidade gigantesca de desenvolvedores e projetos open source,chegando até mesmo a ultrapassar a linguagem C em projetos mantidos no 35
  • 36. site SourceForge.net. A comunidade open source do Java também foiresponsável por causar grandes mudanças nas especificações da linguagem,como na área de mapeamento objeto/relacional, onde a especificação EJB foirevista para se assemelhar mais a produtos que surgiram como ferramentasopen source, que foi o caso do Hibernate ([JPH07]). Sendo uma das primeiras linguagens a introduzir comercialmente comsucesso a idéia de máquinas virtuais, Java mudou o modo como as pessoasviam o desenvolvimento de aplicações, como explica [BAT05]: “(...) Javas virtual machine simply redefines the machine, providing alower-level, firmer foundation for portability. Java designers bet that they couldovercome performance concerns. It was not a new idea; nor was it a popularone. Over time, they proved to be right. Just-in-time compilers improvedperformance so that the overhead of the JVM became acceptable, and evenrivaled compiled languages. The virtual machine, built into Netscape Navigator,proved to be a fantastic launching pad for the Java platform. Its enabled Javato extend into the realm of mobile devices, application servers, and countlesssoftware products. When all is said and done, popularizing the idea of the VMmay be the most important technical contribution of Java.” Tendo como principal apelo a independência de plataforma, a linguagemJava tornou-se rapidamente a linguagem principal da maior parte dasempresas e até mesmo das universidades mundo afora. Além dessacaracterística, outras fizeram com que a linguagem atingisse o sucesso quetem hoje ([BAT05]): 36
  • 37. • Sintaxe muito próxima a C++, o que fez com que a grande massa de programadores C++ não tivesse problemas para migrar de linguagem; • Pronta para a internet: A criação dos servlets, que acabavam com a maior parte dos problemas enfrentados com aplicações baseadas em CGI, levou muitas equipes a migrar pra Java; • Pronta para a integração de aplicações. Utilizada desde cedo para integrar aplicações de diversas maneiras diferentes, é uma das poucas linguagens que provê facilidades para criar servidores de mensagens, transações distribuídas e aplicações completamente distribuídas; • Formação da comunidade. Java conseguiu formar uma comunidade de desenvolvedores em torno da linguagem de forma que eles mesmos contribuíam com o aumento da mão de obra, através de grupos de usuários, palestras e eventos independentes da própria Sun ou outras empresas interesadas; A linguagem hoje já ultrapassou as barreiras da sua simples sintaxe etransformou-se numa plataforma de desenvolvimento que abarca outraslinguagens de programação, como Ruby ([JRUBY07]), Scala ([SCALA07]) evárias outras. A tendência atual do mercado é que a linguagem Java caialentamente em desuso enquanto outras linguagens tomam o seu espaço namáquina virtual da plataforma, como a própria Sun vem demonstrando com osseus investimentos massivos em JRuby, com a contratação dosdesenvolvedores da ferramenta para a sua equipe de desenvolvimento e a 37
  • 38. adição de JavaScript como primeira linguagem dinâmica oficialmente suportadapela máquina virtual a partir da versão 6 do Java. Tendo diversos problemas quando comparada a linguagens maisdinâmicas, como Smalltalk, Python ou Ruby, Java é duramente criticada quantoa sua natureza estática e pouco personalizável, como pode ser visto em[BAT05]: “First, Java offers an impoverished set of abstractions. No first-classfunctions, no reference parameters, no keyword or default params, nodestructuring bind or even parallel assignment, no way to return multiple valuesefficiently, no continuations, no user-defined operators, no generators, noclosures, no tuples...the list just goes on. Javas about 25 teeth shy of a fullmouth. Second, Java is entirely nonextensible. It cant grow. Theres nometaprogramming, no macros, no templates, nothing that gives you syntacticabstraction. So, Javas incompressible. Java code is always filled with stuff thatlooks like copy and paste, but you cant factor it out. Java code and APIs alwayswind up bloated (and yet oddly impressive looking).” A abertura de espaço para novas linguagens pode abrir espaço para quea plataforma Java continue crescendo além das possibilidades que alinguagem provê nos dias de hoje. 2.5.1. JavaServer Faces JavaServer Faces (JSF, [JIA04]) é o framework especificado pelo JCPatravés da Java Specification Request (JSR) 127, a qual faz parte da 38
  • 39. especificação guarda-chuva da plataforma Java EE. JSF é uma tecnologia queincorpora características de um framework Model View Controller (MVC) paraweb e de um modelo de interfaces gráficas baseadas em componentes querespondem a eventos do usuário. Como [JIA04] afirma, a especificação JSF tem um objetivo específico: “JavaServer Faces has a specific goal: to make web development fasterand easier. It allows developers to think in terms of components, events,backing beans, and their interactions, instead of requests, responses, andmarkup. In other words, it masks a lot of the complexities of web developmentso that developers can focus on what they do best — build applications.” A proposta do padrão MVC é dividir uma aplicação em três camadas:modelo (model), visualização (view) e controle (controller), como é definido em[GHJV98]: “MVC consists of three kinds of objects. The Model is the applicationobject, the View is its screen presentation, and the Controller defines the waythe user interface reacts to user input. Before MVC, user interface designstended to lump these objects together. MVC decouples them to increaseflexibility and reuse.“ Com essa separação em camadas e responsabilidades, os objetos domodelo não ficam mais poluídos com informações da camada de visualização,pois agora eles interagem apenas indiretamente, quando o objeto que faz opapel de controlador envia as informações de um lado para o outro, fazendo opapel de um Mediator ([GHJV98]). A estrutura do MVC no JSF é definida pelaimagem seguinte: 39
  • 40. Figura 4 - Arquitetura de uma aplicação JSF A parte que representa o controlador em uma aplicação JSF se inicia noFacesServlet, que é um objeto que implementa o padrão de projeto “FrontController” visto em [FOWPOEAA02], que é definido como: “The Front Controller consolidates all request handling by channelingrequests through a single handler object. This object can carry out commonbehavior, which can be modified at runtime with decorators. The handler thendispatches to command objects for behavior particular to a request. (...) A FrontController handles all calls for a Web site, and is usually structured in two parts:a Web handler and a command hierarchy. The Web handler is the object thatactually receives post or get requests from the Web server. It pulls just enoughinformation from the URL and the request to decide what kind of action toinitiate and then delegates to a command to carry out the action“ No JSF, o “Front Controller” envia as informações para um objeto que échamando na especificação de “backing bean”, que no fim vai ser responsávelpor fazer o processamento da requisição HTTP e retornar um resultado para ousuário, sendo uma nova página JSF, um arquivo ou um redirecionamento para 40
  • 41. outro recurso no servidor. Os “backing beans” ainda estão na camada decontrole do MVC, mas são eles que fazem o acesso aos objetos do modelopara carregar as informações, tanto trazendo informações da camada devisualização para o modelo como também seguindo no caminho contrário,trazendo informações do modelo para a camada de visualização. Os “backing beans” também são os objetos que respondem diretamenteas interações do usuário com os controles que estão sendo mostrados na tela,como listas de seleção, campos de edição e botões de envio de informações.Quando um destes componentes é selecionado, um evento é acionado no“backing bean” correspondente, fazendo com que esse objeto responda aoevento com alguma ação que possa alterar o modelo, como por exemploadicionar ou atualizar um objeto no banco de dados. A camada de visualização em uma aplicação JSF segue outro padrãovisto em [FOWPOEAA02], que é o “Template View”: “The basic idea of Template View is to embed markers into a staticHTML page when its written. When the page is used to service a request, themarkers are replaced by the results of some computation, such as a databasequery. This way the page can be laid out in the usual manner, often withWYSIWYG editors, often by people who arent programmers. The markers thencommunicate with real programs to put in the results. A lot of tools use Template View. As a result this pattern isnt about howto build one yourself, but about how to use one effectively and what thealternative is.” A principal diferença entre a implementação do padrão em JSF paraoutras alternativas, como JavaServer Pages ou engines de templates como 41
  • 42. Velocity ou FreeMarker, é que a estrutura da visualização de uma página JSFnão segue simplesmente a marcação HTML/XHTML, mas sim uma estrutura decomponentes visuais que se desenham na tela, como em uma aplicaçãodesktop. Uma página JSF é um conjunto de componentes que formam umaárvore e que são desenhados por objetos específicos, chamados de“renderers”, que são no fim os objetos responsáveis pela geração do que évisto pelo usuário final. Com essa separação do componente da sua representação visual, épossível reutilizar uma mesma página JSF para gerar resultados diferentes,como uma página em XUL ou WML, bastando apenas que o “renderer” doscomponentes seja alterado para um que dê suporte a outro tipo devisualização. Além da personalização do modo pelo qual os componentes sãogerados para o usuário final, a especificação JSF também define outros pontosde extensão, para que os desenvolvedores possam alterar o funcionamentodas aplicações sem que seja necessário alterar o código do modelo delas,como por exemplo na redefinição das políticas de navegação entre páginas ouno modo pelo qual os componentes visuais persistem o seu estado. O desenvolvimento de aplicações web baseadas em componentes, quesempre foi fato comum em tecnologias como o .Net ([.NET07]) da Microsft, sóagora chega a comunidade Java, mas parece não estar arrebanhando muitosseguidores. A quantidade de frameworks web MVC que seguem o padrão de“action”, como o framework Struts ([STRUTS07]), continuam se proliferando emesmo com todas as ferramentas e vantagens propostas pelo JSF, ele não 42
  • 43. vem alcançando a penetração esperada no mercado de ferramentas paradesenvolvimento de aplicações web em Java. 2.6. O Projeto Eclipse O projeto Eclipse ([ECP07]) surgiu de uma necessidade da IBM([IBM07]] de integrar todas as suas aplicações desktop em uma base comumde software para evitar o retrabalho e aumentar o reuso, como afirmam[JDE05]: “(...) Launched in open source in the fall of 2001, Eclipse hás come along way from it’s roots as na internal project at IBM’s OTI subsidiary –designed originally as a way for IBM to integrate it’s desktop tools onto acommom software base.” Nascida com a premissa de funcionar como um integrador de váriasferramentas através da sua estrutura de plugins, o Eclipse reúne diversasferramentas dentro de uma só, para facilitar a vida do desenvolvedor deaplicações. Durante as tarefas comuns de desenvolvimento de código, o profissionalnormalmente tem que lidar com diversas ferramentas distintas e que muitasvezes não conversam entre si. Ele usa um ambiente de desenvolvimento dasua linguagem para escrever o seu código, utiliza uma ferramenta de “build”como o GNU Make ([GMAKE07]) e uma ferramenta de controle de versãocomo o CVS. Para fazer o seu trabalho de forma satisfatória ele precisa trocarconstantemente de aplicação e cada uma dessas trocas de contexto faz comque ele perca a concentração no trabalho que está fazendo. 43
  • 44. Utilizando uma ferramenta que integra todas estas ferramentas em umasó, como o Eclipse faz, o programador não precisa mais sair da ferramenta queestá utilizando no momento para fazer o seu trabalho, ele simplesmenteescolhe os comandos que deseja operar. De dentro da própria ferramenta elepode editar e compilar o seu código, chamar uma ferramenta de automatizaçãode “build”, executar os testes unitários, funcionais e não funcionais e aindamandar as suas alterações diretamente para o sistema de controle de versão.Evitar a troca de contexto faz com que o profissional concentre-se apenas emações que geram valor para o seu trabalho, que é desenvolver software, emvez de perder tempo lidando com ferramentas pouco intuitivas ou que não seintegram corretamente. Hoje o Eclipse já não está direcionado apenas aos desenvolvedores deferramentas para facilitar o desenvolvimento, mas também para odesenvolvimento de aplicações para o usuário final, como bem observam[JDE05]. Com essa separação vinda na versão 3.0 da ferramenta, diversosprojetos começaram a utilizar as bibliotecas disponíveis através da ferramenta,como o conjunto de componentes visuais Standard Widget Toolkit (SWT,[SWTIA05]). O Eclipse RCP permite que sejam desenvolvidas aplicaçõesutilizando todas as qualidades básicas do ambiente de desenvolvimento deplugins, como possibilidade de se ter diversas versões da mesma dependênciade forma independente, atualizações automáticas através da internet ou dearquivos de atualização, compatibilidade com o estilo da visualização doscomponentes no sistema operacional onde a aplicação está executando. 44
  • 45. 2.6.1. SWT – Standard Widget Toolkit e JFace O SWT é o conjunto de componentes visuais desenvolvidos junto com oprojeto Eclipse para que não fosse necessário utilizar as bibliotecas padrão doJava na criação das interfaces gráficas. O SWT acessa diretamente asbibliotecas de interface gráfica e despacho de eventos do sistema operacional,aumentando a performance das aplicações, já que a execução de código deinterface não ocorre mais na máquina virtual e sim diretamente em códigonativo sempre. O JFace é uma biblioteca de abstração para o uso do SWT, eleprovê facilidades para o programador, simplificando a criação de aplicaçõesutilizando o SWT. Mesmo não tendo implementações para todos os sistemas operacionaissuportados pela plataforma Java e apresentando alguns problemas nas suasdiversas implementações, o SWT é a escolha de uso da ferramenta Java maisutilizada na atualidade, que é o Eclipse, e isso conta muito na sua adoção nomercado, além das vantagens de performance e visualização. 2.7. Inversão de Controle O princípio da inversão de controle (Inversion of Control - IoC) tem comoobjetivo oferecer uma maneira simples de prover dependências de objetos emforma de componentes e gerenciar o ciclo de vida dessas dependências.Containeres de IoC servem para fazer a ligação entre dependentes edependências, fazendo isso de várias maneiras diferentes. A IoC ainda sesubdivide em injeção de dependências (Dependency Injection) e busca por 45
  • 46. dependências (Dependency Lookup). A inversão de controle é mais comum doque podemos imaginar, como é exemplificado em [FOWIOC07]: “These are complicated cases of inversion of control, but you run into thiseffect in much simpler situations. A template method is a good example: thesuper-class defines the flow of control, subclasses extend this overridingmethods or implementing abstract methods to do the extension. So in JUnit, theframework code calls setUp and tearDown methods for you to create and cleanup your text fixture. It does the calling, your code reacts - so again control isinverted.” Em uma coisa simples como a implementação do padrão de projeto“template method” nós já podemos perceber o poder da inversão de controle,outro padrão que também é um bom exemplo disso é o Observer/Observable,um objeto registrado nunca sabe quando vai receber um aviso do observable,mas mesmo assim o objeto se registra nele esperando até que ele lhe envieuma notificação, então mais uma vez não é o objeto quem chama, quem o fazé o observable. Uma das primeiras referências a inversão de controle pode ser vista em[RES85], quando ele fala sobre o “princípio de Hollywood”: “Don‘t call us, we’ll call you (Hollywood’s Law). A tool should arrange forTajo to notify it when the user wishes to communicate some event to the tool,rather than adopt an ‘ask the user for a command and execute it’ model.” O princípio, “não nos chame, nós chamamos você” é à base da inversãode controle e também é a base da maioria dos frameworks que nós vemoshoje, eles definem uma base, nós estendemos essa base e o framework faz as 46
  • 47. chamadas quando for necessário, fazendo com que o nosso código nãoprecise depender diretamente de quem o está chamando. Outro exemplo aindamais comum é quando nós colocamos um “ActionListener” no evento de cliquede um botão, nós não sabemos quando é que o botão vai ser clicado, nóssimplesmente esperamos que ele clique e alguém “nos avisa” que ele foiclicado para que possamos executar alguma ação durante esse tempo. 2.7.1. Busca por dependências (Dependency Lookup) A busca por dependências é a maneira mais conhecida de IoC,especialmente para programadores Java. Nela, os objetos procuramativamente por suas dependências, como por exemplo quando fazemos umabusca em um contexto Java Naming and Directory Interface(JNDI, [JNDI07])ou quando buscamos um objeto em um container do servidor de aplicações. As implementações que usam esse tipo de abordagem normalmentefazem com que seus objetos tenham acesso a estes objetos através de umobjeto que implementa o padrão de projeto “Service Locator”, encontrado em[CJPC07]. Ele é definido como: “Enterprise applications require a way to look up the service objects thatprovide access to distributed components. Java 2 Platform, Enterprise Edition TM(J2EE) applications use Java Naming and Directory Interface (JNDI) to look upenterprise bean home interfaces, Java Message Service (JMS) components,data sources, connections, and connection factories. Repetitious lookup codemakes code difficult to read and maintain. Furthermore, unnecessary JNDI 47
  • 48. initial context creation and service object lookups can can cause performanceproblems. The Service Locator pattern centralizes distributed service objectlookups, provides a centralized point of control, and may act as a cache thateliminates redundant lookups. It also encapsulates any vendor-specific featuresof the lookup process. “ Através do uso do “Service Locator” nós já aumentamos o nível deindireção da aplicação, mas ainda assim a aplicação tem que dependerexplicitamente do objeto que implementa o locator, quando o que na verdadenos interessa é o objeto que ele está buscando em algum lugar. O meio peloqual as dependências estão sendo encontradas, seja um contexto JNDI,mensagens, EJBs, já não é mais visível para a aplicação, mas o nível deacoplamento com objetos que não fazem parte diretamente do domíniocontinua alto. 2.7.2. Injeção de dependências – (Dependecy Injection) A injeção de dependências é uma nova abordagem para IoC, nela osobjetos não procuram por suas dependências, elas são inseridas neles pelocontainer de IoC. Ela é feita de duas maneiras diferentes, através do construtordo objeto (passando as dependências como argumentos do construtor) ouatravés de métodos “getter” e “setters” da especificação JavaBeans ([JB07]).A injeção de dependências é a melhor maneira de se trabalhar com IoC, 48
  • 49. porque ela não polui o código com chamadas para o container ou “servicelocators” como no caso da busca por dependências. Os objetos não ficampresos a uma implementação específica porque eles não “sabem” como asdependências foram parar ali, eles apenas as usam. Com a utilização desse modo de inversão de controle nós diminuímos oacoplamento ao mínimo possível, pois os objetos acessam apenas os objetoscom os quais eles precisam colaborar, não precisam mais acessar objetosintermediários que trabalham como fábricas ou fontes dos objetos que elesnecessitam para fazer os seus trabalhos. A inversão de controle normalmente é possibilitada por containers deinversão de controle, como o Spring, que é um dos mais utilizados frameworksde inversão de controle na comunidade Java. 2.7.3. O framework Spring O framework é um container de inversão de controle baseado nospreceitos da injeção de dependências, através dele é possível interrelacionaros diversos objetos de uma aplicação Java sem que eles precisem saber deonde vieram as suas dependências ou o que elas fizeram para que pudessemchegar até eles. Mas o container de inversão de controle é apenas uma daspartes do framework, esse container funciona, segundo [SPR07] da seguinteforma: “The IoC component of the Spring Framework addresses the enterpriseconcern of taking the classes, objects, and services that are to compose anapplication, by providing a formalized means of composing these various 49
  • 50. disparate components into a fully working application ready for use. The SpringFramework takes best practices that have been proven over the years innumerous applications and formalized as design patterns, and actually codifiesthese patterns as first class objects that you as an architect and developer cantake away and integrate into your own application(s). This is a Very Good ThingIndeed as attested to by the numerous organizations and institutions that haveused the Spring Framework to engineer robust, maintainable applications.“ O Spring funciona como um grande contexto onde todos os objetosgerenciados residem, eles são interrelacionados através da configuração deste x 9/7/07 08:50 Deleted: -contexto em arquivos específicos do Spring, que é capaz de instânciá-los ecolocar informações e objetos em suas propriedades. O contexto em sifunciona como um “service locator”, a única diferença é que nenhum dosobjetos que está sendo gerenciado toma conhecimento do “service locator” (anão ser que ele avise explicitamente que deseja acessar ele), ele mesmo faz abusca de todas as dependências e as coloca dentro dos objetos que estágerenciando. Além do container de inversão de controle, o framework contém outrosseis módulos, conforme a figura a seguir: 50
  • 51. Figura 5 – Módulos do framework SpringOs módulos tem como responsabilidades: • Spring AOP: Oferecer suporte e infra estrutura para implementação de programação orientada a aspectos (Aspect Oriented Programming – AOP). O framework provê funcionalidades baseadas em AOP em tempo de execução para os objetos que sejam gerenciados por ele. • Spring ORM: Facilita o uso de ferramentas de mapeamento objeto relacional, criando uma hierarquia de exceções padronizada para todas as ferramentas assim como classes utilitárias para simplificar a utilização de tais frameworks. • Spring Web: Provê funcionalidades simples para aplicações web que fazem o uso do Spring, como um contexto especial para carregar aplicações web.51
  • 52. • Spring DAO: Provê classes utilitárias para a implementação de objetos que seguem o padrão de projeto Data Acess Object, encontrado em [CJPC07]. Através do uso destas classes é possível fazer a demarcação declarativa de transações, sem a necessidade de se utilizar EJBs ou “container managed transactions”. • Spring Context: É o módulo do container de inversão de controle, já explicado anteriormente. • Spring Web MVC: É o módulo do framework que implementa um framework web baseado no MVC e no paradigma de “Actions”, visto também em [STRUTS07]. O Spring Web MVC não se diferencia muito dos outros frameworks web em Java que se baseiam no mesmo paradigma, a sua principal vantagem é já ser completamente integrado com o framework Spring pra as suas ações. Uma das vantagens dele frente a outras ferramentas é a completa abstração da camada de visualização, pois um mesmo “Action” poderia gerar um resultado como HTML e logo após como PDF, bastando apenas que ele alterasse a configuração para isso, sem que fosse necessário alterar o código da aplicação. • Spring Core: é o módulo raiz onde estão as funcionalidades básicas e utilitários do framework. Além destes módulos, o framework também contém integrações comdiversos outros frameworks que fazem serviços distintos mas que são de usocomum em aplicações Java, tanto desktop como web. Um dos exemplos disso 52
  • 53. é a integração com as bibliotecas padrão de envio de e-mails do Java,simplificando o seu uso ou a integração com outros serviços padronizados,como JNDI. O objetivo maior do Spring não é criar mais uma nova solução para umantigo problema, mas sim se aproveitar das ferramentas que existem hoje parasimplificar a resolução das dificuldades que foram encontradas. Por isso eleestá muito mais interessado em integrar os diversos frameworks de formahomogênea do que simplesmente criar novos frameworks para competir comos que já estão disponíveis no mercado. 53
  • 54. 3. Atividades realizadas O trabalho desenvolvido durante o estágio foi o de projetar eimplementar a aplicação Report Center e o framework de componentes deinterface Phrame UI, possibilitando a criação de aplicações para a web e para odesktop de forma transparente, utilizando as tecnologias e técnicasapresentadas na seção 2. As atividades serão separadas a partir de agora porcada artefato produzido. 3.1. Report Center O Report Center é uma aplicação de apresentação de relatórios para aweb, que acessa um gerador de relatórios baseado na ferramenta CrystalReports ([CRPT07]), ela apresenta um formulário com os dados necessáriospara executar o relatório e após o preenchimento destes dados, a aplicaçãoinvoca o gerador de relatórios para que ele gere o resultado para o cliente. Antes do início do meu trabalho com a ferramenta, o projeto estavaparado há mais de um ano e utilizava tecnologias defasadas no mercado, como“scriptlets” em páginas JavaServer Pages puras, o que segue contra aseparação da aplicação em camadas. A aplicação também não fazia acessodireto a bancos de dados nem tinha um modelo de objetos que representasseos objetos com os quais ela trabalhava, que eram os relatórios, as telas de filtroe os campos que deveriam aparecer nas telas de filtro. A ferramenta havia surgido dos pedidos de vários clientes de ter algummeio de acessar as informações dos seus bancos de dados através de 54
  • 55. relatórios sem que fosse necessário instalar uma aplicação desktop completapara isso. Eles desejavam acessar o sistema de forma remota tendo comocliente apenas um simples navegador web. 3.1.1. Requisitos funcionais Os requisitos funcionais iniciais para a aplicação eram: • Controle de acesso a relatórios através dos perfis dos usuários. Cada usuário teria os seus próprios direitos para acessar ou não os relatórios que estavam cadastrados no banco de dados; • Listagem dos relatórios disponíveis através de uma estrutura em árvore, de forma que os relatórios fossem organizados em grupos, como os que já existiam nas ferramentas desktop de visualização de relatórios; • Filtros específicos com as informações de filtragem para cada um dos relatórios disponíveis, de forma que o usuário pudesse facilmente selecionar as informações no formulário para obter relatórios com base nas variáveis que ele informaria; • Os campos dos filtros devem ser capazes de criar vínculos de mestre-detalhe entre eles; • Integração e acesso aos bancos de dados das aplicações transacionais, para obter informações necessárias a filtragem dos dados; • Integração com a ferramenta Report Server que é responsável pela geração real do relatório acessando bibliotecas nativas do Crystal Reports; 55
  • 56. 3.1.2. Requisitos não funcionais Os requisitos não funcionais da aplicação foram definidos inicialmentecomo os seguintes: • Utilizar interface web pura, com XHTML e JavaScript. Applets ou outras ferramentas intrusivas estão fora de escopo; • Ser compatível com a maior gama de navegadores possível, mas ser compatível preferencialmente com as últimas versões do Internet Explorer; • Ter uma interface tão próxima quanto possível da interface web, além de simples e intuitiva para o usuário final; • Causar o mínimo de impacto possível nos sistemas transacionais quando for necessário gerar os relatórios, pois eles são prioritários e não podem ter as suas funcionalidades atrasadas por causa do gerador de relatórios; • A ferramenta deve ser capaz de diagnosticar facilmente falhas de comunicação com a aplicação Report Server, de forma que seja simples descobrir onde está a real causa do problema. 3.1.3. Seleção de tecnologias Baseando-se nos requisitos da aplicação, o primeiro passo foi definir astecnologias que seriam utilizadas no decorrer da implementação. Para acamada de apresentação, resolveu-se utilizar JavaServer Faces por ser a que 56
  • 57. faria com que a experiência fosse a mais próxima possível da encontrada pelosusuários nas aplicações desktop. A opção por JSF também se deu baseando-se nos conjuntos de componentes visuais prontos que já estavam disponíveisno mercado, de forma que muito do trabalho de geração de interfaces gráficasseria evitado com o simples uso destes componentes. O framework Spring foi selecionado como container de inversão decontrole padrão tanto pelas suas qualidades no campo de containers IoC, comotambém pela farta documentação encontrada tanto em livros como em sitesespecializados. A integração completa com JSF também foi um dos fatos quepesou a favor dele, pois nada seria necessário para fazer com que elefuncionasse junto com a aplicação JSF, ele já vem integrado “out-of-the-box”com o framework. Para opção de acesso a banco de dados, a solução de mapeamentoobjeto-relacional Hibernate, foi escolhida pela sua grande penetração demercado e apoio de uma grande comunidade, também com muitadocumentação e exemplos de uso. 3.1.4. Modelagem e implementação do sistema A partir da definição inicial dos requisitos do sistema, foi possívelcomeçar a definir o modelo de domínio da aplicação. Sabendo que a aplicaçãoé um gerador de relatórios, nós assumimos que o modelo deve ser baseadonos comportamentos necessários para que seja possível se acessar e gerarum relatório para o usuário final. Partimos então para o descobrimento dasentidades que seriam encontradas nesse modelo, através da análise dasinformações que haviam sido coletadas. 57
  • 58. As entidades Report, ReportFilter, ReportField, User e Right, são asentidades principais que nós encontramos no nosso sistema, é através delasque nós montamos a nossa lógica de negócio para resolver o problema dageração de relatórios. Além delas, nós temos também uma classe de serviço, que é aReportServer que abstrai toda a comunicação do Report Center com o servidorde relatórios Report Server. Através desta abstração, a aplicação não precisasaber que os relatórios estão vindo de uma aplicação externa, aimplementação poderia ser facilmente alterada para um gerador de relatóriospróprio e isso não causaria impacto algum na aplicação, pois ela não conheceo real comportamento do objeto, conhece apenas a interface que ele exporta eos contratos que ele exige que sejam mantidos. Para fazer a requisição da geração de um relatório, o código deve dizerao objeto ReportServer qual o relatório ele deseja que seja gerado e quais osvalores devem ser passados para os campos do relatório. Com apenas estasinformações, ele já é capaz de acessar o servidor externo e fazer a requisiçãode um relatório, se todos os dados houverem sido enviados corretamente, oservidor retorna o arquivo de relatório gerado que é então mostrado para ousuário final. A comunicação feita com o Report Server atualmente é feia com baseem sockets simples, o cliente envia uma requisição de relatório em formatoXML pelo socket e o servidor responde a essa requisição com um arquivo XMLde resposta e o relatório gerado se tudo houver corrido corretamente. Osarquivos XML são consumidos e gerados através do uso da API JDOM deparsing de arquivos XML. 58
  • 59. Além de gerar os relatórios, a aplicação Report Server também éresponsável por controlar o acesso de usuários aos relatórios, mas como oacúmulo de responsabilidades não é uma boa idéia em um sistema orientado aobjetos, para o Report Center a autorização e autenticação de usuários é feitaatravés do objeto “SecutityManager”, que atualmente faz uma chamada diretaao Report Server mas que futuramente pode fazer a autenticação e autorizaçãoutilizando outros meios. Mais uma vez, alterar a implementação do “SecurityManager” não devecausar impactos na aplicação, pois ela não sabe como os usuários sãoautenticados ou autorizados, eles simplesmente acessam um serviço providopor um objeto que está na aplicação. 3.1.5. Arquitetura do sistema A arquitetura do sistema foi baseada no esquema de separação em trêscamadas encontrado em [FOWPOEAA02]. Na camada de visualização encontram-se os “backing beans” do JSF eas páginas JSF propriamente ditas, que geram os formulários de filtrobaseados no relatório que o usuário deseja gerar. Essa camada é responsávelpor obter informações do usuário e repassá-las para o modelo, para que elepossa fazer o seu trabalho e gerar o resultado que o usuário espera. Na camada de dados nós encontramos os objetos que fazem acesso abancos de dados. Todo o acesso a bancos de dados é feito através de objetosque implementam o padrão de projeto “Repository”, encontrado em [DDD03].Aqui nesta camada também poderiam estar os objetos que implementam os 59
  • 60. serviços baseados em mensagens, que são aqueles que enviam mensagenspara a aplicação Report Server. Entretanto, como ele estavam próximosdemais da necessidade real da aplicação, tornou-se mais lógico colocá-losdiretamente na camada de domínio, para que os objetos do domínio tomassemconhecimento destes objetos e pudessem utilizá-los como meio paradesenvolver as suas funcionalidades. Todo o acesso a banco de dados feito pelas classes que implementam opadrão Repository é feito através da ferramenta de mapeamento objetorelacional Hibernate. Dentro da aplicação ela é utilizada em conjunto com oframework Spring para prover controle declarativo de transações. Na camada de domínio encontram-se as entidades e os serviços que jáforam comentados na seção de modelagem e implementação do sistema. Estacamada encontra-se isolada das outras de forma que ela não acessadiretamente ou conhece nenhuma das outras camadas do sistema. Todo omodelo de domínio é independente da camada de visualização e de dados dosistema. Todo os relacionamentos dos objetos nas diversas camadas égerenciado pelo container de IoC do framework Spring, que tem, em seumódulo web, uma integração completa com a especificação JSF, de forma quetornou-se simples controlar e integrar os diversos objetos dentro da aplicação. 3.1.6. Problemas encontrados Durante a implementação da ferramenta, alguns problemas foramencontrados, entre eles destacaram-se: 60
  • 61. • A API JDOM é extremamente lenta quando comparada a outros meios de parsing de arquivos XML, bibliotecas baseadas em técnicas StAX ([WSTAX07]) foram até 50 vezes mais rápidas do que as suas contra-partes utilizando as técnicas do DOM em testes realizados no sistema; • A falta de uma biblioteca padrão para acessar relatórios do Crystal Reports através de uma aplicação Java gera uma complicação desnecessária para as aplicações, que necessitam acessar os recursos de relatórios indiretamente, como o Report Center precisa pedir ao Report Server que gere o relatório; • Os relatórios do Crystal Reports precisam ser compilados para um banco de dados específico, diferentemente de uma aplicação Java que acessa o banco de dados via JDBC, então para cada banco de dados que a aplicação de relatórios tiver que acessar, o relatório deve ser copiado e recompilado com as bibliotecas do novo banco. • Mesmo o uso de uma biblioteca padrão de componentes não evitou que a aplicação sofresse com a compatibilidade entre os browsers, o mais problemático de todos, o Internet Explorer, apresentou diversos problemas em suas configurações de segurança, evitando que os relatórios fossem abertos, apenas porque eram arquivos diferentes de páginas HTML. • A criação de componentes JSF “on-the-fly” em uma página e o relacionamento deles com propriedades dos “backing beans” em61
  • 62. tempo de execução é uma operação pouco documentada e difícil de ser implementada, o framework deveria fornecer um ponto de extensão mais simples para soluções que precisem adicionar componentes em tempo de execução. 3.1.7. Resultados e futuro A aplicação foi escrita, testada e hoje está implantada em clientes daempresa, já na sua fase de transição. Para o futuro existem novos requisitossurgindo, que devem abrir espaço para uma nova versão da aplicação. Um dosprincipais requisitos é a adição de novas engines de relatório que sejam Javapuro, para evitar os problemas enfrentados com a implementação atual doCrystal Reports, entre as possibilidades está o uso das ferramentasJasperReports ou Eclipse Birt. 3.2. Phrame UI O Phrame UI é um framework de componentes visuais que tem comoseu objetivo principal acabar com a necessidade de se escrever uma versãoweb para uma aplicação que já existe no desktop. Com o uso do Phrame UI épossível que uma mesma aplicação, execute de forma igual tanto em umambiente desktop como web, sem que seja necessário reescrever nenhumalinha de código. O framework faz parte de um conjunto de frameworks que estão emdesenvolvimento dentro da Phoebus pra atualizar toda a sua base deaplicações para a plataforma Java, este conjunto de frameworks recebeu onome coletivo de projeto Phrame. O objetivo destes diversos projetos é 62
  • 63. aumentar a velocidade com a qual as aplicações são escritas, garantindo oreuso entre as diversas implementações e garantindo também a qualidade docódigo, que é testado com freqüência para evitar que problemas surjam. O framework Phrame UI foi concebido inicialmente como sendo umaferramenta baseada em meta-dados e que faria o uso de transformadores XMLpara gerar o código de interface. Entretanto, o projeto seguiu por outro caminhoe tornou-se um conjunto de componentes visuais igual a qualquer outrabiblioteca de componentes. 3.2.1. Requisitos Funcionais Os requisitos funcionais definidos para o framework em seu primeiromomento foram: • Conjunto de componentes que contenha os itens mais comuns, como todos os controles de formulário; • Implementação baseada primariamente na instanciação de objetos e não através de meta-dados; • Conjunto simples de funcionalidades que faça com que seja possível e fácil de se “portar” novas bibliotecas de componentes; 3.2.2. Requisitos Não funcionais Os requisitos não funcionais do framework foram definidos como: • Conter pelo menos uma implementação para ambientes desktop e uma implementação para ambientes web; • A implementação web deve ser compatível com os browsers mais utilizados no mercado, especialmente com o Internet Explorer; 63
  • 64. • A solução web não pode fazer uso de clientes especiais, como Applets ou soluções em Flash; • O framework deve ser fácil de se utilizar e de se criar novos componentes; • O ambiente desktop deve fazer o possível para manter a aparência igual a das aplicações nativas do sistema; 3.2.3. Seleção de tecnologias Baseando-se nos requisitos repassados, partiu-se para a definição detecnologias. Para a implementação inicial da versão desktop do framework, foiselecionado o conjunto de componentes visuais do projeto Eclipse, o SWT,pois ele é mais rápido que as suas contra-partes em Java puro e ainda garanteque o “look and feel” das aplicações é sempre igual ao do sistema operacionalno qual ela está executando. Para a implementação da versão web, dois frameworks foramselecionados, o Echo 2 Framework ([ECHO07]) e o Thinwire ([THI07]). Naavaliação dos dois, o framework Thinwire demonstrou ter mais vantagens euma implementação mais sólida do modelo de componentes. A principalcaracterística que fez com que ele fosse selecionado no lugar do Echo 2, foi apossibilidade de posicionar os componentes de forma absoluta na tela donavegador do cliente, algo que é extremamente comum em aplicações desktope que é complexo de se conseguir em aplicações web. Com a adição dessa característica através do uso do Thinwire, tambémfoi possível fazer com que os gerenciadores de layout dos diversos frameworkspudessem ser utilizados com o Phrame UI com um mínimo de personalização, 64
  • 65. como aconteceu com os layouts do SWT e o FormLayout, do projeto JGoodies([JGO07]). Ambos foram portados de forma simples para serem utilizados peloPhrame UI e estão funcionando corretamente, da mesma forma que elesfuncionavam para os seus conjuntos de componentes específicos. Ainda que funcionando corretamente, algumas das capacidades dogerenciador de layouts JGoodies foram perdidas. A mais importande delas é adefinição do tamanho dos componentes através de medidas relativas aotamanho da tela e das fontes utilizadas e não em medidas absolutas. Como eraimpossível obter as informações do tamanho da fonte no ambiente web deforma simples, essa característica foi removida da adaptação da ferramenta. Além disso, o módulo de “form builders”, que são classes especializadasna construção automatizada de formulários padronizados também não foiadicionado, pois ele necessitava da implementação da característica detamanho e posicionamentos relativos que não foi adicionada. 3.2.4. Modelagem e implementação do framework A idéia do framework é abstrair a criação dos componentes visuais, paraque dessa forma ele possa escolher exatamente qual implementação docomponente utilizar baseando-se no contexto onde ele está inserido. Parachegar a solução deste problema, foi criada uma família inteira de interfacesque representam os componentes visuais básicos que qualquer aplicaçãodeveria conter, através da definição dessa família de componentes, definimostambém interfaces para as fábricas de componentes, que seriam os objetosresponsáveis pela criação dos objetos de uma implementação específica. 65
  • 66. A solução para a resolução do problema de criar objetos das diversasfamílias de componentes é análoga ao exemplo apresentado por [GHJV99],onde é necessário criar componentes de famílias diferentes. Toda aimplementação gira em torno das interfaces Widget e WidgetFactory. Ainterface Widget é a interface pai de todos os componentes visuais e ainterface WidgetFactory é a fábrica de componentes para a família decomponentes na qual ela está inserida. Existe, então, uma implementação daWidgetFactory que cria os componentes baseados nos objetos do SWT e outraWidgetFactory que cria os componentes baseados nos objetos do Thinwire. Como os componentes apresentam interfaces distintas, é necessáriofazer com que eles apresentem interfaces homogêneas. Para que isso fossepossível, foi criada toda uma hierarquia de objetos “adapters” quetransformavam as interfaces proprietárias dos componentes na interfacepadrão definida pela API. Dessa forma, as duas famílias de objetos e suasárvores de herança foram homogeneizadas através da definição da APIpadrão. Então, toda a implementação do modelo é apenas a criação de classes“adapter” para as diversas classes das bibliotecas de componentes queprecisam ser compatibilizadas. Como não era possível reaproveitar também os modelos apresentadospelos componentes em suas implementações específicas, foram criadosobjetos que funcionam como mediadores entre modelos específicos do PhrameUI e os componentes visuais, Um dos exemplos disso é o componente Table,que tem um TableModel e que se relaciona com ele através de um objeto 66
  • 67. TableMediator (que é uma implementação do padrão “mediator” encontrado em[GHJV99]). 3.2.5. Problemas encontrados Durante o desenvolvimento do framework alguns problemas foramencontrados, os mais importantes foram: • Os ambientes desktop e web são intrinsecamente diferentes e isso é perceptível até mesmo no modo pelo qual aplicações web são projetadas. Aplicações web normalmente compartilham recursos entre diversos usuários, como conexões com bancos de dados, em uma aplicação desktop não há necessidade de se implementar o compartilhamento pois apenas um usuário está utilizando ao aplicação, levar esse tipo de comportamento para uma aplicação web que deve ser acessada por diversas pessoas pode trazer sérios problemas de escalabilidade; • A aplicação web escrita utilizando o Thinwire mantém todo o seu estado e de seus componentes no servidor, onerando ainda mais a sua memória e a sua capacidade de processamento. Quanto mais memória for utilizada em um único servidor apenas com o intuito de manutenção de estado, menores são as chances de conseguir fazer com que a aplicação consiga escalar horizontalmente. • Uma aplicação web baseada em AJAX, como o Thinwire, consome muita banda de conexão apenas para se manter visível e se comunicando com o servidor. Em um ambiente que tenha 67
  • 68. uma rede lenta, a latência de rede pode fazer com que a aplicação se comporte de forma inesperada ou ela pode apresentar-se demasiadamente lenta para o usuário final. • Conceitos básicos como o salvar e abrir de arquivos não são facilmente mapeáveis nos dois ambientes. Enquanto que abrir um arquivo no desktop é apenas uma seleção de um arquivo na máquina onde a aplicação está executando e o salvar é guardar as informações no disco corrente, em uma aplicação web estas ações se transformam para interações no servidor e no servidor torna-se complexo garantir a independência de um usuário em detrimento dos outros em tempo de execução; • Fazer com que a aplicação execute de forma igual nos dois ambientes fez com que diversas características do ambiente desktop não fossem implementados ou não disponibilizados para o código cliente, como a implementação nativa de desenhos em componentes visuais. Atualmente é impossível fazer um desenho manualmente em um componente e isso pode vir a causar problemas quando for necessário trabalhar com imagens que se atualizem em tempo real, como gráficos e relatórios; 3.2.6. Resultados e futuro O framework já tem diversas aplicações que utilizam a sua parte desktopem produção em diversos clientes, mas até agora nenhuma delas foi testadaoficialmente como aplicação web. No decorrer do tempo após a criação do 68
  • 69. framework, ele recebeu uma nova biblioteca, a biblioteca de binding, querelaciona fontes de dados, como objetos, resultados de buscas em bancos dedados e outros. Essa biblioteca facilita a junção de bancos de dados e aumenta aprodutividade no desenvolvimento de aplicações que simplesmente acessam obanco de dados. Os planos futuros para o framework ainda não foram definidos, as únicasalterações em andamento são resolução de bugs e a adição de novoscomponentes, nenhuma mudança na modelagem ou na arquitetura doframework estão sendo esperadas no momento atual. 69
  • 70. 4. Considerações finais A experiência de estagio como desenvolvedor Java foi extremamenteimportante por ter possibilitado colocar em prática os conceitos e teoriasaprendidos em sala de aula, além do que o convívio em um ambiente real detrabalho também fornece uma visão diferenciada do que é ser umdesenvolvedor no mercado de trabalho que nós temos hoje. O uso da linguagem Java e de seus diversos frameworks paradesenvolver provou ser uma boa escolha para as aplicações escolhidas, masisso não fez com que outras soluções não fossem avaliadas. A linguagem Javaestá perdendo lentamente espaço na máquina virtual e o esperado é que asnovas linguagens como Ruby, Groovy e Scala abram espaço para a criação deuma nova cultura de programação. As grandes desvantagens do Java hoje frente estas linguagens maissimples são a burocracia para se iniciar um projeto qualquer e o tempo que seespera até que um servidor web esteja pronto para fazer requisições eresponder às interações do usuário. Em uma linguagem como Ruby, apenasalterar e salvar o arquivo já é o suficiente para que eu possa ver as alteraçõessendo mostradas, sem que seja necessário reiniciar o servidor. Além disso, aquantidade de arquivos de configuração necessários para se desenvolver umaaplicação simples às vezes é tão grande que a quantidade de XMLs trocados émaior do que até mesmo o código das aplicações. A comunidade precisa sevoltar mais para o princípio da “convertion over configuration”, para evitar arepetição e o retrabalho na hora de definir os sistemas. 70
  • 71. A experiência de trabalhar em um lugar que procura implementar umprocesso onde ainda não está formada a cultura de processo e onde asferramentas também não simplificam o trabalho, também foi importante paraperceber que a maior parte dos problemas que nós enfrentamos nodesenvolvimento de software não são técnicos, são humanos. Falhas nacomunicação, problemas de entendimento, exceções que são mais comunsque as regras e más interpretações do que está sendo definido são umacomprovação de que simplesmente definir um processo de qualquer forma nãoresolve o problema. Trabalhar em equipe, acessando o mesmo repositório de código fonte,utilizando as mesmas ferramentas de automatização de projeto, foi possívelcompreender o valor da comunicação entre as pessoas envolvidas no projeto eo quanto isso pode facilitar a vida da equipe, quando todos estão envolvidosem achar uma solução pra o problema. O Report Center foi um passo a frente, migrando um software que eraeminentemente desktop para a plataforma web. Com isso diminuiu-se osgastos com implantação, suporte e manutenção de sistemas, além de garantira satisfação dos clientes, que hoje podem visualizar os seus relatórios dequalquer lugar que eles acharem necessário. A ferramenta só precisa melhorarnos quesitos de facilidade de se adicionar novos relatórios e filtros para osmesmos; ainda é complicado demais criar novos filtros. O Phrame UI ainda hoje é uma incógnita, investir em aplicações desktopnão parece ser uma boa escolha em uma época onde todos os serviços estãofazendo de tudo para migrar para a web. Até mesmo clientes e usuárioscostumam preferir aplicações web, pois eles podem sempre utilizar quando e 71
  • 72. como quiserem, sem que seja necessário a instalação de nenhum software amais. Além disso, aplicações web e desktop existem em ambientesextremamente diferentes e lidam com realidades completamente diferentes,ignorar estes fatos pode trazer sérios problemas no futuro, especialmente se asferramentas começarem a ser utilizadas sem avaliações ou testes nãofuncionais. A tendência atual de aplicações parece ser na direção de “rich-clients”,os clientes ricos, que são aplicações que devem funcionar como Applets noseu navegador. Esse modelo lembra muito o modelo clássico de cliente-servidor, onde um cliente fazia uma busca no servidor, guarda as informaçõese opera com elas. Neste caminho existem tecnologias como o Adobe Flex, oMicrosft Silverlight e o JavaFX, nenhum deles poderia ser facilmente “plugado”no Phrame UI porque eles não executam código em Java nem podem sercriados diretamente por uma fábrica de componentes, o que evitacompletamente que eles possam ser utilizados. A experiência e os conhecimentos adquiridos foram válidos e vão sermuito importantes no meu crescimento pessoal e profissional, nestes dias queainda estão por vir. 72
  • 73. 5. Referências bibliográficas[.NET07] .NET Framework Developer Center. Disponível em<http://msdn.microsoft.com/netframework/>, acesso em 02/07/2007.[BAT05] Tate, Bruce A. Beyond Java. O’Reilly, 2005.[BBM07] Casey, John; Massol, Vincent; Porter, Brett; Sanches, Carlos; Van Zyl,Jason. Better Builds With Maven. DevZuz Library Press, Abril 2007.Disponível em <http://www.devzuz.com/web/guest/products/resources>, acessoem 02/07/2007.[CIA07] Version Control Systems. CIA, disponível em <http://cia.vc/stats/vcs>, acesso em 02/07/2007.[CJPC07] Core Java EE Patterns Catalog. disponível em<http://java.sun.com/blueprints/corej2eepatterns/Patterns/index.html>, acessoem 02/07/2007.[CoC07] Chen, Nicholas. Convention Over Configuration. Disponível em<http://softwareengineering.vazexqi.com/files/pattern.html>, acesso em02/07/2007.[CRPT07] Crystal Reports. Business Objects, disponível em <http://www.businessobjects.com/products/reporting/crystalreports/default.asp>,acesso em 02/07/2007.[DDD03] Evans, Eric. Domain Driven Design: Tackling the Complexity inthe Heart of Software. Addison Wesley, 2003. 73
  • 74. [ECHO07] Echo 2 Web Framework. Nextapp, disponível em <http://www.nextapp.com/platform/echo2/echo/>, acesso em 02/07/2007.[ECP07] Eclipse Project Website. Disponível em <http://eclipse.org/>, acessoem 02/07/2007.[EJB07] Enterprise Java Beans Technology. Sun Microsystems, disponívelem <http://java.sun.com/products/ejb/>, acesso em 02/07/2007.[ELP07] Open Source Issue Tracker Software in Java – Elips. Disponível em<http://www.java-source.net/open-source/issue-trackers/elips>, acesso em02/07/2007.[FOWPOEAA02] Fowler, Martin. Patterns of Enterprise ApplicationArchiteture. Addison-Wesley, 2002.[FOWIOC07] Fowler, Martin. Inversion of Control. Disponível em <http://www.martinfowler.com/bliki/InversionOfControl.html>, acesso em02/07/2007.[FOWUML03] Fowler, Martin. UML Distilled: A Brief Guide to the StandardObject Modeling Language. Addison-Wesley, 2003.[GHJV99] Gamma, E.; Helm, R., Johnson; R. E Vlissides, J. Design Patterns:Elements of reusable Object Oriented Software. Addison Wesley, 1998.[GMAKE07] Gnu Make Project. Disponível em<http://www.gnu.org/software/make/>, acesso em 02/07/2007.[IBM07] IBM Website. Disponível em <http://ibm.com/>, acesso em02/07/2007.[JAC07] Jacobson, Ivar; Ng, Pan-Wei; Spence, Ian. Enough of Processes:Lets Do Practices Part I. Dr. Doob’s Journal, disponível em <http://www.ddj.com/dept/java/198000264>, acesso em 02/07/2007. 74
  • 75. [JB07] JavaBeans Technology. Sun Microsystems, disponível em <http://java.sun.com/products/javabeans/>, acesso em 02/07/2007.[JCP07] The Java Community Process. Disponível em < http://www.jcp.org/>, acesso em 02/04/2007.[JDE05] D’Anjou, Jim; Fairbrother, Scott; Kehn, Dan; Kellerman, John;McCarthy, Pat. The Java Developer’s Guide to Eclipse, Second Edition.Addison-Wesley, Bostom, 2005.[JIA04] Mann, Kito D. Java Server Faces In Action. Manning, 2004.[JGO07] JGoodies: Java User Interfaces. Disponível em<http://www.jgoodies.com/>, acesso em 02/07/2007.[JNDI07] Java Naming and Directory Interface. Sun Microsystems, disponívelem <http://java.sun.com/products/jndi/>, acesso em 02/07/2007.[JPH07] Bauer, Christian; King, Gavin. Java Persistence With Hibernate.Manning, 2007.[JRUBY07] Pure Java Powered Ruby implementation. Disponível em <http://jruby.codehaus.org/>, acesso em 02/07/2007.[MPJ97] Page-Jones, Meilir. O Que Todo Programador Deveria Saber SobreProjeto Orientado a Objeto. Makron Books, São Paulo, 1997.[PEN03] Pender, Tom. UML Bible. Wiley Publishing, Indiana, Indianapolis,2003.[PKW05] Kroll, Peter; Royce, Walker. Key principles for business-drivendevelopment. IBM Developer Works, disponível em <http://www-128.ibm.com/developerworks/rational/library/oct05/kroll/>, acesso em02/07/2007. 75
  • 76. [PHK03] Kruchten, Philippe. The Rational Unified Process: An Introduction.Addison-Wesley, 2003.[PHO07] Phoebus Tecnologia, disponível em <http://www.phoebus.com.br>,acesso em 02/07/2007.[PRE05] Pressman, Roger. Engenharia de Software, 6. ed. São Paulo:McGraw-Hill, 2006.[RES] Sweet, Richard E. The Mesa Programming Environment. Xerox PaloAlto Research Center, 1985.[SCALA07] Scala Programming Language. Disponível em <http://www.scala-lang.org/>, acesso em 02/07/2007.[SFN07] SourceForge.net. SourceForge, disponível em<http://sourceforge.net/>, acesso em 02/07/2007.[SJAVA07] Sun Java Technology. Sun Microsytems, disponível em<http://java.sun.com/>, acesso em 02/07/2007.[SPR07] The Spring Framework Reference Documentation. Disponível em<http://springframework.org/>, acesso em 02/07/2007.[STRUTS07] Struts Java Web Framework. Disponível em<http://struts.apache.org/>, acesso em 02/07/2007.[SWTIA05] Scarpino, Mattew; Holder, Stephen; Ng, Stanford; Mihalkovic,Laurent. SWT/JFace in Action. Manning, 2005.[THI07] Thimwire Project Website. Disponível em <http://www.thinwire.com/>,acesso em 02/07/2007.[WOMT07] Object Modeling Technique. English Wikipedia, disponível em <http://en.wikipedia.org/wiki/Object-modeling_technique>, acesso em02/07/2007. 76
  • 77. [WBM07] Booch’s method. English Wikipedia, disponível em <http://en.wikipedia.org/wiki/Object-oriented_software_engineering>, acesso em02/07/2007.[WOCL07] Object Constraint Language. English Wikipedia, disponível em <http://en.wikipedia.org/wiki/Object_Constraint_Language>, acesso em02/07/2007.[WOOSE07] Object-Oriented Engineering. English Wikipedia, disponível em<http://en.wikipedia.org/wiki/Object-oriented_software_engineering>, acessoem 02/07/2007.[WRC07] Revision Control. English Wikipedia, disponível em<http://en.wikipedia.org/wiki/Revision_control>, acesso em 02/07/2007.[WSTAX07] StAX – Streaming API for XML. English Wikipedia, disponível em<http://en.wikipedia.org/wiki/StAX>, acesso em 02/07/2007.[WSVN07] Subversion (software). English Wikipedia, disponível em<http://en.wikipedia.org/wiki/Subversion_%28software%29>, acesso em02/07/2007.[WQVT07] QVT (Queries/Views/Transformations). English Wikipedia,disponível em < http://en.wikipedia.org/wiki/QVT>, acesso em 02/04/2007. 77