Uso de frameworks em aplicações ágeis

ESCOLA SUPERIOR ABERTA DO BRASIL - ESAB
CURSO DE PÓS-GRADUAÇÃO LATO SENSU EM
ENGENHARIA DE SISTEMAS

ROGÉRIO DA SILVA BATISTA

O USO DE FRAMEWORKS EM APLICAÇÕES DESKTOP BASEADAS
NA METODOLOGIA DE DESENVOLVIMENTO ÁGIL

VILA VELHA - ES
2012



Monografia apresentada ao Curso de Pós-
Graduação Lato Sensu em Engenharia de
Sistemas da Escola Superior Aberta do
Brasil como requisito para obtenção do
título de Especialista em Engenharia de
Sistemas, sob orientação do Prof. Msc.
Cleyverson Pereira Costa

VILA VELHA - ES
2012



Monografia aprovada em ___ de __________ de 2012.

Banca Examinadora

VILA VELHA - ES
2012

RESUMO

Palavras-chave: “Desenvolvimento Ágil”, “Metodologia”, “Frameworks” “Design
Patterns”.

Uma das principais necessidades no desenvolvimento de software atualmente é a
otimização do tempo e trabalho gasto no andamento do projeto, por diversos
motivos o cliente não se satisfaz ou não aceita esperar mais do que alguns meses
por um produto de qualidade.
Dentre as diversas ferramentas criadas para suprir esta necessidade, duas se
destacam, as metodologias de desenvolvimento ágeis e os frameworks, cada uma
delas possuem características que as qualificam para esta tarefa, as metodologias
tratam da forma como o projeto é gerenciado e da equipe envolvida nele enquanto
os frameworks são direcionados a parte técnica do desenvolvimento fornecendo
rotinas e funcionalidades para reutilização.
Porque então não aplicar ambas em projetos de desenvolvimento de software? E
quais seriam as principais vantagens e desvantagens disso?
Para responder essas questões este trabalho busca descrever algumas destas
metodologias de desenvolvimento ágeis juntamente com alguns frameworks a fim de
conhecê-los melhor e descobrir se realmente existe vantagem em substituir
ferramentas com aproximadamente 30 anos de existência e vários casos de
sucesso, para isso, um projeto criado com metodologias tradicionais foi adaptado
para metodologias ágeis juntamente com frameworks, o resultado foi satisfatório
apesar de ser um caso único.

SUMÁRIO

INTRODUÇÃO ............................................................................................................ 6
CAPÍTULO 1 - METODOLOGIA DE DESENVOLVIMENTO ÁGIL DE SOFTWARE . 8
1.1 – O MANIFESTO ÁGIL........................................................................................ 10
1.2 – VANTAGENS E DESVANTAGENS DO DESENVOLVIMENTO ÁGIL ............. 12
1.2.1 Principais vantagens do Desenvolvimento Ágil ....................................... 12
1.2.2 Principais desvantagens do Desenvolvimento Ágil ................................ 13
1.3 CONSIDERAÇÕES PARCIAIS ........................................................................... 14
CAPÍTULO 2 - TÉCNICAS DE DESENVOLVIMENTO ÁGIL ................................... 15
2.1 – EXTREME PROGRAMMING (XP) ................................................................... 15
2.2. SCRUM .............................................................................................................. 18
2.3. FEATURE DRIVEN DEVELOPMENT (FDD) ..................................................... 21
2.4. CONSIDERAÇÕES PARCIAIS .......................................................................... 23
CAPÍTULO 3 - FRAMEWORKS PARA APLICAÇÕES JAVA ................................. 24
3.1. HIBERNATE 4.0 ................................................................................................. 24
3.1.1 Configuration............................................................................................... 25
3.1.2 Session ........................................................................................................ 25
3.1.3 SessionFactory ........................................................................................... 26
3.1.4 Query............................................................................................................ 26
3.1.5 Transaction .................................................................................................. 26
3.2. OPENSWING 2.4.5 ............................................................................................ 27
3.3. JASPERREPORTS 4.5 ...................................................................................... 29
CAPÍTULO 4 - DESIGN PATTERNS ........................................................................ 34
4.1. MODEL VIEW CONTROLLER (MVC) ................................................................ 35
4.2. VALUE OBJECT (VO) ........................................................................................ 37
4.3. DATA ACSESS OBJECT (DAO) ........................................................................ 37
CAPÍTULO 5 - PORQUE UTILIZAR FRAMEWORKS EM UM PROJETO DE
DESENVOLVIMENTO ÁGIL ..................................................................................... 39
5.1. APRESENTAÇÃO DO CASO DE USO .............................................................. 39

CAPÍTULO 6 - CONCLUSÃO ................................................................................... 49
6.1. TRABALHOS FUTUROS ................................................................................... 50
REFERÊNCIA BIBLIOGRÁFICA.............................................................................. 51

6

INTRODUÇÃO

Segundo Theunissen, Boake e Kourie (2005) as metodologias tradicionais como
SDM-70 e Method-1 foram desenvolvidas antes de tecnologias como a internet e o
XML (Extensible Markup Language), sendo inovadoras e efetivas no contexto das
tecnologias e requisitos de negócios existentes na época, além de exigirem
documentações extensas baseados nos requisitos do negócio e em suas possíveis
alterações.

As metodologias de desenvolvimento de software mais populares, como a
metodologia de desenvolvimento em cascata, e a metodologia de desenvolvimento
incremental revolucionaram a maneira de criar software estabelecendo padrões e
métodos antes desconhecidos ou ignorados pelos desenvolvedores, contudo,
atualmente devido as grandes inovações na área da tecnologia e informação e do
crescente interesse das empresas em se adaptar rapidamente as mudanças, tais
métodos podem não atender eficientemente aos requisitos e devido a esta e outras
razões as metodologias de desenvolvimento ágil vem ganhando destaque no cenário
atual.

De acordo com Lindstrom e Jeffries (2005) as metodologias de desenvolvimento
ágeis são usadas para criar softwares em um curto período de tempo seguindo
cronogramas de desenvolvimento adaptando-se as possíveis alterações dos
requisitos de negócio.

Os frameworks não estão focados no desenvolvimento ágil mais na reutilização de
códigos e funcionalidades, porém com isto o desenvolvedor economiza um tempo
considerável de desenvolvimento.

Porque então não conciliar metodologia de desenvolvimento ágil com frameworks
em um único projeto? Quais seriam as principais vantagens e desvantagens desta
união?

O mundo moderno exige soluções cada vez mais rápidas e eficazes, capazes de
adaptarem-se rapidamente as mudanças, o desenvolvedor de softwares deve ser

7

capaz de atender essas exigências, e para isso é extremamente importante o
conhecimento sobre as ferramentas disponíveis, suas características e suas
funcionalidades a fim de atender o cliente de forma satisfatória.

O objetivo principal deste trabalho é mostrar as vantagens e desvantagens em se
utilizar as metodologias de desenvolvimento ágil, detalhar o que são frameworks e
especificar alguns deles descrevendo suas características, depois associar as duas
tecnologias para demostrar como uma complementa a outra no desenvolvimento de
softwares.

A pesquisa apresentara como caso de uso trechos de software, desenvolvidos a
partir das metodologias de desenvolvimento ágil Scrum e XP, e de três frameworks
com finalidades totalmente distintas, hibernate, OpenSwing e JasperReports, antes
de analisa-los, porém é importante conhecer tais ferramentas, e para isto, elas foram
especificadas nos capítulos iniciais deste trabalho.

No total este trabalho conta com cinco capítulos sobre dos quais o primeiro
especifica o que são as metodologias de desenvolvimento ágil, como surgiu, e como
elas contribuem para o desenvolvimento do software de forma ágil e confiável, o
segundo especifica três destas metodologias, o Scrum, o Extreme Programming
(XP) e o Feature Driven Development (FDD) demostrando características de cada
uma delas, no terceiro capitulo o assunto passa a ser os frameworks, ferramentas
que auxiliam na reutilização de processos e funcionalidades acelerando o
desenvolvimento, este capitulo possui três subseções onde são especificados três
frameworks diferentes, o hibernate, o OpenSwing e o JasperReports, cada um com
uma finalidade diferente quando utilizado em uma aplicação, na sequência, no
capítulo seguinte é descrito superficialmente informações sobre a arquitetura MVC
(Model, View e Controller) e dois modelos de design patterns (padrões de projeto), o
VO (Value Object) e o DAO (Data Access Object), utilizados no caso de uso
apresentado no último capítulo deste trabalho, que tem como objeto de pesquisa um
software desenvolvido com base nas metodologias de desenvolvimento ágeis e nos
frameworks apresentados, encerrando o trabalho a conclusão mostra que para o
projeto se tornar realmente ágil tanto os frameworks quanto as metodologias de
desenvolvimento ágeis devem ser utilizadas de forma que uma complemente a
outra.

