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

  • 1,538 views
Uploaded on

 

  • Full Name Full Name Comment goes here.
    Are you sure you want to
    Your message goes here
    Be the first to comment
No Downloads

Views

Total Views
1,538
On Slideshare
0
From Embeds
0
Number of Embeds
0

Actions

Shares
Downloads
35
Comments
0
Likes
1

Embeds 0

No embeds

Report content

Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
    No notes for slide

Transcript

  • 1. ESCOLA SUPERIOR ABERTA DO BRASIL - ESAB CURSO DE PÓS-GRADUAÇÃO LATO SENSU EM ENGENHARIA DE SISTEMAS ROGÉRIO DA SILVA BATISTAO USO DE FRAMEWORKS EM APLICAÇÕES DESKTOP BASEADAS NA METODOLOGIA DE DESENVOLVIMENTO ÁGIL VILA VELHA - ES 2012
  • 2. ROGÉRIO DA SILVA BATISTAO USO DE FRAMEWORKS EM APLICAÇÕES DESKTOP BASEADAS NA METODOLOGIA DE DESENVOLVIMENTO ÁGIL 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
  • 3. ROGÉRIO DA SILVA BATISTAO USO DE FRAMEWORKS EM APLICAÇÕES DESKTOP BASEADAS NA METODOLOGIA DE DESENVOLVIMENTO ÁGIL Monografia aprovada em ___ de __________ de 2012. Banca Examinadora VILA VELHA - ES 2012
  • 4. RESUMOPalavras-chave: “Desenvolvimento Ágil”, “Metodologia”, “Frameworks” “DesignPatterns”.Uma das principais necessidades no desenvolvimento de software atualmente é aotimização do tempo e trabalho gasto no andamento do projeto, por diversosmotivos o cliente não se satisfaz ou não aceita esperar mais do que alguns mesespor um produto de qualidade.Dentre as diversas ferramentas criadas para suprir esta necessidade, duas sedestacam, as metodologias de desenvolvimento ágeis e os frameworks, cada umadelas possuem características que as qualificam para esta tarefa, as metodologiastratam da forma como o projeto é gerenciado e da equipe envolvida nele enquantoos frameworks são direcionados a parte técnica do desenvolvimento fornecendorotinas e funcionalidades para reutilização.Porque então não aplicar ambas em projetos de desenvolvimento de software? Equais seriam as principais vantagens e desvantagens disso?Para responder essas questões este trabalho busca descrever algumas destasmetodologias de desenvolvimento ágeis juntamente com alguns frameworks a fim deconhecê-los melhor e descobrir se realmente existe vantagem em substituirferramentas com aproximadamente 30 anos de existência e vários casos desucesso, para isso, um projeto criado com metodologias tradicionais foi adaptadopara metodologias ágeis juntamente com frameworks, o resultado foi satisfatórioapesar de ser um caso único.
  • 5. SUMÁRIOINTRODUÇÃO ............................................................................................................ 6CAPÍTULO 1 - METODOLOGIA DE DESENVOLVIMENTO ÁGIL DE SOFTWARE . 81.1 – O MANIFESTO ÁGIL........................................................................................ 101.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 ................................ 131.3 CONSIDERAÇÕES PARCIAIS ........................................................................... 14CAPÍTULO 2 - TÉCNICAS DE DESENVOLVIMENTO ÁGIL ................................... 152.1 – EXTREME PROGRAMMING (XP) ................................................................... 152.2. SCRUM .............................................................................................................. 182.3. FEATURE DRIVEN DEVELOPMENT (FDD) ..................................................... 212.4. CONSIDERAÇÕES PARCIAIS .......................................................................... 23CAPÍTULO 3 - FRAMEWORKS PARA APLICAÇÕES JAVA ................................. 243.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 .................................................................................................. 263.2. OPENSWING 2.4.5 ............................................................................................ 273.3. JASPERREPORTS 4.5 ...................................................................................... 293.4. CONSIDERAÇÕES PARCIAIS .......................................................................... 32CAPÍTULO 4 - DESIGN PATTERNS ........................................................................ 344.1. MODEL VIEW CONTROLLER (MVC) ................................................................ 354.2. VALUE OBJECT (VO) ........................................................................................ 374.3. DATA ACSESS OBJECT (DAO) ........................................................................ 374.4. CONSIDERAÇÕES PARCIAIS .......................................................................... 38CAPÍTULO 5 - PORQUE UTILIZAR FRAMEWORKS EM UM PROJETO DEDESENVOLVIMENTO ÁGIL ..................................................................................... 395.1. APRESENTAÇÃO DO CASO DE USO .............................................................. 39
  • 6. 5.2. CONSIDERAÇÕES PARCIAIS .......................................................................... 48CAPÍTULO 6 - CONCLUSÃO ................................................................................... 496.1. TRABALHOS FUTUROS ................................................................................... 50REFERÊNCIA BIBLIOGRÁFICA.............................................................................. 51
  • 7. 6INTRODUÇÃOSegundo Theunissen, Boake e Kourie (2005) as metodologias tradicionais comoSDM-70 e Method-1 foram desenvolvidas antes de tecnologias como a internet e oXML (Extensible Markup Language), sendo inovadoras e efetivas no contexto dastecnologias e requisitos de negócios existentes na época, além de exigiremdocumentações extensas baseados nos requisitos do negócio e em suas possíveisalterações.As metodologias de desenvolvimento de software mais populares, como ametodologia de desenvolvimento em cascata, e a metodologia de desenvolvimentoincremental revolucionaram a maneira de criar software estabelecendo padrões emétodos antes desconhecidos ou ignorados pelos desenvolvedores, contudo,atualmente devido as grandes inovações na área da tecnologia e informação e docrescente interesse das empresas em se adaptar rapidamente as mudanças, taismétodos podem não atender eficientemente aos requisitos e devido a esta e outrasrazões as metodologias de desenvolvimento ágil vem ganhando destaque no cenárioatual.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 seguindocronogramas de desenvolvimento adaptando-se as possíveis alterações dosrequisitos de negócio.Os frameworks não estão focados no desenvolvimento ágil mais na reutilização decódigos e funcionalidades, porém com isto o desenvolvedor economiza um tempoconsiderável de desenvolvimento.Porque então não conciliar metodologia de desenvolvimento ágil com frameworksem um único projeto? Quais seriam as principais vantagens e desvantagens destaunião?O mundo moderno exige soluções cada vez mais rápidas e eficazes, capazes deadaptarem-se rapidamente as mudanças, o desenvolvedor de softwares deve ser
  • 8. 7capaz de atender essas exigências, e para isso é extremamente importante oconhecimento sobre as ferramentas disponíveis, suas características e suasfuncionalidades a fim de atender o cliente de forma satisfatória.O objetivo principal deste trabalho é mostrar as vantagens e desvantagens em seutilizar as metodologias de desenvolvimento ágil, detalhar o que são frameworks eespecificar alguns deles descrevendo suas características, depois associar as duastecnologias para demostrar como uma complementa a outra no desenvolvimento desoftwares.A pesquisa apresentara como caso de uso trechos de software, desenvolvidos apartir das metodologias de desenvolvimento ágil Scrum e XP, e de três frameworkscom finalidades totalmente distintas, hibernate, OpenSwing e JasperReports, antesde analisa-los, porém é importante conhecer tais ferramentas, e para isto, elas foramespecificadas nos capítulos iniciais deste trabalho.No total este trabalho conta com cinco capítulos sobre dos quais o primeiroespecifica o que são as metodologias de desenvolvimento ágil, como surgiu, e comoelas contribuem para o desenvolvimento do software de forma ágil e confiável, osegundo especifica três destas metodologias, o Scrum, o Extreme Programming(XP) e o Feature Driven Development (FDD) demostrando características de cadauma delas, no terceiro capitulo o assunto passa a ser os frameworks, ferramentasque auxiliam na reutilização de processos e funcionalidades acelerando odesenvolvimento, este capitulo possui três subseções onde são especificados trêsframeworks diferentes, o hibernate, o OpenSwing e o JasperReports, cada um comuma finalidade diferente quando utilizado em uma aplicação, na sequência, nocapítulo seguinte é descrito superficialmente informações sobre a arquitetura MVC(Model, View e Controller) e dois modelos de design patterns (padrões de projeto), oVO (Value Object) e o DAO (Data Access Object), utilizados no caso de usoapresentado no último capítulo deste trabalho, que tem como objeto de pesquisa umsoftware desenvolvido com base nas metodologias de desenvolvimento ágeis e nosframeworks apresentados, encerrando o trabalho a conclusão mostra que para oprojeto se tornar realmente ágil tanto os frameworks quanto as metodologias dedesenvolvimento ágeis devem ser utilizadas de forma que uma complemente aoutra.
  • 9. 8CAPÍTULO 1 - METODOLOGIA DE DESENVOLVIMENTO ÁGIL DESOFTWAREVários estudos apontam que grande parte dos projetos de softwares não é concluídacomo planejada por diversos fatores, um desses estudos foi realizado pelo grupoThe Standish Group (2009) e mostrou, com base em cerca de 8380 projetos que24% deles fracassaram, ou seja, foram cancelados ou não foram utilizados, 44%obtiveram sucesso parcial, onde o projeto foi entregue mais não atendeu asexpectativas funcionais ou de custo do projeto e apenas 32% dos projetos obtiveramsucesso, ou seja, foram entregues dentro do prazo, dentro do orçamento e com boaparte do escopo concluída. Segundo esta mesma pesquisa, dentre os principaisfatores para o fracasso dos projetos estão: requisitos incompletos, falta deenvolvimento do usuário e de recursos, expectativas não realistas, falta de apoioexecutivo, 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
  • 10. 9Além dos fatores citados acima diariamente surgem novas tecnologias e novasnecessidades, um exemplo disto foi à criação da nota fiscal eletrônica (NF-e), quesegundo 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 emitiamnotas fiscais apenas em papel se tornassem obsoletos, necessitando seremmodificados 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 dossoftwares no menor tempo possível e com garantias de confiabilidade devido àdemanda.Utilizado um dos modelos mais comuns para desenvolvimento de software como omodelo em cascata, uma alteração como a inclusão da emissão de NF-e em umsoftware pode levar meses até ser concluída adequadamente, uma vez que todas asfases do projeto (Análise, Projeto, Codificação, Teste e Manutenção) devem serrefeitas.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) é caracterizadapela adaptabilidade, ou seja, pela capacidade de absorver mudanças, sejam elasnos requisitos do sistema, tendências de mercado, nas tecnologias empregadaspara o desenvolvimento ou nas equipes envolvidas no projeto.
  • 11. 10Lindstrom 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 ÁGILDe acordo com Fowler (2000) o termo “Metodologias Ágeis” se popularizou no finalda década de 90, mais especificamente em fevereiro de 2001 em Utah, EstadosUnidos, quando um grupo de 17 grandes pensadores em processos dedesenvolvimento de software, se reuniram para discutir maneiras de melhorar astécnicas de desenvolvimento de software.A partir do consenso estabelecido neste encontro foi criado o Manifesto Ágil para odesenvolvimento 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 adocumentação e a negociação de contratos, cada um deles possuem um valorfundamental para o desenvolvimento do software, porém baseado na necessidadedo cliente em se adaptar rapidamente as mudanças, o manifesto ágil prioriza outrospontos como a interação entre os indivíduos e o funcionamento do software.
  • 12. 11Além dos valores ainda segundo Fowler (2000), o Manifesto Ágil descreve dozeprincí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.
  • 13. 12Guiados por estes valores e princípios o profissional de software adquiri acapacidade de criar e modificar softwares de forma efetiva, incentivando adaptaçõesnos requisitos para que o resultado seja o mais próximo possível do esperado.1.2 – VANTAGENS E DESVANTAGENS DO DESENVOLVIMENTO ÁGILApesar de trazer inúmeras vantagens para o desenvolvedor, o desenvolvimento ágilpode demostrar ineficiência em alguns aspectos que não devem sermenosprezados, Nas sessões seguintes tais vantagens e desvantagens sãodescritas.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.
  • 14. 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.
  • 15. 141.3 CONSIDERAÇÕES PARCIAISHighsmith e Cockburn (2000) afirmam que a novidade das metodologias ágeis nãosão as práticas que ela utiliza mais o reconhecimento das pessoas envolvidas comoprincipio fundamental para o sucesso do projeto.Acredito que dificilmente será criada uma metodologia que deixe de apresentarqualquer desvantagem, seja para o cliente quanto para o desenvolvedor, porém asmetodologias ágeis possuem um diferencial positivo ao trazerem o cliente paradentro do projeto, detalhando juntamente com o arquiteto os requisitos em cadaetapa, tornando a comunicação mais harmoniosa quanto aos obstáculosencontrados. Sem entrar em detalhes, observando algumas metodologiastradicionais onde o cliente apresenta os requisitos no inicio do projeto e suaparticipação é novamente requisitada apenas ao final, o trabalho terá que serparcialmente refeito caso exista algum equivoco, o que exigirá mais tempo e maisinvestimento que o planejado, contudo existem diversas vantagens neste tipo demetodologia, uma delas é a documentação detalhada, que em sistemas muitocomplexos o desenvolvedor pode utiliza-la para rever parâmetros e funcionalidades,economizando tempo de análise do sistema.
  • 16. 15CAPÍTULO 2 - TÉCNICAS DE DESENVOLVIMENTO ÁGIL2.1 – EXTREME PROGRAMMING (XP)De acordo com Highsmith (2000) a metodologia XP foi utilizada pela primeira vez noprojeto payroll da Chrysler por Kent Beck após anos de fracassos utilizandometodologias tradicionais.A XP se baseia em requisitos que se modificam rapidamente, diferenciam-se dasoutras metodologias, pois necessitam de constantes avaliações (feedbacks), umaabordagem incremental, e encoraja a comunicação entre todas as pessoasenvolvidas no projeto, incluindo o cliente tratado como parte da equipe dedesenvolvimento.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 clarado software, a comunicação neste caso é incentivada entre todos os membrosenvolvidos no projeto principalmente entre clientes e desenvolvedores, incluindo asconversas informais.Entende-se por simplicidade desenvolver apenas o necessário evitando, porexemplo, métodos e funções que podem vir a ser úteis no futuro, tendo comopremissa 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çãoao software, através de testes realizados em módulos funcionais do mesmo, onde ocliente opta sobre suas características a fim de que a evolução do produto até oproduto final transcorra de forma eficiente e de acordo com as expectativas reais docliente, por essa razão de acordo com Teles (2004) este é o mais importante dosvalores do XP.
  • 17. 16A coragem neste caso está diretamente relacionada aos três valores anteriores,sendo eles contrários aos convencionais, é preciso coragem para adaptar-se aosnovos paradigmas.A XP ainda segundo Beck (2005) apoiada nestes quatro valores descreve umconjunto de doze práticas para o desenvolvimento de software que são:planejamento, entregas frequentes, metáfora, projeto simples, programação empares, refatoração, testes, propriedade coletiva, integração continua, 40 horas detrabalho semanal, cliente presente e código padrão.O planejamento em todas as metodologias tem em comum a mesma finalidade, delevantar e analisar os requisitos, determinar a maneira como o projeto seráimplementado, os processos, ferramentas e cronograma. A diferença é a maneiracomo tal objetivo é alcançado, no caso do XP requisitos futuros sãodesconsiderados, a área de negócios (clientes) é vista como parte da equipe dedesenvolvimento, ela fica responsável pela definição do escopo do software,composição das versões e prazos de entrega enquanto os desenvolvedoresdecidem os detalhes técnicos, como as ferramentas e cronogramas.As entregas frequentes visam o acompanhamento do software pelo clienteperiodicamente, de preferência mensalmente, cada versão entregue deve ser o maissimples 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 projetopode ser adaptado durante o desenvolvimento, evitando que o produto final fiqueinconsistente em relação aos requisitos.O uso de metáforas é empregado com a finalidade de melhorar a comunicação entea equipe, evitando a utilização de termos técnicos e substituindo-os por nomes maisgenéricos, como por exemplo, um método criado para cadastrar clientes pode-sechamar “cadatrarClientes()”, com isso outras pessoas além daquelas que criaram ométodo podem idealizar rapidamente sua função.O desenvolvimento é realizado em duplas, enquanto um digita o outro fica centradoem identificar erros sistemáticos e semânticos, ambos pensando estrategicamenteno 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
  • 18. 17personagens a fim de possibilitar continuamente uma troca de conhecimentos entreeles. 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 queum processo pode ser simplificado sem perder sua funcionalidade mesmo que nãotenha sido de sua autoria o aperfeiçoamento deve ser realizado, a isto dá-se o nomede refatoração, ressaltando que os devidos testes de validação devem serrealizados, uma vez que o código trata-se de uma propriedade coletiva e deresponsabilidade 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 osdesenvolvedores estejam em sintonia com seus trabalhos, possibilitando validá-losunificadamente.O XP prevê que um excesso de carga constante, acima de 40 horas semanais, podesignificar um problema no projeto que não deve ser solucionado sobrecarregando osdesenvolvedores, e sim caso necessário ratificando os processos e o planejamento.
  • 19. 18Na realidade o XP não é baseado em diagramas e processos formais, trata-se deuma metodologia baseada em algumas praticas simples com o objetivo de unir aequipe e se adaptar à medida que o projeto é desenvolvido.2.2. SCRUMScrum é uma metodologia de desenvolvimento ágil baseada em princípios,semelhante ao XP, porém com dimensões distintas, segundo Beck (2005) é possíveldizer que ambos são complementares, pois o Scrum se apoia em práticas degerenciamento enquanto o XP em práticas de desenvolvimento.De acordo com Schwaber (2002) o método Scrum é direcionado à ambientes dedesenvolvimento de software orientado a objetos onde os requisitos mudamconstantemente, seu nome é originado de uma estratégia esportiva utilizada emjogos de Rugby onde a bola é levada adiante pelo campo através de um timecomposto de oito integrantes trabalhando em conjunto, semelhante a isto o Scrumse baseia em princípios como equipes pequenas, requisitos pouco conhecidos ouinstáveis e iterações curtas.As práticas do Scrum ainda segundo Schwaber (2002) não descrevem uma formasequencial de se desenvolver softwares, mas sim um conjunto de práticasgerenciais.O ciclo de vida do Scrum segundo Schwaber e Beedle (2002) é divido em três fasesprincipais divididas em sub-fases.
  • 20. 19 Figura 3 - Fases de desenvolvimento utilizando Scrum Fonte: ESPOO (2002). VTT PUBLICATIONS 478A primeira fase é chamada de Pré-planejamento (Pre-game phase) e inclui duassub-fases conhecidas como Planejamento e Arquitetura. No planejamento osrequisitos do sistema são descritos em um documento conhecido como ProductBacklog List, neste documento estão incluídos níveis de prioridade para cadarequisito, estimativas de custo e tempo, e são constantemente atualizadas com maise novos detalhes, o planejamento inclui também as ferramentas que serão utilizadasno desenvolvimento, a equipe responsável e possíveis treinamentos. A sub-fase deplanejamento tem a finalidade de se estimar o esforço e os riscos do projeto e criaruma proposta de arquitetura de desenvolvimento.A segunda fase é a fase de desenvolvimento (Game-phase), diferentemente dasmetodologias tradicionais, os requisitos técnicos e de ambiente são observados econtrolados constantemente tornando-os flexíveis para adaptarem-se as mudanças,nesta fase o desenvolvimento do software e dividido em ciclos iterativos eincrementais denominados Sprints, cada Sprint é desenvolvido preferencialmente no
  • 21. 20período de uma semana a um mês e de forma tradicional fazendo a análise dosrequisitos, 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õespara analise, avaliação e exibição do software ao cliente, nesta etapa todos osrequisitos 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 dosoftware, após os testes finais é realizada a integração e a documentação dosistema.Assim como no XP o sucesso do desenvolvimento com Scrum está nas pessoas enã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 umrepresentante que conheça suas necessidades, é ele que define os requisitos bemcomo sua importância e urgência, deve ter uma visão clara do produto e sempreestar o mais próximo possível da equipe de desenvolvimento contribuindo cominformações e opiniões para obter um produto o mais próximo possível dasexpectativas.O Scrum master é o líder do projeto, diferentemente do gerente do projeto, o Scrummaster não define o cada um deve fazer nem estima prazos ou resultados, elesimplesmente acompanha a equipe para garantir o uso correto do Scrum, éresponsável por garantir que as reuniões sejam devidamente organizadas erealizadas assim como os objetivos atingidos, evitando interferências externas quepossam comprometer a agilidade do desenvolvimento, como por exemplo, pedidosque não tenham sido discutidos no planejamento, além disso, o Scrum mater éresponsável por reportar diariamente a equipe o andamento do projeto, osproblemas 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 adesempenhar no desenvolvimento. Por ter pessoas com diferentes aptidões o timepassa a ser multifuncional, multidisciplinar e auto gerenciável. É o time quem decidea estimativa de esforço de cada Sprint já que será ele o responsável porimplementá-los.
  • 22. 212.3. FEATURE DRIVEN DEVELOPMENT (FDD)Segundo Jeff De Luca, um dos criadores do FDD, o motivo para se utilizar ametodologia é: 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, em1999, Jeff De Luca e Peter Coad apresentaram oficialmente a metodologia atravésdo livro “Java Modeling In Color with UML”.De acordo com o site oficial da metodologia a FDD é uma metodologia que combinaas melhores práticas de desenvolvimento ágil de projetos com uma abordagemcompleta para engenharia de software orientada a objetos. Figura 4 – Estrutura da FDD Fonte: http://www.heptagon.com.br/fdd-estrutura
  • 23. 22Segundo Palmer e Felsing (2002), a FDD possui cinco etapas que não necessitamde treinamentos extensos para utiliza-las. Conforme a figura 4 a FDD é objetiva epossui apenas duas fases, na primeira denominada concepção e planejamento,existem três dessas etapas que são: desenvolver um modelo abrangente, construir alista de features e planejar por feature, na segunda fase, os processos são divididosem duas etapas: detalhar por feature e construir por feature. De acordo com Palmere Felsing (2002), após cada feature ser desenvolvida e publicada, a lista de featuresé reclassificada de acordo com a prioridade para manter o time trabalhandoconstantemente 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, ospapé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.
  • 24. 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 PARCIAISPara Hawrysh e Ruorecht (2000) uma única metodologia pode não funcionaradequadamente para diferentes projetos, contudo, o gerente do projeto deveidentificar qual é a natureza de seu projeto e escolher uma metodologia dedesenvolvimento que melhor se aplica.Algumas práticas são bem comuns entre diferentes metodologias, como porexemplo, entre o XP e o FDD, ambos incentivam testes unitários, programação empares e integridade continua, porém algumas características também se contrastamtornando a metodologia mais especifica, como por exemplo, o FDD, segundo DeLuca (2002), foi originalmente criado para um projeto de grande porte com umgrande número de pessoas envolvidas, devido a essa natureza e aspectos como oprojeto e o grupo de programadores serem divididos em pequenas partes, garantemque essa metodologia funcione bem para projetos de pequenas e grandesmagnitudes o que não ocorre com o XP que é mais viável para projetos pequenos.Apesar de apresentarem certas semelhanças cada metodologia possuicaracterísticas distintas que ajudam a definir uma ou outra mais apropriada paradeterminado projeto. O scrum é voltado para o gerenciamento do projeto já o XP e oFDD são mais apropriados para o desenvolvimento do projeto.
  • 25. 24CAPÍTULO 3 - FRAMEWORKS PARA APLICAÇÕES JAVABasicamente um framework é um conjunto de funcionalidades comuns em váriasaplicações, que são disponibilizadas ao desenvolvedor para que ele complete e crieuma nova aplicação reduzindo o tempo gasto no desenvolvimento. Neste capitulo éapresentado três frameworks para aplicações baseadas na linguagem deprogramação Java com funcionalidades distintas.3.1. HIBERNATE 4.0Hibernate 4.0 é um poderoso framework de mapeamento objeto-relacional (ORM)para aplicações Java, ou seja, é uma ferramenta utilizada para persistir objetos Javaem 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 depersistência, entre as mais importantes podemos citar as que são responsáveis poroperações como criação, remoção, consulta e alterações no banco de dados,denominadas Session, Transaction e Query, interface de configuração denominadaConfiguration, interfaces que realizam interações entre os eventos do hibernatechamadas Interceptor, Lifecycle e Validatable e as interfaces UserType,CompositeUserType e IdentifierGenerator que permitem extender as funcionalidadesde mapeamento.Segundo Zhang (2007) o hibernate possui cinco interfaces principais detalhadas nositens abaixo, são elas: Configuration, Session, SessionFactory, Query e Transaction.
  • 26. 253.1.1 ConfigurationSegundo Fernandes (2005) um objeto do tipo Configuration é utilizado para definir asconfigurações de inicialização do hibernate como, por exemplo, o endereço doservidor de banco de dados, usuário, senha, entre outras. Dessa forma umaalteração como a senha, ou do endereço do banco de dados pode ser simplesmentealterada 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.htmlA 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 decriar tais arquivos.3.1.2 SessionÉ responsável pela comunicação entre a aplicação e a persistência, utiliza umaconexão JDBC (Java Database Connectivity), onde através desta é possívelexecutar 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 perdassignificativas ao software.
  • 27. 263.1.3 SessionFactoryO objeto SessionFactory também conhecido como fábrica de sessões guarda oORM em memória, é criado a partir do Configuration e através dele são criados osobjetos do tipo Session, para cada BD relacional existente no projeto deve-se criaruma SessionFactory, e como são objetos pesados que utilizam consideráveisespaços na memória é recomendável criar apenas uma instância de cada naaplicação.3.1.4 QueryAs querys (consultas) podem ser realizadas em um projeto com hibernate utilizandouma linguagem para banco de dados, denominada HQL (Hibernate QueryLanguage), que se parece muito com a SQL (Structured Query Language), porém,totalmente orientada a objetos. Nesta o usuário pode realizar suas requisiçõesdiretamente nas classes de persistência o que melhora o desempenho do software ecaso haja necessidade de alterar o SGBD (Sistema Gerenciador de Banco deDados), basta alterar o driver de conexão, sem se preocupar com alterações nocódigo do programa.3.1.5 TransactionO uso deste objeto é opcional, porém, é praticamente essencial em uma situaçãoonde número de sessões é relativamente excessivo, sua finalidade é abstrair econtrolar as transações do hibernate tratando os possíveis erros que posam vir aocorrer 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 osarquivos de mapeamento em XML com exceção do arquivo de configuração.
  • 28. 273.2. OPENSWING 2.4.5De acordo com a documentação oficial do framework, o OpenSwing é baseado naAPI (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 adicionadosdiretamente a um IDE (Interface de Desenvolvimento) como o NetBeans ou oEclipse. Figura 6 - Esquema de funcionamento do framework OpenSwing Fonte: http://oswing.sourceforge.net/features.html (2011)
  • 29. 28Ainda segundo a documentação do framework o OpenSwing possui um total de 30componentes, entre eles text field (campo de texto), text formatted field (campo detexto 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, aoadiciona-la ao projeto o usuário já possui vários eventos definidos, entre eles paginaros dados, filtrar colunas, ordenar os dados, entre outros.O OpenSwing permite criar aplicações baseadas em SDI (Simple DocumentInterface) ou MDI (Multiple Document Interface), as aplicações MDI possuem umajanela principal com janelas internas alternadas conforme solicitação do usuário, nocaso do OpenSwing estas aplicações ao serem criadas incluem diversascaracterísticas e ferramentas, como mostra a figura 3, que o desenvolvedor opta sedisponibiliza ao usuário ou não, reduzindo o tempo de desenvolvimento e o esforçodo desenvolvedor. Figura 7 - Modelo de aplicação MDI criada a partir do framework OpenSwing Fonte: Elaboração própria (2011)
  • 30. 29Juntamente com os arquivos do OpenSwing é disponibilizado um repositório comvárias demonstrações de aplicações e seus respectivos códigos fonte, todas criadasa partir do framework, a figura 5 ilustra uma destas aplicações, que corresponde auma aplicação MDI com um formulário principal, uma barra de menus no cantosuperior, uma barra de ferramentas, uma barra de menus em árvore, um mecanismode busca, uma barra de status no canto inferior, entre outras, que o desenvolvedorpode simplesmente editar e construir um novo projeto.Além da parte visual as demonstrações trazem também toda uma lógica de negóciosestruturada, para que o desenvolvedor tenha o menor trabalho possível, substituindoos 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 OpenSwingrotinas 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, oque significa que quando habilitado, o hibernate é responsável pela comunicação daaplicação com o Banco de dados.3.3. JASPERREPORTS 4.5JasperReports 4.5 é um framework que auxilia na criação de relatórios, de acordocom sua documentação ele é inteiramente escrito na linguagem de programaçãoJava, capaz de abstrair qualquer tipo de dado desta linguagem e criar documentosque podem ser visualizados, impressos, ou expostos ao usuário em vários formatoscomo HTML (HyperText Markup Language), PDF (Portable Document Format) entreoutras.
  • 31. 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 frameworkJasperReports 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 arquivoDTD (Document Type Definition) denominado “jasperreports.dtd”, através dasinformações declaradas neste arquivo pode-se definir os tipos de componentesapresentados no relatório e suas respectivas localizações. Figura 9 - Exemplo de arquivo XML usado pelo JasperReports Fonte: Elaboração própria (2011)
  • 32. 31Em seguida este arquivo XML é compilado gerando um arquivo com extensão“.jasper”, os campos definidos no arquivo XML podem ser estáticos, recebidos viaparâ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 comoapresentado na figura 9, ou executada na classe Java, armazenando o resultado emum objeto JRDataSource e transferindo-o via parâmetro juntamente com os camposestá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 disponibilizaum aplicativo do tipo front-end, para configurar e desenvolver os relatórios de formagráfica reduzindo as chances de erros semânticos, este aplicativo é conhecido pelonome de iReports, exibido na figura 10.
  • 33. 32Especificamente para o IDE NetBeans foi desenvolvido um plugin onde é possívelintegrar as ferramentas disponibilizadas no iReports com a interface dedesenvolvimento obtendo uma paleta de ferramentas ilustrada na figura 11, com estapaleta o desenvolvedor pode criar seus relatórios de forma visual sem alternar entreos editores. Figura 11 - Paleta de componentes do plugin do JasperReports 4.5 para NetBeans IDE Fonte: Elaboração própria (2011)3.4. CONSIDERAÇÕES PARCIAISEm um projeto o programador pode reduzir substancialmente o tempo que levariapara desenvolver rotinas e funcionalidades, reutilizando-as através de frameworksespecializados, ao fazer isto dependendo do framework utilizado, o programador nãoestará substituindo apenas um código por outro, mais por um código já testado evalidado geralmente por um especialista ou um grupo de especialistas.
  • 34. 33Com isso é possível afirmar que algumas das vantagens de se utilizar frameworkssão ter a codificação ou design parcialmente desenvolvidos, códigos menores, maislimpos e confiáveis, contudo também percebemos algumas desvantagens, umadelas é garantir a integridade de versões, ou a pouca documentação disponibilizadaa 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, nocapítulo anterior foram descritos apenas três deles, totalmente distintos entre si, oHibernate para persistir objetos no banco de dados, o OpenSwing para tratar osobjetos 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 asregras de negócio especificas do cliente e tornar sua aplicação consistente.
  • 35. 34CAPÍTULO 4 - DESIGN PATTERNSO conceito de design patterns (padrões de projeto) foi criado por um arquiteto ematemá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 deSoftware, Reutilizado Orientado a Objetos pela Gangue dos Quatro”, foi que designpatterns 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 seguintespartes:  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.
  • 36. 35Para Deschamps (2002, p.4) um padrão de projeto nomeia, abstrai, e identifica osaspectos chave de uma estrutura de projeto comum para torná-la útil para a criaçãode um projeto orientado a objeto reutilizável. Padrão de Projeto é uma soluçãocomum 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 softwaresurgiu 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 nestaarquitetura outros, porém são baseados apenas em uma ou duas destas camadas. Figura 12 – Funcionamento do MVC Fonte: Moreira (2006), p.15Ainda segundo Moreira (2006), modelo é a camada responsável por abrigar acamada de negócios, a visão é a camada de apresentação, ou seja, a camadaresponsá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 camadavisão acessando a camada modelo e realizando as alterações.
  • 37. 36Sempre que um modelo é alterado, as visões associadas a ele são notificadas, destaforma as visões podem ser atualizadas juntamente com o modelo, contudo odesempenho da aplicação pode vir a reduzir caso tenha muitas visões ou se omodelo é atualizado constantemente.O modelo encapsula e persiste os dados e as regras de negócio sem a preocupaçãode como estes serão exibidos, cabe a camada visão esta tarefa que por sua vez nãose 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 camadade 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ívelconcluir 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 fazparte 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 frameworkpossui componentes para visualização, parte em amarelo da figura representando acamada de visão, ferramentas para comunicação, objetos em verde representando acamada de modelo, e ferramentas para gerenciamento dos dados, parte azul dafigura representando a camada de controle.No caso do OpenSwing as camadas podem ser utilizadas separadamente, odesenvolvedor pode utilizar apenas os componentes e configurar a lógica denegócio através de outro framework, ou diretamente no código do programa.A camada modelo do OpenSwing é compatível com o hibernate cabendo aodesenvolvedor a decisão de utiliza-la ou não.
  • 38. 374.2. VALUE OBJECT (VO)De acordo com a empresa SUN Microsystens atualmente subsidiada pela OracleCorporation 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 toPlatform, Enterprise Edition), que se encontra na camada de negócios, seu objetivosegundo a é reduzir o número de iterações necessárias para transferir dados entre aaplicaçã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 nacamada 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.
  • 39. 38Assim como nas classes VO é recomendável que cada entidade da tabela tenhauma classe DAO. Quando necessário, por exemplo, inserir dados no BD, um objetoda classe VO é transferido por parâmetro para um método da classe DAOresponsável pela ação, porém, diferentemente da VO a classe DAO pode termétodos que envolvam outras tabelas desde que estejam relacionadas. Figura 14 – Exemplo de classe DAO Fonte: Elaboração própria (2011)A figura 14 é apenas um exemplo de como a lógica de negócio pode ser tratada, nãohavendo uma maneira sequencial para desenvolvê-la ficando a cargo de oprogramador codifica-la.4.4. CONSIDERAÇÕES PARCIAISExistem 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 econsequência, assim como os frameworks reutilizam funcionalidades, os padrões deprojeto compartilham ideias e conceitos.
  • 40. 39CAPÍTULO 5 - PORQUE UTILIZAR FRAMEWORKS EM UM PROJETODE DESENVOLVIMENTO ÁGIL5.1. APRESENTAÇÃO DO CASO DE USOAo 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 cidadede Cruzeiro, interior do estado de São Paulo, a primórdio baseado na metodologiaem cascata, todas as etapas de desenvolvimento de software foram cumpridas, olevantamento de requisitos, modelagem, entre outros, a partir disto foi definido umprazo de seis meses para o término do software denominado “SICEP - Sistema paraControle de Estoque e Patrimônio”.Segundo Pressman (2006) no modelo cascata cada fase do desenvolvimentoprogride em uma ordem estrita sem qualquer sobreposição ou passos iterativos,ainda segundo ele esse modelo descreve um método de desenvolvimento linear esequencial.No início em decorrência da falta de experiência modelei o sistema com algumasdificuldades, mesmo assim o projeto seguiu conforme o cronograma e logo após oinício da codificação fui chamado pela matriz da empresa em São José dos Campostambém no estado de São Paulo, que demonstrou interesse em incluir o softwarenas demais unidades, fiz uma pequena apresentação de tudo que já tinha elaboradoaté o momento, o projeto agradou e ganhou uma nova dimensão.A realidade da empresa matriz, apesar de ter o mesmo segmento da filial, erarelativamente 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 sidodefinidas 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 doproduto final, com um pouco de rejeição por parte do cliente concordamos emadicionar mais três meses.
  • 41. 40Remodelei 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 suficientepara finaliza-lo, muitos processos simples como validação de campos, criptografia desenha, entre outros ocupavam um tempo considerável.Percebi também que muitos processos envolvidos eram semelhantes comocadastrar fornecedores, cadastrar clientes, cadastrar usuários, cadastrar produtos, eque tais rotinas poderiam ser reaproveitadas de alguma forma, mas da maneiracomo estavam sendo criadas se tornou inviável reutiliza-las.Durante o desenvolvimento realizei diversas pesquisas, em busca de técnicas eferramentas que me auxiliassem neste projeto, primeiramente descobri o designpatterns, e sobre a arquitetura MVC, com o banco de dados já modelado earquitetado, criei os objetos VO e DAO.De acordo com Esjug (2007) desenvolver um mapeamento objeto relacional podeser 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 acontinuar utilizando o modelo em cascata em meu projeto. Aplicar qualquerframework 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.
  • 42. 41 Figura 15: Modelo de Banco de Dados do programa SICEP Fonte: Elaboração própria (2011)Quando o prazo para o término do projeto estava para expirar, entrei em acordo como cliente e negociamos de entregar o programa em dois módulos, o módulo paracontrole de estoque que já estava em fase final e requisitei mais algum tempo paraterminar o módulo de patrimônio, ao todo o projeto levou aproximadamente dozemeses para ser concluído, aproximadamente um terço a mais do que o planejado.Para demostrar as ideias apresentadas neste trabalho comecei a refatorar osoftware para uma nova versão, a proposta inicial foi utilizar as metodologias dedesenvolvimento á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...
  • 43. 42Para 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çõesreferentes ao banco de dados para estabelecer a conexão, feito isto utilizei oassistente que a IDE disponibiliza para mapeamento que automaticamente criouvárias classes denominadas POJOs (Plain Old Java Object), similares as classesVOs porém sem particularidades. Em seguida fiz o download do OpenSwing eadicionei seus componentes a paleta de componentes do IDE. Figura 16- Paleta do NetBeans com alguns componentes do framework OpenSwing Fonte: Elaboração própria (2011)Devido a regras especificas da empresa decidi não utilizar a interface MDI doOpenSwing neste projeto e manter a mesma estrutura da primeira versão.O programa trata-se de um software cliente-servidor criado para funcionar em redecom diferentes permissões para os usuários, ao inicia-lo é solicitado usuário esenha, um usuário do tipo administrador tem acesso a todas as ferramentas e é eleque cria novos usuários, as outras permissões são de comprador e almoxarife, nesta
  • 44. 43empresa o controle de estoque se limitava a estas duas funções, sendo que ocomprador efetua a entrada dos produtos no almoxarifado e o almoxarife efetua assaídas. Figura 17: Janela principal do programa SICEP Fonte: Elaboração própria (2011)Ao mesmo tempo em que a nova versão era desenvolvida o cliente avaliava aanterior, e com isso constantemente o software estava recebendo feedbacks, comisso muitos processos foram melhorados, e o cliente começou acompanhar maisdetalhadamente 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.
  • 45. 44Nos formulários de cadastros os campos de texto foram substituídos por camposmais específicos como, por exemplo, os campos de entrada de datas, foramsubstituídas pelo componente do OpenSwing chamado DateControl, onde a datapode ser selecionada diretamente de um calendário, isso evita que o usuário digiteuma data inválida, da mesma forma os campos de valores numéricos inteiros comoquantidade foram substituídos pelo componente NumericControl, os valores reaiscomo preço foi utilizado o CurrencyControl, nos campos com máscara como o CPF eCNPJ utilizei o componente FormattedTextControl e assim por diante . Figura 18 - Componente DateControl Fonte: Elaboração própria (2011)Substituindo os componentes, uma parte do código foi eliminada já que não era maisnecessá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 previamenteAlgumas rotinas são mais especificas, para citar um exemplo, neste projeto existiauma regra de negócio que dizia que o almoxarife poderia desmembrar um item efornece-lo em outra unidade, de maneira que um produto, adquirido em caixa com200 unidades, por exemplo, poderia ser fornecido individualmente ou em pacotescom 50 unidades ou em outra unidade compatível, numa situação como esta se ovalor da caixa adquirida fosse de 400 reais ao desmembra-la cada produto passariaa custar dois reais, mais supondo que a caixa tenha custado 450 reais, a divisão
  • 46. 45resultante seria uma dizima periódica nestas ocasiões foi definido que um produtoterá 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ãoprocessos que dificilmente serão reutilizados em outro programa, ou serão tratadosde forma diferente de acordo com cada empresa. Figura 19 - Exemplo dos componentes no formulário de cadastro Fonte: Elaboração própria (2011)Na primeira versão do software as consultas, notas de fornecimento ou qualqueroutro documento eram exibidas ao usuário em objetos do tipo JTable, para satisfazera necessidade do usuário imprimir ou salvar o resultado em um arquivo, foi criadoum processo que através de um botão o usuário exportava a tabela para um arquivotexto. Na nova versão foi adicionado ao projeto o JasperReports, o que deixou oprocesso de emissão de relatórios muito mais profissional.O primeiro passo para criar os relatórios é estabelecer uma conexão, para isso oNetBeans com o plugin do JasperReports instalado disponibiliza um assistente, ondebasta fornecer algumas informações, tais como usuário e senha do banco de dadosconforme figura 20.
  • 47. 46 Figura 20 - Assistente para conexão do JasperReports com o Banco de Dados Fonte: Elaboração própria (2011)Estabelecida à conexão o IDE disponibiliza uma interface onde o usuário podeliteralmente desenhar o layout do relatório que desenha criar, enquanto o sistemacria automaticamente o arquivo XML que o JasperReports precisa para funcionarcorretamente.A figura 21 mostra o layout criado para um relatório de fornecimento e logo abaixo nafigura 22 o mesmo relatório é ilustrado já com os campos preenchidos em tempoexecução conforme é exibido ao usuário.
  • 48. 47Figura 21 - Desenvolvimento dos relatórios com JasperReports e NetBeans Fonte: Elaboração própria (2011) Figura 22 - Relatório exibido ao usuário Fonte: Elaboração própria (2011)
  • 49. 48Na figura 20, o relatório é exibido dentro de uma janela que o frameworkdisponibiliza, onde é possível através de uma barra de ferramentas imprimir oarquivo, salva-lo em diversos formatos como html, pdf, doc, entre outros, rotacionaro arquivo, aplicar zoom, navegar entre as demais páginas geradas, entre outros.Como podemos observar, todos os frameworks disponibilizam ferramentas que se odesenvolvedor fosse programa-las ocuparia um tempo considerável o qual elepoderia estar utilizando para algo de maior importância para o projeto.5.2. CONSIDERAÇÕES PARCIAISO software demonstrado no caso de uso em sua primeira versão levouaproximadamente um ano para ser concluído, sendo que o cronograma inicial era deseis 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 insatisfeitoapenas pelo tempo que o projeto levou para ser concluído, mas também devido afunções inconsistentes ocasionadas pela falta de comunicação, novos requisitosmuitas vezes demoravam ou não poderiam ser atendidos devido aos autos custos, eoutros fatores que levaram ao desenvolvimento de uma nova versão, estipulada paraseis meses, porém utilizando métodos ágeis e frameworks esta nova versão ficoupronta aproximadamente com a metade do tempo estipulado e satisfazendo todas asexpectativas do usuário.Podemos concluir então que as metodologias de desenvolvimento ágil não visamapenas à rapidez no desenvolvimento do projeto mais também a satisfação docliente.
  • 50. 49CAPÍTULO 6 - CONCLUSÃOEm se tratando de TI (tecnologia e informação), a cada dia surgem novos avanços, epodemos concluir que é impossível que metodologias de desenvolvimento desoftwares 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 oferecembase para que novas metodologias sejam criadas como é o caso das metodologiasde 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 econfiabilidade. A reutilização de ferramentas certificadas e testadas, através dosframeworks possibilita o desenvolvimento do projeto de forma rápida, confiável eorganizada tornando o software robusto e dinâmico.Porque então não conciliar metodologia de desenvolvimento ágil com frameworksem um único projeto? Quais seriam as principais vantagens e desvantagens destaunião?Analogicamente as metodologias de desenvolvimento ágil são as placas quemostram o caminho mais curto, e os frameworks são os automóveis que ajudam atransitar por este caminho mais rapidamente, portanto se a necessidade é deagilidade o ideal é utilizar essas ferramentas em conjunto, porém é extremamenteimportante que o desenvolvedor conheça bem com o que está trabalhando, pois,existem várias metodologias e diversos tipos de frameworks, sem um conhecimentoadequado 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 ferramentasapresentadas neste trabalho já tenham sido melhoradas ou substituídas porferramentas mais avançadas, por isso é importante sempre analisar quais delassatisfaz melhor os requisitos do projeto.
  • 51. 50Em se tratando de TI, avanços acontecem constantemente, novos requisitos e novastecnologias levam o desenvolvimento de software a patamares diferentes desde osurgimento do PC (Personal Computer). Um dos principais motivos desta evolução ésem dúvida a necessidade de agilidade, qualquer tecnologia nova nunca será maislenta que a anterior a não ser que exista um motivo muito importante para isto.6.1. TRABALHOS FUTUROSCom base neste trabalho espero que outros envolvendo metodologias ágeis eframeworks venham a surgir, especificando outros frameworks e outrasmetodologias como Crystal Clear, Adaptive Software Development, entre outras quenão puderam ser descritas neste.Outra sugestão é a criação de parâmetros e situações para comparação entremetodologias demostrando através destes quais são superiores em cada situação, ecom isso ajudar o desenvolvedor iniciante a definir qual metodologia deve utilizar emseu projeto.
  • 52. 51REFERÊNCIA BIBLIOGRÁFICATHEUNISSEN, W., BOAKE, A. & KOURIE, D. In search of the sweet spot: Agileopen collaborative corporate software development. Trabalho apresentado durante aCoferência Anual de Institutos de Ciência da Computação e Informação da Africa doSul. África do Sul, 2005, p. 268-277.COCKBURN, A. Agile software development. Addison-Wesley, Boston, 2002.LINDSTROM, L. & JEFFRIES, R. Extreme programming and agile softwaredevelopment 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 de2011.HIGHSMITH, J. ORR, K. COCKBURN, A. Extreme Programming, E-BusinessApplication Delivery, 2000, p. 4-17.TELES, V. Manhães. Extreme Programming: Aprenda como encantar seususuá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 setembrode 2011.SCHWABER, K. BEEDLE, M. Agile Software Development with SCRUM. PrenticeHall, 2002.ABRAHAMSSOM P., SALLO O., RONKAINEN J. & WARSTA J. Agile SoftwareDevelopment Methods, ESPOO (2002). VTT PUBLICATIONS 478DENG M., ZHANG H., Implementation of Funds Management InformationSystem 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 de2011.
  • 53. 52JASPERREPORTS, Site oficial.Disponível em: <http://jasperforge.org/projects/jasperreports/>. Acesso em: 26 desetembro de 2011.ALEXANDER, C., ISHIKAWA, S., SILVERSTEIN, M., JACOBSON, M., FIKSDAHL-KING, I. & ANGEL, S. A Pattern Language, Oxford University Press, New York,1977FONSECA, M. VILELA & ALVES, A. Luiz, MVC & FRAMEWORK, Monografia,PROPE/PUC, GOIAS, 2008MOREIRA, S. Utilização do Struts Framework no desenvolvimento de umgerenciador 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 denovembro 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 eHibernate - 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 UniversityPress, 1977ALEXANDER, C. The Timeless Way of Building. Oxford University Press, 1979.
  • 54. 53How to Use Design Patterns, entrevista com Erich GammaDisponível em http://www.artima.com/lejava/articles/gammadp2.html. Acesso em 22de 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 SantaCatarina.GAMMA, E., HELM, R., JOHNSON, R., VLISSIDES, J. Design Patterns: Elementsof Reusable Object-Oriented Software. Reading, MA: Addison Wesley, 1995.MOREIRA, Silvio, Utilização do Struts Framework no Desenvolvimento de umGerenciador de Eventos. Monografia, 2006.Disponível em <http://www.ulbra-to.br/ensino/43020/artigos/relatorios20061/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>. Acessoem: 26 de novembro de 2011.PRESSMAN, Roger S. Engenharia de Software. Trad. José Carlos Barbosa dosSantos. São Paulo: Makron Books, 1995.