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

1. CENTRO FEDERAL DE EDUCAÇÃO
TECNOLÓGICA DA PARAÍBA
Coordenação do Curso Superior de Tecnologia em Sistemas
para a Internet
RELATÓRIO FINAL DE ESTÁGIO
Report Center e Phrame UI
Desenvolvimento 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/2007
1

2. 2

3. Centro Federal de Educação Tecnológica da
Paraíba
Coordenação do Curso Superior de Tecnologia em Desenvolvimento de
Softwares para a Internet
Report Center e Phrame UI
Desenvolvimento da ferramenta de relatórios Report Center e
do framework de interface Phrame UI
Maurício Linhares de Aragão Junior
3

4. Relatório de Estágio Supervisionado apresentado á
disciplina Estágio Supervisionado da Coordenação do Curso
Superior de Tecnologia em Sistemas para a Internet do
Centro Federal de Educação Tecnológica da Paraíba como
requisito parcial para obtenção do grau de Tecnólogo em
Sistemas 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 Lira
Presidente da CESUT: Heremita Brasileiro Lira
Empresa: Phoebus Tecnologia
Período: 01/04/2006 até 01/10/2006
4

5. SUMÁRIO
1.
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 da
ferramenta Report Center, um visualizador de relatórios para a web escrito na
linguagem Java e a tecnologia JavaServer Faces, e a construção do framework
de componentes visuais Phrame UI, que tem por objetivo abstrair, de forma
que não seja necessário decidir se uma aplicação deve ser criada para o
desktop ou web, baseado nas bibliotecas Standard Widget Toolkit (SWT) para
os componentes desktop, Echo 2 Web Framework e Thinwire para os
componentes web.
7

8. 8

9. AGRADECIMENTOS
À minha família, à minha namorada e aos meus amigos, pela confiança
e incentivo que sempre depositaram em mim. Dando força nos momentos
difíceis, nas noites de sono perdidas e, acima de tudo, demonstrando que
ninguém está sozinho no mundo.
A todas as pessoas que formam a equipe da Phoebus Tecnologia, que
me receberam muito bem e foram de extrema importância para o meu
crescimento pessoal e profissional, graças a tudo o que eu pude aprender junto
com eles.
Aos meus amigos de curso, começamos como 25 alunos e terminamos
como 10. Todos vocês foram importantes durante esses anos de turma
COBAIA. Além deles, gostaria de agradecer também aos alunos das outras
turmas de DSI, especialmente os P4 e P5 da época, que também deram força
para a conquista de mais este degrau.
A todos os professores da COINFO, em especial ao professor Frederico
Guedes Pereira, não apenas pelos cinco períodos que passamos juntos, por
estar me orientando neste trabalho e pelos conhecimentos que foram
passados, mas pelos ensinamentos fora de sala de aula, como pessoa, que me
fizeram 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 trabalho
desenvolvido fosse baseado no que havia de melhor na indústria, além de
ajudar 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 em
capí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ágio
na Phoebus Tecnologia, que é uma empresa paraibana de tecnologia
especializada em soluções de integração entre aplicações, desde a
implementaçã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. O
estagio representou o desenvolvimento da aplicação web Report Center, que é
um visualizador de relatórios utilizando a tecnologia JavaServer Faces e o
framework de componentes visuais Phrame UI, que tem por objetivo abstrair a
criação de aplicações que sejam ao mesmo tempo desktop e web, sem que
seja necessário o desenvolvedor preocupar-se diretamente com isso. Também
serão descritos por este documento as técnicas de desenvolvimento, padrões
de 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óxima
com as disciplinas que foram vistas e praticadas ao longo do curso, nele foram
desenvolvidas práticas em análise e arquitetura de sistemas, implementação
de software orientado a objetos e extensão de frameworks. Utilizando como
ferramenta a plataforma Java EE e a linguagem Java como um todo, para
aproximar os conhecimentos teóricos formados durante o curso das aplicações
práticas do dia a dia de desenvolvimento de aplicações. O foco maior foi a
implementação de interfaces gráficas, tanto para aplicações desktop como para
aplicaçõ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 de
aplicações através de sistemas de trocas de mensagens, é uma das únicas
empresas do Brasil com experiência no desenvolvimento de soluções para
dispositivos clientes de captura como POS, trabalhando com uma gama
gigantesca de fornecedores e sistemas operacionais distintos. A empresa se
define como:
“Uma empresa que alinha tecnologia, dinamismo e funcionalidade na
aplicação e desenvolvimento de soluções multiplataformas para terminais
POS`s (point-of-service), aplicativos como Palm`s, cartões inteligentes e
microcontroladores.
Atua no mercado nacional e internacional implantando soluções para redes de
arrecadação de contas, distribuição e venda de crédito digital, correspondentes
bancá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 Phoebus
disponibiliza sistemas flexíveis, oferecendo excelente rentabilidade.” [PHO07]
Com base nessa premissa, diversas aplicações de suporte foram criadas
para possibilitar o funcionamento dos sistemas nos diversos clientes que a
empresa tem por todo o país.
13

14. 1.5. Report Center
O Report Center é uma ferramenta de filtragem e visualização de
relatórios para a web. Ele surgiu da necessidade de se evitar que cada cliente
instalasse uma aplicação desktop na sua máquina para poder visualizar os
relatórios e fazer o acompanhamento do funcionamento dos sistemas. Com o
advento do Report Center a única coisa que o usuário necessita em sua
máquina é um navegador web comum com suporte a XHTML e JavaScript.
A aplicação foi desenvolvida utilizando-se a linguagem Java e a
tecnologia JavaServer Faces de desenvolvimento web baseado em
componentes.
1.6. Phrame UI
O Phrame UI faz parte do conjunto de frameworks para a renovação da
arquitetura de aplicações da Phoebus, o projeto Phrame. O Phrame UI tem
como objetivo abstrair para o desenvolvedor a necessidade de se escrever
uma mesma aplicação para a web e para o desktop, através dele é possível
escrever uma única aplicação que vai ser executada igualmente na web e no
desktop bastando alterar apenas alguns parâmetros de configuração. O código
que foi desenvolvido não precisa ser alterado para que uma aplicação web
execute em um ambiente desktop, nem o contrário.
14