8

CAPÍTULO 1 - METODOLOGIA DE DESENVOLVIMENTO ÁGIL DE
SOFTWARE

Vários estudos apontam que grande parte dos projetos de softwares não é concluída
como planejada por diversos fatores, um desses estudos foi realizado pelo grupo
The Standish Group (2009) e mostrou, com base em cerca de 8380 projetos que
24% deles fracassaram, ou seja, foram cancelados ou não foram utilizados, 44%
obtiveram sucesso parcial, onde o projeto foi entregue mais não atendeu as
expectativas funcionais ou de custo do projeto e apenas 32% dos projetos obtiveram
sucesso, ou seja, foram entregues dentro do prazo, dentro do orçamento e com boa
parte do escopo concluída. Segundo esta mesma pesquisa, dentre os principais
fatores para o fracasso dos projetos estão: requisitos incompletos, falta de
envolvimento do usuário e de recursos, expectativas não realistas, falta de apoio
executivo, mudança de requisitos, falta de planejamento entre outros.

Figura 1 – Evolução dos percentuais das pesquisas CHAOS de 1994 até 2008
Fonte: Standish Group, CHAOS Summary for 2010

9

Além dos fatores citados acima diariamente surgem novas tecnologias e novas
necessidades, um exemplo disto foi à criação da nota fiscal eletrônica (NF-e), que
segundo a Secretaria da Fazenda é uma alteração, adotada pelo governo brasileiro,
da sistemática de emissão de notas fiscais em papel por notas fiscais eletrônicas,
essa alteração fez com que muitos sistemas de softwares que no momento emitiam
notas fiscais apenas em papel se tornassem obsoletos, necessitando serem
modificados para as novas normas, logicamente houve um tempo de adaptação,
mas na prática vários clientes passaram a dar preferência às empresas já
adaptadas, e neste ponto tornou-se visível a necessidade da modificação dos
softwares no menor tempo possível e com garantias de confiabilidade devido à
demanda.

Utilizado um dos modelos mais comuns para desenvolvimento de software como o
modelo em cascata, uma alteração como a inclusão da emissão de NF-e em um
software pode levar meses até ser concluída adequadamente, uma vez que todas as
fases do projeto (Análise, Projeto, Codificação, Teste e Manutenção) devem ser
refeitas.

Theunissen, Boake e Kourie (2005) dizem que:

Traditional methodologies such as SDM-70 or Method-1 were developed
before technologies such as the Internet, XML, or ubiquitous computing
were in existence. Traditional methodologies were innovative and effective in
the context of existing technologies and business requirements. Traditional
methodologies require extensive documentation, locking in business
requirements, and require changes to existing software products and
documentation produced prior to requirement changes.

A metodologia de desenvolvimento ágil segundo A. Cockburn (2002) é caracterizada
pela adaptabilidade, ou seja, pela capacidade de absorver mudanças, sejam elas
nos requisitos do sistema, tendências de mercado, nas tecnologias empregadas
para o desenvolvimento ou nas equipes envolvidas no projeto.

10

Lindstrom e Jeffries (2005) descrevem as metodologias ágeis como:

Agile methodologies are used to produce higher quality software in a shorter
period of time. Agile methodologies were developed to streamline the
development process and remove barriers to accepting business
requirement changes during the development process. Agile methodologies
do not require that business requirements and design details be locked in for
the duration of development.

1.1 – O MANIFESTO ÁGIL

De acordo com Fowler (2000) o termo “Metodologias Ágeis” se popularizou no final
da década de 90, mais especificamente em fevereiro de 2001 em Utah, Estados
Unidos, quando um grupo de 17 grandes pensadores em processos de
desenvolvimento de software, se reuniram para discutir maneiras de melhorar as
técnicas de desenvolvimento de software.

A partir do consenso estabelecido neste encontro foi criado o Manifesto Ágil para o
desenvolvimento de software, apoiado nos seguintes valores:

1. Indivíduos e interações mais que processos e ferramentas.

2. Software em funcionamento mais que documentação abrangente.

3. Colaboração com o cliente mais que negociação de contratos.

4. Responder a mudanças mais que seguir um plano.

O Manifesto ágil não ignora os processos e ferramentas, muito menos a
documentação e a negociação de contratos, cada um deles possuem um valor
fundamental para o desenvolvimento do software, porém baseado na necessidade
do cliente em se adaptar rapidamente as mudanças, o manifesto ágil prioriza outros
pontos como a interação entre os indivíduos e o funcionamento do software.

11

Além dos valores ainda segundo Fowler (2000), o Manifesto Ágil descreve doze
princípios para o desenvolvimento ágil do software com qualidade, que são:

1. Nossa maior prioridade é satisfazer o cliente através da entrega contínua e
adiantada de software com valor agregado.

2. Mudanças nos requisitos são bem-vindas, mesmo tardiamente no
desenvolvimento. Processos ágeis tiram vantagem das mudanças visando
vantagem competitiva para o cliente.

3. Entregar frequentemente software funcionando, de poucas semanas a poucos
meses, com preferência à menor escala de tempo.

4. Pessoas de negócio e desenvolvedores devem trabalhar diariamente em
conjunto por todo o projeto.

5. Construa projetos em torno de indivíduos motivados. Dê a eles o ambiente e
o suporte necessário e confie neles para fazer o trabalho.

6. O método mais eficiente e eficaz de transmitir informações para e entre uma
equipe de desenvolvimento é através de conversa face a face.

7. Software funcionando é a medida primária de progresso.

8. Os processos ágeis promovem desenvolvimento sustentável. Os
patrocinadores, desenvolvedores e usuários devem ser capazes de manter
um ritmo constante indefinidamente.

9. Contínua atenção a excelência técnica e bom design aumenta a agilidade.

10. Simplicidade – a arte de maximizar a quantidade de trabalho não realizado –
é essencial.

11. As melhores arquiteturas, requisitos e designs emergem de equipes auto-
organizáveis.

12. Em intervalos regulares, a equipe reflete sobre como se tornar mais eficaz e
então refina e ajusta seu comportamento de acordo.

12

Guiados por estes valores e princípios o profissional de software adquiri a
capacidade de criar e modificar softwares de forma efetiva, incentivando adaptações
nos requisitos para que o resultado seja o mais próximo possível do esperado.

1.2 – VANTAGENS E DESVANTAGENS DO DESENVOLVIMENTO ÁGIL

Apesar de trazer inúmeras vantagens para o desenvolvedor, o desenvolvimento ágil
pode demostrar ineficiência em alguns aspectos que não devem ser
menosprezados, Nas sessões seguintes tais vantagens e desvantagens são
descritas.

1.2.1 Principais vantagens do Desenvolvimento Ágil

 Liderança de mercado e maiores lucros – Pesquisas apontam que os
principais líderes de mercado foram os que lançaram seus produtos primeiro,
o que também indica maior arrecadação financeira, o desenvolvimento ágil
favorece o lançamento de versões regulares seguido de constantes
atualizações até a entrega final do produto, a partir da primeira versão do
software o produto já pode ser disponibilizado.

 Qualidade e satisfação do cliente – Dois fatores fundamentais no
desenvolvimento ágil são os testes realizados durante todo o
desenvolvimento do software, visando à eliminação de possíveis falhas e a
qualidade do produto, e o acompanhamento do cliente que possibilita uma
visão mais aguçada dos requisitos tornando-o flexível perante as mudanças.

13

 Controle de riscos e adaptabilidade – Ao disponibilizar constantes versões
do software é possível identificar ainda durante o desenvolvimento erros
sistemáticos e corrigi-los, da mesma forma é possível prever novos requisitos
e se adaptar as mudanças antes do produto ser lançado.

 Expectativas alcançadas – Levando em conta os itens anteriores é possível
concluir que o sucesso do projeto é garantido, destacando que o cliente está
presente praticamente durante todo o desenvolvimento do produto,
justamente para que o produto final esteja adequado as suas necessidades.

1.2.2 Principais desvantagens do Desenvolvimento Ágil

 Responsabilidade e compromisso – A metodologia requer um constante
envolvimento por parte do cliente para que aconteça uma colaboração
constante com o desenvolvedor, o resultado desta interação se torna algo
positivo, mais o compromisso pode exigir muito tempo e muitas vezes o
cliente pode não estar disponível.

 Imprevisibilidade – Como o desenvolvimento ágil se baseia em adaptação e
flexibilidade, o processo de desenvolvimento pode ser alongado a ponto de se
correr riscos financeiros já que é impossível prever a dimensão do produto
final e calcular um preço fixo.

 Pouca documentação – A tendência ao utilizar o desenvolvimento ágil é o
