O uso de frameworks em aplicações desktop baseadas na metodologia de desenvolvimento ágil

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




Monografia aprovada em ___ de __________ de 2012.


Banca Examinadora

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.

http://www.extremeprogramming.org/map/images/project.gif

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.

http://docs.jboss.org/hibernate/core/3.3/reference/en/html/session-configuration.html

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)

http://oswing.sourceforge.net/features.html

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


http://jasperforge.org/projects/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.

http://java.sun.com/blueprints/corej2eepatterns/Patterns/TransferObject.html

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.

http://www.extremeprogramming.org/

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_thinlet_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.

http://jasperforge.org/projects/jasperreports

http://www.projectsmart.co.uk/docs/chaos-report.pdf

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%20Curso.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.

http://www.artima.com/lejava/articles/gammadp2.html

http://www.argonavis.com.br/cursos/java/j930/index.html

Documents

O uso de frameworks em aplicações desktop baseadas na metodologia de desenvolvimento ágil