15. 1.7. Atividades realizadas
Durante o estágio foram realizadas atividades na fase de
desenvolvimento do Report Center de do Phrame UI. Essas podem ser
resumidas 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 uma
personalização do Rational Unified Process (RUP) desenvolvida pela própria
empresa através de uma equipe que estava responsável pela definição de
processos de qualidade e um consultor externo.
As ferramentas utilizadas no decorrer do trabalho foram o ambiente de
desenvolvimento Eclipse, em sua versão 3.2 (Callisto), a ferramenta de
automatização de build e gerencia de projetos Maven 2, o sistema de controle
de versionamento de software CVS e a ferramenta de gerenciamento de casos
(Issue Tracker) PhElips.
O Report Center foi desenvolvido sob a plataforma Java Enterprise
Edition (Java EE), utilizando as especificações das tecnologias Servlet,
JavaServer Pages e JavaServer Faces para a camadas de visualização e
controle. Para a camada de persistência foi utilizada a ferramenta de
mapeamento objeto/relacional Hibernate em sua versão 3. O relacionamento
entre as três camadas foi provido pelo framework de inversão de controle
baseado 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 sua
versão web. Os frameworks utilizados na criação dos componentes visuais
foram 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 que
surgiu da fusão de duas grandes empresas que trabalhavam na definição de
processos de desenvolvimento de software, a Rational Software Corporation e
a Objectory AB. Com essa fusão eles também criaram um novo processo, que
unificava as práticas dos dois processos que elas haviam criado, surgia então o
Rational Objectory Process, que mais tarde foi rebatizado de Rational Unified
Process.
Ele surgiu como uma reunião das boas práticas encontradas nos
processos mais tradicionais de desenvolvimento e comprovadas através de
seu uso com as novas tendências encontradas, como desenvolvimento
iterativo, preocupação com a comunicação e foco constante no cliente da
solução.
O RUP é definido por [PHK03] como sendo:
“(...) um processo de engenharia de software. Ele provê um modo
disciplinado de designar tarefas e responsabilidades dentro de uma
organização de desenvolvimento de software. Seu interesse é garantir a
produção de software de alta qualidade que atinja as espectativas de seus
usuários dentro de um prazos e custos previsíveis. O Rational Unified Process
é um ‘processo produto’. Ele é desenvolvido e mantido pela Rational Software
e integrado com a sua suíte de ferramentas de desenvolvimento. (...) Ele é
também um framework de processos que pode ser adaptado e estendido para
as necessidades de uma organização que o está adotando. (...) Ele captura
17

18. muitas das boas práticas no desenvolvimento de software da atualidade em
uma forma aceitável para a maioria dos projetos e organizações”.
Em 2005, o RUP teve os seus seis princípios atualizados para a
realidade atual das empresas e das necessidades dos projetos de software,
segundo [PKW05]:
“Nossas seis boas práticas, testadas e garantidas, tem sido a base para
a evolução de nossas ferramentas e processos por mais de uma década. Hoje,
enquanto vemos mais companhias buscando o desenvolvimento de software
como uma capacidade essencial de negócio, nós vemos estas práticas
amadurecendo dentro do contexto mais abrangente do desenvolvimento
‘direcionado ao negócio’. Nós acreditamos que é o momento de rearticular
nossas boas práticas para um ciclo mais amplo na contínua evolução de
sistemas, 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 focados
na implementação dos produtos, pois tratavam de características de baixo
nível, o novo grupo de princípios tem um foco mais direcionado aos resultados
que a solução desenvolvida vão trazer para a empresa.
18

19. O RUP é dividido em quatro fases seqüenciais onde todas as disciplinas
são aplicadas de forma paralela e com freqüências diferentes, como
demonstrado na figura abaixo:
Figura 1 – Fases e disciplinas do RUP
Durante o início do projeto, na fase de concepção (Inception), as
disciplinas que são mais exercidas são as que têm por objetivo formar uma
arquitetura 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) o
foco é 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 os
esforços estão direcionados mais fortemente à implantação e ao
gerenciamento de configuração e mudanças.
19