enfoque no desenvolvimento e a diminuição da documentação, muito se fica
na informalidade, dificultando o ingresso de novos integrantes a equipe e
causando muitas vezes desentendimentos entre os desenvolvedores.

14

1.3 CONSIDERAÇÕES PARCIAIS

Highsmith e Cockburn (2000) afirmam que a novidade das metodologias ágeis não
são as práticas que ela utiliza mais o reconhecimento das pessoas envolvidas como
principio fundamental para o sucesso do projeto.

Acredito que dificilmente será criada uma metodologia que deixe de apresentar
qualquer desvantagem, seja para o cliente quanto para o desenvolvedor, porém as
metodologias ágeis possuem um diferencial positivo ao trazerem o cliente para
dentro do projeto, detalhando juntamente com o arquiteto os requisitos em cada
etapa, tornando a comunicação mais harmoniosa quanto aos obstáculos
encontrados. Sem entrar em detalhes, observando algumas metodologias
tradicionais onde o cliente apresenta os requisitos no inicio do projeto e sua
participação é novamente requisitada apenas ao final, o trabalho terá que ser
parcialmente refeito caso exista algum equivoco, o que exigirá mais tempo e mais
investimento que o planejado, contudo existem diversas vantagens neste tipo de
metodologia, uma delas é a documentação detalhada, que em sistemas muito
complexos o desenvolvedor pode utiliza-la para rever parâmetros e funcionalidades,
economizando tempo de análise do sistema.

15

CAPÍTULO 2 - TÉCNICAS DE DESENVOLVIMENTO ÁGIL

2.1 – EXTREME PROGRAMMING (XP)

De acordo com Highsmith (2000) a metodologia XP foi utilizada pela primeira vez no
projeto payroll da Chrysler por Kent Beck após anos de fracassos utilizando
metodologias tradicionais.

A XP se baseia em requisitos que se modificam rapidamente, diferenciam-se das
outras metodologias, pois necessitam de constantes avaliações (feedbacks), uma
abordagem incremental, e encoraja a comunicação entre todas as pessoas
envolvidas no projeto, incluindo o cliente tratado como parte da equipe de
desenvolvimento.

Segundo Beck (2005) a XP se apoia em quatro valores que são: comunicação,
simplicidade, feedback e coragem.

É comum que o cliente não saiba o que realmente necessita até ter uma visão clara
do software, a comunicação neste caso é incentivada entre todos os membros
envolvidos no projeto principalmente entre clientes e desenvolvedores, incluindo as
conversas informais.

Entende-se por simplicidade desenvolver apenas o necessário evitando, por
exemplo, métodos e funções que podem vir a ser úteis no futuro, tendo como
premissa o fato que os requisitos sempre podem mudar.

A prática do feedback é a realização periódica de avaliações do cliente em relação
ao software, através de testes realizados em módulos funcionais do mesmo, onde o
cliente opta sobre suas características a fim de que a evolução do produto até o
produto final transcorra de forma eficiente e de acordo com as expectativas reais do
cliente, por essa razão de acordo com Teles (2004) este é o mais importante dos
valores do XP.

16

A coragem neste caso está diretamente relacionada aos três valores anteriores,
sendo eles contrários aos convencionais, é preciso coragem para adaptar-se aos
novos paradigmas.

A XP ainda segundo Beck (2005) apoiada nestes quatro valores descreve um
conjunto de doze práticas para o desenvolvimento de software que são:
planejamento, entregas frequentes, metáfora, projeto simples, programação em
pares, refatoração, testes, propriedade coletiva, integração continua, 40 horas de
trabalho semanal, cliente presente e código padrão.

O planejamento em todas as metodologias tem em comum a mesma finalidade, de
levantar e analisar os requisitos, determinar a maneira como o projeto será
implementado, os processos, ferramentas e cronograma. A diferença é a maneira
como tal objetivo é alcançado, no caso do XP requisitos futuros são
desconsiderados, a área de negócios (clientes) é vista como parte da equipe de
desenvolvimento, ela fica responsável pela definição do escopo do software,
composição das versões e prazos de entrega enquanto os desenvolvedores
decidem os detalhes técnicos, como as ferramentas e cronogramas.

As entregas frequentes visam o acompanhamento do software pelo cliente
periodicamente, de preferência mensalmente, cada versão entregue deve ser o mais
simples possível, porém contendo todos os requisitos de maior valor para o negócio,
a cada avaliação do cliente novos requisitos podem surgir e dessa forma o projeto
pode ser adaptado durante o desenvolvimento, evitando que o produto final fique
inconsistente em relação aos requisitos.

O uso de metáforas é empregado com a finalidade de melhorar a comunicação ente
a equipe, evitando a utilização de termos técnicos e substituindo-os por nomes mais
genéricos, como por exemplo, um método criado para cadastrar clientes pode-se
chamar “cadatrarClientes()”, com isso outras pessoas além daquelas que criaram o
método podem idealizar rapidamente sua função.

O desenvolvimento é realizado em duplas, enquanto um digita o outro fica centrado
em identificar erros sistemáticos e semânticos, ambos pensando estrategicamente
no modo mais simples e prático para implementação de determinado processo, é
recomendável que as duplas troquem seus papéis periodicamente e se possível os

17

personagens a fim de possibilitar continuamente uma troca de conhecimentos entre
eles.

Figura 2 – Fase de desenvolvimento utilizando o Extreme Programming
Fonte: http://www.extremeprogramming.org/map/images/project.gif (2011)

No decorrer do desenvolvimento quando um ou os dois personagens percebe que
um processo pode ser simplificado sem perder sua funcionalidade mesmo que não
tenha sido de sua autoria o aperfeiçoamento deve ser realizado, a isto dá-se o nome
de refatoração, ressaltando que os devidos testes de validação devem ser
realizados, uma vez que o código trata-se de uma propriedade coletiva e de
responsabilidade de todos os membros da equipe, por esta razão também é
necessário uma padronização na codificação.

Os módulos do sistema devem ser continuamente integrados, para que todos os
desenvolvedores estejam em sintonia com seus trabalhos, possibilitando validá-los
unificadamente.

O XP prevê que um excesso de carga constante, acima de 40 horas semanais, pode
significar um problema no projeto que não deve ser solucionado sobrecarregando os
desenvolvedores, e sim caso necessário ratificando os processos e o planejamento.

18

Na realidade o XP não é baseado em diagramas e processos formais, trata-se de
uma metodologia baseada em algumas praticas simples com o objetivo de unir a
equipe e se adaptar à medida que o projeto é desenvolvido.

2.2. SCRUM

Scrum é uma metodologia de desenvolvimento ágil baseada em princípios,
semelhante ao XP, porém com dimensões distintas, segundo Beck (2005) é possível
dizer que ambos são complementares, pois o Scrum se apoia em práticas de
gerenciamento enquanto o XP em práticas de desenvolvimento.

De acordo com Schwaber (2002) o método Scrum é direcionado à ambientes de
desenvolvimento de software orientado a objetos onde os requisitos mudam
constantemente, seu nome é originado de uma estratégia esportiva utilizada em
jogos de Rugby onde a bola é levada adiante pelo campo através de um time
composto de oito integrantes trabalhando em conjunto, semelhante a isto o Scrum
se baseia em princípios como equipes pequenas, requisitos pouco conhecidos ou
instáveis e iterações curtas.

As práticas do Scrum ainda segundo Schwaber (2002) não descrevem uma forma
sequencial de se desenvolver softwares, mas sim um conjunto de práticas
gerenciais.

O ciclo de vida do Scrum segundo Schwaber e Beedle (2002) é divido em três fases
principais divididas em sub-fases.

19

Figura 3 - Fases de desenvolvimento utilizando Scrum
Fonte: ESPOO (2002). VTT PUBLICATIONS 478

A primeira fase é chamada de Pré-planejamento (Pre-game phase) e inclui duas
sub-fases conhecidas como Planejamento e Arquitetura. No planejamento os
requisitos do sistema são descritos em um documento conhecido como Product
Backlog List, neste documento estão incluídos níveis de prioridade para cada
requisito, estimativas de custo e tempo, e são constantemente atualizadas com mais
e novos detalhes, o planejamento inclui também as ferramentas que serão utilizadas
no desenvolvimento, a equipe responsável e possíveis treinamentos. A sub-fase de
planejamento tem a finalidade de se estimar o esforço e os riscos do projeto e criar
uma proposta de arquitetura de desenvolvimento.

A segunda fase é a fase de desenvolvimento (Game-phase), diferentemente das
metodologias tradicionais, os requisitos técnicos e de ambiente são observados e
controlados constantemente tornando-os flexíveis para adaptarem-se as mudanças,
nesta fase o desenvolvimento do software e dividido em ciclos iterativos e
incrementais denominados Sprints, cada Sprint é desenvolvido preferencialmente no

