Comparativo Java Ruby para XP

UNIVERSIDADE FEDERAL DO RIO DE JANEIRO
DEPARTAMENTO DE CINCIA DA COMPUTAO
Comparativo entre as linguagens de programao Java e Ruby para projetos que utilizem Extreme Programming
ALAN KLOH, RODOLFO CORDEIRO BURLA DE AGUIAR
DCC-IM/UFRJ Bacharelado em Cincia da Computao
Orientador: Vincius Manhes Teles
Rio de Janeiro 2007
Comparativo entre as linguagens de programao Java e Ruby para projetos que utilizem Extreme Programming
Alan Kloh, Rodolfo Cordeiro Burla de Aguiar Projeto Final de Curso submetido ao Departamento de Cincia da Computao do Instituto de Matemtica da Universidade Federal do Rio de Janeiro como parte dos requisitos necessrios para obteno do grau de Bacharel em Cincia da Computao.
Apresentado por: _______________________________________ Alan Kloh
_______________________________________ Rodolfo Cordeiro Burla de Aguiar
Aprovado por: _______________________________________ Vincius Manhes Teles, M.Sc. (Presidente)
_______________________________________ Adriano Joaquim de Oliveira Cruz, Ph.D.
_______________________________________ Carlo Emmanoel Tolla de Oliveira, Ph.D. . _______________________________________ Vanessa de Paula Braganholo, D.Sc
RIO DE JANEIRO, RJ - BRASIL JUNHO DE 2007
AGRADECIMENTOS
Rodolfo A Deus, por ter me dado a oportunidade de concluir mais essa etapa na minha vida. Aos meus pais, Jos Geraldo e Paula, que mesmo estando longe, me deram todo incentivo, auxilio e carinho que precisava para completar mais essa etapa. minha irm Rosane, que foi quem sempre esteve ao meu lado durante todos esses anos, me ajudando quando precisava, me incentivando quando era necessrio e me divertindo nos momentos de descanso. minha irm, Ceclia, e meu cunhado, Pascoal, pelo o apoio e carinho durante todos esses anos. minha namorada Mayara, pela compreenso nos momentos de ausncia, pelo carinho e amor nos momentos em que estvamos juntos, que tornaram a graduao muito mais agradvel, e pelo grande incentivo em todos os momentos. Ao nosso orientador Vincius Manhes Teles, por ter me apresentado a essa nova metodologia, pelo apoio e auxilio na escolha do tema, e sem o qual essa monografia no teria a mesma qualidade. Ao Alan, parceiro durante toda a graduao, inclusive nessa monografia, sempre tornando os momentos mais difceis naqueles mais divertidos com seu bom humor e suas piadas. Aos amigos da graduao, Luciano, Rafael, Carlos Eduardo (Kadu), Joo Paulo (Pipa) e Wallace, pela ajuda nos momentos de dificuldade e pela amizade nos momentos de diverso. Aos professores do DCC/UFRJ os quais nos transmitiram valiosos conhecimentos ao longo da graduao. A todos que nos ajudaram de alguma forma, direta ou indiretamente, na elaborao desta monografia.
RESUMO
KLOH, Alan; AGUIAR, Rodolfo Cordeiro Burla, Comparativo entre as linguagens de programao Java e Ruby para projetos que utilizem Extreme Programming. Orientador: Vincius Manhes Teles. Rio de Janeiro: UFRJ/IM/DCC, 2007. Monografia ( Bacharelado em Cincia da Computao)
Este trabalho apresenta um estudo comparativo entre as linguagens Java e Ruby, com o framework Rails, no que se refere utilizao da metodologia de desenvolvimento Extreme Programming. Esse comparativo foi criado atravs de uma pesquisa de tecnologias para as linguagens a fim de identificarmos as vantagens e desvantagens das mesmas. Para o estudo, tambm foram criados dois blogs para comparar a qualidade do produto final, o tempo de durao do processo de desenvolvimento e a facilidade de sua utlizao.
ABSTRACT
KLOH, Alan; AGUIAR, Rodolfo Cordeiro Burla, Comparativo entre as linguagens de programao Java e Ruby para projetos que utilizem Extreme Programming. Orientador: Vincius Manhes Teles. Rio de Janeiro: UFRJ/IM/DCC, 2007. Monografia ( Bacharelado em Cincia da Computao)
This work presents a comparative study between Java and Ruby languages, relating to the use of Extremme Programming methodology. This comparative was created through research on technologies to the languages and by the development of two blogs, each of them in one of the languages. To identify the advantages and disadvantages of each used language with a set of technologies previously chosen.
SUMRIO
Introduo .......................................................................................................7 1.1 Motivao ..................................................................................................7 1.2 Proposta ....................................................................................................8 1.3 Validao...................................................................................................9 Extreme Programming .................................................................................10 2.1 Valores ....................................................................................................10 2.2 Prticas ...................................................................................................15 Blog em Java ................................................................................................29 3.1 Introduo ...............................................................................................29 3.2 Padro Model-View-Controller ................................................................32 3.3 MVC Model 2...........................................................................................34 3.4 Struts 1 ....................................................................................................35 3.5 JUnit ........................................................................................................41 3.6 Estrutura do Blog.....................................................................................43 3.7 Funcionamento do Blog...........................................................................44 3.8 Consideraes.........................................................................................45 Blog em Ruby ...............................................................................................46 4.1 Introduo ...............................................................................................46 4.2 Ruby on Rails ..........................................................................................46 4.3 Migration..................................................................................................52 4.4 Estrutura do Blog.....................................................................................57 4.5 Funcionamento do Blog...........................................................................60 4.6 Consideraes.........................................................................................60 Comparativo..................................................................................................61 5.1 Introduo ...............................................................................................61 5.2 Linhas de Cdigo.....................................................................................62 5.3 Analisando as prticas ............................................................................65 Concluso .....................................................................................................74
1 Introduo
1.1 Motivao Ao longo de mais de trs anos, entre estgio e trabalho, percebemos que apesar de trabalharmos em lugares distintos nos deparvamos com os mesmos problemas em nossos projetos. Eles constantemente sofriam alterao no cronograma, pois era verificado que este era irreal e no poderia ser cumprido. Com isso, projetos que deveriam durar um determinado nmero de meses duravam, na realidade, quase o dobro. Os projetos eram entregues mas, muitas das vezes no atendiam s necessidades dos usurios. Em alguns casos at, esta j havia
deixado de existir, devido a alguma mudana no ambiente em que seria utilizada. Esses problemas no aconteciam somente na nossa equipe, mas sim em grande parte dos projetos que as empresas estavam envolvidas, o que nos mostrava que no era um problema gerencial ou tcnico das equipes. Como ocorriam em empresas diferentes, verificamos que se tratava de um problema em algo que era de uso comum s duas empresas. Foi ento que comeamos a estudar Extreme Programming (XP)1 na faculdade. Durante esse estudo, o professor apresentou diversos problemas que eram comuns em projetos de software em geral. E eram, exatamente, esses os que identificvamos nas respectivas empresas. Assim descobrimos que as metodologias utilizadas nas duas empresas eram muito parecidas e, portanto, tinham alguma influncia nos constantes atrasos e falhas dos projetos de software. E essa uma metodologia comum, no somente a essas duas empresas, mas maioria das companhias de desenvolvimento de software.
Metodologia de desenvolvimento de softwares criada no final da dcada de 90. (TELES, 2004)
No estudo do XP vimos que ela apresenta diversas prticas que buscam corrigir os erros mais comuns no desenvolvimento de software. Essa metodologia nos foi apresentada utilizando-se o Java (SUN 2006f), por ser tratar de uma linguagem amplamente utilizada hoje em dia no mercado e por possuir artefatos que auxiliam na utilizao dessa metodologia. Porm, a integrao desses artefatos que auxiliam na utilizao dessa metodologia nem sempre fcil e rpido, assim como o desenvolvimento nessa linguagem em geral requer a codificao de muitas classes, interfaces e arquivos de configuraes. Diante dessa caracterstica da linguagem, optamos por buscar, uma outra , e foi ento que conhecemos a linguagem Ruby(THOMAS; HANSSON 2005) e o framework Ruby on Rails (THOMAS; HANSSON 2005). Porm, no sabamos como seria utilizar a metodologia XP com essa linguagem, quais prticas possuiriam ferramentas para auxlio e quais seriam as dificultadas. Decidimos comparar as duas linguagens para verificar qual delas se mostraria mais eficiente, utilizando-se as prticas de XP, levando-se em conta as caractersticas de cada linguagem e o seu suporte na utilizao das prticas de XP. 1.2 Proposta
Nesse trabalho iremos testar essas duas linguagens utilizando-se as tcnicas de XP, com a finalidade de verificarmos qual seria mais recomendada para o desenvolvimento de aplicaes Web. Iremos com isso gerar um estudo comparativo entre as duas linguagens, apresentando vantagens e desvantagens, para cada tcnica utilizada em XP. Ao
final, apresentaremos aquela que considerarmos a mais adequada para o desenvolvimento de aplicaes Web, se verificarmos a existncia de uma. Nesse comparativo iremos utilizar a mtrica de linhas de cdigo, como uma das formas de comparao entre as duas, bem como uma anlise subjetiva em relao a complexidade no desenvolvimento da aplicao. 1.3 Validao Para obtermos esse comparativo, iremos desenvolver uma mesma aplicao Web, utilizando-se as tcnicas de XP, nas duas linguagens, anotando as caractersticas de cada uma em relao a cada tcnica. Essa aplicao ser um blog2, por se tratar de uma aplicao bastante utilizada atualmente, simples de ser implementada, mas, ao mesmo tempo, suficiente para a elaborao desse estudo.
Pgina da web que possui textos, que em geral se referem a um mesmo assunto, ou pertencem a uma mesma pessoa, que so organizados cronologicamente, que normalmente podem ser comentadas.
10
Extreme Programming
Extreme Programming (XP) uma metodologia de desenvolvimento de
software, nascida nos Estados Unidos, na dcada de 90, baseada em alguns valores e prticas que ajudam a tornar o desenvolvimento dos softwares mais gil e produzir resultados com maior qualidade. Essa uma das metodologias conhecidas como metodologias de
desenvolvimento gil. Essas metodologias seguem um conjunto de princpios criados por um grupo de profissionais veteranos que se reuniram numa estao de esqui, no EUA, para discutir formas de melhorar e agilizar o processo de desenvolvimento de software. Eles chegaram concluso de que todos os projetos em que estiveram envolvidos e que obtiveram sucesso, seguiam um mesmo conjunto de princpios. Com base nisso, eles criaram o Manifesto para o Desenvolvimento gil (http://agilemanifesto.org/history.html), tambm conhecido como Manifesto gil. Esses princpios so:
Indivduos e interao entre eles mais que processos e ferramentas Software em funcionamento mais que documentao abrangente Colaborao com o cliente mais que negociao de contratos Responder a mudanas mais que seguir um plano
O manifesto ressalta que, mesmo que haja valor nos itens direita, os itens esquerda so considerados prioritrios. No decorrer desse captulo, iremos apresentar e explicar cada um dos valores e prticas utilizadas no desenvolvimento de software que seguem o XP. 2.1 Valores
11
Feedback Projetos de software so bastante suscetveis falha, pelo fato de que, em muitas vezes, os clientes no sabem exatamente o que desejam quando fazem uma solicitao de softwares Em geral, os clientes reconhecem os seus problemas e querem um sistema para resolv-lo. No entanto, no sabem ao certo o que o software deve fazer para solucion-lo. Devido a essa caracterstica, geralmente, o entendimento do que o sistema deveria fazer no o mesmo entre os desenvolvedores e os clientes, e por isso, constantemente, vemos softwares que no satisfazem s necessidades dos clientes (BROOKS, 1987). Para contornar essa caracterstica do desenvolvimento de software, o XP utiliza um valor chamado feedback, que consiste em obter o feedback dos seus clientes o mais rpido possvel. Esse processo busca diminuir, ao mximo, a defasagem de tempo entre o momento entre a execuo da ao e a obteno de seu resultado. Quanto mais cedo um mau entendimento de alguma funcionalidade for identificado, menor ser o custo de seu reparo. Por isso, este valor to importante no XP, pois quanto maior o feedback dos clientes menor o risco de se produzir algo errado.
Comunicao No desenvolvimento de software esto envolvidas pelo menos duas pessoas. O desenvolvedor e o cliente. Mas, em sua maioria, um maior nmero de pessoas esto envolvidas( mais clientes e desenvolvedores). No desenvolvimento de software, o cliente geralmente, precisa informar o que deseja ser produzido. E cabe ao desenvolvedor, informar quais as limitaes tcnicas envolvidas. No processo, os problemas na comunicao, frequentemente, causam uma compreenso equivocada do que est sendo solicitado.
12
Muitas vezes o meio de comunicao que est sendo utilizado faz toda a diferena na compreenso das pessoas que esto se comunicando, pois uma srie de conhecimentos tcitos podem ser perdidos, dependendo do meio de comunicao empregado. Quando explicamos algo pessoalmente, por exemplo, percebemos atravs das expresses faciais, se estamos sendo compreendidos pela outra pessoa. Quando fazemos essa explicao por telefone, esse conhecimento tcito perdido. Muitas vezes os clientes executam suas atividades de modo tcito, e por isso tm dificuldades de descrever suas atividades utilizando meio de comunicao pouco ricos como, telefone e e-mail por exemplo, mas em uma conversa presencial conseguem explicar facilmente essas tarefas. Por isso o XP valoriza meios de comunicao mais ricos, trazendo o cliente, ou ao menos um representante, para dentro da equipe de desenvolvimento. Isso significa trazer o cliente para o mesmo ambiente em que esto os desenvolvedores, para que a comunicao entre eles seja feita de forma presencial e o mais rpido possvel. O XP tambm faz uso de radiadores de informao (COCKBURN, 2002) que, alm de facilitar a comunicao, ajudam a colocar em prtica um modelo de autodirecionamento do processo de desenvolvimento. Outra caracterstica do XP, importante para que haja uma melhor comunicao entre os integrantes do processo de desenvolvimento, a utilizao de equipes pequenas, pois quanto menos pessoas envolvidas no processo de desenvolvimento, mais fcil saber o que cada uma est fazendo. Assim, evita-se que duas pessoas realizem tarefas que interfiram nas tarefas dos outros. Alm disso, quanto menos pessoas envolvidas num processo de comunicao, mais fcil a
13
compreenso do que uma pessoa est falando, por termos menos interferncia e conversas paralelas, o que torna a comunicao mais rica.
Simplicidade Um estudo do Standish Group (JOHNSON, 2002) mostrou que 45% das funcionalidades de um sistema tpico jamais so utilizadas e que 19% das funcionalidades so usadas raramente. Esses nmeros revelam um pouco da razo pela qual o desenvolvimento de software costuma ser mal sucedido. Quando falamos mal sucedido, nos referimos a projetos que, foram entregue fora do prazo, ou extrapolaram o custo, ou os dois, ou at que no terminaram. Esses 64% de funcionalidades desenvolvidas, sem necessidade, indicam um desperdcio de tempo, dinheiro e pessoal responsvel. Isto, em grande parte, pelo insucesso dos projetos de software. Essas funcionalidades surgem basicamente por trs motivos: O escopo do sistema, geralmente, fechado no inicio do
desenvolvimento e alteraes no mesmo so evitadas; Desenvolvedores criam solues genricas para facilitar possveis alteraes no escopo; Desenvolvedores tm a tendncia de criar funcionalidades que eles imaginam que sero solicitadas pelos clientes. Para combater esses problemas, o XP utiliza um escopo negocivel (POPPENDIECK & POPPENDIECK, 2003) e utiliza iteraes curtas onde so projetados, programados, testados, integrados e entregues incrementos de softwares teis (POPPENDIECK & POPPENDIECK, 2003).
14
Como essas iteraes so curtas, o feedback do usurio obtido em um espao curto de tempo e, assim, o desenvolvimento de funcionalidades desnecessrias evitada, j que as funcionalidades de uma iterao so definidas pelo usurio que estabelece a prioridade de cada funcionalidade que ele imagina ser necessria ao sistema. Os desenvolvedores selecionam as mais prioritrias dentro do limite de tempo para realizao daquela iterao, deixando as outras para a iterao seguinte. E, assim, aquelas funcionalidades que o usurio imaginava necessria no inicio do desenvolvimento, mas que no eram prioritrias, mostram o seu carter desnecessrio com o passar das iteraes e no so desenvolvidas. O valor da simplicidade implica em fazer somente o que necessrio agora, sem tentar adivinhar o que ser necessrio no futuro, fazendo da maneira mais simples possvel. Porque mantendo o seu sistema o mais simples possvel, fica mais fcil adicionar novas funcionalidades no futuro, nas iteraes seguintes. Coragem Existem diversos temores no processo de desenvolvimento de software. Esses temores podem interferir no desenvolvimento, j que atingem tanto os clientes como os desenvolvedores, e as tarefas executadas passam a ser baseadas nesses temores.. Em projetos XP, estes temores tambm esto presentes. Porm, o XP utiliza um conjunto de prticas que tendem a diminuir a conseqncia desses temores e, com isso, torna a equipe mais confiante de que seu trabalho no ser afetado por esses temores. Por exemplo: Os clientes possuem medo de que no seja produzido o que eles querem, ou que estejam pagando muito por pouco. Para isso o XP usa a prtica de iteraes curtas que mostram o resultado rapidamente ao cliente, que assim pode
15
avaliar se est sendo bem interpretado e ainda avaliar se a equipe com a qual est trabalhando est produzindo o suficiente que justifique o investimento. Essas e outras prticas do suporte para que as equipes XP se sintam encorajadas a desenvolver seus trabalhos.
2.2 Prticas Cliente Presente Esta prtica consiste em levar o cliente para perto da equipe de desenvolvimento ou levar a equipe para perto do cliente. Quando falamos perto, queremos dizer, colocar os dois, fisicamente, no mesmo local. Esta prtica importantssima para dois dos valores em que o XP se baseia: comunicao. O feedback aprimorado na medida em que o desenvolvedor, estando prximo ao cliente, pode tirar dvidas, na hora que sentir necessidade. Por sua vez, o cliente pode ir testando o sistema, medida que este vai ficando pronto e com isso ir fornecendo feedback a respeito do que foi produzido. E, assim, o desenvolvedor assimila mais rapidamente as necessidades do cliente, fazendo com o feedback e
desenvolvimento fique mais rpido ao longo do tempo. A comunicao melhora, pois conforme falamos anteriormente, o XP valoriza os meios de comunicao mais ricos e, nada mais rico do que uma conversa presencial. Estando o cliente no mesmo espao fsico do desenvolvedor, a comunicao entre eles tender ser sempre presencial, o que importantssimo para uma maior compreenso do que est sendo conversado. A presena do cliente no mesmo espao do desenvolvedor cria uma outra relao benfica, que a
16
relao de confiana, onde o cliente toma conhecimento dos esforos das equipes de desenvolvimento. Apesar da presena dos clientes trazer essas vantagens, nem sempre fcil envolv-los nos projetos. Boehm e Turner (2003) e Teles (2004) apresentam situaes nas quais pode ser difcil, ou invivel, a utilizao desta prtica. Como por exemplo, quando o cliente est situado em outra cidade, estado ou pas diferente de onde se encontra a equipe de desenvolvimento. Jogo de Planejamento O planejamento em XP feito de forma contnua ao longo do desenvolvimento do software, onde o cliente e os desenvolvedores esto presentes. Os clientes escrevem pequenas funcionalidades em cartes, chamadas de histrias. Essas histrias devem ser simples e escritas de forma que cliente e desenvolvedores sejam capazes de entend-las. Uma vez com as histrias definidas, os desenvolvedores estimam quanto tempo iro levar para desenvolver cada uma. Com as estimativas definidas, o cliente define o valor de negcio de cada uma e ento determina as prioridades e, baseado no oramento dos
desenvolvedores, define quais as histrias devero ser entregues no prximo release .(BECK & FOWLER, 2001). Os releases so intervalos de tempos, que geralmente duram alguns meses, onde um pequeno conjunto de funcionalidades, devidamente testado e integrado, entregue aos usurios para serem utilizados. Esses releases so divididos em intervalos menores chamados de iteraes. As iteraes so intervalos de tempos que, geralmente, duram algumas semanas, e onde os desenvolvedores entregam algumas funcionalidades, tambm devidamente testadas. Uma coisa que vale ressaltar que a durao de cada
17
iterao constante ao longo do de todo o projeto. Essas iteraes servem para se obter uma melhor estimativa do andamento do projeto e, com isso, estimar melhor o tempo de desenvolvimento da equipe, chamada de velocidade, ao longo do desenvolvimento. Essa velocidade tende a se estabilizar. As iteraes tambm so extremamente importantes para obteno de feedback de que o que est sendo desenvolvido realmente o que foi pedido pelos clientes. Assim podemos identificar, mais rapidamente, possveis erros cometidos e corrig-los. A cada incio de iterao definido quais funcionalidades sero implementadas, baseado na velocidade das iteraes passadas e aps redefinio das prioridades das histrias. Por se tratar de um processo continuo de planejamento, reviso de prioridades e entrega de produtos, as funcionalidades desnecessrias tendem a no serem desenvolvidas, uma vez que o cliente vai tendo acesso ao sistema e verifica que essas funcionalidades no se fazem mais necessrias. Com isso, o desperdcio de recursos minimizado e aumenta a chance do projeto ser bem sucedido. Stand up meeting O Stand up meeting, como o prprio nome em ingls diz, uma reunio em que seus participantes ficam em p. Essa caracterstica e extremamente importante para demonstrar que esta reunio deve ser rpida. Ela ocorre, diariamente, para que todos tomem cincia do que aconteceu no dia anterior. Todos contam o que fizeram um dia antes para que toda a equipe tenha conhecimento do andamento do projeto. Essa reunio tambm importante para a obteno do feedback dos outros integrantes da equipe. Neste momento, cada um fica sabendo de sua atividade diria, que definida por toda a equipe. Ao tomar conhecimento de todas as atividades dos membros, dos problemas enfrentados e das solues encontradas, o conhecimento adquirido por uma pessoa
18
disseminado para toda a equipe. Porm, esta reunio s possvel se todos os membros da equipe trabalharem no mesmo lugar. Programao em Par A programao em par consiste em duas pessoas programando juntas em um mesmo computador. primeira vista, essa prtica pode ser vista como uma perda de recursos. Porm, como iremos ver, essa prtica traz uma srie de vantagens. A inspeo de cdigo realizada intensamente a primeira das vantagens que podem ser citadas. Ter algum, ao lado, desenvolvendo com voc, faz com que esta pessoa funcione como um revisor do cdigo capaz de verificar erros simples, que podem passar despercebidos pelos programadores. Tais erros poder consumir dias para serem corrigidos. Assim, detect-los cedo diminui o esforo da correo. Discusses ao longo do desenvolvimento fazem com que os programadores explorem um nmero maior de cenrios, fazendo com que estes cheguem a uma forma mais simples de resolver o problema. Isto uma grande vantagem quando tiver que ser dada alguma manuteno no cdigo. Alm disso, implantar a soluo mais simples, em geral, consome menos tempo. Outro aspecto importantssimo na programao, em par, a disseminao do conhecimento. Como os programadores trocam de par constantemente, a troca de conhecimento enquanto trabalham juntos acontece naturalmente. Ao se depararem com problemas, os programadores mais experientes passam seus conhecimentos para os mais jovens. Alm disso, quando as pessoas obtm informaes sobre questes que esto enfrentando no dia-a-dia, a sua concentrao no aprendizado tende e a ser muito melhor. A programao em par tambm extremamente importante para construir uma equipe mais slida, que no depende de um nico programador chave e, ao
19
mesmo tempo, contribui para a adio de uma pessoa equipe. Como o conhecimento disseminado ao longo de toda equipe, a presena de um programador chave se torna mais difcil e a adio de uma pessoa facilitada, pois esta ir trabalhar em par com outros programadores e obter conhecimento do domnio do sistema. Efeito conhecido, gerado pela programao em par, a presso do par importante porque aumenta a produtividade das equipes j que as pessoas se sentem pressionadas por seus pares. Isso diminui o tempo perdido com atividades externas ao projeto, como verificao de e-mail e conversas. As pessoas ficam inibidas em parar suas atividades pois isto implicar em parar, tambm, o trabalho de seu companheiro . Alem disso, a programao em par aumenta a motivao da equipe e o relacionamento inter pessoal pois proporciona o convvio direto com as pessoas e aumenta a confiana no outro, gerando uma maior intimidade que do incio. At mesmo, a conversas sobre lazer e vida pessoal. Alm disso, o fato de desenvolverem uma soluo, em conjunto aumenta, a confiana nas atividades que executam. Todos esses fatores geram um aumento de produtividade que compensa o uso de dois desenvolvedores em um mesmo computador, alm de produzir software mais rapidamente e de melhor qualidade. Existem alguns fatores, como ego e competitividade, que podem tornar a programao em par problemtica. A presena de programadores com egos extremamente elevados, que no aceitam ver seus cdigos serem questionados, e a existncia de um ambiente extremamente competitivo, onde as pessoas no querem ser vistas aprendendo com um companheiro de trabalho, podem atrapalhar o
20
andamento do trabalho em conjunto. E, ao mesmo tempo em que alguns no esto dispostos a aprender, tambm se recusam a ensinar, a um colega de trabalho, algo que ele poderia passar adiante. Cdigo Coletivo Uma outra prtica utilizada no XP, que complementa a programao em par, a pratica do cdigo coletivo. Em XP, ningum proprietrio de um cdigo. O cdigo pertence a toda a equipe e todos podem alter-lo, sem pedir permisso a ningum, o que ajuda na formao de uma equipe coesa. J que todos tm acesso ao cdigo, e sempre h um revezamento de pares e do trecho de cdigo que cada um est desenvolvendo, na hora que for necessrio dar manuteno em algum trecho de cdigo, vrias pessoas podero fazer pois j trabalharam naquele trecho em algum momento. Como pessoas diferentes alteram o mesmo trecho de cdigo, a tendncia que o cdigo fique cada vez mais simplificado, pois cada um que notar que algo est sendo feito de uma maneira muito complicada tentar simplific-lo. Assim, o cdigo fica cada vez mais simples e os erros so detectados mais rapidamente, pois as pessoas que iro alter-lo faro uma reviso do cdigo e podero identificar erros que ainda no haviam sido detectados (BECK, 2000, p.99-100). Essa prtica tambm agiliza o processo de desenvolvimento uma vez que as pessoas no precisam esperar que outra altere alguma coisa para que eles realizem os seus trabalhos. Eles mesmos alteram. Temos que ressaltar que esta prtica s deve ser usada se a equipe desenvolve seu sistema utilizando uma base slida de testes, pois alteraes em trechos de cdigos que no foram desenvolvidos pela prpria pessoa podem causar muitos erros, mas com um grande conjunto de testes esse problema contornado,
21
porque a pessoa poder identificar esses erros quando rodar os testes e consert-lo antes de integr-lo. Cdigo Padronizado Projetos XP utilizam cdigo padronizado. Essa padronizao determinada pelos prprios desenvolvedores, o que auxilia na programao em par e no cdigo coletivo. Mas essas prticas tambm so importantes para que se tenha um cdigo padronizado, j que um cdigo encontrado fora do padro pode ser alterado para que fique no padro. Design Simples Quando os usurios solicitam um software, esperam, basicamente, que ele possua quatro caractersticas : Que faa a coisa certa; Que funcione; Que seja fcil de utilizar e Que possa evoluir com o tempo.
As duas primeiras caractersticas so alcanadas com a utilizao da prtica de iteraes curtas (TELES, 2005), assim rapidamente os clientes podem verificar se o que est sendo feito est correto e funciona. Porm, essa mesma tcnica pode ser uma armadilha para se obter as duas ltimas caractersticas. Uma vez que o processo iterativo, corre-se o risco de que nas iteraes futuras seja difcil inserir novas funcionalidades e fazer com estas sejam facilmente adaptadas ao que j existe. Isso poderia tornar o sistema complexo de se usar e muitas vezes engessado. Mas para resolver esse problema, o XP utiliza uma srie de prticas que so usadas em conjunto para corrigir possveis falhas das outras e, uma delas, a do
22
design simples. Equipes XP procuram manter o design dos sistemas o mais simples possvel para que nas iteraes futuras fique mais fcil agregar novas funcionalidades. Esta prtica consiste em fazer sempre o mnimo possvel, deixando que decises complicadas sejam tomadas na hora certa, sem tentar prever o que est por vir, ou tentar prever mudanas que podero acontecer no futuro. Essas previses acabam fazendo com que os desenvolvedores comecem a gerar funcionalidades genricas, porque acreditam que no futuro essas funcionalidades sero utilizadas por outros procedimentos e, com isso, vo gerando cdigos complexos e difceis de serem mantidos. Esta prtica tambm muito importante na utilizao da prtica de iteraes curtas, pois apenas possuindo um design simples possvel fazer anlise, design, implementao, testes e depurao de um conjunto de funcionalidades, em uma ou duas semanas. O design simples obtido utilizando-se outras prticas que veremos a seguir. Essas prticas juntas fazem com que o crescimento do custo de manutenes futuras seja linear, e no exponencial, como na maioria dos casos. Isso ocorre porque com um design, sempre mantido o mais simples possvel, com uso de computadores rpidos pelo os desenvolvedores, que permite que estes realizem testes sempre que fizerem uma mudana no sistema, e a adoo dos testes automatizados, evita que manutenes no futuro sejam muito mais custosas que as feitas no presente (BECK, 2000). Desenvolvimento Orientado a Testes Uma das prticas citadas acima que ajudam na elaborao de um design simples e que reduz o custo de manutenes futuras a prtica de desenvolvimento orientado a testes (HUNT & THOMAS, 2003). Essa prtica consiste na elaborao
23
de um teste para um mtodo, antes de desenvolv-lo. Primeiro desenvolva um novo teste, depois rode todos os testes e veja este falhar. Faa mudanas e teste novamente, faa isso at que todos os teste passem e depois faa refatorao ( que iremos apresentar mais adiante nesse captulo) para remover duplicaes e teste novamente para garantir que tudo continua funcionando. Essa prtica auxilia na elaborao de cdigo simples, uma vez que escrevendo o teste antes de escrever a funcionalidade, quando formos escrever a funcionalidade saberemos exatamente o comportamento que esperado dela, a chamada programao por inteno. Esse tipo de programao atingido porque, quando o desenvolvedor est codificando os testes, ele age como se todos os recursos necessrios j estivessem disponveis em produo e utiliza as interfaces conforme a sua necessidade. Esses testes, geralmente, nem funcionam no incio. Quando os desenvolvedores vo escrever as funcionalidades, eles j puderam descobrir como essa funcionalidade realmente ir funcionar e, com isso, tem a oportunidade de simplificar seu cdigo (HUNT & THOMAS, 2003). O XP faz uso basicamente de dois tipos de testes: os unitrios e os de aceitao. Os testes unitrios testam o que cada mtodo deve fazer,
individualmente, e os testes de aceitao testam a integrao dos mdulos para verificar se, juntos, estes realizam o que esperado. Geralmente estes testes so escritos pelos clientes, a cada iterao, com o auxilio dos desenvolvedores. Testes automatizados so fundamentais para a utilizao de iteraes curtas e contnuas pois, sem eles, a cada nova iterao, poderiam ser gerados bugs no sistema que s seriam notados na frente, uma vez que na incluso de uma nova funcionalidade podemos alterar alguma coisa que usada por outra, ou gerar um comportamento que no aceitvel em outra, mas com a utilizao de testes
24
automatizados toda vez que novas funcionalidades so inseridas roda-se o teste. Assim, esses possveis bugs so apontados e corrigidos, evitando-se que s sejam detectados quando estas funcionalidades j estiverem em produo. A utilizao de testes automatizados importante pois esses podem ser executados facilmente toda vez que se fizer necessrio e, com isso, a deteco de bugs ocorre ainda na fase de desenvolvimento. Esses testes apontam onde est o bug, reduzindo-se muito o tempo de depurao e, conseqentemente, o de correo. E como os testes so automatizados, uma vez que um bug foi corrigido, pode-se rodar os testes novamente para verificar se estes no geraram novos erros. Devido a essa caracterstica de reduo do tempo de identificao, depurao e correo de erros, apesar de parecer contra intuitivo, o desenvolvimento orientado a testes agiliza o processo de desenvolvimento de software. Alm disso, os desenvolvedores se tornam mais confiantes e, por isso, desempenham suas atividades da melhor maneira, sem medo de errar, pois sabem que se errarem os testes iro mostrar-lhes os erros. Refatorao Outra prtica extremamente importante para que o design do sistema se mantenha sempre simples a refatorao. Desenvolvedores XP realizam, durante o desenvolvimento, todas as vezes que terminam de desenvolver uma nova funcionalidade, uma reviso do cdigo. Eles retiram duplicaes, reescrevem mtodos e variveis para que estas demonstrem melhor o que significam. Projetos XP possuem uma lgica fcil de ler e presente em um nico lugar. Essa caracterstica muito importante, pois evita que possveis erros sejam causados em manutenes futuras, pois uma lgica que era idntica em dois lugares diferentes foi alterada somente em uma (FOWLER, 2000).
25
Esse mtodo muito vantajoso pois, com o tempo, existe uma tendncia de aumento da complexidade dos cdigos. Porm, com o uso da refatorao, o cdigo novamente simplificado. A refatorao tambm auxilia na documentao do sistema, pois quando o desenvolvedor sente a necessidade de comentar um trecho de cdigo, pode tentar refator-lo at que o comentrio se torne suprfluo. Apesar de, no inicio, essa prtica parecer que diminui a produtividade ao longo do desenvolvimento, os benefcios trazidos por ela ajudam a reduzir o tempo de execuo do processo, fazendo com que, no geral, esse tempo inicial seja recuperado no futuro. O grfico abaixo demonstra bem essa caracterstica.
Figura 1 - melhoria contnua do design sustenta a produtividade.(Poppendieck, 2003)
Integrao contnua
Essa uma prtica extremamente importante para que a de cdigo coletivo funcione bem. Uma vez que o cdigo coletivo, podemos ter mais de uma pessoa alterando o mesmo trecho de cdigo ao mesmo tempo e essas alteraes, muitas
26
vezes, podem ser conflitantes. Por isso, o XP faz uso desta prtica, que consiste em se integrar o mais rpido possvel e diversas vezes ao dia. recomendado integrar o cdigo a cada vez que se termine uma alterao e que esta esteja devidamente testada. Com isso, as mudanas realizadas a cada integrao so pequenas e, assim, fica mais fcil solucionar possveis problemas que venham a acontecer (JEFFRIES,ANDERSON et al., 2001). A integrao feita de forma serial, ou seja, quando um par est integrando seu cdigo, nenhum outro par poder faz-lo enquanto este no tiver terminando de integrar, testar e acertar possveis conflitos. Somente aps o cdigo de produo ter passado por todos os testes, e sem nenhum problema, que este par libera a fila para que outro possa integrar. Com isso, evitado que, durante uma integrao, um par faa uma mudana que v interferir na integrao do outro, sem que esta mudana seja percebida o quanto antes. Releases Curtos Quando investimos nosso dinheiro em alguma coisa, esperamos obter retorno o mais rpido possvel. Quando um cliente investe no desenvolvimento de software, ele tambm espera obter retorno o mais rpido possvel. Por isso o XP faz uso da prtica de Releases Curtos, que consiste em colocar pedaos do sistema em produo, o mais rpido possvel, e com certa freqncia, como de trs em trs meses, por exemplo. E como projetos XP procuram fazer o que mais importante para o cliente primeiro, atravs da priorizao das histrias, o cliente tem, logo no incio, aquilo que para ele era mais importante que o sistema fizesse. Assim, conquistamos a confiana do cliente para que ele continue com o projeto e obtemos feedback mais rapidamente, pois uma vez que o sistema esteja em produo podemos obter feedback, no somente do usurio que est auxiliando no
27
desenvolvimento do sistema, como de todos os usurios. Isso muito importante pois, algumas vezes, o usurio que estava auxiliando no desenvolvimento no conhece bem as necessidades de todos os usurios e, com esse releases curtos, esse feedback obtido rapidamente. Alm disso, como j falamos anteriormente, quanto antes se descobre falhas, menos custoso o reparo. Metforas O XP faz uso de uma prtica chamada de metfora, que consiste na utilizao de metforas para comparar elementos computacionais com elementos do dia a dia do cliente. O objetivo dessa prtica estabelecer uma comunicao mais fcil entre equipe tcnica e clientes. Assim, utiliza-se uma linguagem com a qual todos esto acostumados e, com isso, a compreenso do que est sendo dito maior de ambas as partes. Ritmo Sustentvel Projetos de software saem mais do curso por falta de tempo do que qualquer outra causa (Brooks, 1995). Quando isso ocorre, os gerentes de projetos tendem a utilizar os seus recursos ao mximo, fazendo uso de horas-extras. XP entende isso como um erro, pois pessoas submetidas ao mximo de sua capacidade, e ainda trabalhando horas a mais, tendem a ficar esgotadas e, com esse esgotamento, aumenta o numero de erros causados pelo cansao. Isso causa mais trabalho e declnio na produtividade, ao longo do projeto. Por isso, em projetos XP recomendado que a equipe trabalhe somente o tempo regulamentar e que saia do trabalho na hora certa. Mas isso no significa que os prazos devam ser alterados. Como XP trabalha com priorizao, o que se altera o escopo do que ser entregue naquele determinado prazo, e o acompanhamento do andamento do projeto feito constantemente e assim o escopo de cada iterao
28
ajustado para o atual andamento do projeto. O XP entende que ao longo do projeto voc tem um aumento de produtividade utilizando-se essa prtica, uma vez que voc mantm sua equipe sempre motivada e descansada, podendo desempenhar seu trabalho da melhor forma possvel. Assim, evita-se que erros sejam gerados pelo cansao diminuindo o re-trabalho(MASI, 2000).
29
Blog em Java
3.1 Introduo Como estamos realizando um estudo comparativo entre as linguagens de
programao Java e Ruby, iremos desenvolver um blog, em cada uma das linguagens. Neste capitulo, iremos apresentar a arquitetura utilizada para o desenvolvimento do blog em Java e a estrutura deste. Para o desenvolvimento do blog em Java, usamos Java 5.0, Eclipse3, Struts 1(APACHE, 2006 d) e JUnit (COHEN, 2004). O blog em Java foi desenvolvido em uma arquitetura em trs camadas, onde a primeira camada a de interface com o usurio, a segunda a camada de negcios e que possui a lgica da aplicao e, por fim, a camada de dados que possui a funcionalidade de armazenamento e recuperao. Para isso, utilizamos o padro MVC (que ser explicado mais a frente). A linguagem Java foi uma das escolhidas como nosso objeto de estudo primeiro porque foi a linguagem com a qual fomos apresentados metodologia XP e, tambm, por se tratar de uma linguagem amplamente utilizada no mercado de informtica. Escolhemos a verso 5.0 dessa linguagem e fizemos uso da IDE4 Eclipse 3.1, por tambm ser muito usada no mercado, alm de ser uma ferramenta de cdigo aberto. Esta IDE possui um conjunto de funcionalidades que servem de suporte para a utilizao da tcnica de refatorao. Segue abaixo figuras que mostram algumas dessas funcionalidades.
Ferramenta Open Source de desenvolvimento formado por extenses de frameworks e ferramentas. Diversas empresas, instituies de pesquisas, universidades entre outras instituies desenvolvem evolues e do suporte para o Eclipse. http://www.eclipse.org 4 IDE, do ingls Integrated Development Environment, ou Ambiente de Desenvolvimento Integrado, um programa de computador que rene caractersticas e ferramentas de apoio ao desenvolvimento de software com o objetivo de agilizar este processo.
30
Figura 2 - Refatorao de uma varivel
Na imagem acima temos o menu de refatorao para uma varivel. Nele, podemos renomear uma varivel atualizando todas as suas referencias, extrair uma varivel local, alterar a assinatura de um mtodo, extrair uma interface, entre outras funcionalidades.
31
Figura 3 - Refatorao de um trecho de cdigo.
Na imagem acima vemos o menu de refatorao, quando estamos com um trecho de cdigo selecionado. Nesse menu, temos a opo de extrair um mtodo. Nessa opo, a IDE se encarrega de copiar o trecho de cdigo e coloc-lo em um mtodo criado pelo usurio, atravs da tela abaixo, colocando no lugar do trecho selecionado a chamada para o novo mtodo.
32
Figura 4 - Extraindo um mtodo.
Nesta opo, no somente o texto selecionado copiado para o mtodo, mas todo cdigo, na classe, igual ao selecionado, trocado pela chamada do novo mtodo. Tambm por possurem essas funcionalidades, decidimos fazer uso dessa IDE. Nas sees a seguir, iremos explicar melhor o MVC, Struts 1, Junit, alm da estrutura do blog em Java. 3.2 Padro Model-View-Controller Diversos problemas podem existir quando softwares so desenvolvidos sem uma preocupao quanto a sua arquitetura e estrutura. Os cdigos produzidos, em geral, apresentam uma mistura entre regras de negcios, acesso a dados e apresentao. Isso torna a manutenibilidade do software muito difcil pois, alm de serem difceis de entender, uma alterao em um trecho de cdigo pode causar problemas em diversas reas do software, devido a este alto acoplamento. Alm
33
disso, o reuso de uma classe se torna muito difcil, praticamente impossvel, devido ao alto grau de dependncia dessa classe com outras. Para resolver esse problema, foi criado o padro Model-View-Controller (MVC) (SUN, 2006k) para promover esse desacoplamento. O MVC busca promover esse desacoplamento, separando o modelo de negcio, a interface com o usurio e a lgica de controle em camadas distintas fazendo, assim, com que alteraes em uma dessas camadas afetem o mnimo possvel as demais camadas. Os trs componentes da arquitetura MVC so:
Modelo (Model) - Esse componente responsvel pelo modelo de dados bem como a regras de negcios que governam o acesso e atualizaes desses dados.
Vista (View) - Essa a camada responsvel pela interface com o usurio, ou seja, tudo o que o usurio v e usa para interagir com a aplicao. Em aplicaes web, que geralmente utilizam MVC, essa camada seria composta por pginas HTML5 e JSP 6, por exemplo.
Controle (Controller) O controlador responsvel por fazer a conexo entre a camada de vista e de modelo, ou seja, ele quem instancia os objetos, de acordo com a solicitao da camada de vista, pede os dados ao modelo e devolve para a vista as informaes. Ele decide para onde a aplicao deve ir, de acordo com as solicitaes dos usurios e as informaes obtidas do modelo.
HTML(HTML, 1995) do ingls HyperText Markup Language, que significa Linguagem de Marcao de Hipertexto) uma linguagem de marcao utilizada para produzir pginas na Web. Documentos HTML podem ser interpretados por navegadores. 6 JSP (SUN, 2006a) uma tecnologia baseada na linguagem de programao JAVA e que permite aos desenvolvedores gerar dinmicamente arquivos HTML, XML ou outros tipos de documentos em resposta a uma requisio do cliente web.
34
Em geral, temos muitas alteraes na camada de vista sem que essa deva impactar nas demais. Isso aumenta a importncia da separao da camada de vista das outras, mostrando assim o valor do MVC. Com o MVC, tambm podemos ter diversas implementaes de vista para uma mesma aplicao. 3.3 MVC Model 2 Recentemente, a aplicao de arquiteturas MVC tem sido objeto de interesse no desenvolvimento de aplicaes web. O MVC, no contexto desse tipo de aplicao, chamado de arquitetura Model 2 (SESHADRI, 2006) nos BluePrints7 da Sun para o Java Enterprise Edition (Java EE) 8. Em aplicaes que utilizam Model 2, as requisies (requests) so passadas para o controlador, implementado como um servlet9. O controlador recebe a requisio, verifica quais os objetos necessrios para process-la, instancia esses objetos, faz chamadas de mtodos do modelo e ento decide para qual vista ele deve retornar enviando a resposta (response) para o servidor de aplicao. A ento esse objeto entregue ao browser do cliente. Esse comportamento est representado na figura abaixo:
Java BluePrints (SUN, 2006b) so melhores prticas definidas pela Sun para o desenvolvimento na plataforma Java EE. 8 Java Enterprise Edition (SUN, 2006a) a tecnologia Java para aplicaes corporativas que podem estar na internet ou no. Possui um grande nmero de APIs onde a segurana a principal preocupao. ideal para a construo de servidores de aplicao, integrao de sistemas ou distribuio de servios para terceiros. 9 Servlet (SUN, 2006j) uma API que permite adicionar contedo dinmico a um web server. O contedo gerado geralmente HTML, mas pode ser outros tais como XML. Poode manter o estado usando cookies do HTTP, variveis de sesso entre outras.
7
35
Figura 5 - Arquitetura Model 2 (MAHMOUD, 2006)
O Model 2 melhora a arquitetura de um software pois separa bem as trs camadas, promovendo um desacoplamento entre elas ao mesmo tempo em que garante a integrao destas. Os servlets ficam responsveis pelo controle do fluxo das aplicaes, enquanto os JSPs ficam responsveis somente por reter os dados inseridos pelos usurios e apresentar os dados dinmicos gerados pelos Servlets. Tirando assim melhor proveito de cada uma das tecnologias. 3.4 Struts 1 O Struts (APACHE, 2006 d) um framework10 open-source em Java, que auxilia o desenvolvimento de pginas web em Java que seguem MVC Model 2. O Struts foi criado em 2000 por Craig R. McClanahan como parte do projeto Jakarta da Apache e desde ento vem sendo melhorado pela comunidade open-source. A escolha da utilizao de Struts, no desenvolvimento do blog, se deve ao fato desse framework ser amplamente utilizado no mercado. Tanto, que se tornou um padro de fato (APACHE, 2006 d). Apesar de hoje j existir o Struts 2, a primeira verso deste foi utilizada, uma vez que no incio do projeto no conhecamos a nova verso e, portanto, no tnhamos informaes quanto a sua estabilidade.
10
Framework uma aplicao semicompleta e reutilizvel que pode ser especializada para produzir aplicaes customizadas.
36
O Struts consiste em uma camada de controle que se integra com diversas tecnologias, tanto na camada de modelo, como JDBC11, EJB e Hibernate12, quanto na camada de vista, como JSP entre outras. O controlador serve de ponte entre a camada de modelo e a interface. O Struts possui sua prpria classe de controle, a Action. Cada requisio da camada de vista possui uma Action especfica, responsvel pelo controle da requisio. Para facilitar a transferncia de dados entre a camada de vista e de controle, o Struts possui uma classe chamada ActionForm, que capta as informaes colocadas no formulrio na camada de vista, colocando-as em um objeto disponvel na camada de controle. Esta classe tambm faz o papel inverso, ou seja, obtm as informaes na camada de modelo e preenche os formulrios com essas informaes. A figura 6 apresenta os componentes da implementao da arquitetura Model 2 pelo Struts e a interao entre os mesmos.
Figura 6 - Componentes da implementao da arquitetura Model 2 pelo Struts e suas interaes (CAVANESS, 2005).
O JDBC uma API padro para a conexo independente entre a lnguagem de programao Java e uma grande escala de bases de dados. 12 Hibernate um framework de acesso a banco de dados escrito em Java que permite desenvolver as classes persistentes, permitindo associao, herana, polimorfismo, composio e colees atravs do mapeamento entre o modelo relacional e o orientado a objetos.
11
37
Uma das vantagens do uso do struts, no desenvolvimento de pginas web, a possibilidade da reutilizao das Actions e dos ActionForms. Para isso, preciso tomar o cuidado de no se colocar lgica de negcio nas actions, evitando-se assim um acoplamento entre as actions e demais classes. Sendo o reuso uma das principais prticas do XP, a utilizao do Struts se mostrou bastante aconselhvel. Arquitetura Para utilizao do struts com a arquitetura Model 2, temos a seguinte estrutura: Controlador O Struts fica responsvel pela camada de controle. ele quem recebe as requisies da camada de vista, instancia os objetos necessrios, faz a chamada de mtodos da camada de modelo, recebe as informaes e seleciona o componente de vista que dever receber essas informaes e, ento, as repassa ao componente escolhido. O principal componente do framework o Servlet, configurado pela classe ActionServlet, que mapeado para as Actions por um conjunto de ActionMappings. So as Actions que faro o papel do controlador, ou seja, que iro fazer as chamadas aos mtodos das classes de modelo e trocar informaes com a camada de vista, provendo, assim, total desacoplamento entre estas. Modelo O Struts no apresenta nenhuma caracterstica especial em relao camada de modelo mas, no entanto, capaz de se integrar com diversas tecnologias utilizadas nesta camada, desde tecnologias padres como EJB e JDBC como outras, tais como Hibernate, iBATIS (APACHE, 2006a) e Object Relational Bridge (OJB) (APACHE, 2006b). A camada de modelo pode, e , comumente, dividida em duas: uma que contm a lgica de negcio, que pode ser classes Java
38
simples ou SessionsBeans13, e outra responsvel pela persistncia de dados, que contem um conjunto de classes que representam o estado interno da aplicao, os Beans14, e as classes responsveis pela a persistncia desses estados, como os DAOs15. Vista Aplicaes desenvolvidas com o Struts geralmente fazem uso das Java Server Pages (JSPs). Essas JSPs contm um conjunto de tags padro que implementam funcionalidades bsicas, utilizadas em pginas web para incluso de contedo dinmico, evitando-se a incluso de cdigo na camada de vista. O Struts tambm possui um conjunto de tags que auxiliam a integrao da camada de vista com a camada de controle, atravs das classes de ActionForm. Apesar de ser muito utilizado com JSP, o Struts no restringe seu uso utilizao de JSPs. Ele tambm pode ser utilizado com outras tecnologias empregadas na camada de vista, como Java Server Faces (JSFs) e XSLT16. Configurao Para que as aplicaes web desenvolvidas com o Struts funcionem, preciso fazer a configurao do framework atravs de dois arquivos, um o arquivo utilizado por todas as aplicaes web que utilizam Java Servlet, que o Web Application Deployment Descriptor, chamado de web.xml, utilizado para inicializar recursos como tag libs e servlets. E o segundo arquivo de configurao especfico do struts, geralmente chamado de struts-config.xml, que utilizado para inicializar recursos especficos do struts que so os ActionForms, utilizados para capturar e enviar
13Session Beans (SUN, 2006h) representam um nico cliente dentro do usurio de J2EE. O session bean executa o trabalho para seu cliente, protegendo o cliente da complexidade executando tarefas do negcio dentro do usurio. 14 JavaBeans so programas reusveis que podem ser desenvolvidos facilmente para criar aplicaes sofisticadas. 15 Data Access Object (SUN, 2006i) uma classe que fornece uma relao comum entre a aplicao e um ou mais dispositivos do armazenamento de dados, tais como um banco de dados ou um arquivo. 16 XSLT uma linguagem baseada no XML para transformar arquivos XML em outros arquivos XML. XSLT projetado para o uso como parte de XSL, que uma lngua de style sheet para XML. XSL especifica o estilo de um arquivo XML usando XSLT para descrever como o documento ser transformado em outro arquivo XML. http://www.w3.org/TR/xslt
39
dados para as interfaces, os ActionMappings, que fazem o mapeamento das urls para as actions especficas, e os ActionForwards que so usadas para selecionar a pgina de sada adequada. A seguir, temos um exemplo de um trecho de um arquivo struts-config.xml:
<?xml version="1.0" encoding="ISO-8859-1" ?> <!DOCTYPE struts-config PUBLIC "-//Apache Software Foundation//DTD Struts Configuration 1.2//EN" "http://jakarta.apache.org/struts/dtds/struts-config_1_2.dtd"> <struts-config>   <forward name="welcome" path="principal.do"/> </global-forwards>
<!-- =========================================== Action Mapping Definitions -> <action-mappings> <action
40
path="/principal" type="struts.PrincipalAction" scope="request"> <exception key="error.exception.erroListagem" type="exception.ErroListagemException" path="/pages/erroListagem.jsp"/> <forward name="Principal" path="/pages/principal.jsp"/> </action>
Nesse trecho de exemplo temos as definies dos ActionForms, do mapeamento de excees global, do mapeamento de forwards global utilizado para o mapeamento da action inicial, e o mapeamento de uma action, a principal. Benefcios do Struts O Struts no o nico framework para a camada de controle no desenvolvimento de pginas web. No entanto, ele apresenta alguns benefcios chaves (CAVANESS, 2005): baseado na arquitetura Model 2; Suporta a filosofia Java Write Once, Run Anywhere; Suporta diferentes implementaes para o Modelo (JavaBeans, EJB, Hibernate, etc.); Suporte internacionalizao (I18N); Contm um rico conjunto de bibliotecas de tag; Possui diversos pontos de extenso para customizao do framework; Suporta diferentes implementaes para a Vista (JSP, XML/XSLT, JavaServer Faces, etc.). Alm disso, segundo Cavaness (2005), o Struts: Tornou-se um padro de fato no mercado; um framework estvel e maduro; open-source e mantido por experientes desenvolvedores do Apache Group;
41
Integra-se facilmente com os principais ambientes de desenvolvimento integrado do mercado;
Possui uma vasta documentao disponvel;
Possibilita um grande ganho de produtividade, uma vez que prov a infraestrutura bsica para o desenvolvimento de aplicaes web baseadas na arquitetura Model 2. 3.5 JUnit Para fazermos uso de prticas como desenvolvimento orientado a testes, integrao contnua e cdigo coletivo, precisamos de uma boa ferramenta de testes. Para isso, fizemos uso de um framework, amplamente utilizado na comunidade Java, o JUnit. O JUnit um framework de cdigo aberto desenvolvido em Java, por Erich Gamma e Kent Beck, para a construo de testes unitrios para classes Java (COHEN, 2004, traduo nossa). Conforme j dissemos anteriormente, este framework bastante popular na comunidade Java. Porm, no popular somente entre os desenvolvedores, mas tambm em equipes responsveis pela qualidade de software. Devido a essa popularidade e nosso conhecimento anterior do framework, e por esse se encaixar muito bem no desenvolvimento orientado a testes, resolvemos utiliz-lo para a criao dos nossos testes no desenvolvimento do blog em Java. No XP, assim como em outras metodologias geis, o desenvolvimento orientado a testes importante. To importante que, cdigos que no foram testados e aprovados, no devem ser adicionados ao repositrio por motivos j vistos quando explicamos a metodologia XP. Para garantir que essa prtica seja adotada, o JUnit implementa um framework para construo de testes que rodam, automaticamente, toda vez que o cdigo modificado.
42
Antes do Junit, existiram diversas tentativas de se construir frameworks bem entendidos e largamente utilizados para testar mdulos de software. Kent Beck anteriormente trabalhou no desenvolvimento de um framework de teste unitrio em Smalltalk que inspirou a forma como os frameworks de teste unitrio funcionam em Java17, Pythoon18 e em .Net 19(COHEN, 2004, traduo nossa). Segundo COHEN, um framework de teste unitrios tem um conjunto conciso de objetivos que so: 1. Tornar os testes familiares de serem usados. Os desenvolvedores de softwares desenvolvem seus testes junto com todas as suas outras atividades. Por isso, o framework deve apresentar um conjunto de ferramentas que requeiram o mnimo de trabalho dos desenvolvedores quando estes esto escrevendo seus testes. 2. Fazer com que os testes perdurem por muito tempo. Testar uma nova verso do software nos diz que ele est funcionando agora. Mas isso no garante que este mesmo mdulo continuar funcionando amanh, daqui h uma semana ou cinco anos. Os testes unitrios precisam continuar funcionando ao longo do tempo. mais do que esperado que outra pessoa, que no a desenvolvedora original, ir usar o teste unitrio no futuro. Ento, o framework de teste unitrio deve garantir que os testes unitrios mantenham seu valor ao longo do tempo. 3. Tornar fcil especializar testes existentes. Escrever novos testes custa tempo e esforo. O framework deve tornar fcil reusar testes existentes.
17 18
http://www.junit.org http://www.pyunit.sourceforge.net/pyunit.html 19 http://sourceforge.net/projects/nunit/
43
O JUnit pode ser integrado com Ant20 de forma que, sempre que o cdigo for compilado, os teste sejam executados, fazendo com que os testes sejam eficientes e transparentes aos desenvolvedores, uma vez que eles passam a fazer parte de mais uma etapa da compilao do cdigo. Alm disso, os testes do JUnit podem ser rodados a qualquer momento durante o desenvolvimento, sem que seja necessariamente na compilao. Para atingir esses objetivos, o JUnit implementa um conceito simples, o TestCase. Ele implementa trs mtodos: o setUp, que configura o sistema antes dos testes, o runTest, que roda os testes e o tearDown, que responsvel pela limpeza do sistema aps os testes. O TestCase implementa mtodos que rodam mdulos do sistema e verificam se este est retornando o dados esperado. O TestCase implementa mtodos para receber as excees disparadas pelos mdulos e para gravar os resultados dos testes para que possam ser analisados posteriormente. Podemos reunir vrios TestCases em um TestSuite que ser responsvel por rodar todos os TestCases de um s vez. Se todos os testes passarem o JUnit informa que todos os testes foram bem sucedidos. Caso contrrio, o JUnit dispara uma exceo e informa qual teste falhou. 3.6 Estrutura do Blog Fazendo uso de todas essas tecnologias citadas anteriormente,
desenvolvemos o nosso blog em Java com a seguinte estrutura de pacotes:
config Pacote onde foi armazenado o arquivo de configurao para conexo com o banco de dados.
20
Ant Ferramenta de automao do processo de construo de sistemas, como um makefile, baseada em Java. http://ant.apache.org.
44
dao Pacote que armazena as classes de acesso ao banco de dados. Possui trs classes, ComentarioDAOMysql, TopicoDAOMysql,
UsuarioDAOMysql. Cada uma dessas classes possui os mtodos necessrios para obteno e insero de informaes no banco de dados. db Pacote que possui a classe responsvel pela conexo ao banco de dados. nessa classe que utilizamos o arquivo armazenado no pacote config. exception Armazena as classes de exceo. modelo Contm as classes bsicas dos objetos desse blog, que so o Usuario, Topico e Comentario. struts Contm as Actions e ActionForms do blog. util Pacote onde armazenada a classe utilitria do sistema, que a FormataData, responsvel pela a formatao de datas.
Os pacotes config, dao, db, exception, modelo e til formam a camada de modelo. A camada de controle formada pelo pacote Struts. J a camada de vista, formada pelas pastas pages, js e images, onde ficam armazenados os JSPs, arquivo de JavaScript 21, arquivo de CSS22 e as imagens das pginas web.
3.7 Funcionamento do Blog O nosso blog funciona basicamente como todo blog. Nele, qualquer usurio pode ler e comentar os tpicos que so exibidos na pgina inicial. Para comentar um tpico, o usurio precisa entrar no link de comentrios do tpico desejado e ento,
21
Javascript (FLANAGAN, 2006) uma linguagem de programao interpretada com capacidade de orientao a objetos e utilizada principalmente no lado do cliente tornando as pginas web dinmicas e interativas. 22 CSS (CSS, 2007) um mecanismo simples para mudar o formato de documentos web (por exemplo textos, cores, espaamentos) normalmente escritos em uma linguagem de marcao, como HTML ou XML.
45
na pgina onde so mostrados os comentrios relacionados a esse tpico, inserir o seu comentrio no formulrio apresentado nesta mesma pgina. Somente o proprietrio do blog poder inserir um novo tpico. Para isso, ele precisa se logar no sistema, a partir do formulrio apresentado na pgina inicial, informando login e senha. Uma vez logado, o usurio deve entrar no link Inserir novo tpico, que trar uma pgina com o formulrio a ser preenchido para a insero desse tpico. 3.8 Consideraes Seguindo a estrutura acima e utilizando as tecnologias citadas nas sees anteriores, construmos o nosso blog. Encontramos alguns problemas para configurar o ambiente de desenvolvimento como, por exemplo, a configurao do struts e fazer com que os testes desenvolvidos no JUnit funcionassem. Porm, a partir do momento em que o ambiente estava configurado e funcionando bem, no encontramos maiores problemas no desenvolvimento deste blog. Quanto s prticas de XP, encontramos ferramentas que auxiliaram no desenvolvimento de testes, inclusive no desenvolvimento orientado a testes, importante para a utilizao de algumas prticas do XP, como cdigo coletivo e integrao contnua. Atravs da IDE utilizada (Eclipse), tivemos acesso a ferramentas que auxiliaram na prtica de refatorao.
46
4 Blog em Ruby
4.1 Introduo Nesse captulo iremos apresentar a arquitetura utilizada para o
desenvolvimento do blog em Ruby, bem como a sua estrutura. Para o desenvolvimento do blog em Ruby, utilizamos o framework Ruby on Rails. Ruby uma linguagem de programao orientada a objetos criada por Yukihiro "Matz" Matsumoto que comeou o seu desenvolvimento em 1993 e teve a primeira verso divulgada em 1995. Nesta linguagem os programadores podem expressar suas idias de maneira simples e clara (THOMAS, HANSSON, 2005). Essa caracterstica torna os cdigos em Ruby fceis de serem escritos e, o mais importante, de serem lidos posteriormente, pois parecem textos escritos em ingls. A linguagem permite, facilmente, a criao de mtodos que parecem extenso da sintaxe, o que torna os cdigos menores e mais legveis. Em Ruby tudo objeto, no existem tipos simples como no Java. Ruby uma linguagem de script, dinamicamente tipada, o que torna a refatorao do seu cdigo mais difcil. 4.2 Ruby on Rails Para criao do blog em Ruby, utilizamos o framework Ruby on Rails, um framework para desenvolvimento de aplicaes web. Esse framework tambm utiliza o padro MVC, apresentado no capitulo anterior, para desenvolvimento das aplicaes. O Rails apresenta uma srie de scripts para gerao de cdigos e o primeiro que deve ser rodado o script, que gera uma aplicao em Rails. Esse script prepara todo o esqueleto da aplicao.
47
Depois de rodar esse script, o programador j tem um lugar preparado para colocar os seus cdigos. Assim, o programador s tem que se preocupar com a lgica da aplicao. Rails baseado em duas filosofias. A primeira conhecida como DRY, do ingls Dont Repeat Yourself, que significa no se repita. Essa filosofia diz que cada trecho de conhecimento de um sistema deve ser expresso em um nico lugar. O Rails usa o poder do Ruby para tornar isso realidade. Por causa disso, encontramos pouqussima duplicao nas aplicaes desenvolvidas em Rails. O programador escreve um trecho de cdigo em um lugar sugerido pelas convenes do padro MVC e depois segue em frente. A segunda filosofia a da conveno no lugar de configurao (convention over configuration). Isso significa que o Rails possui padres de nomenclatura e localizao de arquivos que, quando seguidos, fazem com que a aplicao funcione sem a necessidade de configuraes adicionais, diminuindo assim a complexidade das aplicaes e tornando os cdigos menores. Esses padres tambm podem ser customizados em caso de necessidade. O Rails possui um conjunto de tecnologias integradas no framework, como suporte a web service23, AJAX24, um framework de testes unitrios completo com suporte ao uso de mock objects25 de forma transparente, e possvel criar ambientes de desenvolvimento, testes e produo isolados. Dave Thomas, em seu livro Agile Web Development with Rails, apresenta dez razes para gostar do Rails:
23
Segundo a W3C web service um sistema de software projetado para permitir a interao entre mquinas atravs de uma rede. http://www.w3.org/TR/ws-arch/ 24 Ajax um acrnimo do termo em ingls Asynchronous Javascript And XML, o uso sistemtico de Javascript e XML, para tornar o navegador mais interativo utilizando-se de solicitaes assncronas de informaes. http://developer.mozilla.org/en/docs/AJAX:Getting_Started 25 Mock objects so usados na programao orientada a objetos para simular o comportamento de algum objeto especifico nos testes de um segundo objeto. http://www.mockobjects.com/
48
a) Este traz agilidade para o desenvolvimento web. b) possvel criar aplicaes web com bons efeitos. c) Rails permite que o desenvolvedor mantenha o foco na criao da aplicao, e no em alimentar o framework. d) As aplicaes se mantm manutenveis medida que crescem. e) possvel dizer Sim para os clientes com mais freqncia. f) Testes so integrados e fceis de serem construdos, por isso so usados. g) O feedback instantneo: edite o cdigo e clique em atualizar e a mudana j estar no navegador. h) Meta-programao significar que se pode programar realmente em alto nvel. i) Geradores de cdigos permitem iniciar a programao rapidamente. j) No se utiliza XML para configuraes.
O Rails um framework altamente integrado, no s com XP, mas com todas as metodologias de desenvolvimento gil. Isso porque o Rails foi desenvolvido seguindo os valores do manifesto gil, apresentados no capitulo 2, mesmos valores que so a base de todas as metodologias de desenvolvimento gil. Rails estimula o uso de iteraes, uma vez que os cdigos so produzidos rapidamente, fazendo com que os usurios obtenham retorno do que est sendo produzido, encorajando, assim, a contribuio dos clientes. Por causa do principio DRY, as mudanas no escopo no so evitadas, j que as alteraes nos cdigos se tornam pontuais e por estarem garantidas por um conjunto de testes, que so desenvolvidos sem muito esforo. Rails no renuncia o uso de documentao. Pelo contrrio, trivial criar
49
documentao HTML para todo cdigo da aplicao, mas isso no significa que o desenvolvimento em Rails orientado por documentao. Arquitetura do Rails Nesta seo iremos descrever a arquitetura do Rails. Como j mencionamos anteriormente, o rails um framework de desenvolvimento web baseado no padro MVC. Ele gera uma estrutura para o desenvolvimento de aplicaes web, onde o desenvolvedor produz os modelos, as interfaces e os controladores como um conjunto de funcionalidades separados, cada um no seu lugar especfico, e atravs da conveno de nomenclatura ele integra todo esse conjunto quando a aplicao executada. Em aplicaes desenvolvidas em Rails, as requisies so primeiro enviadas para um roteador que decide para onde, na aplicao, deve ser enviada e como ela deve ser quebrada. Por ltimo, essa fase identifica um mtodo especfico, chamado de Action no Rails, em algum lugar no cdigo do controlador. A action ento deve olhar para os dados da requisio, interagir com a camada de modelo, e ento invocar outras actions ou pode preparar informao para ser entregue para a camada de vista, que ento apresenta essas informaes para os usurios. Na figura a seguir temos o comportamento do Rails para o recebimento de uma chamada. Esta chamada apresenta a URL http://my.url/store/add_to_cart/123, nesta URL, atravs das convenes de nomenclatura identifica que a requisio deve ser processada pelo mtodo add_to_cart do controlador store. O valor 123 identificado como o id do produto a ser adicionado ao carrinho.
50
Figura 7 - MVC no Rails (THOMAS, HANSSON, 2005)
A utilizao do padro MVC no Rails vai alm da montagem da arquitetura para a aplicao. O Rails possui um conjunto de padres que do suporte as trs camadas. Na camada de modelo, o Rails utiliza o ORM (Object/Relational Mapping), que o mapeamento das classes de objetos para as tabelas de banco de dados. Esse padro utilizado por outros frameworks para outras linguagens. O que diferencia o Rails dos outros frameworks, o fato de que o Rails no utiliza nenhum arquivo de configurao para estabelecer esse relacionamento. Ele utiliza Active Record, que o ORM suportado pelo Rails, que realiza o mapeamento atravs de suas convenes, alm de possuir alguns padres iniciais. O uso do Active Record facilita muito o desenvolvimento, visto que o mapeamento realizado por arquivos de configuraes, so, por muitas vezes, complexos, grandes e precisam ser alterados sempre que acontecer uma modificao no objeto. Com isso, projetos em Rails tm a sua manuteno simplificada. Nas camadas de controle e vista, o framework possui um nico componente de suporte. Isso se deve ao fato de que essas duas camadas esto estritamente ligadas, uma vez que o controlador responsvel por gerar as informaes que sero apresentadas na camada de vista e recebe desta os eventos de respostas das pginas web. Apesar do Rails fazer uso de apenas um componente para as duas
51
camadas, no significa que os cdigos para essas sero misturados ou guardados em um nico lugar. Pelo contrrio, os cdigos so bem divididos e esse componente que fica responsvel pelo transporte das informaes entre as duas de maneira simples. No Rails, a camada de vista responsvel pela criao de toda ou parte da pgina a ser exibida no navegador. Muitas vezes essas pginas apresentam contedo dinmico. O Rails possui duas formas de incluso desses contedos nas pginas: uma a utilizao de cdigo Ruby, embutido nas pginas HTML atravs de tags especficas do Rails, e a outra atravs de builder-style views, onde so usados arquivos XML, com cdigo em Ruby. O controlador no Rails o centro lgico de sua aplicao. Ele o responsvel pela interao entre o usurio, a camada de vista e a camada do modelo. Muitas dessas interaes so transparentes ao desenvolvedor, pois so feitas atravs das convenes do framework, possibilitando que o desenvolvedor se concentre nas funcionalidades, no nvel da aplicao, o que torna os cdigo muito simples, fceis de serem desenvolvidos e de sofrerem manuteno. O controlador , tambm, o lugar de um nmero de servios importantes. (THOMAS, HANSSON, 2005): responsvel pelo roteamento de requisies externas para aes internas. Isso sustenta URLs amigveis aos usurios. Gerencia o cache, que pode dar um ganho de performance de aplicaes com grande nmero de requisies. Gerencia mdulos de ajuda, que estendem as capacidades dos templates da camada de vista sem dificultar os seus cdigos.
52
Gerencia as sesses, dando aos usurios a impresso de uma interao contnua com as aplicaes.
4.3 Migration Nesta seo iremos apresentar mais uma classe do Rails, para a qual dedicamos uma seo por entendermos que esta apresenta funcionalidades que merecem ser destacadas. No desenvolvimento de software raro elaborar um modelo de dados no incio do projeto que ser utilizado durante todo o desenvolvimento da aplicao sem que este sofra alteraes. Em geral, os modelos so alterados diversas vezes durante o processo e essas mudanas se tornam mais constantes quando utilizamos alguma metodologia de desenvolvimento gil, como o XP, j que um dos pensamentos dessas metodologia faa somente aquilo o que for necessrio agora. Logo, os modelos de dados no so construdos como um todo no incio do desenvolvimento, so incrementados no decorrer do projeto. Mudanas de modelos, algumas vezes, se mostram problemticas. E quando isso acontece, consomem muito tempo e recursos. Deste modo, por muitas vezes, alteraes de modelos que se mostram interessantes no so feitas pelo medo de que se tornem muito custosas e, com isso, temos uma queda na qualidade dos softwares, j que no pudemos usufruir dos benefcios que essas mudanas trariam. Como j dissemos anteriormente, o Rails foi desenvolvido baseado no pensamento do desenvolvimento gil. Sendo assim, alteraes de modelos eram mais que esperadas quando este foi desenvolvido. Com essa expectativa em mente, os desenvolvedores do Rails construram uma classe para tornar esse processo menos custoso que chamaram de Migration.
53
Assim, mudanas de modelos, no Rails, passam a ser feitas atravs de classes escritas em Ruby que estendem ActiveRecord::Migration. Essas classes possuem dois mtodos: up e down. O primeiro contm o cdigo que deve ser executado quando estamos avanando a verso do Migration (iremos explicar o que significa avanar e voltar verses do Migration, mais frente, nessa seo). O segundo mtodo apresenta o cdigo que deve ser executado quando estamos voltando a verso do Migration. O Rails possui um arquivo, o schema.rb, que contm a descrio do esquema de banco de dados escrito em Ruby. Quando uma Migration realizada, esse arquivo atualizado com a nova verso do esquema do banco de dados e, nele, guardado o numero da verso. Os arquivos que possuem a definio de uma migrao possuem em seu nome, por conveno, o nmero da verso de migrao pela qual so responsveis. com o nmero dos arquivos de definio de uma migrao e com o nmero da verso atual do banco de dados, armazenado no arquivo que contm a definio do esquema de banco de dados, que o Migration realiza as alteraes de verso do banco de dados para uma verso mais nova, com um nmero maior que o atual, ou para uma verso anterior, com um nmero menor, que foi o que chamamos, anteriormente, de avano e volta de verso respectivamente. O Migration no possui suporte a todas as alteraes possveis em um banco de dados, porm, possui para aquelas que so mais comuns de ocorrerem. Para essas alteraes, temos um conjunto de instrues que so: create_table(name, options) - Esta instruo responsvel pela criao de uma tabela com nome passado no parmetro name. No parmetro options so passados valore como "DEFAULT CHARSET=UTF-8" que podem ser
54
utilizados na definio no script de criao da tabela. Essa instruo tambm responsvel pela criao de um bloco de tabela, onde podem ser inseridas as colunas dessa tabela. drop_table (name) Instruo utilizada para a remoo da tabela passada no parmetro name. rename_table (old_name, new_name) Instruo utilizada para renomear uma tabela, onde o nome atual da tabela passado no old_name e o novo nome no new_name. add_column (table_name, column_name, type, options) - Adiciona uma coluna, com nome passado no parmetro column_name, tabela com o nome passado no parmetro table_name. Essa coluna do tipo (type) que pode ser: :string, :text, :integer, :float, :decimal, :datetime, :timestamp, :time, :date, :binary, :boolean. O parmetro options usado para configuraes da coluna como valor padro (:default). rename_column (table_name, column_name, new_column_name)
Renomeia a coluna (column_name) da tabela (table_name) colocando o novo nome (new_column_name). O tipo da coluna e o contedo so mantidos. remove_column (table_name, column_name) Remove a coluna
(column_name) da tabela (table_name). add_index (table_name, column_name, index_type, index_name) Adiciona um ndice coluna (column_name) da tabela (table_name) do tipo (index_type) com o nome da coluna ou com o nome em index_name. O tipo do ndice opcional.
55
remove_index
(table_name,
index_name)
Remove
ndice
(index_name) da tabela (table_name).
Alm das instrues, esses arquivos de definio de uma migrao tambm podem possuir cdigo em Ruby, como Tag.find(:all).each { |tag| tag.destroy if tag.pages.empty? }. Esse cdigo serve tambm para ilustrar que, nem sempre, um arquivo de migrao de banco de dados realiza uma mudana no esquema do banco de dados, e sim nos dados nele armazenados. Esse cdigo retira do banco todas as tags cujo atributo pages vazio. Quando queremos fazer alguma mudana no banco de dados que o Migration no d suporte, devemos fazer diretamente no banco de dados. O Migration tambm nos possibilita a execuo de comandos SQL atravs da instruo execute, como no exemplo:
class MakeJoinUnique < ActiveRecord::Migration def self.up execute "ALTER TABLE `pages_linked_pages` ADD UNIQUE
`page_id_linked_page_id` (`page_id`,`linked_page_id`)" end
def self.down execute "ALTER TABLE `pages_linked_pages` DROP INDEX
`page_id_linked_page_id`" end end
Para executar uma Migration nova, primeiro devemos rodar o script de gerao de migrao (script/generate migration NomeDaMinhaMigrao), onde gerado um arquivo de migrao com o nome igual a
nnn_nome_da_minha_migracao, onde nnn o prximo nmero maior que o maior nmero de migrao existente. Esse arquivo gerado, por conveno, no diretrio db/migrate. Depois que alterarmos os mtodos up e down, com as alteraes que
56
queremos realizar no banco de dados, devemos rodar o comando rake db:migrate, que ir atualizar o banco de dados, executando todos os mtodos up dos arquivos de migrao com nmero entre o nmero do esquema de banco de dados atual e o nmero que acabamos de criar. Caso estivssemos querendo mudar a verso do banco de dados para uma verso especfica, maior ou menor, bastava rodar o comand rake db:migrate VERSION = X, onde X o nmero da verso que queremos colocar no ar. Esse comando ir executar, assim como no caso anterior, todos os mtodos up, se X > que valor atual, ou down, se X < que o valor atua, dos arquivos entre X e o valor da verso atual do esquema. Outra caracterstica importante do Migration, que devemos ressaltar, o fato de ele manter os valores armazenados no banco de dados quando realiza uma alterao, isto , se temos uma tabela populada e adicionamos uma coluna a ela, ou retiramos uma coluna dela, os valores armazenados nas demais colunas sero mantidos evitando-se, assim, que dados utilizados para testes tenham que ser reinseridos. No caso da incluso de uma nova coluna, podemos inserir valores em suas linhas, no prprio arquivo de Migration, como no exemplo abaixo:
class AddPeopleSalary < ActiveRecord::Migration def self.up add_column :people, :salary, :integer Person.reset_column_information Person.find(:all).each do |p| p.update_attribute :salary, SalaryCalculator.compute(p) end end end
A seguir, iremos apresentar o arquivo do esquema de banco de dados do blog em Ruby e um dos arquivos de migrao usados:
ActiveRecord::Schema.define(:version => 4) do
57
create_table "comentarios", :force => true do |t| t.column "mensagem", :text t.column "topico_id", :integer t.column "autor_comentario", :string t.column "data_postagem", :datetime, :default => now() end create_table "topicos", :force => true do |t| t.column "titulo", :string t.column "descricao", :text t.column "data_postagem", :datetime t.column "nome_autor", :string t.column "comentarios_count", :integer, :default => 0 end create_table "usuarios", :force => true do |t| t.column "login", :string t.column "senha", :string end end
Arquivo de definio do esquema do blog Ruby - schema.rb
class AdicionandoAutorComentario < ActiveRecord::Migration def self.up add_column "comentarios", "autor_comentario", :string add_column "comentarios", "data_postagem", :datetime Comentario.update_all "autor_comentario = 'Anonimo'" Comentario.update_all "data_postagem = '2006-12-17'" end
def self.down remove_column "comentarios", "autor_comentario" remove_column "comentarios", "data_postagem" end end
Arquivo de migrao para adio do autor do comentrio e a data da postagem do comentrio. 003_adicionando_autor_comentario.rb
4.4 Estrutura do Blog O blog desenvolvido, utilizando-se o Ruby on Rails, possui a estrutura padro das aplicaes desenvolvidas nesse framework. Utilizamos esse padro para
58
aproveitarmos as convenes do framework, sem que tivssemos que fazer nenhuma configurao extra. A seguir, iremos apresentar essa estrutura. app Este o diretrio onde ficam os principais arquivos da aplicao. Ele dividido em: o controllers Onde ficam os controladores da aplicao. a camada de controle na arquitetura do padro MVC; o models Onde ficam os modelos da aplicao. a camada de modelo na arquitetura do padro MVC; o views Contm as interfaces da aplicao. a camada de vista na arquitetura do padro MVC; o helpers Neste pacote ficam classes que estendem as funcionalidades dos templates da camada de vista. components Este diretrio contm os componentes da aplicao. Neste blog no criamos nenhum componente, mas o diretrio est presente, pois foi criado pelo script de gerao da aplicao. config Diretrio que armazena os arquivos de configurao da aplicao. Todos os arquivos que se encontram nesse diretrio foram criados pelos scripts de gerao de cdigo rodados ao longo do desenvolvimento. db Contm os arquivos relacionados a uso do banco de dados. Tambm contm um diretrio migrate, onde ficam os arquivos relacionados ao migration. doc Onde ficam armazenados os arquivos de documentao gerada automaticamente. lib Contm as bibliotecas de cdigos compartilhados.
59
log Arquivos de logs gerados quando a aplicao est sendo executada.
public Diretrio acessvel na web. Onde ficam armazenados os arquivos utilizados nas pginas, como arquivos de javascript e css.
script Onde ficam armazenados os arquivos de script de gerao de cdigo.
test Diretrio que armazena os testes da aplicao. vendor Similar ao diretrio lib, com a diferena que o lib foi criado para utilizao de cdigo externos a aplicao mas que foram gerados pelo desenvolvedor da aplicao ou pela empresa do desenvolvedor, enquanto o diretrio vendor contm cdigos desenvolvidos por outras empresas e que so utilizados na sua aplicao.
A figura abaixo retrata essa estrutura de diretrios apresentada acima.
Figura 8 - Estrutura de diretrios do Ruby on Rails
60
4.5 Funcionamento do Blog O Blog em Ruby possui um funcionamento muito similar ao do blog em Java. Neste blog, tambm, qualquer usurio pode ler os tpicos e comentrios. Todos podem adicionar novos comentrios aos tpicos mas somente o dono do blog pode adicionar um novo tpico. Para isso, ele precisa se logar no blog e, uma vez logado, ir aparecer um link para adio de um novo tpico. 4.6 Consideraes No desenvolvimento do blog, utilizandose o framework, no encontramos dificuldades no desenvolvimento da aplicao. Quanto s prticas de XP, tivemos muita facilidade para o desenvolvimento de testes, uma vez que o Rails possui um framework completo de desenvolvimento de testes completamente integrado. Tivemos o auxilio do Migration para a utilizao da prtica de integrao contnua. Porm, por ser uma linguagem dinmicamente tipada, a prtica de refatorao se tornou um pouco complicada.
61
Comparativo
5.1 Introduo Neste captulo iremos apresentar o resultado do nosso estudo. Nele,
apresentaremos o comparativo entre as linguagens de programao Java e Ruby, tomando como base as prticas do XP apresentadas no capitulo 2. Para algumas dessas prticas, iremos apresentar caractersticas das linguagens que podem ajudar ou dificultar a adoo. Apresentaremos, tambm, uma tabela com um resumo desse comparativo. Para elaborar esse comparativo, desenvolvemos um blog nas duas linguagens, que foram objetos de nosso estudo. Procuramos desenvolver os blogs com as mesmas funcionalidades e o mesmo funcionamento. Buscamos essa similaridade para que no fossemos influenciados, na nossa comparao, por dificuldades no desenvolvimento de funcionalidades existentes em um blog e no no outro. Os dois blogs tambm apresentam bases de dados similares, com mudanas somente em alguns nomes. Poderamos ter usado a mesma base de dados para as duas aplicaes, mas preferimos desenvolver as duas aplicaes do zero, como se no existisse outra, para que mais uma vez no tivssemos nossa comparao afetada por diferena no desenvolvimento. A seguir, segue a estrutura bsica da base de dados das aplicaes:
62
Figura 9 - Modelo de dados bsico dos blogs
A base de dados do blog em Ruby apresenta mais uma tabela a schema_info. Ela usada pelo Rails para o controle de verses do migration. Essa tabela gerada e atualizada pelos scripts de gerao do migration e de execuo de uma migrao. Sendo assim, essa tabela no afetou, em nada, o nvel de dificuldade do desenvolvimento, ficando transparente para o desenvolvedor.
5.2 Linhas de Cdigo