20. É importante lembrar que mesmo que uma ou outra disciplina seja o foco
da fase corrente, as outras disciplinas nunca devem ser “congeladas”, pois o
RUP baseia-se em um processo iterativo de desenvolvimento de software e
não nos clássicos processos seqüenciais, também conhecidos como processos
em cascata.
Ainda segundo [PHK03] algumas das vantagens dos processos
iterativos 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íticas
principalmente nas áreas de personalização do processo. A quantidade de
artefatos padrão é tão grande que para pequenas equipes ou equipes que não
tem conhecimento suficiente, o início de um projeto e a seleção dos artefatos
que são realmente necessários é lenta e trabalhosa, aumentando ainda mais o
peso do processo sobre a equipe. [JAC07] apresenta uma crítica à dificuldade
de se remover artefatos dos processos:
“The desire to provide a complete process also makes the process
heavier as more and more information is added to cover all of the disciplines
involved. 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 to
come). If a process is successful, then the desire to keep it up to date and
extend its market leads it to become even heavier as more information is added
to expand its scope, add new techniques, and address new challenges. This
leads to the need for organizations, practitioners, and methodologists to start
trimming to get a lighter, more-focused process. We don't think this is the way
to go. You shouldn't need to spend time deselecting the things you don't want.
You should be able to start from a small, useful kernel of information, then add
the guidance you need.”
Todos os papéis, atividades, guias e artefatos disponíveis fazem com
que a escolha por quais são realmente necessários no projeto seja penosa e
esse também não é, de forma alguma, o produto final que se espera dele. O
artefato 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 como
o conhecimento do domínio do problema vai evoluir.
2.3. UML
A Unified Modelling Language (UML) é uma linguagem de modelagem
de propósito geral que parte dos pressupostos da orientação a objetos para
desenvolver os seus diagramas. Sendo uma linguagem de propósito geral, a
UML é mais comumente utilizada na definição de sistemas de software
orientados a objetos.
Assim como o RUP, a UML também foi desenvolvida pela fusão da
Rational 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 de
modelagem de sistemas orientados a objetos, a Object-Oriented Software
Engineering (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 onde
eram fortes e outras onde necessitavam de melhorias e foi com a fusão dos
três que foi possível desenvolver a linguagem de modelagem que conhecemos
hoje, como afirma [PEN03]:
“Object-Oriented Software Engineering (OOSE), developed by Ivar
Jacobson is based around the use-case concept that proved itself by archieving
high 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 and
data intensive systems for defining a target problem, a second key sucess
factor for IT projects. The Booch method, developed by Grady Booch, had
particular strenghts in design and implemenation, defining and mapping a
solution to the target problem, a third key to sucessful IT projects. These
significant contributions are like the legs on a three-legged stool: the
combination of the three methods and ther notations supported the entire range
of requirements needed to reate a single, comprehensive software-modelling
standard.”
A UML contém 13 tipos diferentes de diagramas, conforme a imagem a
seguir:
22

23. Imagem 2 – Tipos de diagramas UML – Retirada de [FOWUML03]
Diagrama Propósito
Atividade (Activity) Comportamento procedural ou paralelo
23

24. Classe (Class) Classes, atributos e relacionamentos
Comunicação Interações entre objetos
(Communication)
Componente (Component) Estrutura e relacionamentos entre componentes
Estrutura (Composite Decomposição em tempo de execução de uma
Structure) classe
Implantação (Deployment) Implantação de artefatos em seus locais
Interação (Interaction Junção dos diagramas de seqüência e
overview) atividades
Objeto (Object) Estados de exemplo das instâncias no sistema
Pacote (Package) Estrutura hierárquica dos objetos
Seqüência (Sequence) Interações entre objetos, ênfase na seqüência
das ações
Estado (State Machine) Alterações do estado dos objetos durante a sua
existência
Tempo (Timing) Interações entre objetos, ênfase nos momentos
quando elas acontecem
Caso 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 UML
também é agnóstica à linguagem na qual o sistema vai realmente ser
construído. Baseando-se nas premissas da orientação a objetos que já existem
há década no mercado, a linguagem contém praticamente todos os constructos
comuns 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 de
implementação, retenção de estado, identidade de objeto, mensagens, classes,
gerança, polimorfismo e genericidade.”
A linguagem conta com transformadores baseados no padrão de
transformações Query/View/Transformations (QVT, [WQVT07]) definidos pelo
Object Management Group, que também é responsável hoje por dar
manutenção na especificação da UML. Transformações QVT tornam possível
que um modelo UML seja facilmente transformado em outro artefato, como por
exemplo código fonte.
Mesmo com estas facilidades, as transformações ainda encontram
alguns problemas, como o caso da herança múltipla. Enquanto é possível
modelar diagramas que apresentam herança múltipla em UML, algumas
linguagens, como Java e C#, não tem suporte a esta construção do paradigma
orientado a objetos, então a transformação pode seguir por caminhos
diferentes do esperado.
Em alguns momentos, também é necessário se prender a características
específicas dos ambientes que nós estamos trabalhando para desenvolver os
diagramas UML, para estes casos existem os estereótipos que adicionam
novas qualidades a um modelo já existente sem que seja necessário alterar
diretamente a modelagem atual. Um caso de uso para estereótipos é quando
está se utilizando a especificação Enterprise Java Beans (EJB, [EJB07]) para a
definição das entidades do sistema. As entidades modeladas em si não
necessitam 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 de
forma correta e correspondendo ao que a especificação EJB afirma.
Além dos estereótipos também existe a possibilidade de se desenvolver
modelos com restrições embutidas dentro deles próprios, através do uso da
Object Contraint Language (OCL, [WOCL07]) que foi uma das primeiras
extensões à linguagem UML. Com ela é possível definir pré e pós-condições
para os modelos, através da definição de contratos e restrições, além de
também ser possível navegar entre os objetos do diagrama na forma de uma
linguagem de consulta.
2.4. Gestão de modificações
A gestão de modificações (Change Management, CM), também
conhecida como gestão de configuração de software (Software Configuration
Management, SCM), é a atividade responsável por garantir a rastreabilidade
das mudanças sofridas por um artefato de software. Ela vem definir critérios
que possam realizar tais modificações mantendo a consistência e a integridade
do software com os requisitos identificados e com as pessoas envolvidas no
processo. Segundo [PRE06]:
“Como modificações podem ocorrer em qualquer época, as atividades
de SCM são desenvolvidas para (1) identificar modificações, (2) controlar
modificações, (3) garantir que as modificações sejam adequadamente
implementadas e (4) relatar as modificações a outros que possam ter
interesse”.
26

27. Através desse controle, é possível diminuir os problemas e gargalos
criados através de problemas de comunicação entre as equipes ou pessoas
que trabalham alterando um mesmo artefato de software. Ainda segundo
[PRE06] “... A SCM pode ser vista como uma atividade de garantia de
qualidade de software, que é aplicada ao longo de todo o processo de
software”.
Para garantir essa qualidade, ferramentas são utilizadas para
automatizar estes processos seguindo um plano de gerência de configuração
que consiste em estabelecer normas, ferramentas e modelos que permitam
gerenciar 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 utilizados
softwares de controle de versão (Version Control) em projetos de software. Um
software 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 of
the same unit of information. It is most commonly used in engineering and
software development to manage ongoing development of digital documents
like application source code, art resources such as blueprints or electronic
models and other critical information that may be worked on by a team of
people. Changes to these documents are identified by incrementing an
associated number or letter code, termed the "revision number", "revision level",
27

28. or simply "revision" and associated historically with the person making the
change.”
Ele é responsável pela manutenção e controle de alteração de códigos
fonte e arquivos necessários para a geração dos artefatos de software, como
scripts de build, documentações externas ao código, definições de testes e
configurações para ferramentas de avaliação de código.
O CVS baseou-se em uma ferramenta anterior, o Revision Control
System, que fazia o controle de revisões (alterações) em arquivos comuns de
texto. Como apenas controlar as alterações no nível de arquivos não era o
suficiente em projetos de software, o CVS criou o conceito de controle de
projetos e módulos, onde todo um conjunto de artefatos de software que
formavam um projeto são versionados em conjunto.
Em um ambiente sem uma ferramenta de controle de versão de código
fonte, todas as alterações dos arquivos teriam que ser salvas pelos próprios
desenvolvedores e dois desenvolvedores nunca poderiam alterar o mesmo
arquivo ao mesmo tempo. Ter que salvar cada alteração em um arquivo
diferente é trabalhoso e também poderia fazer com fosse utilizado espaço em
disco demais para desenvolver até mesmo a mais simples das aplicações,
evitar que dois desenvolvedores alterem o mesmo arquivo também pode
aumentar o tempo necessário para fazer uma alteração de software, mesmo
que os dois estejam trabalhando em partes diferentes do arquivo (em funções
diferentes, por exemplo), porque enquanto um estiver alterando o outro não vai
ser capaz de acessar o arquivo.
Através do uso do CVS estas preocupações já não existem mais, pois
quando 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ínima
possível. Ele também conta com ferramentas automáticas de resolução de
conflitos que evitariam que os desenvolvedores fossem bloqueados de fazer o
seu trabalho porque alguém já está alterando o arquivo. Quando duas ou mais
pessoas estão alterando o mesmo arquivo e enviam a modificação para o
controle de versão, ele verifica se é capaz de fazer o “merge” (fusão) dos dois
arquivos sem a necessidade de intromissão do usuário. Se ele não for capaz
de fazer isso sozinho, ele avisa ao usuário para que ele tome a decisão de o
que deve ser enviado como alteração ou não, garantindo assim que os
arquivos não vão ser corrompidos nem transformados em inválidos por
alterações mal planejadas.
Além destas características, ele também tem esquemas de marcação de
arquivos através de “tags”, onde o usuário pode marcar um arquivo ou um
conjunto deles com uma identificação para controles futuros, como por exemplo
quando uma versão é liberada para um cliente. Todo aquele código deve ser
marcado 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 eles
possam rastrear exatamente quais são os arquivos que fizeram parte dela.
Nele também existe o mecanismo de “branches” que são utilizados para
criar linhas de desenvolvimento alternativas de um projeto, comuns quando é
necessário adicionar novas funcionalidades que podem entrar em conflito ou
causar alguma quebra no comportamento atual do produto.
O CVS anda perdendo muito espaço no mercado de sistemas de
controle 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á a
incapacidade do CVS de renomear ou mover arquivos e manter o histórico de
alterações deles e a falta de “commits” atômicos, se enquanto você estiver
enviando dados para o servidor CVS ocorrer algum problema de qualquer um
dos lados, o envio de informações é parado mas as informações que já haviam
sido enviadas, mesmo que incompletas, são colocadas no repositório do
controle de versão, ele não garante transações no formato “all-of-nothing”, o
que pode causar problemas de informações inconsistentes ou desatualizadas
no 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 que
funciona como um gerenciador de casos (Issue Tracker), tanto para cadastrar
bugs e problemas nas aplicações como também para controlar as atividades
dos desenvolvedores e das equipes envolvidas no projeto.
A ferramenta é baseada em uma antiga ferramenta open source
conhecida como Elips ([ELP07]), que não se encontra mais em
desenvolvimento 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 a
própria empresa começasse a personalizar a aplicação conforme as suas
necessidades, o que vem acontecendo até os dias de hoje.
30

31. Ela funciona controlando os casos e as atividades que cada pessoa
designada para o caso fazem, contando assim com um histórico de quanto
tempo 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 das
aplicações, pois elas misturam a lógica da aplicação com a lógica da
visualizaçã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. Ele
gerencia projetos desde a sua criação (com a geração do esqueleto inicial do
sistema) 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, o
Project Object Model (POM), que é o arquivo de configuração do projeto onde
são definidas todas as suas características. No POM são definidas desde
informações básicas do projeto, como nome, desenvolvedores, repositórios de
código fonte (sistemas de controle de versão, como CVS e Subversion), como
suas dependências em bibliotecas externas e até mesmo plugins do próprio
Maven que são utilizados para facilitar a vida dos desenvolvedores, como um
servidor web embutido que executa diretamente de dentro do projeto.
Além de tudo isso, ele é uma ferramenta que prega a padronização dos
projetos. Se você conhece a estrutura de um projeto básico do Maven, não vai
ter problemas para entender outro projeto que também siga a mesma estrutura
e isso diminui drasticamente o tempo que o desenvolvedor vai levar para
“entrar” no novo sistema, pois ele não vai precisar entender uma nova estrutura
ou 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 de
diretó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 Jakarta
Turbine com o objetivo de simplificar os “build files” do Ant utilizados no projeto.
Eles estavam procurando por uma maneira de deixar todos os projetos
seguindo uma mesma estrutura padronizada e também queriam não ter mais
que enviar os arquivos “.jar” das dependências para os sistemas de controle de
versão, foi então que surgiu a primeira versão da ferramenta, que em 2005 foi
completamente reescrita, resultando no Maven 2, que foi construído sobre toda
a 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 qualquer
máquina que tenha acesso ao código fonte e aos mesmos repositórios ou a
repositórios que contenham os artefatos que o projeto necessita. Desse modo
as pessoas responsáveis pelos “builds” não precisam sempre utilizar uma
máquina específica ou configurar um ambiente específico para gerar versões
dos 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 os
builds, ele também contém diversos plugins que ajudam na garantia de
qualidade de código, como os que fazem engenharia reversa do código para
modelos UML, avaliadores de métricas de qualidade de software, execução de
testes unitários, funcionais e não funcionais, avaliadores de estilo de código e
geradores automáticos de documentação através do código fonte. Trabalhando
sempre de forma distribuída e acessando apenas os recursos que são
necessários naquele momento, o Maven garante que o uso de recursos (como
disco e rede) serão sempre racionalizados, pois ele nunca vai requisitar
dependências externas que não sejam absolutamente necessárias para os
projetos 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, no
desenvolvimento de aplicações servidoras, em aplicações para celulares,
smartphones e PDAs e em uma pequena parte também para aplicações
desktop. 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 para
dispositivos móveis ou com pouco poder de processamento, o Java Micro
Edition.
A linguagem e as especificações são definidas por um consórcio de
empresas e pessoas físicas que trabalham no Java Community Process (JCP,
[JCP07]), definindo especificações e implementações de referência para as
mesmas, de forma que qualquer pessoa pode participar da criação e
implementação das características da linguagem. O JCP funciona através de
votações para as especificações, quando uma nova especificação é enviada
pra o grupo, ela recebe uma avaliação geral e em uma votação com os seus
membros é definido se ela deve ou não começar a ser produzida. Apenas
especificações que são aceitas na votação são aceitas pelo JCP e podem fazer
parte oficialmente da plataforma Java.
Mesmo com toda esta estrutura formal, a linguagem conseguiu formar
uma 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 foi
responsável por causar grandes mudanças nas especificações da linguagem,
como na área de mapeamento objeto/relacional, onde a especificação EJB foi
revista para se assemelhar mais a produtos que surgiram como ferramentas
open source, que foi o caso do Hibernate ([JPH07]).
Sendo uma das primeiras linguagens a introduzir comercialmente com
sucesso a idéia de máquinas virtuais, Java mudou o modo como as pessoas
viam o desenvolvimento de aplicações, como explica [BAT05]:
“(...) Java's virtual machine simply redefines the machine, providing a
lower-level, firmer foundation for portability. Java designers bet that they could
overcome performance concerns. It was not a new idea; nor was it a popular
one. Over time, they proved to be right. Just-in-time compilers improved
performance so that the overhead of the JVM became acceptable, and even
rivaled compiled languages. The virtual machine, built into Netscape Navigator,
proved to be a fantastic launching pad for the Java platform. It's enabled Java
to extend into the realm of mobile devices, application servers, and countless
software products. When all is said and done, popularizing the idea of the VM
may be the most important technical contribution of Java.”
Tendo como principal apelo a independência de plataforma, a linguagem
Java tornou-se rapidamente a linguagem principal da maior parte das
empresas e até mesmo das universidades mundo afora. Além dessa
característica, outras fizeram com que a linguagem atingisse o sucesso que
tem 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 e
transformou-se numa plataforma de desenvolvimento que abarca outras
linguagens de programação, como Ruby ([JRUBY07]), Scala ([SCALA07]) e
várias outras. A tendência atual do mercado é que a linguagem Java caia
lentamente em desuso enquanto outras linguagens tomam o seu espaço na
máquina virtual da plataforma, como a própria Sun vem demonstrando com os
seus investimentos massivos em JRuby, com a contratação dos
desenvolvedores da ferramenta para a sua equipe de desenvolvimento e a
37

38. adição de JavaScript como primeira linguagem dinâmica oficialmente suportada
pela máquina virtual a partir da versão 6 do Java.
Tendo diversos problemas quando comparada a linguagens mais
dinâmicas, como Smalltalk, Python ou Ruby, Java é duramente criticada quanto
a sua natureza estática e pouco personalizável, como pode ser visto em
[BAT05]:
“First, Java offers an impoverished set of abstractions. No first-class
functions, no reference parameters, no keyword or default params, no
destructuring bind or even parallel assignment, no way to return multiple values
efficiently, no continuations, no user-defined operators, no generators, no
closures, no tuples...the list just goes on. Java's about 25 teeth shy of a full
mouth.
Second, Java is entirely nonextensible. It can't grow. There's no
metaprogramming, no macros, no templates, nothing that gives you syntactic
abstraction. So, Java's incompressible. Java code is always filled with stuff that
looks like copy and paste, but you can't factor it out. Java code and APIs always
wind up bloated (and yet oddly impressive looking).”
A abertura de espaço para novas linguagens pode abrir espaço para que
a plataforma Java continue crescendo além das possibilidades que a
linguagem provê nos dias de hoje.
2.5.1. JavaServer Faces
JavaServer Faces (JSF, [JIA04]) é o framework especificado pelo JCP
atravé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 que
incorpora características de um framework Model View Controller (MVC) para
web e de um modelo de interfaces gráficas baseadas em componentes que
respondem 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 faster
and easier. It allows developers to think in terms of components, events,
backing beans, and their interactions, instead of requests, responses, and
markup. In other words, it masks a lot of the complexities of web development
so 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 application
object, the View is its screen presentation, and the Controller defines the way
the user interface reacts to user input. Before MVC, user interface designs
tended to lump these objects together. MVC decouples them to increase
flexibility and reuse.“
Com essa separação em camadas e responsabilidades, os objetos do
modelo 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 o
papel de controlador envia as informações de um lado para o outro, fazendo o
papel de um Mediator ([GHJV98]). A estrutura do MVC no JSF é definida pela
imagem seguinte:
39

40. Figura 4 - Arquitetura de uma aplicação JSF
A parte que representa o controlador em uma aplicação JSF se inicia no
FacesServlet, que é um objeto que implementa o padrão de projeto “Front
Controller” visto em [FOWPOEAA02], que é definido como:
“The Front Controller consolidates all request handling by channeling
requests through a single handler object. This object can carry out common
behavior, which can be modified at runtime with decorators. The handler then
dispatches to command objects for behavior particular to a request. (...) A Front
Controller 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 that
actually receives post or get requests from the Web server. It pulls just enough
information from the URL and the request to decide what kind of action to
initiate 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ável
por fazer o processamento da requisição HTTP e retornar um resultado para o
usuá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 de
controle do MVC, mas são eles que fazem o acesso aos objetos do modelo
para carregar as informações, tanto trazendo informações da camada de
visualizaçã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 diretamente
as 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 ao
evento com alguma ação que possa alterar o modelo, como por exemplo
adicionar ou atualizar um objeto no banco de dados.
A camada de visualização em uma aplicação JSF segue outro padrão
visto em [FOWPOEAA02], que é o “Template View”:
“The basic idea of Template View is to embed markers into a static
HTML page when it's written. When the page is used to service a request, the
markers are replaced by the results of some computation, such as a database
query. This way the page can be laid out in the usual manner, often with
WYSIWYG editors, often by people who aren't programmers. The markers then
communicate with real programs to put in the results.
A lot of tools use Template View. As a result this pattern isn't about how
to build one yourself, but about how to use one effectively and what the
alternative is.”
A principal diferença entre a implementação do padrão em JSF para
outras alternativas, como JavaServer Pages ou engines de templates como
41

42. Velocity ou FreeMarker, é que a estrutura da visualização de uma página JSF
não segue simplesmente a marcação HTML/XHTML, mas sim uma estrutura de
componentes visuais que se desenham na tela, como em uma aplicação
desktop. 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” dos
componentes seja alterado para um que dê suporte a outro tipo de
visualização.
Além da personalização do modo pelo qual os componentes são
gerados para o usuário final, a especificação JSF também define outros pontos
de extensão, para que os desenvolvedores possam alterar o funcionamento
das 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 ou
no modo pelo qual os componentes visuais persistem o seu estado.
O desenvolvimento de aplicações web baseadas em componentes, que
sempre foi fato comum em tecnologias como o .Net ([.NET07]) da Microsft, só
agora chega a comunidade Java, mas parece não estar arrebanhando muitos
seguidores. A quantidade de frameworks web MVC que seguem o padrão de
“action”, como o framework Struts ([STRUTS07]), continuam se proliferando e
mesmo 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 para
desenvolvimento 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 comum
de 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 a
long 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 a
commom software base.”
Nascida com a premissa de funcionar como um integrador de várias
ferramentas através da sua estrutura de plugins, o Eclipse reúne diversas
ferramentas dentro de uma só, para facilitar a vida do desenvolvedor de
aplicações.
Durante as tarefas comuns de desenvolvimento de código, o profissional
normalmente tem que lidar com diversas ferramentas distintas e que muitas
vezes não conversam entre si. Ele usa um ambiente de desenvolvimento da
sua linguagem para escrever o seu código, utiliza uma ferramenta de “build”
como o GNU Make ([GMAKE07]) e uma ferramenta de controle de versão
como o CVS. Para fazer o seu trabalho de forma satisfatória ele precisa trocar
constantemente de aplicação e cada uma dessas trocas de contexto faz com
que ele perca a concentração no trabalho que está fazendo.
43

44. Utilizando uma ferramenta que integra todas estas ferramentas em uma
só, como o Eclipse faz, o programador não precisa mais sair da ferramenta que
está utilizando no momento para fazer o seu trabalho, ele simplesmente
escolhe os comandos que deseja operar. De dentro da própria ferramenta ele
pode editar e compilar o seu código, chamar uma ferramenta de automatização
de “build”, executar os testes unitários, funcionais e não funcionais e ainda
mandar 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 em
ações que geram valor para o seu trabalho, que é desenvolver software, em
vez de perder tempo lidando com ferramentas pouco intuitivas ou que não se
integram corretamente.
Hoje o Eclipse já não está direcionado apenas aos desenvolvedores de
ferramentas para facilitar o desenvolvimento, mas também para o
desenvolvimento de aplicações para o usuário final, como bem observam
[JDE05].
Com essa separação vinda na versão 3.0 da ferramenta, diversos
projetos 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ções
utilizando todas as qualidades básicas do ambiente de desenvolvimento de
plugins, como possibilidade de se ter diversas versões da mesma dependência
de forma independente, atualizações automáticas através da internet ou de
arquivos de atualização, compatibilidade com o estilo da visualização dos
componentes 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 o
projeto Eclipse para que não fosse necessário utilizar as bibliotecas padrão do
Java na criação das interfaces gráficas. O SWT acessa diretamente as
bibliotecas 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 de
interface não ocorre mais na máquina virtual e sim diretamente em código
nativo sempre. O JFace é uma biblioteca de abstração para o uso do SWT, ele
provê facilidades para o programador, simplificando a criação de aplicações
utilizando o SWT.
Mesmo não tendo implementações para todos os sistemas operacionais
suportados pela plataforma Java e apresentando alguns problemas nas suas
diversas implementações, o SWT é a escolha de uso da ferramenta Java mais
utilizada na atualidade, que é o Eclipse, e isso conta muito na sua adoção no
mercado, 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 como
objetivo oferecer uma maneira simples de prover dependências de objetos em
forma de componentes e gerenciar o ciclo de vida dessas dependências.
Containeres de IoC servem para fazer a ligação entre dependentes e
dependências, fazendo isso de várias maneiras diferentes. A IoC ainda se
subdivide em injeção de dependências (Dependency Injection) e busca por
45

46. dependências (Dependency Lookup). A inversão de controle é mais comum do
que podemos imaginar, como é exemplificado em [FOWIOC07]:
“These are complicated cases of inversion of control, but you run into this
effect in much simpler situations. A template method is a good example: the
super-class defines the flow of control, subclasses extend this overriding
methods or implementing abstract methods to do the extension. So in JUnit, the
framework code calls setUp and tearDown methods for you to create and clean
up your text fixture. It does the calling, your code reacts - so again control is
inverted.”
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 envie
uma 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 for
Tajo 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ão
de controle e também é a base da maioria dos frameworks que nós vemos
hoje, 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ão
precise depender diretamente de quem o está chamando. Outro exemplo ainda
mais comum é quando nós colocamos um “ActionListener” no evento de clique
de um botão, nós não sabemos quando é que o botão vai ser clicado, nós
simplesmente esperamos que ele clique e alguém “nos avisa” que ele foi
clicado 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 procuram
ativamente por suas dependências, como por exemplo quando fazemos uma
busca 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 normalmente
fazem com que seus objetos tenham acesso a estes objetos através de um
objeto 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 that
provide access to distributed components. Java 2 Platform, Enterprise Edition
TM
(J2EE) applications use Java Naming and Directory Interface (JNDI) to look up
enterprise bean home interfaces, Java Message Service (JMS) components,
data sources, connections, and connection factories. Repetitious lookup code
makes code difficult to read and maintain. Furthermore, unnecessary JNDI
47

48. initial context creation and service object lookups can can cause performance
problems.
The Service Locator pattern centralizes distributed service object
lookups, provides a centralized point of control, and may act as a cache that
eliminates redundant lookups. It also encapsulates any vendor-specific features
of the lookup process. “
Através do uso do “Service Locator” nós já aumentamos o nível de
indireção da aplicação, mas ainda assim a aplicação tem que depender
explicitamente do objeto que implementa o locator, quando o que na verdade
nos interessa é o objeto que ele está buscando em algum lugar. O meio pelo
qual 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 de
acoplamento com objetos que não fazem parte diretamente do domínio
continua alto.
2.7.2. Injeção de dependências – (Dependecy
Injection)
A injeção de dependências é uma nova abordagem para IoC, nela os
objetos não procuram por suas dependências, elas são inseridas neles pelo
container de IoC. Ela é feita de duas maneiras diferentes, através do construtor
do objeto (passando as dependências como argumentos do construtor) ou
atravé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 “service
locators” como no caso da busca por dependências. Os objetos não ficam
presos a uma implementação específica porque eles não “sabem” como as
dependências foram parar ali, eles apenas as usam.
Com a utilização desse modo de inversão de controle nós diminuímos o
acoplamento ao mínimo possível, pois os objetos acessam apenas os objetos
com os quais eles precisam colaborar, não precisam mais acessar objetos
intermediários que trabalham como fábricas ou fontes dos objetos que eles
necessitam para fazer os seus trabalhos.
A inversão de controle normalmente é possibilitada por containers de
inversão de controle, como o Spring, que é um dos mais utilizados frameworks
de inversão de controle na comunidade Java.
2.7.3. O framework Spring
O framework é um container de inversão de controle baseado nos
preceitos da injeção de dependências, através dele é possível interrelacionar
os diversos objetos de uma aplicação Java sem que eles precisem saber de
onde vieram as suas dependências ou o que elas fizeram para que pudessem
chegar até eles. Mas o container de inversão de controle é apenas uma das
partes do framework, esse container funciona, segundo [SPR07] da seguinte
forma:
“The IoC component of the Spring Framework addresses the enterprise
concern of taking the classes, objects, and services that are to compose an
application, by providing a formalized means of composing these various
49

50. disparate components into a fully working application ready for use. The Spring
Framework takes best practices that have been proven over the years in
numerous applications and formalized as design patterns, and actually codifies
these patterns as first class objects that you as an architect and developer can
take away and integrate into your own application(s). This is a Very Good Thing
Indeed as attested to by the numerous organizations and institutions that have
used the Spring Framework to engineer robust, maintainable applications.“
O Spring funciona como um grande contexto onde todos os objetos
gerenciados 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 e
colocar informações e objetos em suas propriedades. O contexto em si
funciona como um “service locator”, a única diferença é que nenhum dos
objetos que está sendo gerenciado toma conhecimento do “service locator” (a
não ser que ele avise explicitamente que deseja acessar ele), ele mesmo faz a
busca 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 outros
seis módulos, conforme a figura a seguir:
50

51. Figura 5 – Módulos do framework Spring
Os 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 com
diversos outros frameworks que fazem serviços distintos mas que são de uso
comum 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 um
antigo problema, mas sim se aproveitar das ferramentas que existem hoje para
simplificar a resolução das dificuldades que foram encontradas. Por isso ele
está muito mais interessado em integrar os diversos frameworks de forma
homogênea do que simplesmente criar novos frameworks para competir com
os que já estão disponíveis no mercado.
53

54. 3. Atividades realizadas
O trabalho desenvolvido durante o estágio foi o de projetar e
implementar a aplicação Report Center e o framework de componentes de
interface Phrame UI, possibilitando a criação de aplicações para a web e para o
desktop de forma transparente, utilizando as tecnologias e técnicas
apresentadas na seção 2. As atividades serão separadas a partir de agora por
cada artefato produzido.
3.1. Report Center
O Report Center é uma aplicação de apresentação de relatórios para a
web, que acessa um gerador de relatórios baseado na ferramenta Crystal
Reports ([CRPT07]), ela apresenta um formulário com os dados necessários
para executar o relatório e após o preenchimento destes dados, a aplicação
invoca 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 estava
parado há mais de um ano e utilizava tecnologias defasadas no mercado, como
“scriptlets” em páginas JavaServer Pages puras, o que segue contra a
separação da aplicação em camadas. A aplicação também não fazia acesso
direto a bancos de dados nem tinha um modelo de objetos que representasse
os objetos com os quais ela trabalhava, que eram os relatórios, as telas de filtro
e os campos que deveriam aparecer nas telas de filtro.
A ferramenta havia surgido dos pedidos de vários clientes de ter algum
meio 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 completa
para isso. Eles desejavam acessar o sistema de forma remota tendo como
cliente 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 inicialmente
como 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 as
tecnologias que seriam utilizadas no decorrer da implementação. Para a
camada 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 pelos
usuá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íveis
no mercado, de forma que muito do trabalho de geração de interfaces gráficas
seria evitado com o simples uso destes componentes.
O framework Spring foi selecionado como container de inversão de
controle padrão tanto pelas suas qualidades no campo de containers IoC, como
também pela farta documentação encontrada tanto em livros como em sites
especializados. A integração completa com JSF também foi um dos fatos que
pesou a favor dele, pois nada seria necessário para fazer com que ele
funcionasse 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 mapeamento
objeto-relacional Hibernate, foi escolhida pela sua grande penetração de
mercado e apoio de uma grande comunidade, também com muita
documentaçã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ível
começ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 baseado
nos comportamentos necessários para que seja possível se acessar e gerar
um relatório para o usuário final. Partimos então para o descobrimento das
entidades que seriam encontradas nesse modelo, através da análise das
informações que haviam sido coletadas.
57

58. As entidades Report, ReportFilter, ReportField, User e Right, são as
entidades principais que nós encontramos no nosso sistema, é através delas
que nós montamos a nossa lógica de negócio para resolver o problema da
geração de relatórios.
Além delas, nós temos também uma classe de serviço, que é a
ReportServer que abstrai toda a comunicação do Report Center com o servidor
de relatórios Report Server. Através desta abstração, a aplicação não precisa
saber que os relatórios estão vindo de uma aplicação externa, a
implementação poderia ser facilmente alterada para um gerador de relatórios
próprio e isso não causaria impacto algum na aplicação, pois ela não conhece
o real comportamento do objeto, conhece apenas a interface que ele exporta e
os contratos que ele exige que sejam mantidos.
Para fazer a requisição da geração de um relatório, o código deve dizer
ao objeto ReportServer qual o relatório ele deseja que seja gerado e quais os
valores devem ser passados para os campos do relatório. Com apenas estas
informações, ele já é capaz de acessar o servidor externo e fazer a requisição
de um relatório, se todos os dados houverem sido enviados corretamente, o
servidor retorna o arquivo de relatório gerado que é então mostrado para o
usuário final.
A comunicação feita com o Report Server atualmente é feia com base
em sockets simples, o cliente envia uma requisição de relatório em formato
XML pelo socket e o servidor responde a essa requisição com um arquivo XML
de resposta e o relatório gerado se tudo houver corrido corretamente. Os
arquivos XML são consumidos e gerados através do uso da API JDOM de
parsing 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 o
acúmulo de responsabilidades não é uma boa idéia em um sistema orientado a
objetos, para o Report Center a autorização e autenticação de usuários é feita
através do objeto “SecutityManager”, que atualmente faz uma chamada direta
ao Report Server mas que futuramente pode fazer a autenticação e autorização
utilizando outros meios.
Mais uma vez, alterar a implementação do “SecurityManager” não deve
causar impactos na aplicação, pois ela não sabe como os usuários são
autenticados ou autorizados, eles simplesmente acessam um serviço provido
por 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ês
camadas encontrado em [FOWPOEAA02].
Na camada de visualização encontram-se os “backing beans” do JSF e
as páginas JSF propriamente ditas, que geram os formulários de filtro
baseados no relatório que o usuário deseja gerar. Essa camada é responsável
por obter informações do usuário e repassá-las para o modelo, para que ele
possa 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 a
bancos de dados. Todo o acesso a bancos de dados é feito através de objetos
que 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 mensagens
para a aplicação Report Server. Entretanto, como ele estavam próximos
demais da necessidade real da aplicação, tornou-se mais lógico colocá-los
diretamente na camada de domínio, para que os objetos do domínio tomassem
conhecimento destes objetos e pudessem utilizá-los como meio para
desenvolver as suas funcionalidades.
Todo o acesso a banco de dados feito pelas classes que implementam o
padrão Repository é feito através da ferramenta de mapeamento objeto
relacional Hibernate. Dentro da aplicação ela é utilizada em conjunto com o
framework 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. Esta
camada encontra-se isolada das outras de forma que ela não acessa
diretamente ou conhece nenhuma das outras camadas do sistema. Todo o
modelo de domínio é independente da camada de visualização e de dados do
sistema.
Todo os relacionamentos dos objetos nas diversas camadas é
gerenciado pelo container de IoC do framework Spring, que tem, em seu
módulo web, uma integração completa com a especificação JSF, de forma que
tornou-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 foram
encontrados, 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” em
61

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 da
empresa, já na sua fase de transição. Para o futuro existem novos requisitos
surgindo, que devem abrir espaço para uma nova versão da aplicação. Um dos
principais requisitos é a adição de novas engines de relatório que sejam Java
puro, para evitar os problemas enfrentados com a implementação atual do
Crystal Reports, entre as possibilidades está o uso das ferramentas
JasperReports ou Eclipse Birt.
3.2. Phrame UI
O Phrame UI é um framework de componentes visuais que tem como
seu objetivo principal acabar com a necessidade de se escrever uma versão
web 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 um
ambiente desktop como web, sem que seja necessário reescrever nenhuma
linha de código.
O framework faz parte de um conjunto de frameworks que estão em
desenvolvimento dentro da Phoebus pra atualizar toda a sua base de
aplicações para a plataforma Java, este conjunto de frameworks recebeu o
nome coletivo de projeto Phrame. O objetivo destes diversos projetos é
62

63. aumentar a velocidade com a qual as aplicações são escritas, garantindo o
reuso entre as diversas implementações e garantindo também a qualidade do
código, que é testado com freqüência para evitar que problemas surjam.
O framework Phrame UI foi concebido inicialmente como sendo uma
ferramenta baseada em meta-dados e que faria o uso de transformadores XML
para gerar o código de interface. Entretanto, o projeto seguiu por outro caminho
e tornou-se um conjunto de componentes visuais igual a qualquer outra
biblioteca de componentes.
3.2.1. Requisitos Funcionais
Os requisitos funcionais definidos para o framework em seu primeiro
momento 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 de
tecnologias. Para a implementação inicial da versão desktop do framework, foi
selecionado 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 garante
que o “look and feel” das aplicações é sempre igual ao do sistema operacional
no qual ela está executando.
Para a implementação da versão web, dois frameworks foram
selecionados, o Echo 2 Framework ([ECHO07]) e o Thinwire ([THI07]). Na
avaliação dos dois, o framework Thinwire demonstrou ter mais vantagens e
uma implementação mais sólida do modelo de componentes. A principal
característica que fez com que ele fosse selecionado no lugar do Echo 2, foi a
possibilidade de posicionar os componentes de forma absoluta na tela do
navegador do cliente, algo que é extremamente comum em aplicações desktop
e que é complexo de se conseguir em aplicações web.
Com a adição dessa característica através do uso do Thinwire, também
foi possível fazer com que os gerenciadores de layout dos diversos frameworks
pudessem 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 pelo
Phrame UI e estão funcionando corretamente, da mesma forma que eles
funcionavam para os seus conjuntos de componentes específicos.
Ainda que funcionando corretamente, algumas das capacidades do
gerenciador de layouts JGoodies foram perdidas. A mais importande delas é a
definição do tamanho dos componentes através de medidas relativas ao
tamanho da tela e das fontes utilizadas e não em medidas absolutas. Como era
impossível obter as informações do tamanho da fonte no ambiente web de
forma simples, essa característica foi removida da adaptação da ferramenta.
Além disso, o módulo de “form builders”, que são classes especializadas
na construção automatizada de formulários padronizados também não foi
adicionado, pois ele necessitava da implementação da característica de
tamanho 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, para
que dessa forma ele possa escolher exatamente qual implementação do
componente utilizar baseando-se no contexto onde ele está inserido. Para
chegar a solução deste problema, foi criada uma família inteira de interfaces
que representam os componentes visuais básicos que qualquer aplicação
deveria conter, através da definição dessa família de componentes, definimos
também interfaces para as fábricas de componentes, que seriam os objetos
responsá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 diversas
famílias de componentes é análoga ao exemplo apresentado por [GHJV99],
onde é necessário criar componentes de famílias diferentes. Toda a
implementação gira em torno das interfaces Widget e WidgetFactory. A
interface Widget é a interface pai de todos os componentes visuais e a
interface WidgetFactory é a fábrica de componentes para a família de
componentes na qual ela está inserida. Existe, então, uma implementação da
WidgetFactory que cria os componentes baseados nos objetos do SWT e outra
WidgetFactory que cria os componentes baseados nos objetos do Thinwire.
Como os componentes apresentam interfaces distintas, é necessário
fazer com que eles apresentem interfaces homogêneas. Para que isso fosse
possível, foi criada toda uma hierarquia de objetos “adapters” que
transformavam as interfaces proprietárias dos componentes na interface
padrã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 API
padrão.
Então, toda a implementação do modelo é apenas a criação de classes
“adapter” para as diversas classes das bibliotecas de componentes que
precisam ser compatibilizadas.
Como não era possível reaproveitar também os modelos apresentados
pelos componentes em suas implementações específicas, foram criados
objetos que funcionam como mediadores entre modelos específicos do Phrame
UI 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 foram
encontrados, 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 desktop
em produção em diversos clientes, mas até agora nenhuma delas foi testada
oficialmente 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, que
relaciona fontes de dados, como objetos, resultados de buscas em bancos de
dados e outros.
Essa biblioteca facilita a junção de bancos de dados e aumenta a
produtividade no desenvolvimento de aplicações que simplesmente acessam o
banco de dados.
Os planos futuros para o framework ainda não foram definidos, as únicas
alterações em andamento são resolução de bugs e a adição de novos
componentes, nenhuma mudança na modelagem ou na arquitetura do
framework estão sendo esperadas no momento atual.
69