20

período de uma semana a um mês e de forma tradicional fazendo a análise dos
requisitos, projeto, implementação e testes.

A última fase relacionada ao ciclo de vida do Scrum é o pós-planejamento (Post-
game phase), onde concluída a fase de desenvolvimento são realizadas reuniões
para analise, avaliação e exibição do software ao cliente, nesta etapa todos os
requisitos do sistema devem ter sido atendidos e nenhum outro deve ser adicionado,
caso necessário novos requisitos deverão ser incluídos em uma nova versão do
software, após os testes finais é realizada a integração e a documentação do
sistema.

Assim como no XP o sucesso do desenvolvimento com Scrum está nas pessoas e
não nos processos, no Scrum os personagens são divididos em três categorias:
Product Owner, Scrum master e Scrum team, o Product owner é o cliente ou um
representante que conheça suas necessidades, é ele que define os requisitos bem
como sua importância e urgência, deve ter uma visão clara do produto e sempre
estar o mais próximo possível da equipe de desenvolvimento contribuindo com
informações e opiniões para obter um produto o mais próximo possível das
expectativas.

O Scrum master é o líder do projeto, diferentemente do gerente do projeto, o Scrum
master não define o cada um deve fazer nem estima prazos ou resultados, ele
simplesmente acompanha a equipe para garantir o uso correto do Scrum, é
responsável por garantir que as reuniões sejam devidamente organizadas e
realizadas assim como os objetivos atingidos, evitando interferências externas que
possam comprometer a agilidade do desenvolvimento, como por exemplo, pedidos
que não tenham sido discutidos no planejamento, além disso, o Scrum mater é
responsável por reportar diariamente a equipe o andamento do projeto, os
problemas e como solucioná-los.

O Scrum team (time), são todos os envolvidos no desenvolvimento do projeto,
analistas, programadores, arquitetos, enfim, qualquer um que tenha um papel a
desempenhar no desenvolvimento. Por ter pessoas com diferentes aptidões o time
passa a ser multifuncional, multidisciplinar e auto gerenciável. É o time quem decide
a estimativa de esforço de cada Sprint já que será ele o responsável por
implementá-los.

21

2.3. FEATURE DRIVEN DEVELOPMENT (FDD)

Segundo Jeff De Luca, um dos criadores do FDD, o motivo para se utilizar a
metodologia é:

To enable the reliable delivery of working software in a timely manner with
highly accurate and meaningful information to all key roles inside and
outside a project.

A FDD foi aplicada inicialmente em 1997 em um projeto para o Banco de Singapura,
contou aproximadamente com 50 pessoas e levou 15 meses para ser concluído, em
1999, Jeff De Luca e Peter Coad apresentaram oficialmente a metodologia através
do livro “Java Modeling In Color with UML”.

De acordo com o site oficial da metodologia a FDD é uma metodologia que combina
as melhores práticas de desenvolvimento ágil de projetos com uma abordagem
completa para engenharia de software orientada a objetos.

Figura 4 – Estrutura da FDD
Fonte: http://www.heptagon.com.br/fdd-estrutura

22

Segundo Palmer e Felsing (2002), a FDD possui cinco etapas que não necessitam
de treinamentos extensos para utiliza-las. Conforme a figura 4 a FDD é objetiva e
possui apenas duas fases, na primeira denominada concepção e planejamento,
existem três dessas etapas que são: desenvolver um modelo abrangente, construir a
lista de features e planejar por feature, na segunda fase, os processos são divididos
em duas etapas: detalhar por feature e construir por feature. De acordo com Palmer
e Felsing (2002), após cada feature ser desenvolvida e publicada, a lista de features
é reclassificada de acordo com a prioridade para manter o time trabalhando
constantemente nas features de maior prioridade e com maior valor para o negócio.

Segundo De Luca (1999) cada etapa possui alguns padrões denominados ETVX,
composto de Entrada (Entry), Tarefa (Task), Verificação (Verification) e saída (Exit).
De Luca descreve cada um como:

 Entrada: Especifica os critérios de entrada para cada etapa;

 Tarefa: Lista de rotinas que deverão ser executadas;

 Verificação: Especifica avaliações e inspeções de projeto e código;

 Saída: Especifica os critérios de saída.

Cada integrante do projeto assume um papel no projeto, alguns mais de um, os
papéis ainda segundo De Luca são divididos em:

 Arquiteto chefe: alguém com experiência em modelagem de projetos com
função de guiar os desenvolvedores;

 Programador chefe: aquele que prioriza as tarefas juntamente com o gerente
de projeto e o gerente de desenvolvimento e as divide entre os
desenvolvedores da equipe incluindo ele mesmo;

 Experts em domínio: Prove todas as informações necessárias sobre a área de
domínio;

 Desenvolvedor: Responsável por uma ou mais tarefas no desenvolvimento de
cada funcionalidade do sistema;

 Gerente de projeto: Juntamente com o programador chefe e o gerente de
desenvolvimento, planeja a ordem em que as funcionalidades serão
desenvolvidas e gerencia o projeto como um todo.

23

 Gerente de desenvolvimento: Planeja a ordem de implementação das
funcionalidades juntamente com o programador chefe e o gerente de projeto,
e gerencia o desenvolvimento de cada funcionalidade.

2.4. CONSIDERAÇÕES PARCIAIS

Para Hawrysh e Ruorecht (2000) uma única metodologia pode não funcionar
adequadamente para diferentes projetos, contudo, o gerente do projeto deve
identificar qual é a natureza de seu projeto e escolher uma metodologia de
desenvolvimento que melhor se aplica.

Algumas práticas são bem comuns entre diferentes metodologias, como por
exemplo, entre o XP e o FDD, ambos incentivam testes unitários, programação em
pares e integridade continua, porém algumas características também se contrastam
tornando a metodologia mais especifica, como por exemplo, o FDD, segundo De
Luca (2002), foi originalmente criado para um projeto de grande porte com um
grande número de pessoas envolvidas, devido a essa natureza e aspectos como o
projeto e o grupo de programadores serem divididos em pequenas partes, garantem
que essa metodologia funcione bem para projetos de pequenas e grandes
magnitudes o que não ocorre com o XP que é mais viável para projetos pequenos.

Apesar de apresentarem certas semelhanças cada metodologia possui
características distintas que ajudam a definir uma ou outra mais apropriada para
determinado projeto. O scrum é voltado para o gerenciamento do projeto já o XP e o
FDD são mais apropriados para o desenvolvimento do projeto.

24

CAPÍTULO 3 - FRAMEWORKS PARA APLICAÇÕES JAVA

Basicamente um framework é um conjunto de funcionalidades comuns em várias
aplicações, que são disponibilizadas ao desenvolvedor para que ele complete e crie
uma nova aplicação reduzindo o tempo gasto no desenvolvimento. Neste capitulo é
apresentado três frameworks para aplicações baseadas na linguagem de
programação Java com funcionalidades distintas.

3.1. HIBERNATE 4.0

Hibernate 4.0 é um poderoso framework de mapeamento objeto-relacional (ORM)
para aplicações Java, ou seja, é uma ferramenta utilizada para persistir objetos Java
em tabelas de banco de dados relacionais, de forma transparente ao usuário.

A arquitetura do hibernate 4.0 é composta por interfaces na camada de negócio e de
persistência, entre as mais importantes podemos citar as que são responsáveis por
operações como criação, remoção, consulta e alterações no banco de dados,
denominadas Session, Transaction e Query, interface de configuração denominada
Configuration, interfaces que realizam interações entre os eventos do hibernate
chamadas Interceptor, Lifecycle e Validatable e as interfaces UserType,
CompositeUserType e IdentifierGenerator que permitem extender as funcionalidades
de mapeamento.

Segundo Zhang (2007) o hibernate possui cinco interfaces principais detalhadas nos
itens abaixo, são elas: Configuration, Session, SessionFactory, Query e Transaction.

25

3.1.1 Configuration

Segundo Fernandes (2005) um objeto do tipo Configuration é utilizado para definir as
configurações de inicialização do hibernate como, por exemplo, o endereço do
servidor de banco de dados, usuário, senha, entre outras. Dessa forma uma
alteração como a senha, ou do endereço do banco de dados pode ser simplesmente
alterada modificando este objeto sem a necessidade de alterar o código do sistema.

Figura 5 – Criação do objeto Configuration
Fonte: http://docs.jboss.org/hibernate/core/3.3/reference/en/html/session-configuration.html

A figura 5 descreve um dos modos de se criar um objeto do tipo Configuration,
especificando algumas propriedades, ressaltando que este não é a única maneira de
criar tais arquivos.

3.1.2 Session

