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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

É 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

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

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

Imagem 2 – Tipos de diagramas UML – Retirada de [FOWUML03]

Diagrama Propósito

Atividade (Activity) Comportamento procedural ou paralelo

23

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

“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

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

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

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

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

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

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

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

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

• 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

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

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

• 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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

• 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

é 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

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

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

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

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

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

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

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

• 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

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

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

• 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

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

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

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

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

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

4. Considerações finais

A experiência de estagio como desenvolvedor Java foi extremamente

importante por ter possibilitado colocar em prática os conceitos e teorias

aprendidos em sala de aula, além do que o convívio em um ambiente real de

trabalho também fornece uma visão diferenciada do que é ser um

desenvolvedor no mercado de trabalho que nós temos hoje.

O uso da linguagem Java e de seus diversos frameworks para

desenvolver provou ser uma boa escolha para as aplicações escolhidas, mas

isso não fez com que outras soluções não fossem avaliadas. A linguagem Java

está perdendo lentamente espaço na máquina virtual e o esperado é que as

novas linguagens como Ruby, Groovy e Scala abram espaço para a criação de

uma nova cultura de programação.

As grandes desvantagens do Java hoje frente estas linguagens mais

simples são a burocracia para se iniciar um projeto qualquer e o tempo que se

espera até que um servidor web esteja pronto para fazer requisições e

responder às interações do usuário. Em uma linguagem como Ruby, apenas

alterar e salvar o arquivo já é o suficiente para que eu possa ver as alterações

sendo mostradas, sem que seja necessário reiniciar o servidor. Além disso, a

quantidade de arquivos de configuração necessários para se desenvolver uma

aplicaçã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 se

voltar mais para o princípio da “convertion over configuration”, para evitar a

repetição e o retrabalho na hora de definir os sistemas.

70

A experiência de trabalhar em um lugar que procura implementar um

processo onde ainda não está formada a cultura de processo e onde as

ferramentas também não simplificam o trabalho, também foi importante para

perceber que a maior parte dos problemas que nós enfrentamos no

desenvolvimento de software não são técnicos, são humanos. Falhas na

comunicação, problemas de entendimento, exceções que são mais comuns

que as regras e más interpretações do que está sendo definido são uma

comprovação de que simplesmente definir um processo de qualquer forma não

resolve 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ível

compreender o valor da comunicação entre as pessoas envolvidas no projeto e

o quanto isso pode facilitar a vida da equipe, quando todos estão envolvidos

em achar uma solução pra o problema.

O Report Center foi um passo a frente, migrando um software que era

eminentemente desktop para a plataforma web. Com isso diminuiu-se os

gastos com implantação, suporte e manutenção de sistemas, além de garantir

a satisfação dos clientes, que hoje podem visualizar os seus relatórios de

qualquer lugar que eles acharem necessário. A ferramenta só precisa melhorar

nos quesitos de facilidade de se adicionar novos relatórios e filtros para os

mesmos; ainda é complicado demais criar novos filtros.

O Phrame UI ainda hoje é uma incógnita, investir em aplicações desktop

não parece ser uma boa escolha em uma época onde todos os serviços estão

fazendo de tudo para migrar para a web. Até mesmo clientes e usuários

costumam preferir aplicações web, pois eles podem sempre utilizar quando e
71

como quiserem, sem que seja necessário a instalação de nenhum software a

mais. Além disso, aplicações web e desktop existem em ambientes

extremamente diferentes e lidam com realidades completamente diferentes,

ignorar estes fatos pode trazer sérios problemas no futuro, especialmente se as

ferramentas começarem a ser utilizadas sem avaliações ou testes não

funcionais.

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 no

seu navegador. Esse modelo lembra muito o modelo clássico de cliente-

servidor, onde um cliente fazia uma busca no servidor, guarda as informações

e opera com elas. Neste caminho existem tecnologias como o Adobe Flex, o

Microsft Silverlight e o JavaFX, nenhum deles poderia ser facilmente “plugado”

no Phrame UI porque eles não executam código em Java nem podem ser

criados diretamente por uma fábrica de componentes, o que evita

completamente que eles possam ser utilizados.

A experiência e os conhecimentos adquiridos foram válidos e vão ser

muito importantes no meu crescimento pessoal e profissional, nestes dias que

ainda estão por vir.

72

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>, acesso

em 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>, acesso

em 02/07/2007.

[CoC07] Chen, Nicholas. Convention Over Configuration. Disponível em

<http://softwareengineering.vazexqi.com/files/pattern.html>, acesso em

02/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 in

the Heart of Software. Addison Wesley, 2003.

73

[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/>, acesso

em 02/07/2007.

[EJB07] Enterprise Java Beans Technology. Sun Microsystems, disponível

em <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 em

02/07/2007.

[FOWPOEAA02] Fowler, Martin. Patterns of Enterprise Application

Architeture. Addison-Wesley, 2002.

[FOWIOC07] Fowler, Martin. Inversion of Control. Disponível em <

http://www.martinfowler.com/bliki/InversionOfControl.html>, acesso em

02/07/2007.

[FOWUML03] Fowler, Martin. UML Distilled: A Brief Guide to the Standard

Object 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 em

02/07/2007.

[JAC07] Jacobson, Ivar; Ng, Pan-Wei; Spence, Ian. Enough of Processes:

Let's Do Practices Part I. Dr. Doob’s Journal, disponível em <

http://www.ddj.com/dept/java/198000264>, acesso em 02/07/2007.
74

[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ível

em <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 Sobre

Projeto 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-driven

development. IBM Developer Works, disponível em <http://www-

128.ibm.com/developerworks/rational/library/oct05/kroll/>, acesso em

02/07/2007.

75

[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 Palo

Alto 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 em

02/07/2007.
76

[WBM07] Booch’s method. English Wikipedia, disponível em <

http://en.wikipedia.org/wiki/Object-oriented_software_engineering>, acesso em

02/07/2007.

[WOCL07] Object Constraint Language. English Wikipedia, disponível em <

http://en.wikipedia.org/wiki/Object_Constraint_Language>, acesso em

02/07/2007.

[WOOSE07] Object-Oriented Engineering. English Wikipedia, disponível em

<http://en.wikipedia.org/wiki/Object-oriented_software_engineering>, acesso

em 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 em

02/07/2007.

[WQVT07] QVT (Queries/Views/Transformations). English Wikipedia,

disponível em < http://en.wikipedia.org/wiki/QVT>, acesso em 02/04/2007.

77

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

Mais conteúdo relacionado

Mais procurados (18)

Destaque (9)

Semelhante a Relatório de Estágio da Graduação (20)

Mais de Maurício Linhares (20)

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