Nesta seo iremos apresentar uma tabela comparando o nmero de linha de cdigos dos dois blogs. Achamos importante mostrar esses nmeros, pois verificamos uma grande diferena.
Linguagem Java Ruby
Nmeros de linhas da aplicao Nmero de linhas de testes Nmero total de linhas. Relao entre linhas da aplicao x teste Linhas Arquivos de configurao
665 147 822 1 : 0.2 449
78 114 192 1 : 1.5 23
Tabela 1 Comparativo de linhas de cdigo.
63
Comparando esses nmeros, verificamos que o blog em Java possui 8,65 linhas de cdigo da aplicao para cada linha em Ruby, 1,29 linhas de testes para cada linha do Ruby e 19,52 linhas em arquivos de configurao para cada linha no Ruby. Com essas informaes, podemos ver que o desenvolvimento em Ruby tende a ser mais rpido e simples, uma vez que preciso escrever menos linhas de cdigo, menos linhas de testes e escrever menos em arquivos de configuraes. No entanto, devemos ressaltar que alguns arquivos de configurao e algumas linhas de cdigos podem ser geradas de forma automtica, reduzindo um pouco o esforo de desenvolvimento em Java. A seguir, apresentamos o trecho de cdigo, responsvel pela criao de tpicos, nas duas linguagens, para melhor ilustrar a diferena entre as mesmas. Java
public ActionForward execute(ActionMapping mapping, ActionForm form, HttpServletRequest request, HttpServletResponse response) Exception { TopicoForm topicoForm = (TopicoForm)form; Topico topico = new Topico();
throws
topico.setTitulo(topicoForm.getTitulo()); topico.setDescricao(topicoForm.getDescricao()); TopicoDAOMysql topicoDao = new TopicoDAOMysql(); try{ topicoDao.adiciona(topico); } catch(Exception e){ throw new Exception("Erro ao adicionar topico " +e); } ActionForward mapping.findForward("Cadastrado"); return forward; } forward =
public void adiciona (Topico topico) throws Exception{
Connection conn = null;
64
ConexaoBD conBD = ConexaoBD.getInstancia();
conn = conBD.getConnection();
PreparedStatement pstmt = null; String sql = ""; int rowsAfected = 0;
try { if (conn == null) throw new Exception("Conexo no foi estabelecida.");
sql = "insert into Topicos (" + " titulo, descricao, data_postagem) " + " values((?), (?), now())";
pstmt = conn.prepareStatement(sql);
pstmt.setString(1,topico.getTitulo()); pstmt.setString(2,topico.getDescricao());
rowsAfected = pstmt.executeUpdate();
if (rowsAfected <= 0) { throw new Exception("Erro na insero do tpico. Por favor, tente novamente."); } }catch(SQLException se) { throw new SQLException("Erro em
TopicoDAOMysql.adiciona(): " + se.getMessage()); }catch (Exception e) { throw new Exception("Erro em
TopicoDAOMysql.adiciona(): " + e.getMessage()); }finally { if(pstmt != null) pstmt.close(); conBD.returnConnection(conn); } }
65
Ruby on Rails
def create @topico = Topico.new(params[:topico]) if @topico.save flash[:notice] = 'Topico criado com sucesso.' redirect_to :action => 'list' else render :action => 'new' end end
5.3 Analisando as prticas Cliente Presente uma prtica que independe da linguagem utilizada, uma vez que se trata de uma prtica muito mais comportamental do que de desenvolvimento, porm, a linguagem pode servir de incentivo para sua utilizao, como acontece com Ruby on Rail,s em que as mudanas de cdigo so visualizadas rapidamente, por no precisar de compilao. Basta clicar e atualizar a pgina no navegador. Sendo assim, o cliente consegue perceber melhor a importncia da sua presena, j que consegue visualizar alteraes de maneira quase imediata. O mesmo no ocorre quando utilizamos o Java, pois uma mudana requer a compilao do cdigo e, s vezes, reinicializao do servidor de aplicao, o que pode demorar um pouco, dependendo do tamanho da aplicao. E muitas vezes no acertamos na primeira alterao de cdigo, o que implica em mais de uma compilao para a visualizao de uma alterao. Portanto, para essa prtica, o desenvolvimento com Ruby se mostrou mais eficiente e estimulante. Jogo do Planejamento Por se tratar de uma prtica aplicada no processo de levantamento de requisitos, no sofre influncia da
66
linguagem utilizada no posterior desenvolvimento. O que pode sofrer alguma influncia da linguagem utilizada a velocidade do
desenvolvimento usada para estimativas. Porm, como a velocidade uma varivel da prtica, essas alteraes no podem ser consideradas benefcios e malefcios de uma determinada linguagem. Sendo assim, no que diz respeito a essa prtica, podemos dizer que o desenvolvimento, tanto em Java como em Ruby, pode ser considerado igual. Stand up Meeting Essa uma prtica comportamental, que completamente independente da linguagem. Portanto, no
desenvolvimento dos blogs, podemos dizer que, para essa tcnica, as linguagens podem ser consideradas iguais. Programao em Par Nessa prtica, acreditamos que a linguagem utilizada possui alguma importncia pois verificamos que, quanto mais fcil for a leitura dos cdigos escritos, mais ganhos teremos ao utilizar essa tcnica. Isto porque uma das vantagens da utilizao dessa prtica a inspeo contnua do cdigo por parte do par e, em um cdigo mais legvel, fica mais fcil a deteco de falhas na codificao. Verificamos no desenvolvimento dos blogs que nossos cdigos escritos em Ruby so menores, mais simples e com menos referncias a outros trechos de cdigos, o que tornou a utilizao da tcnica mais eficaz do que no desenvolvimento com Java. Mas isso no significa que a utilizao dessa prtica em conjunto,, com o Java seja ineficiente. Pelo contrrio, ela continuou se mostrando til e passvel de utilizao,
67
Levando em conta que os programadores possuem conhecimento das linguagens utilizadas por cada um deles. Cdigo Coletivo Esta uma prtica muito associada programao em par e, por isso, acreditamos que a linguagem tambm possui alguma influncia no desenvolvimento dessa prtica, porque
verificamos que, quanto mais fcil for a leitura dos cdigos escritos, mais ganhos teremos ao utilizar essa tcnica. Isto porque uma das vantagens da utilizao dessa prtica a inspeo contnua do cdigo, por parte do par e, em um cdigo mais legvel, fica mais fcil a deteco de falhas na codificao. Verificamos no desenvolvimento dos blogs, que nossos cdigos escritos em Ruby so menores, mais simples e com menos referncias a outros trechos de cdigos, o que tornou a utilizao da tcnica mais eficaz do que no desenvolvimento com Java. Mas isso no significa que a utilizao dessa prtica em conjunto com o Java seja ineficiente, pelo contrrio, ela continuou se mostrando til e passvel de utilizao. Cdigo Padronizado Pode ser aplicado facilmente nas duas linguagens utilizadas no nosso estudo, uma vez que uma tcnica que depende apenas dos desenvolvedores aderirem a um padro. Porm, a linguagem pode ter alguma influncia na utilizao dessa prtica, como o caso do Ruby, pois como dissemos quando apresentamos o Ruby on Rails, este se baseia em convenes, no lugar de configuraes, e essas convenes, por si s, j criam uma certa padronizao do cdigo que estimula e facilita a adoo da tcnica. Logo, a utilizao do Ruby se mostrou mais eficiente para a adoo da
68
prtica, apesar da utilizao desta, mesma com o Java, ser perfeitamente aplicvel. Design Simples Essa outra prtica que pode ser facilmente aplicada nas duas linguagens. Porm, a linguagem utilizada pode melhorar a utilizao da tcnica e, como o Ruby on Rails foi criado baseado no princpio DRY, apresentado no captulo anterior, tem como padro gerar cdigo com design simples, ou seja, a prtica pode ser bem aplicada quando o Ruby on Rails utilizado. Portanto, o desenvolvimento com essa abordagem tornou mais fcil a utilizao da tcnica do que com o Java e Struts. Quando dizemos mais fcil, estamos nos referindo adoo mais natural e menos custosa. Desenvolvimento Orientado a Testes Essa prtica est
diretamente ligada a linguagem utilizada, pois depende desta possuir suporte ao desenvolvimento de testes. As duas linguagens utilizadas neste estudo apresentavam frameworks para o desenvolvimento de testes, o que tornou a adoo dessa prtica bastante simples no desenvolvimento dos dois blogs. No entanto, por ter o framework de desenvolvimento de testes completamente integrado ao Ruby on Rails, o desenvolvimento dos testes se mostrou mais fcil de ser realizado e de serem executados. Com isso, o estmulo utilizao da prtica no Ruby foi maior que no Java, apesar de ser totalmente vivel a utilizao da prtica nessa linguagem. Porm, como o objetivo das metodologias de desenvolvimento gil agilizar o desenvolvimento de software e, como verificamos que a implementao de testes no Java
69
mais custoso do que no Ruby, conclumos que o uso do Ruby on Rails mais adequado no que se refere a adoo dessa prtica. Refatorao A utilizao dessa prtica no dependente da linguagem que est sendo utilizada, mas a linguagem exerce grande influncia na adoo dessa prtica, pois tanto pode facilitar a utilizao atravs de ferramentas, como dificultar, como no caso de linguagens dinamicamente tipadas. O que notamos durante o desenvolvimento dos blogs, foi que o Java, utilizando-se uma IDE como a que usamos, possui um ferramental que auxilia a refatorao e, consequentemente, estimula a adoo da prtica. Por outro lado, por se tratar de uma linguagem dinamicamente tipada, a utilizao da prtica no Ruby se tornou difcil, pois no foi encontrada nenhuma IDE para essa linguagem que possua um conjunto de ferramentas que auxiliem na adoo dessa prtica. Sendo assim, a utilizao do Java no que diz respeito a essa prtica, se mostrou mais adequada. Integrao Contnua Esta um prtica que pode ser influenciada pela linguagem por alguns motivos. O primeiro que, para que esta tcnica funcione bem, preciso que o desenvolvimento possua um conjunto de testes automatizados que devem ser executados toda vez que uma integrao realizada, e para o desenvolvimento desses testes a existncia de um framework para desenvolvimento dos testes muito importante, conforme j dissemos anteriormente. E outro fator que torna uma linguagem mais adequada para a adoo da prtica, a existncia de uma ferramenta, ou plugin para uma ferramenta, de controle de verso de cdigos. No nosso estudo, verificamos que a IDE
70
que utilizamos para o desenvolvimento do site em Java, possui plugin para utilizao de alguns programas de gerncia de configurao, como CVS e Subversion, que funcionam bem. Apesar de no utilizarmos nenhuma IDE para o desenvolvimento do blog em rails, verificamos a existncia de IDE para Rails que possuem integrao com programas de controle de repositrio. Portanto, no que se refere a essa caracterstica, no h diferenas entre as linguagens. Outra caracterstica importante da linguagem que pode influenciar a utilizao da prtica, o suporte que esta possui para criao de scripts de automao deste processo. As duas linguagens estudadas apresentam esse suporte: o Java, atravs de script Ant e o Ruby, atravs do Rake26. Portanto, acreditamos que nenhuma das duas linguagens tenha se mostrado mais eficiente neste quesito. Releases Curtos Essa prtica no sofre influncia da linguagem utilizada, por se tratar de uma tcnica de projeto e no de desenvolvimento. Com isso, no houve diferena no desenvolvimento, no que diz respeito a essa prtica, dos blogs nas duas linguagens. Metforas Essa mais um tcnica de projeto que, portanto, no sofre influncia da linguagem utilizada no desenvolvimento do sistema. Logo, no houve diferena no desenvolvimento dos blogs nas duas linguagens, no que se refere a utilizao dessa prtica. Ritmo Sustentvel Essa uma prtica comportamental e que, portanto, tambm no sofre influncia da linguagem utilizada no
26
O rake um programa de build de aplicativos em Ruby. Possui caracateristiscas muito parecidas com o make e o Ant.
71
desenvolvimento. Sendo assim, o desenvolvimento dos blogs nas duas linguagens, no teve nenhuma influncia na utilizao dessa prtica.
Verificamos acima que, algumas prticas, no sofrem qualquer influncia da linguagem utilizada no desenvolvimento do software. XP no uma metodologia voltada somente para a etapa de implementao e sim para todo o processo de desenvolvimento do software e, com isso, tem prticas voltadas para a etapa de design, e prticas comportamentais, que buscam melhorar o comportamento dos desenvolvedores. No entanto, algumas prticas so voltadas para a etapa da implementao e, com isso, sofrem grande influncia da linguagem utilizada conforme mostramos acima. E, h ainda, prticas que, apesar de comportamentais, podem sofrer um pouco de influncia da linguagem utilizada. A seguir, uma tabela que apresenta o comparativo de forma resumida:
Linguagem Prtica Cliente Presente No influencia
Java
Ruby on Rails
Estimula o uso por parte de cliente, pois as alteraes podem ser visualizadas rapidamente.
Jogo de Planejamento Stand Up Meeting Programao em Par
No influencia No influencia No influencia
No influencia No influencia Melhora o desempenho da prtica por possuir um cdigo pequeno, simples, sem muitas referncias a outros trechos e com isso facilita a sua leitura.
Cdigo Coletivo
No influencia
Melhora o desempenho da prtica por possuir um cdigo pequeno, simples, sem muitas referncias a outros trechos e com isso facilita a sua leitura.
Cdigo Padronizado
No influencia
Por fazer uso de convenes no lugar de configuraes gera um
72
padro
inicial
que
conseqentemente estimula o uso da prtica. Design Simples No influencia Como baseado no princpio DRY a prtica utilizada naturalmente. Desenvolvimento Orientado a Testes Possui framework de testes, Possui framework de testes
necessrios para que a tcnica funcione corretamente.
completamente integrado, por isso se mostrou mais fcil de usar. No foi utilizada nenhuma IDE que auxiliasse a utilizao da prtica.
Refatorao
A IDE utilizada possui conjunto de ferramentas que auxiliam a
utilizao da prtica. Integrao Contnua A IDE utilizada possui ferramentas de integrao com programas de controle de verso, como CVS e Subversion. Possui o Ant para automatizao do processo. No foi utilizada de nenhuma com
ferramenta
integrao
programas de controle de verso, porm foi verificada a existncia de IDE que possuem integrao com esses programas. Possui o Rake para automatizao do processo.
Releases Curtos Metforas Ritmo Sustentvel
No influncia No influncia No influncia
No influncia No influncia No influncia
Tabela 2 - Comparativo Java X Ruby on Rails
Devemos ressaltar que nosso estudo se limitou comparao das linguagens no que se refere utilizao delas, com a metodologia XP, buscando encontrar vantagens e desvantagens, de cada uma, para a adoo da metodologia. Nosso comparativo no inclui estudos de suporte de escalabilidade das linguagens, bem como performances dos softwares. Verificamos que todas as prticas do XP estudadas podem ser aplicadas s duas linguagens. Porm, algumas so auxiliadas por alguma caracterstica, ou ferramenta, de determinada linguagem e outras podem ser atrapalhadas. Durante o desenvolvimento dos blog, constamos que, apesar de no termos tido nenhum contato anterior com o Ruby, e j termos utilizado o Java anteriormente, com pouca freqncia, constatamos que o desenvolvimento do blog no Ruby foi
73
mais rpido, por ter sido mais simples. Baseado nisso, acreditamos que seria vlido os leitores experimentarem utilizao do framework Ruby on Rails para o desenvolvimento de suas aplicaes web.
74
Concluso
O objetivo principal dessa monografia foi apresentar um estudo comparativo entre a utilizao das prticas do Extreme Programming no desenvolvimento de software em relao s linguagens de programao Java e Ruby, sendo a segunda com a utilizao do framework Ruby on Rails. Para que esse objetivo fosse atingido, precisamos estudar o funcionamento e tecnologias disponveis para cada uma das linguagens e escolher aquelas em que acreditvamos ser mais teis para a adoo do XP. Com isso, estudamos alguns frameworks para Java e Ruby. Para validao do nosso estudo, desenvolvemos dois blogs que deveriam ser simples e apresentar as mesmas funcionalidades, j que o nosso objetivo era comparar as duas linguagens. No queramos ser influenciados por dificuldades geradas no desenvolvimento de funcionalidades diferentes. Para o criao dos
blogs, nas duas linguagens, fizemos o uso das arquitetura Java, Struts1, JUnit, com padro MVC, para a linguagem Java, e Ruby on Rails, usando tambm o padro MVC para a linguagem Ruby. No desenvolvimento dos blogs, verificamos que foi possvel usar a metodologia, com as duas linguagens, sem restrio nenhuma das suas tcnicas. No entanto, verificamos que algumas tcnicas podem ser utilizadas de forma mais fcil ou com um despenho melhor em uma das linguagens. Houve uma diferena no tempo de desenvolvimento dos blogs. Ns tivemos menos dificuldades no desenvolvimento do blog em Ruby, devido a diversas caractersticas do framework Ruby on Rails e, com isso, o desenvolvimento do blog nessa linguagem foi mais rpido. Achamos importante ressaltar esse fato uma vez que um dos objetivos da adoo do XP acelerar o processo de desenvolvimento de software. A seguir,
75
iremos apresentar um resumo da tabela apresentada no captulo anterior contendo somente as prticas que sofreram alguma influncia da linguagem utilizada.
Linguagem Prtica Cliente Presente No influencia Estimula o uso por parte do cliente, pois as alteraes podem ser visualizadas rapidamente. Programao em Par No influencia Melhora o desempenho da prtica por possuir um cdigo pequeno, simples, sem muitas referncias a outros trechos e com isso facilita a sua leitura. Cdigo Coletivo No influencia Melhora o desempenho da prtica por possuir um cdigo pequeno, simples, sem muitas referncias a outros trechos e com isso facilita a sua leitura. Cdigo Padronizado No influencia Por fazer uso de convenes no lugar de configuraes gera um padro inicial que Java Ruby on Rails
conseqentemente estimula o uso da prtica. Design Simples No influencia Como baseado no princpio DRY a prtica utilizada naturalmente. Desenvolvimento Orientado a Testes Possui framework de testes, Possui framework de testes
necessrios para que a tcnica funcione corretamente.
completamente integrado, por isso se mostrou mais fcil de usar. No foi utilizada nenhuma IDE que auxiliasse a utilizao da prtica.
Refatorao
A IDE utilizada possui conjunto de ferramentas que auxiliam a
utilizao da prtica. Tabela 3 - Prticas que sofrem influencia de alguma das linguagens utilizadas
Devemos ressaltar que nosso estudo se limitou a verificar as caractersticas das linguagens em relao utilizao das mesmas em conjunto com a metodologia XP. Assim, no foram verificadas as caractersticas da linguagem em relao escalabilidade dos sistemas, como a distribuio da aplicao em diversos
76
servidores trabalhando em conjunto, e em relao a performance dos sistemas desenvolvidos nessa linguagem. Lembramos que o desenvolvimento dos blogs foi feito pela mesma equipe, e de forma sequencial, ou seja, primeiro foi desenvolvido o blog em Java e, em seguida, em Ruby on Rails, o que pode ter afetado o sentimento de dificuldade de desenvolvimento entre as duas linguagens. Portanto, achamos vlido que seja feito um segundo estudo com duas equipes desenvolvendo, separadamente, dois projetos distintos e, logo aps, inverter as equipes. Levando-se em conta somente as questes abordadas e baseados nos resultados obtidos, acreditamos que a utilizao do framework Ruby on Rails, para o desenvolvimento de aplicaes web, desse porte, o mais recomendado. Uma vez que nossos estudos no abordaram o suporte a escalabilidade e performance, esses poderiam ser assuntos de pesquisas futuras, bem como a verificao da existncia de outras linguagens que melhor se adaptariam ao uso da metodologia. Pesquisas futuras poderiam verificar a disponibilidade de
desenvolvimento de ferramentas que melhorem o uso das prticas verificadas como deficientes, em uma das linguagens, em relao a outra, e o possvel desenvolvimento das mesmas, caso no existam como uma IDE para ruby que d suporte refatorao ou o desenvolvimento de migrations para o Java.
77
Referncias Bibliogrficas APACHE, Apache Software Foundation, 2006a. Disponvel em: apache.org. Acessado em: 01/05/2006. APACHE, The Apache DB Project, 2006b. Disponvel em: db.apache.org. Acessado em: 03/05/2006. APACHE, The Apache Jakarta Project, 2006c. Disponvel em: jakarta.apache.org. Acessado em: 19/04/2006. APACHE, The Apache Struts Project, 2006d. Disponvel em: struts.apache.org. Acessado em: 03/05/2006. BECK, Kent. Extreme Programming explained: embrace change. 1. ed. Reading, MA: Addison-Wesley, 2000. 190 p. BECK, Kent; FOWLER, Martin. Planning Extreme Programming. 1. ed. Boston: Addison-Wesley, 2001. 139 p. BOEHM, Barry; TURNER, Richard. Balancing agility and discipline: a guide for the perplexed. 1. ed. Boston: Addison-Wesley, 2003. 266 p. BROOKS, Frederick P. The mythical man-month: essays on software engineering, 20th anniversary edition. 2. ed. Reading, MA: Addison-Wesley, 1995. 322 p. BROOKS, Frederick P. No silver bullet: essences and accidents of Software Engineering. IEEE. Computer, v. 20, n. 4, 1987. p. 10-19. CAVANESS, C., What is Struts, 2005. Disponvel em: www.onjava.com/pub/a/onjava/2005/11/02/what-is-struts.html. Acessado em: 18/07/06 COCKBURN, Alistair. Agile software development. 1. ed. Boston: Addison-Wesley, 2002. 278 p. DARWIN, Ian F. Java Cookbook, 2. ed. Sebastopol, CA: O`Reilly, 2004. 862p. EICHERT, Steve. Ruby on Rails Migrations Explained, 2006. Disponvel em: http://www.emxsoftware.com/RubyOnRails/Ruby+on+Rails+Migrations+Explained. Acessado em: 20/01/2007 FOWLER, Chad. Rail Recipes. 1. ed. USA: The Pragmatic Bookshelf, 2006. 297p. FOWLER, Martin. Refactoring: improving the design of existing code. Upper Saddle River, NJ: Addison-Wesley, 2000. 421 p. HUNT, Andrew; THOMAS, David. Pragmatic unit testing: in Java with JUnit. 1. ed:The Pragmatic Programmers, 2003. 176 p.
78
HUSTED, T.; DUMOULIN, C.; FRANCISCUS, G.; WINTERFELDT, D. Struts in Action: Building web applications with the leading Java framework. 1. ed. Greenwich, CT: Manning, 2003. 664 p. JEFFRIES, Ron; ANDERSON, Ann; HENDRICKSON, Chet. Extreme Programming installed. 1. ed. Boston: Addison-Wesley, 2001. 265 p. JOHNSON, R., Model View Controller as an Aggregate Design Pattern, 2006. Disponvel em: c2.com/cgi/wiki?ModelViewControllerAsAnAggregateDesignPattern. Acessado em: 09/05/2006. JOHNSON, Jim. "ROI, It's your job". Published Keynote Third International Conference on Extreme Progrmming, Alghero, Italy, May 26-29, 2002. Disponvel em: http://www.xp2003.org/talksinfo/johnson.pdf. Acessado em: 09/05/2006 LOZANO, F., Struts: Melhores Prticas em: Java Magazine, vol. 34, pp. 43-51, DevMedia, 2006. MAHMOUD, Q., Servlets and JSP Pages Best Practices, 2006. Disponvel em: java.sun.com/developer/technicalArticles/javaserverpages/servlets_jsp. Acessado em 10/05/2006 MASI, Domenico de. O cio criativo. 1. ed. Rio de Janeiro: Sextante, 2000. 336 p. POPPENDIECK, Mary; POPPENDIECK, Tom. Lean software development: an agile toolkit. 1. ed. Upper Saddle River, NJ: Addison-Wesley, 2003 Rails, Rails Framework Documentation, 2007. Disponvel em: http://api.rubyonrails.org/. Acessado em : 20/01/2007 SESHADRI, G., Understanding JavaServer Pages Model 2 architecture Exploring the MVC design pattern., 2006. Disponvel em: www.javaworld.com/javaworld/jw-12-1999/jw-12-ssj-jspmvc.html. Acessado em: 10/05/2006. SUN, Java Enterprise Edition, 2006a. Disponvel em: java.sun.com/javaee. Acessado em: 15/07/2006. SUN, Java BluePrints, 2006b. Disponvel em: java.sun.com/reference/blueprints/index.html. Acessado em 02/05/2006 SUN, Java BluePrints J2EE Patterns, 2006c. Disponvel em: java.sun.com/blueprints/patterns/index.html. Acessado em: 05/05/2006. SUN, Java BluePrints J2EE Patterns, 2006d. Disponvel em: java.sun.com/blueprints/patterns/TransferObject.html. Acessado em: 05/05/2006. SUN, Java BluePrints J2EE Patterns Catalog MVC, 2006e. Disponvel em: java.sun.com/blueprints/patterns/MVC.html. Acessado em: 07/05/2006. SUN, Java Technology, 2006f. Disponvel em: java.sun.com/products. Acessado em 31/07/2006.
79
TELES, Vincius Manhes. Um estudo de caso da adoo das prticas e valores do Extreme Programming, Dissertao de M. Sc, IM/NCE/UFRJ, Rio de Janeiro Brasil TELES, Vincius Manhes. Extreme Programming: aprenda como encantar seus usurios desenvolvendo software com agilidade e alta qualidade. 1. ed. So Paulo: Novatec, 2004. 316 p. THOMAS, Dave; HANSSON, David Heinemier. Agile Web Development with Rails: A Pragmatic Guide. 1. ed. USA: The Pragmatic Bookshelf, 2005. 554p.

Comparativo Java Ruby para XP

Enviado por

Dados do documento

Título original

Direitos autorais

Formatos disponíveis

Compartilhar este documento

Compartilhar ou incorporar documento

Opções de compartilhamento

Você considera este documento útil?

Este conteúdo é inapropriado?

Direitos autorais:

Formatos disponíveis

Comparativo Java Ruby para XP

Enviado por

Direitos autorais:

Formatos disponíveis

UNIVERSIDADE FEDERAL DO RIO DE JANEIRO

DEPARTAMENTO DE CINCIA DA COMPUTAO

ALAN KLOH, RODOLFO CORDEIRO BURLA DE AGUIAR

DCC-IM/UFRJ Bacharelado em Cincia da Computao

Orientador: Vincius Manhes Teles

Rio de Janeiro 2007

Apresentado por: _______________________________________ Alan Kloh

_______________________________________ Rodolfo Cordeiro Burla de Aguiar

Aprovado por: _______________________________________ Vincius Manhes Teles, M.Sc. (Presidente)

_______________________________________ Adriano Joaquim de Oliveira Cruz, Ph.D.

RIO DE JANEIRO, RJ - BRASIL JUNHO DE 2007

Metodologia de desenvolvimento de softwares criada no final da dcada de 90. (TELES, 2004)

Figura 1 - melhoria contnua do design sustenta a produtividade.(Poppendieck, 2003)

Figura 2 - Refatorao de uma varivel

Figura 3 - Refatorao de um trecho de cdigo.

Figura 4 - Extraindo um mtodo.

Figura 5 - Arquitetura Model 2 (MAHMOUD, 2006)

<!-- =========================================== Action Mapping Definitions -> <action-mappings> <action

Integra-se facilmente com os principais ambientes de desenvolvimento integrado do mercado;

Possui uma vasta documentao disponvel;

http://www.junit.org http://www.pyunit.sourceforge.net/pyunit.html 19 http://sourceforge.net/projects/nunit/

desenvolvemos o nosso blog em Java com a seguinte estrutura de pacotes:

Figura 7 - MVC no Rails (THOMAS, HANSSON, 2005)

(index_name) da tabela (table_name).

`page_id_linked_page_id` (`page_id`,`linked_page_id`)" end

def self.down execute "ALTER TABLE `pages_linked_pages` DROP INDEX

`page_id_linked_page_id`" end end

log Arquivos de logs gerados quando a aplicao est sendo executada.

script Onde ficam armazenados os arquivos de script de gerao de cdigo.

A figura abaixo retrata essa estrutura de diretrios apresentada acima.

Figura 8 - Estrutura de diretrios do Ruby on Rails

Figura 9 - Modelo de dados bsico dos blogs

5.2 Linhas de Cdigo

665 147 822 1 : 0.2 449

78 114 192 1 : 1.5 23

Tabela 1 Comparativo de linhas de cdigo.

public void adiciona (Topico topico) throws Exception{

Connection conn = null;

ConexaoBD conBD = ConexaoBD.getInstancia();

PreparedStatement pstmt = null; String sql = ""; int rowsAfected = 0;

try { if (conn == null) throw new Exception("Conexo no foi estabelecida.");

TopicoDAOMysql.adiciona(): " + se.getMessage()); }catch (Exception e) { throw new Exception("Erro em

TopicoDAOMysql.adiciona(): " + e.getMessage()); }finally { if(pstmt != null) pstmt.close(); conBD.returnConnection(conn); } }

Linguagem Prtica Cliente Presente No influencia

Jogo de Planejamento Stand Up Meeting Programao em Par

No influencia No influencia No influencia

Por fazer uso de convenes no lugar de configuraes gera um

necessrios para que a tcnica funcione corretamente.

A IDE utilizada possui conjunto de ferramentas que auxiliam a

Releases Curtos Metforas Ritmo Sustentvel

No influncia No influncia No influncia

No influncia No influncia No influncia

Tabela 2 - Comparativo Java X Ruby on Rails

necessrios para que a tcnica funcione corretamente.

A IDE utilizada possui conjunto de ferramentas que auxiliam a

Você também pode gostar