É responsável pela comunicação entre a aplicação e a persistência, utiliza uma
conexão JDBC (Java Database Connectivity), onde através desta é possível
executar ações como inserir, remover, alterar ou recuperar objetos persistidos. Não é
thread-safe, ou seja, seu estado pode se tornar instável durante a execução, porém
é um objeto leve e pode ser criado inúmeras vezes sem apresentar perdas
significativas ao software.

26

3.1.3 SessionFactory

O objeto SessionFactory também conhecido como fábrica de sessões guarda o
ORM em memória, é criado a partir do Configuration e através dele são criados os
objetos do tipo Session, para cada BD relacional existente no projeto deve-se criar
uma SessionFactory, e como são objetos pesados que utilizam consideráveis
espaços na memória é recomendável criar apenas uma instância de cada na
aplicação.

3.1.4 Query

As querys (consultas) podem ser realizadas em um projeto com hibernate utilizando
uma linguagem para banco de dados, denominada HQL (Hibernate Query
Language), que se parece muito com a SQL (Structured Query Language), porém,
totalmente orientada a objetos. Nesta o usuário pode realizar suas requisições
diretamente nas classes de persistência o que melhora o desempenho do software e
caso haja necessidade de alterar o SGBD (Sistema Gerenciador de Banco de
Dados), basta alterar o driver de conexão, sem se preocupar com alterações no
código do programa.

3.1.5 Transaction

O uso deste objeto é opcional, porém, é praticamente essencial em uma situação
onde número de sessões é relativamente excessivo, sua finalidade é abstrair e
controlar as transações do hibernate tratando os possíveis erros que posam vir a
ocorrer na camada de persistência.

Segundo Fernandes (2005) outra versão do hibernate, o hibernate annotations,
permite realizar o mapeamento das classes através de anotações eliminando os
arquivos de mapeamento em XML com exceção do arquivo de configuração.

27

3.2. OPENSWING 2.4.5

De acordo com a documentação oficial do framework, o OpenSwing é baseado na
API (Application Programming Interface) de desenvolvimento Swing, com ele é
possível criar aplicações Desktop ou aplicações para internet de forma simples,
utilizando uma coleção de componentes gráficos que podem ser adicionados
diretamente a um IDE (Interface de Desenvolvimento) como o NetBeans ou o
Eclipse.

Figura 6 - Esquema de funcionamento do framework OpenSwing
Fonte: http://oswing.sourceforge.net/features.html (2011)

28

Ainda segundo a documentação do framework o OpenSwing possui um total de 30
componentes, entre eles text field (campo de texto), text formatted field (campo de
texto formatado), numeric field (campo numérico), calendar (calendário), pivot table
(tabela articulada), entre outros.

Um exemplo prático de reuso é a componente grid (grade) similar a uma tabela, ao
adiciona-la ao projeto o usuário já possui vários eventos definidos, entre eles paginar
os dados, filtrar colunas, ordenar os dados, entre outros.

O OpenSwing permite criar aplicações baseadas em SDI (Simple Document
Interface) ou MDI (Multiple Document Interface), as aplicações MDI possuem uma
janela principal com janelas internas alternadas conforme solicitação do usuário, no
caso do OpenSwing estas aplicações ao serem criadas incluem diversas
características e ferramentas, como mostra a figura 3, que o desenvolvedor opta se
disponibiliza ao usuário ou não, reduzindo o tempo de desenvolvimento e o esforço
do desenvolvedor.

Figura 7 - Modelo de aplicação MDI criada a partir do framework OpenSwing
Fonte: Elaboração própria (2011)

29

Juntamente com os arquivos do OpenSwing é disponibilizado um repositório com
várias demonstrações de aplicações e seus respectivos códigos fonte, todas criadas
a partir do framework, a figura 5 ilustra uma destas aplicações, que corresponde a
uma aplicação MDI com um formulário principal, uma barra de menus no canto
superior, uma barra de ferramentas, uma barra de menus em árvore, um mecanismo
de busca, uma barra de status no canto inferior, entre outras, que o desenvolvedor
pode simplesmente editar e construir um novo projeto.

Além da parte visual as demonstrações trazem também toda uma lógica de negócios
estruturada, para que o desenvolvedor tenha o menor trabalho possível, substituindo
os valores do exemplo pelos de sua própria regra de negócio.
Para o tratamento dos dados caso o usuário utilize os componentes do OpenSwing
rotinas como editar, inserir, excluir, consultar, exportar, entre outras, são pré-
configuradas, e disponibilizadas através de objetos.

O OpenSwing é compatível também com outros frameworks inclusive o hibernate, o
que significa que quando habilitado, o hibernate é responsável pela comunicação da
aplicação com o Banco de dados.

3.3. JASPERREPORTS 4.5

JasperReports 4.5 é um framework que auxilia na criação de relatórios, de acordo
com sua documentação ele é inteiramente escrito na linguagem de programação
Java, capaz de abstrair qualquer tipo de dado desta linguagem e criar documentos
que podem ser visualizados, impressos, ou expostos ao usuário em vários formatos
como HTML (HyperText Markup Language), PDF (Portable Document Format) entre
outras.

30

Figura 8 - Etapas para geração do relatório com JasperReports 4.5
Fonte: http://jasperforge.org/projects/jasperreports (2011)

A figura 8 descreve os passos para se criar um relatório utilizando o framework
JasperReports 4.5, de acordo com a documentação oficial da plataforma,
primeiramente os campos devem ser preenchidos em um arquivo do tipo XML,
conforme figura 9 abaixo, que obedece a uma estrutura declarada em um arquivo
DTD (Document Type Definition) denominado “jasperreports.dtd”, através das
informações declaradas neste arquivo pode-se definir os tipos de componentes
apresentados no relatório e suas respectivas localizações.

Figura 9 - Exemplo de arquivo XML usado pelo JasperReports

31

Em seguida este arquivo XML é compilado gerando um arquivo com extensão
“.jasper”, os campos definidos no arquivo XML podem ser estáticos, recebidos via
parâmetro, ou dinâmicos, gerados a partir de uma conexão com o banco de dados.

Para criar um relatório dinâmico é preciso fornecer ao jasper uma consulta (query)
em linguagem SQL, que pode ser inserida diretamente no arquivo XML como
apresentado na figura 9, ou executada na classe Java, armazenando o resultado em
um objeto JRDataSource e transferindo-o via parâmetro juntamente com os campos
estáticos.

Figura 10 – Software iReposts para desenvolvimento de relatórios e gráficos.
Fonte: Elaboração própria 2011)

Para trabalhar especificamente com este framework o mesmo criador disponibiliza
um aplicativo do tipo front-end, para configurar e desenvolver os relatórios de forma
gráfica reduzindo as chances de erros semânticos, este aplicativo é conhecido pelo
nome de iReports, exibido na figura 10.

32

Especificamente para o IDE NetBeans foi desenvolvido um plugin onde é possível
integrar as ferramentas disponibilizadas no iReports com a interface de
desenvolvimento obtendo uma paleta de ferramentas ilustrada na figura 11, com esta
paleta o desenvolvedor pode criar seus relatórios de forma visual sem alternar entre
os editores.

Figura 11 - Paleta de componentes do plugin do JasperReports 4.5 para NetBeans IDE


Em um projeto o programador pode reduzir substancialmente o tempo que levaria
para desenvolver rotinas e funcionalidades, reutilizando-as através de frameworks
especializados, ao fazer isto dependendo do framework utilizado, o programador não
estará substituindo apenas um código por outro, mais por um código já testado e
validado geralmente por um especialista ou um grupo de especialistas.

33

Com isso é possível afirmar que algumas das vantagens de se utilizar frameworks
são ter a codificação ou design parcialmente desenvolvidos, códigos menores, mais
limpos e confiáveis, contudo também percebemos algumas desvantagens, uma
delas é garantir a integridade de versões, ou a pouca documentação disponibilizada
a respeito do framework, e o processo de depuração pode vir a se tornar complexo.

Atualmente existem frameworks direcionados a vários tipos de aplicações, no
capítulo anterior foram descritos apenas três deles, totalmente distintos entre si, o
Hibernate para persistir objetos no banco de dados, o OpenSwing para tratar os
objetos de apresentação ao cliente e o JasperReports para emissão de relatórios,
com isso o programador pode utilizar o tempo que economizou e se dedicar as
regras de negócio especificas do cliente e tornar sua aplicação consistente.

34

CAPÍTULO 4 - DESIGN PATTERNS

O conceito de design patterns (padrões de projeto) foi criado por um arquiteto e
matemático chamado Christopher Alexander (1979), segundo ele:

Cada padrão descreve um problema que ocorre repetidamente de novo e de
novo em nosso ambiente, e então descreve a parte central da solução para
aquele problema de uma forma que você pode usar esta solução um milhão
de vezes, sem nunca implementá-la duas vezes da mesma forma.

A partir de 1995 com a publicação do livro “Padrões de Projetos: Elementos de
Software, Reutilizado Orientado a Objetos pela Gangue dos Quatro”, foi que design
patterns começou a se popularizar no desenvolvimento de softwares.

Segundo Gamma (1995):

Cada padrão tem uma característica diferente para ajudar em algum lugar
onde se precisa de mais flexibilidade ou precisa de encapsular uma
abstração ou de se fazer um código menos casado.

Segundo Alexander (1997) os padrões de projeto são compostos das seguintes
partes:

 Nome - referência em poucas palavras que descreva um problema de projeto,
suas soluções e consequências.

 Problema (motivação, intenção e objetivos, aplicabilidade) – descreve quando
aplicar o padrão.

 Solução (estrutura, participantes, exemplo de código) - fornece uma descrição
abstrata do problema de projeto e como um arranjo geral de elementos é
utilizado para soluciona-lo.

 Consequências - resultados e análises das vantagens e desvantagens em se
utilizar um padrão de projeto.

35

Para Deschamps (2002, p.4) um padrão de projeto nomeia, abstrai, e identifica os
aspectos chave de uma estrutura de projeto comum para torná-la útil para a criação
de um projeto orientado a objeto reutilizável. Padrão de Projeto é uma solução
comum de programação que torna o código mais flexível.

4.1. MODEL VIEW CONTROLLER (MVC)

Segundo Moreira (2006) com o aumento da complexidade dos projetos de software
surgiu uma arquitetura de desenvolvimento conhecida como Model View Controller
(MVC), com o objetivo de organizar a aplicação em três camadasque são: Model
(Modelo), View (Visão) e Controller (Controle), aumentando a flexibilidade e o reuso.

Alguns dos padrões de projeto assim como alguns frameworks são baseados nesta
arquitetura outros, porém são baseados apenas em uma ou duas destas camadas.

Figura 12 – Funcionamento do MVC
Fonte: Moreira (2006), p.15

Ainda segundo Moreira (2006), modelo é a camada responsável por abrigar a
camada de negócios, a visão é a camada de apresentação, ou seja, a camada
responsável pelas visualizações gráficas de interface, e a camada de controle é
responsável por processar as requisições solicitadas pelo usuário a partir da camada
visão acessando a camada modelo e realizando as alterações.

36

Sempre que um modelo é alterado, as visões associadas a ele são notificadas, desta
forma as visões podem ser atualizadas juntamente com o modelo, contudo o
desempenho da aplicação pode vir a reduzir caso tenha muitas visões ou se o
modelo é atualizado constantemente.

O modelo encapsula e persiste os dados e as regras de negócio sem a preocupação
de como estes serão exibidos, cabe a camada visão esta tarefa que por sua vez não
se preocupa a forma como os dados foram obtidos, apenas os apresenta ao usuário.
É a camada de controle que cuida para que o fluxo das informações entre a camada
de modelo e a camada de visão seja realizado.

Segundo Fonseca e Alves (2008)

O MVC facilita a produção via aplicação de Design Patterns (Padrões de
projeto) e facilita a criação e aplicação de FrameWorks (plataforma de
trabalho padronizado) porque com sua melhor organização e separação por
funções (responsabilidades) fica mais fácil projetar sistemas que produzem
sistemas.

Tomando como exemplo os frameworks especificados anteriormente é possível
concluir que o hibernate encontra-se na camada modelo, seu papel fundamental é
fazer a comunicação entre a aplicação e o Banco de Dados, o JasperReports faz
parte da camada de visão dependendo do modelo para exibir os dados ao usuário,
já o OpenSwing possui as três camadas, se observarmos a figura 4, o framework
possui componentes para visualização, parte em amarelo da figura representando a
camada de visão, ferramentas para comunicação, objetos em verde representando a
camada de modelo, e ferramentas para gerenciamento dos dados, parte azul da
figura representando a camada de controle.

No caso do OpenSwing as camadas podem ser utilizadas separadamente, o
desenvolvedor pode utilizar apenas os componentes e configurar a lógica de
negócio através de outro framework, ou diretamente no código do programa.

A camada modelo do OpenSwing é compatível com o hibernate cabendo ao
desenvolvedor a decisão de utiliza-la ou não.

37

4.2. VALUE OBJECT (VO)

De acordo com a empresa SUN Microsystens atualmente subsidiada pela Oracle
Corporation e criadora da linguagem de programação Java o Value Object (VO),
também conhecido como Transfer Object (TO) é um dos padrões J2EE (Java to
Platform, Enterprise Edition), que se encontra na camada de negócios, seu objetivo
segundo a é reduzir o número de iterações necessárias para transferir dados entre a
aplicação e o cliente.

Figura 13 - Diagrama de classe do padrão de projeto Value Object
Fonte: http://java.sun.com/blueprints/corej2eepatterns/Patterns/TransferObject.html (2011)

4.3. DATA ACSESS OBJECT (DAO)

Segundo a documentação oficial do design pattern DAO, ele está localizado na
camada de integração com a finalidade de prover suporte transparente aos dados
(inserir, excluir e alterar), além de disponibilizar métodos de buscas e persistência.

38

Assim como nas classes VO é recomendável que cada entidade da tabela tenha
uma classe DAO. Quando necessário, por exemplo, inserir dados no BD, um objeto
da classe VO é transferido por parâmetro para um método da classe DAO
responsável pela ação, porém, diferentemente da VO a classe DAO pode ter
métodos que envolvam outras tabelas desde que estejam relacionadas.

Figura 14 – Exemplo de classe DAO

A figura 14 é apenas um exemplo de como a lógica de negócio pode ser tratada, não
havendo uma maneira sequencial para desenvolvê-la ficando a cargo de o
programador codifica-la.


Existem vários outros padrões além dos três citados neste capitulo como singleton,
decorator, iterator enfim, cada um deles com seu respectivo problema, solução e
consequência, assim como os frameworks reutilizam funcionalidades, os padrões de
projeto compartilham ideias e conceitos.

39

CAPÍTULO 5 - PORQUE UTILIZAR FRAMEWORKS EM UM PROJETO
DE DESENVOLVIMENTO ÁGIL

5.1. APRESENTAÇÃO DO CASO DE USO

Ao terminar a graduação em Ciência da Computação no início do ano de 2008,
comecei a desenvolver um programa para a filial de uma grande empresa na cidade
de Cruzeiro, interior do estado de São Paulo, a primórdio baseado na metodologia
em cascata, todas as etapas de desenvolvimento de software foram cumpridas, o
levantamento de requisitos, modelagem, entre outros, a partir disto foi definido um
prazo de seis meses para o término do software denominado “SICEP - Sistema para
Controle de Estoque e Patrimônio”.

Segundo Pressman (2006) no modelo cascata cada fase do desenvolvimento
progride em uma ordem estrita sem qualquer sobreposição ou passos iterativos,
ainda segundo ele esse modelo descreve um método de desenvolvimento linear e
sequencial.

No início em decorrência da falta de experiência modelei o sistema com algumas
dificuldades, mesmo assim o projeto seguiu conforme o cronograma e logo após o
início da codificação fui chamado pela matriz da empresa em São José dos Campos
também no estado de São Paulo, que demonstrou interesse em incluir o software
nas demais unidades, fiz uma pequena apresentação de tudo que já tinha elaborado
até o momento, o projeto agradou e ganhou uma nova dimensão.

A realidade da empresa matriz, apesar de ter o mesmo segmento da filial, era
relativamente maior e em decorrência disto o projeto original precisou ser adaptado,
novas funcionalidades tiveram de ser incluídas e algumas das que já haviam sido
definidas tiveram que ser alteradas de forma que atendessem ambas as realidades,
aceitei a proposta na condição de acrescentar alguns meses ao prazo de entrega do
produto final, com um pouco de rejeição por parte do cliente concordamos em
adicionar mais três meses.

40

Remodelei o projeto, porém ao dar início ao processo de construção do software,
percebi que o período, mesmo com o acréscimo de três meses, não seria suficiente
para finaliza-lo, muitos processos simples como validação de campos, criptografia de
senha, entre outros ocupavam um tempo considerável.

Percebi também que muitos processos envolvidos eram semelhantes como
cadastrar fornecedores, cadastrar clientes, cadastrar usuários, cadastrar produtos, e
que tais rotinas poderiam ser reaproveitadas de alguma forma, mas da maneira
como estavam sendo criadas se tornou inviável reutiliza-las.

Durante o desenvolvimento realizei diversas pesquisas, em busca de técnicas e
ferramentas que me auxiliassem neste projeto, primeiramente descobri o design
patterns, e sobre a arquitetura MVC, com o banco de dados já modelado e
arquitetado, criei os objetos VO e DAO.

De acordo com Esjug (2007) desenvolver um mapeamento objeto relacional pode
ser uma tarefa complexa, porém com algumas vantagens dentre elas:

 Produtividade: Elimina códigos SQL no código fonte, tornando as classes
mais simples.

 Manutenção: Reduz o número de linhas do código fonte tornando-o a
manutenção menos complexa.

 Desempenho: Com o tempo economizado de desenvolvimento o programador
tem mais tempo para otimizar outras funcionalidades do sistema.

 Independência: Conforme o banco de dados utilizado, apesar da linguagem
por traz da plataforma ser a mesma o SQL, alguns comandos e tipos de
dados podem ser diferentes.

Neste ponto já conhecia superficialmente algumas metodologias de desenvolvimento
ágeis, porém devido à ausência de um dos valores do XP, a coragem, decidi a
continuar utilizando o modelo em cascata em meu projeto. Aplicar qualquer
framework neste ponto também era complicado, pois, com o cronograma atrasado,
uma alteração como esta de introduzir um framework excluiria muitos processos já
finalizados então decidi desenvolver da forma como estava acostumado.

41

Figura 15: Modelo de Banco de Dados do programa SICEP

Quando o prazo para o término do projeto estava para expirar, entrei em acordo com
o cliente e negociamos de entregar o programa em dois módulos, o módulo para
controle de estoque que já estava em fase final e requisitei mais algum tempo para
terminar o módulo de patrimônio, ao todo o projeto levou aproximadamente doze
meses para ser concluído, aproximadamente um terço a mais do que o planejado.

Para demostrar as ideias apresentadas neste trabalho comecei a refatorar o
software para uma nova versão, a proposta inicial foi utilizar as metodologias de
desenvolvimento ágil, XP e Scrum, juntamente com os frameworks hibernate,
JasperResports e alguns componentes do OpenSwing.

Segundo Asteles (2003), apud Telles (2005)

refatoração é o processo de fazer mudanças em um código existente e
funcional sem alterar seu comportamento externo...

42

Para o desenvolvimento foi utilizado uma IDE (interface de desenvolvimento)
chamada NetBeans, que disponibiliza automaticamente o pacote do hibernate,
apenas o adicionei ao projeto e inclui no arquivo de configuração as informações
referentes ao banco de dados para estabelecer a conexão, feito isto utilizei o
assistente que a IDE disponibiliza para mapeamento que automaticamente criou
várias classes denominadas POJOs (Plain Old Java Object), similares as classes
VOs porém sem particularidades. Em seguida fiz o download do OpenSwing e
adicionei seus componentes a paleta de componentes do IDE.

Figura 16- Paleta do NetBeans com alguns componentes do framework OpenSwing

Devido a regras especificas da empresa decidi não utilizar a interface MDI do
OpenSwing neste projeto e manter a mesma estrutura da primeira versão.

O programa trata-se de um software cliente-servidor criado para funcionar em rede
com diferentes permissões para os usuários, ao inicia-lo é solicitado usuário e
senha, um usuário do tipo administrador tem acesso a todas as ferramentas e é ele
que cria novos usuários, as outras permissões são de comprador e almoxarife, nesta

43

empresa o controle de estoque se limitava a estas duas funções, sendo que o
comprador efetua a entrada dos produtos no almoxarifado e o almoxarife efetua as
saídas.

Figura 17: Janela principal do programa SICEP

Ao mesmo tempo em que a nova versão era desenvolvida o cliente avaliava a
anterior, e com isso constantemente o software estava recebendo feedbacks, com
isso muitos processos foram melhorados, e o cliente começou acompanhar mais
detalhadamente o desenvolvimento assim como manda o Scrum.

De acordo com Telles (2005)

O melhor e mais participativo cliente não será capaz de obter o software
desejado se a equipe de desenvolvimento não implementar corretamente o
que é pedido e a melhor equipe não será capaz de produzir o software certo
se o cliente não for capaz de especificá-lo adequadamente e prover
feedback ao longo do projeto.

44

Nos formulários de cadastros os campos de texto foram substituídos por campos
mais específicos como, por exemplo, os campos de entrada de datas, foram
substituídas pelo componente do OpenSwing chamado DateControl, onde a data
pode ser selecionada diretamente de um calendário, isso evita que o usuário digite
uma data inválida, da mesma forma os campos de valores numéricos inteiros como
quantidade foram substituídos pelo componente NumericControl, os valores reais
como preço foi utilizado o CurrencyControl, nos campos com máscara como o CPF e
CNPJ utilizei o componente FormattedTextControl e assim por diante .

Figura 18 - Componente DateControl

Substituindo os componentes, uma parte do código foi eliminada já que não era mais
necessário validar grande parte dos campos.

Para Freeman (1987) apud Pressman (1995) reuso é:

Qualquer procedimento que produza (ou ajude a produzir) um sistema
tornando a utilizar algo desenvolvido previamente

Algumas rotinas são mais especificas, para citar um exemplo, neste projeto existia
uma regra de negócio que dizia que o almoxarife poderia desmembrar um item e
fornece-lo em outra unidade, de maneira que um produto, adquirido em caixa com
200 unidades, por exemplo, poderia ser fornecido individualmente ou em pacotes
com 50 unidades ou em outra unidade compatível, numa situação como esta se o
valor da caixa adquirida fosse de 400 reais ao desmembra-la cada produto passaria
a custar dois reais, mais supondo que a caixa tenha custado 450 reais, a divisão

45

resultante seria uma dizima periódica nestas ocasiões foi definido que um produto
terá seu valor superior aos outros, a fim de que cada produto tenha um valor real.

Operações como está são as que requerem mais da atenção do desenvolvedor, são
processos que dificilmente serão reutilizados em outro programa, ou serão tratados
de forma diferente de acordo com cada empresa.

Figura 19 - Exemplo dos componentes no formulário de cadastro

Na primeira versão do software as consultas, notas de fornecimento ou qualquer
outro documento eram exibidas ao usuário em objetos do tipo JTable, para satisfazer
a necessidade do usuário imprimir ou salvar o resultado em um arquivo, foi criado
um processo que através de um botão o usuário exportava a tabela para um arquivo
texto. Na nova versão foi adicionado ao projeto o JasperReports, o que deixou o
processo de emissão de relatórios muito mais profissional.

O primeiro passo para criar os relatórios é estabelecer uma conexão, para isso o
NetBeans com o plugin do JasperReports instalado disponibiliza um assistente, onde
basta fornecer algumas informações, tais como usuário e senha do banco de dados
conforme figura 20.

46

Figura 20 - Assistente para conexão do JasperReports com o Banco de Dados

Estabelecida à conexão o IDE disponibiliza uma interface onde o usuário pode
literalmente desenhar o layout do relatório que desenha criar, enquanto o sistema
cria automaticamente o arquivo XML que o JasperReports precisa para funcionar
corretamente.

A figura 21 mostra o layout criado para um relatório de fornecimento e logo abaixo na
figura 22 o mesmo relatório é ilustrado já com os campos preenchidos em tempo
execução conforme é exibido ao usuário.

47

Figura 21 - Desenvolvimento dos relatórios com JasperReports e NetBeans

Figura 22 - Relatório exibido ao usuário

48

Na figura 20, o relatório é exibido dentro de uma janela que o framework
disponibiliza, onde é possível através de uma barra de ferramentas imprimir o
arquivo, salva-lo em diversos formatos como html, pdf, doc, entre outros, rotacionar
o arquivo, aplicar zoom, navegar entre as demais páginas geradas, entre outros.

Como podemos observar, todos os frameworks disponibilizam ferramentas que se o
desenvolvedor fosse programa-las ocuparia um tempo considerável o qual ele
poderia estar utilizando para algo de maior importância para o projeto.


O software demonstrado no caso de uso em sua primeira versão levou
aproximadamente um ano para ser concluído, sendo que o cronograma inicial era de
seis meses, não é correto dizer que a culpa foi da metodologia usada, já que na
época eu era um programador inexperiente, porém o cliente não saiu insatisfeito
apenas pelo tempo que o projeto levou para ser concluído, mas também devido a
funções inconsistentes ocasionadas pela falta de comunicação, novos requisitos
muitas vezes demoravam ou não poderiam ser atendidos devido aos autos custos, e
outros fatores que levaram ao desenvolvimento de uma nova versão, estipulada para
seis meses, porém utilizando métodos ágeis e frameworks esta nova versão ficou
pronta aproximadamente com a metade do tempo estipulado e satisfazendo todas as
expectativas do usuário.

Podemos concluir então que as metodologias de desenvolvimento ágil não visam
apenas à rapidez no desenvolvimento do projeto mais também a satisfação do
cliente.

49

CAPÍTULO 6 - CONCLUSÃO

Em se tratando de TI (tecnologia e informação), a cada dia surgem novos avanços, e
podemos concluir que é impossível que metodologias de desenvolvimento de
softwares criadas entre as décadas de 60 e 70 como a metodologia em cascata,
consigam abstrair todas as exigências de um mundo moderno, porém elas oferecem
base para que novas metodologias sejam criadas como é o caso das metodologias
de desenvolvimento ágil.

Paralelamente ferramentas como os frameworks, não devem ser desconsiderados,
já que dentre as principais exigências em TI na atualidade estão rapidez e
confiabilidade. A reutilização de ferramentas certificadas e testadas, através dos
frameworks possibilita o desenvolvimento do projeto de forma rápida, confiável e
organizada tornando o software robusto e dinâmico.

Porque então não conciliar metodologia de desenvolvimento ágil com frameworks
em um único projeto? Quais seriam as principais vantagens e desvantagens desta
união?

Analogicamente as metodologias de desenvolvimento ágil são as placas que
mostram o caminho mais curto, e os frameworks são os automóveis que ajudam a
transitar por este caminho mais rapidamente, portanto se a necessidade é de
agilidade o ideal é utilizar essas ferramentas em conjunto, porém é extremamente
importante que o desenvolvedor conheça bem com o que está trabalhando, pois,
existem várias metodologias e diversos tipos de frameworks, sem um conhecimento
adequado o programador pode acabar gastando mais tempo que economizando.

Neste trabalho foi abrangido superficialmente três metodologias e três frameworks,
contudo foi possível demostrar os objetivos e características de cada um, e utiliza-
las todas em um único projeto, é provável que daqui a algum tempo, as ferramentas
apresentadas neste trabalho já tenham sido melhoradas ou substituídas por
ferramentas mais avançadas, por isso é importante sempre analisar quais delas
satisfaz melhor os requisitos do projeto.

50

Em se tratando de TI, avanços acontecem constantemente, novos requisitos e novas
tecnologias levam o desenvolvimento de software a patamares diferentes desde o
surgimento do PC (Personal Computer). Um dos principais motivos desta evolução é
sem dúvida a necessidade de agilidade, qualquer tecnologia nova nunca será mais
lenta que a anterior a não ser que exista um motivo muito importante para isto.

6.1. TRABALHOS FUTUROS

Com base neste trabalho espero que outros envolvendo metodologias ágeis e
frameworks venham a surgir, especificando outros frameworks e outras
metodologias como Crystal Clear, Adaptive Software Development, entre outras que
não puderam ser descritas neste.

Outra sugestão é a criação de parâmetros e situações para comparação entre
metodologias demostrando através destes quais são superiores em cada situação, e
com isso ajudar o desenvolvedor iniciante a definir qual metodologia deve utilizar em
seu projeto.

51

REFERÊNCIA BIBLIOGRÁFICA

THEUNISSEN, W., BOAKE, A. & KOURIE, D. In search of the sweet spot: Agile
open collaborative corporate software development. Trabalho apresentado durante a
Coferência Anual de Institutos de Ciência da Computação e Informação da Africa do
Sul. África do Sul, 2005, p. 268-277.

COCKBURN, A. Agile software development. Addison-Wesley, Boston, 2002.

LINDSTROM, L. & JEFFRIES, R. Extreme programming and agile software
development methodologies. Information Systems Management., 2005, p. 41-53.

BECK, K. & FOWLER, M. Planning Extreme Programming, Addison Wesley, 2000.

MANIFESTO ÁGIL PARA DESENVOLVIMENTO DE SOFTWARE, Site oficial.
Disponível em: <http://www.agilemanifesto.org/>. Acesso em: 26 de setembro de
2011.

HIGHSMITH, J. ORR, K. COCKBURN, A. Extreme Programming, E-Business
Application Delivery, 2000, p. 4-17.

TELES, V. Manhães. Extreme Programming: Aprenda como encantar seus
usuários desenvolvendo software com agilidade e alta qualidade. São Paulo,
Novatec Editora, 2004.

BECK, K., Extreme Programming Explained, Embrace Change. 2005.

PROGRAMMING, Site oficial.
Disponível em: <http://www.extremeprogramming.org/>. Acesso em: 26 de setembro
de 2011.

SCHWABER, K. BEEDLE, M. Agile Software Development with SCRUM. Prentice
Hall, 2002.

ABRAHAMSSOM P., SALLO O., RONKAINEN J. & WARSTA J. Agile Software
Development Methods, ESPOO (2002). VTT PUBLICATIONS 478

DENG M., ZHANG H., Implementation of Funds Management Information
System Based on Struts and Hibernate Software Architecture, Computer &
Information Technology, vol. 10, 2007, p. 31-33.

OPENSWING Site oficial.
Disponível em: <http://oswing.sourceforge.net/>. Acesso em: 26 de setembro de
2011.

52

JASPERREPORTS, Site oficial.
Disponível em: <http://jasperforge.org/projects/jasperreports/>. Acesso em: 26 de
setembro de 2011.

ALEXANDER, C., ISHIKAWA, S., SILVERSTEIN, M., JACOBSON, M., FIKSDAHL-
KING, I. & ANGEL, S. A Pattern Language, Oxford University Press, New York,
1977

FONSECA, M. VILELA & ALVES, A. Luiz, MVC & FRAMEWORK, Monografia,
PROPE/PUC, GOIAS, 2008

MOREIRA, S. Utilização do Struts Framework no desenvolvimento de um
gerenciador de eventos. Monografia, CEULP/ULBRA, 2006.

TRANSFER OBJECT, Site oficial.
Disponível em:
<http://java.sun.com/blueprints/corej2eepatterns/Patterns/TransferObject.html/>.
Acesso em: 26 de setembro de 2011.

THE CHAOS REPORT, Site oficial.
Disponível em: <http://www.projectsmart.co.uk/docs/chaos-report.pdf>. Acesso em:
26 de novembro de 2011.

FEATURE DRIVEN DEVELOPMENT, Site oficial.
Disponível em: <http://www.featuredrivendevelopment.com/>. Acesso em 26 de
novembro de 2011.

PALMER, S & FELSING, J. A practical guide to feature-driven development.
Prentice Hall. Upper Saddle Hill River, NJ. 2002.

NEBULON PTY LTD., Site de Jeff de Luca, criador do FDD.
Disponível em <http://www.nebulon.com/>. Acesso em 22 de novembro de 2011.

HEPTAGON, tecnologia da Informação.
Disponível em <http://heptagon.com.br/>. Acesso em 22 de novembro de 2011.

FERNANDEZ, Luiz Rafael. Construindo aplicações utilizando Thinlet e
Hibernate - Parte 02,
Disponível em:
<http://www.imasters.com.br/artigo/3510/oracle/construindo_aplicacoes_utilizando_th
inlet_e_Hibernate_-_parte_02/>, Acesso em 17 de novembro de 2011.

ALEXANDER, C., ISHIKAWA, S., SILVERSTEIN, M., JACOBSON, M., FIKSDAHL-
KING, I., ANGEL, S. A Pattern Language. New York, NY (USA): Oxford University
Press, 1977

ALEXANDER, C. The Timeless Way of Building. Oxford University Press, 1979.

53

How to Use Design Patterns, entrevista com Erich Gamma
Disponível em http://www.artima.com/lejava/articles/gammadp2.html. Acesso em 22
de novembro de 2011.

DESCHAMPS, F. Padrões de Projeto. Uma Introdução. Notas de Aula.
Departamento de Automação e Sistemas (DAS). Universidade Federal de Santa
Catarina.

GAMMA, E., HELM, R., JOHNSON, R., VLISSIDES, J. Design Patterns: Elements
of Reusable Object-Oriented Software. Reading, MA: Addison Wesley, 1995.

MOREIRA, Silvio, Utilização do Struts Framework no Desenvolvimento de um
Gerenciador de Eventos. Monografia, 2006.
Disponível em <http://www.ulbra-to.br/ensino/43020/artigos/relatorios2006
1/Arquivos/Silvio%20C%20M%20%20Trabalho%20de%20Conclusao%20de%20Cur
so.pdf>. Acesso em: 26 de novembro de 2011.

ROCHA, Helder. J930: GoF Design Patterns em Java.
Disponível em <http://www.argonavis.com.br/cursos/java/j930/index.html>. Acesso
em: 26 de novembro de 2011.

PRESSMAN, Roger S. Engenharia de Software. Trad. José Carlos Barbosa dos
Santos. São Paulo: Makron Books, 1995.

Uso de frameworks em aplicações ágeis

Recomendados

Recomendados

Mais conteúdo relacionado

Mais procurados

Mais procurados (20)

Semelhante a Uso de frameworks em aplicações ágeis

Semelhante a Uso de frameworks em aplicações ágeis (20)

Uso de frameworks em aplicações ágeis