Your SlideShare is downloading. ×
Comparação de Tecnologias para Web - JBoss Seam e Ruby on Rails
Comparação de Tecnologias para Web - JBoss Seam e Ruby on Rails
Comparação de Tecnologias para Web - JBoss Seam e Ruby on Rails
Comparação de Tecnologias para Web - JBoss Seam e Ruby on Rails
Comparação de Tecnologias para Web - JBoss Seam e Ruby on Rails
Comparação de Tecnologias para Web - JBoss Seam e Ruby on Rails
Comparação de Tecnologias para Web - JBoss Seam e Ruby on Rails
Comparação de Tecnologias para Web - JBoss Seam e Ruby on Rails
Comparação de Tecnologias para Web - JBoss Seam e Ruby on Rails
Comparação de Tecnologias para Web - JBoss Seam e Ruby on Rails
Comparação de Tecnologias para Web - JBoss Seam e Ruby on Rails
Comparação de Tecnologias para Web - JBoss Seam e Ruby on Rails
Comparação de Tecnologias para Web - JBoss Seam e Ruby on Rails
Comparação de Tecnologias para Web - JBoss Seam e Ruby on Rails
Comparação de Tecnologias para Web - JBoss Seam e Ruby on Rails
Comparação de Tecnologias para Web - JBoss Seam e Ruby on Rails
Comparação de Tecnologias para Web - JBoss Seam e Ruby on Rails
Comparação de Tecnologias para Web - JBoss Seam e Ruby on Rails
Comparação de Tecnologias para Web - JBoss Seam e Ruby on Rails
Comparação de Tecnologias para Web - JBoss Seam e Ruby on Rails
Comparação de Tecnologias para Web - JBoss Seam e Ruby on Rails
Comparação de Tecnologias para Web - JBoss Seam e Ruby on Rails
Comparação de Tecnologias para Web - JBoss Seam e Ruby on Rails
Comparação de Tecnologias para Web - JBoss Seam e Ruby on Rails
Comparação de Tecnologias para Web - JBoss Seam e Ruby on Rails
Comparação de Tecnologias para Web - JBoss Seam e Ruby on Rails
Comparação de Tecnologias para Web - JBoss Seam e Ruby on Rails
Comparação de Tecnologias para Web - JBoss Seam e Ruby on Rails
Comparação de Tecnologias para Web - JBoss Seam e Ruby on Rails
Comparação de Tecnologias para Web - JBoss Seam e Ruby on Rails
Comparação de Tecnologias para Web - JBoss Seam e Ruby on Rails
Comparação de Tecnologias para Web - JBoss Seam e Ruby on Rails
Comparação de Tecnologias para Web - JBoss Seam e Ruby on Rails
Comparação de Tecnologias para Web - JBoss Seam e Ruby on Rails
Comparação de Tecnologias para Web - JBoss Seam e Ruby on Rails
Comparação de Tecnologias para Web - JBoss Seam e Ruby on Rails
Comparação de Tecnologias para Web - JBoss Seam e Ruby on Rails
Comparação de Tecnologias para Web - JBoss Seam e Ruby on Rails
Comparação de Tecnologias para Web - JBoss Seam e Ruby on Rails
Comparação de Tecnologias para Web - JBoss Seam e Ruby on Rails
Comparação de Tecnologias para Web - JBoss Seam e Ruby on Rails
Comparação de Tecnologias para Web - JBoss Seam e Ruby on Rails
Comparação de Tecnologias para Web - JBoss Seam e Ruby on Rails
Comparação de Tecnologias para Web - JBoss Seam e Ruby on Rails
Comparação de Tecnologias para Web - JBoss Seam e Ruby on Rails
Comparação de Tecnologias para Web - JBoss Seam e Ruby on Rails
Comparação de Tecnologias para Web - JBoss Seam e Ruby on Rails
Comparação de Tecnologias para Web - JBoss Seam e Ruby on Rails
Comparação de Tecnologias para Web - JBoss Seam e Ruby on Rails
Comparação de Tecnologias para Web - JBoss Seam e Ruby on Rails
Comparação de Tecnologias para Web - JBoss Seam e Ruby on Rails
Comparação de Tecnologias para Web - JBoss Seam e Ruby on Rails
Comparação de Tecnologias para Web - JBoss Seam e Ruby on Rails
Comparação de Tecnologias para Web - JBoss Seam e Ruby on Rails
Comparação de Tecnologias para Web - JBoss Seam e Ruby on Rails
Comparação de Tecnologias para Web - JBoss Seam e Ruby on Rails
Comparação de Tecnologias para Web - JBoss Seam e Ruby on Rails
Comparação de Tecnologias para Web - JBoss Seam e Ruby on Rails
Comparação de Tecnologias para Web - JBoss Seam e Ruby on Rails
Comparação de Tecnologias para Web - JBoss Seam e Ruby on Rails
Comparação de Tecnologias para Web - JBoss Seam e Ruby on Rails
Comparação de Tecnologias para Web - JBoss Seam e Ruby on Rails
Comparação de Tecnologias para Web - JBoss Seam e Ruby on Rails
Comparação de Tecnologias para Web - JBoss Seam e Ruby on Rails
Comparação de Tecnologias para Web - JBoss Seam e Ruby on Rails
Comparação de Tecnologias para Web - JBoss Seam e Ruby on Rails
Comparação de Tecnologias para Web - JBoss Seam e Ruby on Rails
Comparação de Tecnologias para Web - JBoss Seam e Ruby on Rails
Comparação de Tecnologias para Web - JBoss Seam e Ruby on Rails
Comparação de Tecnologias para Web - JBoss Seam e Ruby on Rails
Comparação de Tecnologias para Web - JBoss Seam e Ruby on Rails
Comparação de Tecnologias para Web - JBoss Seam e Ruby on Rails
Comparação de Tecnologias para Web - JBoss Seam e Ruby on Rails
Comparação de Tecnologias para Web - JBoss Seam e Ruby on Rails
Comparação de Tecnologias para Web - JBoss Seam e Ruby on Rails
Comparação de Tecnologias para Web - JBoss Seam e Ruby on Rails
Comparação de Tecnologias para Web - JBoss Seam e Ruby on Rails
Comparação de Tecnologias para Web - JBoss Seam e Ruby on Rails
Comparação de Tecnologias para Web - JBoss Seam e Ruby on Rails
Comparação de Tecnologias para Web - JBoss Seam e Ruby on Rails
Comparação de Tecnologias para Web - JBoss Seam e Ruby on Rails
Comparação de Tecnologias para Web - JBoss Seam e Ruby on Rails
Comparação de Tecnologias para Web - JBoss Seam e Ruby on Rails
Comparação de Tecnologias para Web - JBoss Seam e Ruby on Rails
Comparação de Tecnologias para Web - JBoss Seam e Ruby on Rails
Comparação de Tecnologias para Web - JBoss Seam e Ruby on Rails
Comparação de Tecnologias para Web - JBoss Seam e Ruby on Rails
Comparação de Tecnologias para Web - JBoss Seam e Ruby on Rails
Comparação de Tecnologias para Web - JBoss Seam e Ruby on Rails
Comparação de Tecnologias para Web - JBoss Seam e Ruby on Rails
Comparação de Tecnologias para Web - JBoss Seam e Ruby on Rails
Comparação de Tecnologias para Web - JBoss Seam e Ruby on Rails
Comparação de Tecnologias para Web - JBoss Seam e Ruby on Rails
Comparação de Tecnologias para Web - JBoss Seam e Ruby on Rails
Comparação de Tecnologias para Web - JBoss Seam e Ruby on Rails
Comparação de Tecnologias para Web - JBoss Seam e Ruby on Rails
Comparação de Tecnologias para Web - JBoss Seam e Ruby on Rails
Comparação de Tecnologias para Web - JBoss Seam e Ruby on Rails
Comparação de Tecnologias para Web - JBoss Seam e Ruby on Rails
Comparação de Tecnologias para Web - JBoss Seam e Ruby on Rails
Comparação de Tecnologias para Web - JBoss Seam e Ruby on Rails
Comparação de Tecnologias para Web - JBoss Seam e Ruby on Rails
Comparação de Tecnologias para Web - JBoss Seam e Ruby on Rails
Upcoming SlideShare
Loading in...5
×

Thanks for flagging this SlideShare!

Oops! An error has occurred.

×
Saving this for later? Get the SlideShare app to save on your phone or tablet. Read anywhere, anytime – even offline.
Text the download link to your phone
Standard text messaging rates apply

Comparação de Tecnologias para Web - JBoss Seam e Ruby on Rails

6,970

Published on

Comparação de Tecnologias para Web - JBoss Seam e Ruby on Rails (Guilherme Serna Martins - Marcos Nunes de Castro - UNISUL, 2010)

Comparação de Tecnologias para Web - JBoss Seam e Ruby on Rails (Guilherme Serna Martins - Marcos Nunes de Castro - UNISUL, 2010)

Published in: Education
0 Comments
4 Likes
Statistics
Notes
  • Be the first to comment

No Downloads
Views
Total Views
6,970
On Slideshare
0
From Embeds
0
Number of Embeds
2
Actions
Shares
0
Downloads
177
Comments
0
Likes
4
Embeds 0
No embeds

Report content
Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
No notes for slide

Transcript

  • 1. UNIVERSIDADE DO SUL DE SANTA CATARINA GUILHERME SERNA MARTINS MARCOS NUNES DE CASTRO COMPARAÇÃO DE TECNOLOGIAS PARA WEB JBOSS SEAM E RUBY ON RAILS Tubarão 2010
  • 2. GUILHERME SERNA MARTINS MARCOS NUNES DE CASTRO COMPARAÇÃO DE TECNOLOGIAS PARA WEB JBOSS SEAM E RUBY ON RAILS Trabalho de Conclusão de Curso apresentado ao Curso de graduação em Ciência da Computação/Sistema de Informação, da Universidade do Sul de Santa Catarina, como requisito parcial para obtenção do título de Bacharel.em Sistemas de Informação/Ciência da Computação. Universidade do Sul de Santa Catarina Orientador Profº. Eder Cachoeira Tubarão 2010
  • 3. AGRADECIMENTOS Eu Guilherme, gostaria primeiramente de agradecer a Deus por me dar a oportunidade de poder estar concluindo meus estudos. Quero deixar registrado meu eterno agradecimento aos meus avós, Antonio Ruiz e Adair Ricardo Serna, pessoas especiais enviadas por Deus que tanto me ajudam e que sem o apoio não poderia estar concluindo esta graduação. Agradecer também a minha esposa Mayaha Barjona Martins que há cinco anos tem se mostrado companheira, compreensiva e que eu muito amo e ao meu filho Arthur que torna minha família completa. Agradecer também a todos os professores que tornaram isto uma realidade. Eu Marcos, agradeço todos meus familiares e amigos que me ajudaram na conclusão deste projeto, e principalmente ao meu pai Claudionor e minha mãe Dulcemar pelo grande incentivo e apoio dado a todo o momento nesta importante fase de minha vida.
  • 4. RESUMO Este projeto apresentará a comparação de dois frameworks para desenvolvimento de aplicações web. O Primeiro é o framework JBoss Seam, escolhido devido a sua linguagem base ser Java, linguagem essa muito bem consolidado, difundida e utilizada. O outro framework se chama Ruby on Rails, que apesar de ser uma linguagem nova, vem recebendo muitos elogios, que na maioria das vezes, se referem às facilidades que o framework oferece. Para realizar as comparações, foi modelada uma aplicação e desenvolvida utilizando-se os dois frameworks, Jboss Seam e Ruby on Rails. As comparações serão avaliadas em curva de aprendizado, tempo de desenvolvimento, facilidade de manutenção, performance e tamanho do código. Palavras-Chave: Ruby, Ruby on Rails, Java, Jboss Seam, Framework, Aplicações web.
  • 5. ABSTRACT This project will present a comparison of two frameworks for web developing applications. The first framework is the JBoss Seam, chosen because its language is based on Java, a language that very well established, disseminated and used. The other framework called Ruby on Rails, which despite being a new language, has received many accolades, which most often, refers to facilities that the framework offers. To make comparisons, was modeled and developed an application using the two frameworks, JBoss Seam and Ruby on Rails. The comparisons will be evaluated on the learning curve, development time, maintainability, performance and code size. Keywords: Ruby, Ruby on Rails, Java, JBoss Seam, Framework, Web applications.
  • 6. LISTA DE GRÁFICOS Gráfico 1 – Tempo de resposta na realização do login. ......................................................... 64 Gráfico 2 – Utilização do processador na realização do login.. ............................................. 64 Gráfico 3 – Tempo de resposta na realização do logout. ....................................................... 65 Gráfico 4 - Utilização do processador na realização do logout.............................................. 66 Gráfico 5 – Tempo de resposta na criação de um serviço. ..................................................... 67 Gráfico 6 – Utilização do processador na criação de um serviço........................................... 67 Gráfico 7 – Média do tempo de resposta na criação de um serviço. ...................................... 68 Gráfico 8 - Média do tempo de resposta na criação de um serviço. ....................................... 68 Gráfico 9– Tempo de resposta na contratação de um serviço.. .............................................. 69 Gráfico 10 – Utilização do processador na contratação de um serviço. ................................. 70 Gráfico 11 – Tempo de resposta na criação de um usuário.................................................... 71 Gráfico 12 – Utilização do processador na criação de um usuário......................................... 71 Gráfico 13 – Tempo de resposta na criação de cem usuários................................................. 72 Gráfico 14 – Utilização do processador na criação de cem usuários...................................... 72 Gráfico 15 – Tempo de resposta na criação de cem serviços.. ............................................... 73 Gráfico 16 – Utilização do processador na criação de cem serviços...................................... 74 Gráfico 17 – Tempo de resposta na criação de mil serviços.. ................................................ 75 Gráfico 18 – Utilização do processador na criação de mil serviços. ...................................... 75 Gráfico 19 – Tempo de resposta na criação de mil serviços. ................................................. 76 Gráfico 20 – Utilização do processador na criação de mil usuários....................................... 76 Gráfico 21 – Média do tempo de resposta na criação de cem usuários .................................. 80 Gráfico 22 – Média do tempo de resposta na criação de mil usuários ................................... 80 Gráfico 23 – Média do tempo de resposta na criação de cem serviços .................................. 81 Gráfico 24 – Média do tempo de resposta na criação de mil serviços.................................... 82
  • 7. LISTA DE ILUSTRAÇÕES Figura 1– Funcionamento do Compilador.) .......................................................................... 22 Figura 2– Funcionamento do Interpretador........................................................................... 24 Figura 3 – Caso de Uso de Empresa. .................................................................................... 87 Figura 4 – Caso de Uso de Cliente ....................................................................................... 87 Figura 5 – Mapa do site) ...................................................................................................... 92 Figura 6 – Tela de login........................................................................................................ 93 Figura 7 – Tela de registro.................................................................................................... 94 Figura 8 – Tela inicial do usuário Empresa........................................................................... 95 Figura 9 – Tela para criar novo Serviço (Usuário Empresa) .................................................. 95 Figura 10 – Tela para ver os Serviços oferecidos (Usuário Empresa). ................................... 96 Figura 11 – Tela para ver Clientes (Usuário Empresa) .......................................................... 96 Figura 12 – Tela inicial do usuário Cliente. .......................................................................... 97 Figura 13 – Tela para solicitar novo Serviço(usuário Cliente). .............................................. 97 Figura 14 – Tela para ver os Serviços solicitados(usuário Cliente)........................................ 98
  • 8. LISTA DE QUADROS Quadro 1 - Exemplo C++ e Delphi....................................................................................... 22 Quadro 2 - Exemplo Pascal e Visual Basic6 ......................................................................... 23 Quadro 3 - Exemplo Java e Ruby ......................................................................................... 24 Quadro 4 - Exemplo PHP e Python ..................................................................................... 25 Quadro 5 - Exemplo Basic e Euphoria................................................................................. 26 Quadro 6 - Exemplo Lua e ActionScript.............................................................................. 26 Quadro 7 - Exemplo de Comparação Java x Ruby................................................................ 46 Quadro 8 - Exemplo de legibilidade de código Ruby on Rails .............................................. 51 Quadro 9 – Script de criação do scaffold em Ruby on Rails.................................................. 51 Quadro 10 – Comando de migração para o banco de dado.................................................... 51 Quadro 11 - Exemplo de Comparação Java x Ruby .............................................................. 54 Quadro 12 Script para instalar plugin ................................................................................... 54 Quadro 13 – Código para filtrar extensões de arquivos do paperclip..................................... 55 Quadro 14 – Script para instalar plugin ................................................................................ 55 Quadro 15 – Configuração do servidor de e-mail em Ruby on Rails ..................................... 55 Quadro 16 Configuração de envio de e-mail em Ruby on Rails ............................................ 56 Quadro 17 – Exemplo de mensagem a ser enviada em Ruby on Rails................................... 56 Quadro 18 – Exemplo de e-mail enviado em Ruby on Rails ................................................. 57 Quadro 19 Comando para enviar e-mail em Ruby on Rails................................................... 57 Quadro 20 - Exemplo da configuração do serviço de e-mail ................................................. 58 Quadro 21 - Exemplo do método de envio de e-mail ............................................................ 58 Quadro 22 - Exemplo do arquivo de renderização de e-mails ............................................... 60 Quadro 23 - Exemplo do e-mail gerado................................................................................ 60 Quadro 24 - Exemplo do arquivo da view ............................................................................ 61 Quadro 25 - Exemplo do método para download.................................................................. 61 Quadro 26 – Configuração dos ambientes de desenvolvimento............................................. 63 Quadro 27 - Métricas do ambiente de desenvolvimento Ruby on Rails................................. 77 Quadro 28 - Métricas do ambiente de desenvolvimento Jboss Seam..................................... 77 Quadro 29 – Quadro de Conclusões. .................................................................................... 83 Quadro 30 - Requisitos F1................................................................................................... 88
  • 9. Quadro 31 - Requisitos F2................................................................................................... 88 Quadro 32 - Requisitos F3................................................................................................... 88 Quadro 33 - Requisitos F4................................................................................................... 89 Quadro 34 - Requisitos F5................................................................................................... 89 Quadro 35 - Requisitos F6.................................................................................................... 89 Quadro 36 - Requisitos F7................................................................................................... 89 Quadro 37 - Requisitos F8................................................................................................... 90 Quadro 38 - Referencias Cruzadas. ..................................................................................... 91
  • 10. SUMÁRIO 1 INTRODUÇÃO............................................................................................................... 13 1.1 OBJETIVOS .............................................................................................................. 14 1.1.1 Objetivo Geral ..................................................................................................... 14 1.1.2 Específicos .......................................................................................................... 14 1.2 JUSTIFICATIVA........................................................................................................ 15 1.3 RESUMO DA METODOLOGIA PARA DESENVOLVIMENTO DO TRABALHO.. 16 1.4 RESULTADOS ESPERADOS ................................................................................... 17 1.5 DESCRIÇÃO DO DOCUMENTO............................................................................. 17 2 INTRODUÇÃO A LINGUAGEM DE PROGRAMAÇÃO ........................................... 19 2.1 TIPOS DE LINGUAGENS ........................................................................................ 20 2.1.1 Linguagem Compilada ...................................................................................... 21 2.1.2 Linguagem Interpretada ................................................................................... 23 2.1.3 Linguagem De Script......................................................................................... 25 3 LINGUAGEM DE PROGRAMAÇÃO JAVA................................................................ 27 4 LINGUAGEM DE PROGRAMAÇÃO RUBY .............................................................. 31 5 ESTRUTURA MVC........................................................................................................ 33 6 SERVIDORES WEB....................................................................................................... 35 6.1 APACHE HTTP SERVER .......................................................................................... 36 6.2 TOMCAT ................................................................................................................... 37 6.3 JBOSS........................................................................................................................ 37 7 FRAMEWORKS............................................................................................................. 40 7.1 JBOSS SEAM............................................................................................................ 41 7.2 RUBY ON RAILS...................................................................................................... 43 8 JAVA X RUBY................................................................................................................. 46 9 PONTOS A SEREM COMPARADOS ........................................................................... 47 9.1 CURVA DE APRENDIZADO .................................................................................... 47 9.2 TEMPO DE DESENVOLVIMENTO ......................................................................... 47 9.3 FACILIDADE DE MANUTENÇÃO.......................................................................... 47 9.4 PERFORMANCE ...................................................................................................... 48 9.5 TAMANHO DO CÓDIGO ......................................................................................... 48 10 ANÁLISE COMPARATIVA DAS FERRAMENTAS JBOSS SEAM E RUBY ON RAILS................................................................................................................................. 49 10.1 METODOLOGIA PARA DESENVOLVIMENTO DO TRABALHO ....................... 49 11 ANÁLISE DOS RESULTADOS.................................................................................... 51 11.1 Curva de Aprendizado............................................................................................ 51 11.2 Tempo de Desenvolvimento .................................................................................... 52 11.3 Facilidade de manutenção ...................................................................................... 54 11.4 Performance ............................................................................................................. 62 11.4.1 Teste - Login...................................................................................................... 63 11.4.2 Teste – Logout ................................................................................................... 65 11.4.3 Teste – Criar Serviço.......................................................................................... 66 11.4.4 Teste – Contratar Serviço ................................................................................... 69 11.4.5 Teste - Criar Usuário .......................................................................................... 71 11.4.6 Teste – Criar 100 Usuários ................................................................................. 72 11.4.7 Teste – Criar 100 Serviços.................................................................................. 73 11.4.8 Teste – Criar 1000 Serviços................................................................................ 74
  • 11. 11.4.9 Teste – Criar 1000 Usuários ............................................................................... 76 11.5 Tamanho do código ................................................................................................. 77 12 CONCLUSÕES ............................................................................................................. 79 13 TRABALHOS FUTUROS. ........................................................................................... 84 APÊNCIDE A - Visão geral do Sistema............................................................................. 86 APÊNCIDE B - Casos de uso............................................................................................. 87 APÊNCIDE C - Análise de requisitos funcionais e não funcionais. ................................. 88 APÊNCIDE D - Referências Cruzadas ............................................................................. 91 APÊNCIDE E - Mapa do site ............................................................................................ 92 APÊNCIDE F - Wireframes .............................................................................................. 93
  • 12. 13 1 INTRODUÇÃO Com o passar do tempo novas tecnologias vão sendo criadas, e com elas sempre surgem novidades. Este processo ocorre desde os primeiros computadores e linguagens de programação, e para cada nova tecnologia apresentada, existem pessoas interessadas em estudá-las e analisá-las para sua experiência própria ou mesmo para substituir a sua tecnologia atual. Foi assim desde as linguagens de programação ADA1, Fortran (1954), COBOL (1959), etc. Neste projeto, foi realizado um comparativo de duas tecnologias presentes atualmente. JBoss Seam destaca-se por ser uma tecnologia baseada na plataforma Java EE e por ser um framework que está contribuindo e investindo através de seus conceitos para o desenvolvimento da plataforma JEE (JSR-299). JBoss Seam tem como objetivo eliminar a complexidade existente na integração de frameworks como Java Server Faces, Java Persistence, Enterprise Java Beans, AJAX, permitindo ao desenvolvedor focar-se na implementação do negócio e abstraindo-o da árdua tarefa de realizar a integração entre as tecnologias empregadas. Em contra partida encontramos Ruby On Rails, um framework2 gratuito e aberto que teve seu inicio em meados de 2004 e foi escrito na linguagem de programação Ruby, linguagem esta que foi idealizada em 1993 em um bate-papo on-line informal entre Matsumoto (Matz) e Keiju Ishitsuka, e destaca-se cada vez mais por tornar fácil o desenvolvimento de aplicações para web. 1 Nome dado por Charles Babbage, o idealizador do computador em homenagem a sua esposa e programadora Ada Lovelace. 2 Framework - “Um framework provê uma solução para uma família de problemas semelhantes Usando um conjunto de classes e interfaces que mostra como decompor a família de problemas.” (Sauvé, 2010, p.1)
  • 13. 14 1.1 OBJETIVOS 1.1.1 Objetivo Geral Apresentar um estudo comparativo dos frameworks Jboss Seam e Ruby on Rails para desenvolvimento de aplicações Web. 1.1.2 Específicos  Pesquisar técnicas de desenvolvimento de aplicações em JBoss Seam;  Pesquisar técnicas de desenvolvimento de aplicações em Ruby on Rails;  Realizar a comparação entre as tecnologias nos seguintes quesitos: Curva de aprendizado, Tempo de desenvolvimento, Facilidade de manutenção, Performance e Tamanho do código;  Modelar uma aplicação e implementá-la em ambos os frameworks;  Apresentar resultados alcançados e discuti-los;
  • 14. 15 1.2 JUSTIFICATIVA Java é uma das principais linguagens de programação utilizada pela comunidade de desenvolvimento do mundo todo e se destaca cada vez mais por ser uma linguagem gratuita e com abrangente fonte de pesquisa na sua API e comunidades seguidoras. Mas será que devemos ficar apenas nesse pensamento e deixar as outras tecnologias vagando pela internet sem ao menos tentar achar alternativas de desenvolvimento, quem sabe, melhor do que a você usa? Pensando nisso resolvemos escolher dois frameworks de linguagens distintas para realizar uma pesquisa fundamentada e após elaborar um comparativo sólido entre essas duas tecnologias e destacar os seus pontos fortes e fracos. Em Java, o framework escolhido foi o JBoss Seam. O principal motivo para a sua escolha foi devido ao fato de o mesmo ser o principal responsável pela implementação da JRS-299(Java Context and Dependency Injection). Muitas das idéias originadas com o desenvolvimento deste framework estão sendo analisadas para tornar-se um padrão de desenvolvimento na Plataforma JEE através desta JRS (Java Specification Requests). Várias empresas como, Apache Software Foundation, Google Inc, Red Hat, Intel entre outras gigantes do meio deram seu parecer aprovando este padrão de desenvolvimento. Depois do JBoss Seam, o outro framework escolhido para a elaboração deste projeto foi a Ruby on Rails, que vem se popularizando por ser conhecida como uma grande ajudante no desenvolvimento de aplicativos para web com sua tão citada facilidade e agilidade no seu desenvolvimento. Para uma melhor distinção, temos de início o intuito de desenvolver um software com as mesmas funcionalidades em ambas as linguagens, com isso ter-se-á um melhor embasamento para a elaboração das conclusões.
  • 15. 16 1.3 RESUMO DA METODOLOGIA PARA DESENVOLVIMENTO DO TRABALHO  Realizar estudo dos frameworks Jboss Seam e Ruby on Rails e suas linguagens, Java e Ruby.  Desenvolver uma aplicação para a comparação dos frameworks supracitados.  Comparar os frameworks.. Mais detalhes sobre a metodologia utilizada será abordado no tópico 4.1.
  • 16. 17 1.4 RESULTADOS ESPERADOS Os resultados esperados são:  Obter através do desenvolvimento do aplicativo, subsídios para identificar a melhor linguagem de programação para o nosso projeto proposto.  Descobrir através da fase de desenvolvimento, facilidades que as linguagens nos proporcionam na comparação JBoss Seam e Ruby on Rails.  Realizar uma tabela com várias características e mensurá-las de acordo com os benchmarks realizados durante o processo de desenvolvimento e execução. 1.5 DESCRIÇÃO DO DOCUMENTO Capítulo 1: Introdução sobre o que o projeto irá abordar, os objetivos gerais e específicos, justificativas, resumo da metodologia a ser seguida para a conclusão do projeto e os resultados esperados. Capítulo 2: Este capítulo irá fazer uma introdução a linguagem de programação e mostrar os seus diferentes tipos. Capítulo 3: Este capítulo mostrará a linguagem de programação Java. Capítulo 4: Este capítulo mostrará a linguagem de programação Ruby. Capítulo 5: Aqui irá falar sobre estrutura MVC. Capítulo 6: Neste capítulo será abordado sobre os servidores web. Capítulo 7: Explicará o que é framework, e mostrará os dois frameworks utilizados neste projeto (Jboss Seam e Ruby on Rails). Capítulo 8: Uma pequena tabela mostrará algumas características das linguagens Java e Ruby.
  • 17. 18 Capítulo 9: Aqui será mostrado os pontos importantes que serão usados na comparação dos frameworks JBoss Seam e Ruby on Rails, como curva de aprendizado, tempo de desenvolvimento, facilidade de manutenção, performance e tamanho do código. Capítulo 10: Este capítulo explana a metodologia utilizada para a comparação entre os frameworks JBoss Seam e Ruby on Rails. Capítulo 11: Neste capítulo está os resultados detalhados obtidos na comparação entre JBoss Seam e Ruby on Rails. Capítulo 12: Conclusões sobre a comparação realizada entre os frameworks JBoss Seam e Ruby on Rails. Capítulo 13: Aqui estão listados os trabalhos futuros pretendidos pelos autores.
  • 18. 19 2 INTRODUÇÃO A LINGUAGEM DE PROGRAMAÇÃO O primeiro projeto de linguagem de programação na verdade era um algoritmo3 que permitia cálculos de funções matemáticas que foi desenvolvido pela inglesa Ada Lovelace durante um período de nove meses entre os anos de 1842 e 1843, para um computador que ainda estava sendo criado por Charles Babbage, e que recebeu o nome de ADA em homenagem a esta programadora. Uma das primeiras linguagens de programação realmente para computadores foi provavelmente Plankalkül (1945), criada por Konrad Zuse na Alemanha Nazista Conforme Faccat (2009, p.1): Konrad Zuse percebeu que ainda não existia uma notação formal para a descrição de algoritmos e começou a trabalhar em uma. O resultado foi uma linguagem chamada Plankalkül (program calculus), uma extensão do cálculo proposicional e de predicado de Hilbert. Plankalkül já possuía chamadas da função (sub-rotinas), instruções condicionais, estrutura de repetição (iteração), aritmética de ponto flutuante, matrizes (arrays), tipos de dados compostos, tratamento de exceção, dentre outras características, mas que não teve muito sucesso. Para Fialho Jr (2002, p.123), Linguagem de Programação se define como: Uma seqüência de linhas de instruções escritas por um programador, que são dadas ao computador para que possa executar as tarefas solicitadas por estas instruções. As linguagens de programação normalmente são escritas de forma compreensível pelos seres humanos, porém devem passar por um compilador4 ou interpretador5 para serem convertidas para uma linguagem de baixo nível, denominada linguagem de maquina6 ou código de maquina, para que o computador possa entender as instruções e, assim, executá-las. Uma linguagem de programação é então um conjunto de palavras, compostas por regras sintáticas e semânticas interpretável pela máquina, que permite ao programador que informe ou especifique os comandos que o computador irá executar em determinadas ações 3 Um algoritmo é um conjunto determinístico de instruções que cumprem alguma tarefa, na qual partindo de um estado inicial chegam a um determinado estado final. (Wangenheim, 2010, p.3) 4 Compilador é um tradutor que mapeia um programa escrito em linguagem de alto nível para um programa equivalente em uma linguagem simbólica ou linguagem de maquina (Price & Toscane 2001, p.4). 5 Interpretador – Programa responsável pela conversão e posterior execução das instruções de um programa que tenha sido escrito num tipo de linguagem interpretada. (Fialho JR, 2002, p.117). 6 Linguagem de máquina – “Trata-se de uma seqüência de instruções em códigos binários, totalmente compreensível pelo computador [...] é o resultado obtido após a compilação ou interpretação que se faz de um código fonte.” (Fialho Jr, 2002, p.123).
  • 19. 20 ou circunstancias. Estes conjuntos de palavras são denominados de “tokens” que se adequados às regras impostas pelas linguagens se transformam em códigos-fonte7, que por sua vez é traduzido para linguagem de maquina, que nada mais são do que números binários (“zeros” e “uns”) interpretados pelo processador, conhecido como linguagem de baixo nível. Segundo Icea(2009, p.2), a linguagem de maquina “É constituída inteiramente de números, o que torna praticamente impossível entendê-la diretamente. Cada CPU tem seu conjunto único de linguagem de máquina, definido pelo fabricante do chip”. Um dos principais objetivos da linguagem de programação é permitir que os programadores tenham uma maior produtividade, criando condições para que eles interajam mais facilmente com a máquina. No decorrer dos tempos as linguagens de programação foram sofrendo diversas modificações, onde muitas dessas ficaram desatualizadas a realidade computacional em termos de hardware e outros artefatos que deixaram de existir, surgindo então as linguagens de alto nível, com funções semelhantes ao idioma humano e de fácil entendimento. A primeira linguagem de programação de alto nível amplamente usada foi Fortran, criada em 1954. Em 1957 foi criada B-0, que daria origem a Flow-Matic (1958), antecessor imediato de COBOL, de 1959. Lisp e ALGOL foram criadas em 1958. Prolog e Pascal começaram em 1970, C++ em 1983 seguido de Perl em 1987. Java teve seu inicio com o nome de Oak em 1991 que recebeu seu nome atual em 1995 com o Java 1. Ruby começou em 1993, desenvolvido pelo japonês Yukihiro Matsumoto (Matz). No capítulo a seguir serão mostrados os tipos existentes de linguagens de programação, citando e exemplificando as mais populares. 2.1 TIPOS DE LINGUAGENS As linguagens são definidas em basicamente três tipos, são eles:  Linguagem compilada 7 Código-fonte são as linhas de programação que formam um software em sua forma original. Inicialmente, um programador "escreve" o programa em uma certa linguagem —como C++ ou Visual Basic. (Folha Online, p. 1)
  • 20. 21  Linguagem interpretada  Linguagem de script 2.1.1 Linguagem Compilada Segundo Nguyen (2009, p.1), “Uma linguagem compilada é uma linguagem que requer um compilador para transformar o código fonte de programação em um programa binário8 executável na linguagem de máquina [...]”. O código fonte é traduzido para linguagem de máquina através do processo de compilação e executado diretamente pelo sistema operacional ou pelo processador, usando um programa de computador chamado compilador, para uma linguagem de baixo nível (Programas Binários), ou seja, não existe nenhum tipo de interpretador neste tipo de linguagem, tornando esse tipo de processamento muito mais rápido do que nas linguagens interpretadas. A figura 1 mostra como é feito este processo de compilação, onde o código fonte (Programa Fonte) é traduzido para linguagem de máquina (Programa Objetivo). 8 Sistema Binário é um Sistema numérico empregado em tecnologia digital, representado por dois valores: 0 e 1. (Fialho 2002, p.170).
  • 21. 22 Programa Fonte Analisador Léxico Analisador Sintático Analisador Semântico e Gerador Otimizador Tabela de Símbolos de Código Intermediário Gerador de Código Programa Objetivo Figura 1– Funcionamento do Compilador. Fonte: Azambuja (2004, p1) Alguns exemplos de linguagens compiladas são:  Ada  Delphi  BASIC  Fortran  C  Pascal  C++  Visual Basic  COBOL  Visual Prolog  Cobra Exemplo simples de código fonte de algumas linguagens de programação compilada: C++ Delphi main() Begin { WriteLn('Hello World'); cout << "Hello World!" << endl; End. return 0; } Quadro 1 - Exemplo C++ e Delphi – Fonte Roesler (2010, p1)
  • 22. 23 Pascal Visual Basic6 program HelloWorld(output); Private Sub Form_Load() begin Print "Hello World" WriteLn('Hello World!'); End Sub end. Quadro 2 - Exemplo Pascal e Visual Basic6 – Fonte Roesler (2010, p1) Podemos citar como um exemplo neste tipo de linguagem o programa desenvolvido em Delphi pela Sigma-Aldrich9, uma empresa de alta tecnologia, no setor de Ciências. De acordo com Borland (2009, p.1), O programa desenvolvido é utilizado por seus bioquímicos e biólogos na investigação científica e genomica, biotecnologia, farmacêutica, em diagnósticos de doenças e identificação dos principais componentes de produtos farmacêuticos e outros de alta tecnologia. A Companhia possui diversos clientes como universidades, instituições governamentais, hospitais e indústrias. Mais de um milhão de cientistas e tecnólogos utilizam seus produtos. A Companhia atende mais de 150 países a partir de suas operações em 36 países e possui 7.600 empregados proporcionando excelentes serviços a nível mundial. 2.1.2 Linguagem Interpretada Linguagem interpretada é uma linguagem de programação, onde o código fonte não é somente executado pelo compilador e sim por um programa de computador chamado interpretador. O compilador lê o código-fonte e o interpreta diretamente durante o seu processamento, avaliando o código e executando as operações (instruções digitadas pelo programador) nele descritas. Em seguida é executado pelo sistema operacional ou processador, por este fato as linguagens interpretadas em geral têm uma eficiência muito menor do que as linguagens compiladas tradicionais. A execução é de 10 a 100 vezes mais lenta do que em programas compilados. Além disso, a solução como um todo normalmente ocupa bem mais espaço, pois além do fonte do programa, é necessário o interpretador e muitas vezes uma série de outras bibliotecas disponíveis, em cada máquina onde o programa for executado (Azambuja, 2004). A Figura 2 mostra como é feito este processo de Interpretação do Código Fonte. 9 Disponível em <http://www.sigma-aldrich.com>. Acesso em: 20 mai 2009.
  • 23. 24 Programa Fonte Analisador Léxico Analisador Sintático Tabela de Símbolos Analisador Semântico Interpretação Figura 2– Funcionamento do Interpretador. Fonte: Azambuja (2004, p1) Mesmo que um código em uma linguagem passe pelo processo de compilação, a linguagem pode ser considerada interpretada, se o programa resultante não for executado diretamente pelo sistema operacional ou processador. Alguns exemplos de linguagens interpretadas são:  ActionScript  PHP  C#  Python  Java  Ruby  JavaScript  Scheme  Lua  Smalltalk Exemplo simples de código fonte de algumas linguagens de programação interpretada: Java Ruby class HelloWorld { static public void main( String args[] ) { System.out.println( "Hello World!" ); puts "Hello World!" } } Quadro 3 - Exemplo Java e Ruby – Fonte Roesler (2010, p1)
  • 24. 25 PHP Python <?php echo 'Hello World!'; print "Hello World" ?> Quadro 4 - Exemplo PHP e Python – Fonte Roesler (2010, p1) Como exemplo de soluções com essas linguagens, podemos citar o caso de A.B. Watley10, na qual tem como negocio serviços financeiros. Segundo Huston(2009 SUN, p.1, tradução nossa), “Nossa nova tecnologia, tem permitido a Watley competir como uma empresa completamente nova. Uma grande parte de nosso sucesso nos serviços financeiros B2B deve-se a qualidade de nossos softwares e a nossa migração de nossos sistemas do NT para o UNIX com o Sistema operacional Solaris. Nossa plataforma UNIX e arquitetura empresarial claramente nos diferenciam das grandes empresas corretoras e bancos”. As tecnologias empregada nesta evolução de arquitetura foram, o Ambiente de desenvolvimento Java, juntamente com outros produtos criados com esta tecnologia, por exemplo, Sistema Operacional Solaris - Aplicações client-side desenvolvidas por A.B.Watley sendo 100% puro Java client-side entre outras tecnologias da Sun. 2.1.3 Linguagem De Script Linguagem de Script (também conhecido como linguagem de scripting, ou linguagem de extensão) é uma linguagem de programação desenvolvida para um aplicativo específico que é executado no interior de programas e/ou de outras linguagens de programação, não se restringindo a esses ambientes. Segundo Capron (2004 citado por Herculiani , 2007, p.40): Linguagens de scripts representam uma forma nova de se programar. Nestas linguagens é assumida a existência de um conjunto de componentes já desenvolvidos em outras linguagens, de forma que o objetivo destas linguagens passa a ser o de combinar estes componentes e não o de desenvolver programas a partir de estruturas de dados elementares. Por esta razão, as linguagens de scripts são também chamadas de linguagens de colagem11 (glue languages) ou de linguagens de integração se sistemas (system integration languages). 10 Disponível em < http://www.abwatley.com/>. Acesso em 20 mai 2009. 11 Linguagem de Colagem (Glue Language) Uma linguagem de colagem é usado para mesclar vários programas em um único aplicativo. (Flynt (2003), Tradução nossa).
  • 25. 26 As linguagens de script servem para estender a funcionalidade de um programa e/ou controlá-lo, acessando sua API e, são freqüentemente usadas como ferramentas de configuração e instalação. Todas as linguagens de script são linguagens interpretadas, porém, nem todas as linguagens interpretadas são linguagens de script. Os programas escritos em linguagens de script são, normalmente, referidos como scripts. Alguns exemplos de linguagens de Script são:  ActionScript  Lua  BASIC  PHP  C  Python  Euphoria  Ruby  JavaScript  Tcl Exemplo simples de código fonte de algumas linguagens de programação script: BASIC Euphoria PRINT "Hello World!" puts(1, "Hello World!") Quadro 5 - Exemplo Basic e Euphoria – Fonte Roesler (2010, p1) Lua ActionScript print "Hello world" trace ("Hello World"); Quadro 6 - Exemplo Lua e ActionScript – Fonte Roesler (2010, p1) Este tipo de linguagem é usado para softwares pequenos produzidos em tempo curto para fins específicos e relativamente simples. O próximo tópico abordará a linguagem base para o framework JBoss Seam.
  • 26. 27 3 LINGUAGEM DE PROGRAMAÇÃO JAVA Java, inicialmente chamada de OAK (tradução do inglês "Carvalho") foi criada por James Gosling. Algum tempo depois foi descoberto que já havia uma linguagem chamada Oak, então foi trocado para Java, seu nome atual. Teve seu desenvolvimento iniciado em 1991 com a Sun Micro systems em um projeto de codinome Green. A principio a linguagem não teve grande sucesso devido à falta de mercado, pois o setor eletrônico não se desenvolvia tanto quanto era esperado e o foco central da linguagem naquele momento era a programação de produtos eletrônicos. No entanto, em 1993 com a popularidade da internet a Sun viu um grande potencial para a linguagem que era a criação de conteúdo dinâmico em paginas para internet. Em 1995 a Sun anunciou formalmente a linguagem Java. Segundo JAVAFREE (2010, p.1), “Desde seu lançamento, em maio de 1995, a plataforma Java foi adotada mais rapidamente do que qualquer outra linguagem de programação na história da computação”. Java é uma linguagem que possuem muitas características atrativas ao programador como, por exemplo, Orientação a objetos. O modelo de Orientação a objetos do Java foi baseado nas linguagens Smalltalk e Simula67. A Orientação a objetos é um paradigma de análise, projeto e programação de sistemas de software onde o programador com esta nova perspectiva começa a lidar não mais com uma programação sistemática e seqüencial mas sim com a programação de objetos isolados que possuem atributos e métodos próprios e que trabalham em harmonia para executar tarefas complexas e alcançar um resultado final. Outra característica importante da linguagem Java é a sua portabilidade, que por trata-se de uma linguagem interpretada, possui a capacidade de ser executada em qualquer ambiente operacional que suporte a sua plataforma. Trata-se de uma linguagem atualmente muito utilizada e contando com muitos canais de acesso a informações, provendo aos programadores suporte para suas APIs. Javafree (2009, p.1) diz que, “Atualmente Java é uma das linguagens mais usadas e serve para qualquer tipo de aplicação, entre elas: web, desktop, servidores, mainframes, jogos, aplicações móveis, chips de identificação, etc.”. Java devido ao seu alto grau de maturidade possui muitas bibliotecas (APIs) com diversas funcionalidades para os mais diversos tipos de ambientes e problemas, por exemplo temos a disponibilidade de desenvolver aplicativos desde para um aparelho domestico como microondas até um aparelho celular. Muitas APIs já estão implementadas para facilitar o desenvolvimento de aplicações, APIs referentes a conexões de rede, conexões com banco de
  • 27. 28 dados, interfaces gráficas, gráficos 2d,3d, para aplicativos multimídia e muitas outras funcionalidades. JVM (Java Virtual Machine) é o interpretador java, que possibilita ao Java o poder de ser uma linguagem multi-plataforma "write once, run anywhere", ou seja, uma vez desenvolvido a aplicação a JVM conseguirá executá-lo em qualquer ambiente. Generalizando e ignorando as diferenças entre implementações e versões, a JVM roda realizando o Garbage Colection quando há a necessidade de mais memória para a execução. Durante a execução, o programa pode perder a referencia á determinado objeto – tornando este objeto um candidato a exclusão. Não há garantia que a JVM irá liberar a memória. (Devdaily, 2009, p.1). Java possui uma tecnologia chamada Garbage Colector12 (Coletor de Lixo), que proporciona ao sistema que esta executando a aplicação Java uma melhor estabilidade. Esta estabilidade é adquirida pois a JVM gerencia toda a memória alocada para determinado programa em execução e quando determinado espaço de memória não é mais necessário para o programa, este espaço é limpo e passa a ser utilizado para outro dado se necessário. Esta tarefa é efetuada automaticamente pelo Garbage Colection. Outras linguagens como C++ por exemplo, deixavam esta tarefa com o programador que tinha que se preocupar em criar mecanismos que realizassem esta tarefa em runtime. Podemos dividir a plataforma Java em três edições, J2SE, JEE e J2ME. Segundo a Sun (2009, p.1, tradução nossa), “A plataforma Java SE é a plataforma para rápido desenvolvimento e implantação de aplicações seguras, portáveis que rodam no servidor e ou vários sistemas operacionais.”. J2SE trata-se da Standard Edition OU JAVA SE. Cada edição conta com uma JVM, API e ferramentas próprias para esta versão. O JEE (Java Enterprise Edition) é adaptada para aplicações multicamadas baseadas em componentes que são executados em um servidor de aplicação. J2ME (Java Plataforma Micro Edition) é a plataforma desenvolvida para ser introduzida em dispositivos de propósitos específicos, por exemplo, celulares, pdas, controles remotos entre outros. Esta plataforma assim como as outras também possui um JVM e APIs e ferramenta próprias. 12 Garbage Collections é o processo que automaticamente libera objetos que não são mais referenciados pelo programa (Venners, 2009, p.1).
  • 28. 29 O próximo capítulo irá falar sobre a edição da linguagem Java voltada para web, conhecida como JEE.  JEE – JAVA ENTERPRISE EDITION Segundo Prado (2009, p.1), "O JEE (Java Enterprise Edition) é a plataforma Java voltada para redes, internet, intranets e semelhantes, sendo assim, ela contém bibliotecas especialmente desenvolvidas para o acesso a servidores, a sistemas de e-mail, a banco de dados, entre outras características.". JEE é formada por componentes que podem ser estruturados para desenvolver uma aplicação web. Podemos citar, por exemplo, Servlets, JSP Pages, JavaBeans, JMS entre muitas outras tecnologias disponibilizadas ao desenvolvedor. Esta plataforma foi projetada para possibilitar a construção de aplicações multicamadas proporcionando o desenvolvimento de projetos escaláveis e com mantenabilidade. Bortolassi (2007, p.1) ressalta que, “A especificação JEE define quatro tipos de “containers” ou “plataformas” ou simplesmente “componentes” (como é citado na especificação) que um produto JEE deve suportar”. Estes componentes são: Aplicação Cliente, Applet, Web Container (Web Server) e Enterprise Java Beans. Na especificação JEE uns dos principais componentes é o JEE Server, que tem como objetivo proporcionar uma interface para os componentes utilizados nas aplicações, definindo assim o conceito de containeres13. Antes de um componente Web, Enterprise Bean, Applet ou aplicação cliente ser executado, ele necessita ser montado (assembled) dentro de um modulo JEE e distribuído (assembled) em seu container apropriado. O processo de montagem (assembler) envolve a configuração de cada componente no aplicativo JEE definindo normalmente através de arquivos XML suas características como segurança, gerenciamento de transação, Java Naming and Directory Interfaces lookups (JNDI) e conectividade remota. Na especificação JEE, os containeres interagem entre si, executando assim as tarefas determinadas pelo programador. 13 Java EE containers fornece suporte de execução para componentes de aplicação Java EE. Componentes de aplicações Java EE usam os protocolos e métodos do recipiente para acessar outros componentes de aplicações e os serviços prestados pelo servidor .(Sun 2010, p.1).
  • 29. 30 Esta plataforma é considerada um padrão, afinal qualquer desenvolvedor de ferramentas que queira disponibilizar ferramentas para esta edição deve submeter-se a certos padrões da especificação JEE para que o seu produto possa ser compatível com a plataforma. Podemos citar algumas destas especificações:  JDBC (Java Database Connectivity) que é utilizada para realizar a conexão com um banco de dados.  Servlets: Especificação na qual é disponibilizada ao programador recursos do servidor para a criação de aplicações Web com conteúdo dinâmico.  JSP: (Java Server Pages) Podemos declará-lo como uma evolução do Servlets, pois o JSP é internamente tratado com um Servlet, mas é codificado em uma sintaxe muito mais limpa e intuitiva. Proporciona as mesmas características do Servlets.  JTA: (Java Transaction API) é uma API que padroniza o tratamento de transações dentro de uma aplicação Java.  EJBs: (Enterprise Java Beans) São os componentes de negocio. Através destes componentes é possível abstrair o programador de todas as questões de infra- estrutura, segurança, disponibilidade e estabilidade e permitir que o programador esteja focado somente na lógica do negocio a ser desenvolvido.  JCA (Java Connector Architecture): Trata-se de uma API que padroniza a ligação a aplicações legadas.  JPA (Java Persistence API) É uma API que padroniza o acesso a banco de dados através de mapeamento Objeto – Relacional. Urubatan (2007, p.1) diz que: Atualmente os servidores de aplicação Web que suportam a especificação JEE 5.0 são, WebLogic v10, Apusic Application Server v5.0, SAP NetWeaver Application Server Java EE 5 Edition, Sun Java System Application Server Plataform Edition 9, TmaxSoft JEUS 6, Glassfish Application Server. Agora que já foi apresentada a linguagem Java e sua edição para web (JEE), mostraremos a segunda linguagem que será apresentada neste projeto, a linguagem de programação Ruby.
  • 30. 31 4 LINGUAGEM DE PROGRAMAÇÃO RUBY Ruby é uma linguagem de programação criada por um Engenheiro de Software chamado Yukihiro “Matz” Matsumoto em fevereiro de 1993. Ruby é licenciada sobre a GPL e foi liberada ao publico em 1995, mais ou menos um ano depois que o Java. A linguagem é mantida por Matz e colaboradores por todo o mundo. Ruby-Lang (2010, p.1) afirma que “O Ruby tem um sistema de threading independente do Sistema Operativo. Portanto, para todas as plataformas nas quais o Ruby corre, temos multithreading, independentemente de o Sistema Operativo o suportar ou não, até em MS-DOS temos multithreading!”. Assim como ouras linguagens de programação, Matz desenvolveu Ruby para melhorar a facilidade de programar a permitir que os desenvolvedores se focassem no problema do desenvolvimento ao invés da sintaxe da linguagem. Esta é uma das grandes diferenças se comparado com outras linguagens. Matz (2000, p.1, tradução nossa) diz tentar tornar o Ruby natural, não simples, de uma forma que reflita a vida. “O Ruby é simples na aparência, mas muito complexo no interior, tal como o corpo humano”. Ruby-Lang (2009, p.1), “Em muitas linguagens, números e outros tipos primitivos não são objetos”. Ruby é considerado uma linguagem totalmente orientada a objetos, o que significa que tudo que você manipula em Ruby é um objeto, incluindo dados que normalmente são tipos primitivos em outras linguagens, como números inteiros e números de ponto flutuante. (Santos, 2007, p.1). Matz (2001, p.1) fala da época em que estava criando o Ruby, “Eu queria uma linguagem interpretada que fosse mais poderosa que o Perl e mais orientada aos objetos do que o Python" Ruby também é super dinâmico, permitindo ao programador alterar classes e introduzir novos métodos no momento de execução. Esta característica possibilita o programador realizar coisas em que outras linguagens não seriam possíveis. O Ruby é visto como uma linguagem flexível, uma vez que permite aos seus utilizadores alterar partes da Linguagem. Partes essenciais do Ruby podem ser removidas ou redefinidas à vontade. Partes existentes podem ser acrescentadas. O Ruby tenta não restringir o programador. (Ruby-Lang, 2009, p.1). Ruby-Lang (2009, p.1) afirma ainda que: Os Blocos do Ruby são vistos como uma fonte de grande flexibilidade. Um programador pode adicionar um fecho a qualquer método, descrevendo como esse
  • 31. 32 método se deve comportar. O fecho é chamado bloco e tornou-se uma das características mais populares para os recém chegados ao Ruby vindos de outras linguagens imperativas como o PHP ou o Visual Basic. Será ressaltado no capítulo a seguir a estrutura MVC, utilizada para facilitar o entendimento e a criação de um software.
  • 32. 33 5 ESTRUTURA MVC MVC (Model-View-Controler) é um padrão de arquitetura de software. Desde os anos 80 a Engenharia de Software começou a se preocupar com a maneira que os softwares eram desenvolvidos. As primeiras tentativas em tentar explicar como os softwares eram desenvolvidos e arquitetados foram meio confusas. Durante a década de 90, houve um grande esforço pela comunidade da Engenharia de Software no propósito de identificar e compreender os fatores e aspectos fundamentais no desenvolvimento de software. Com o aumento da complexidade das aplicações desenvolvidas, verificou-se que se torna fundamental que os dados sejam divididos em camadas para simplificar esta complexidade. Dividindo-se em camadas, torna-se mais claro para os desenvolvedores focarem-se em determinada parte do projeto sem comprometer o desenvolvimento de outra parte. Sun (2009, p.1, tradução nossa) afirma que: O padrão MVC proporciona vários benefícios de designer. MVC separa as responsabilidades de desenvolvimento (persistência de dados e comportamentos, apresentação e controle) diminuindo a duplicação de código e centralizando o controle e fazendo a aplicação ser mais modificável. E-Genial (2009, p.1) completa ainda dizendo: O molde MVC oferece vantagens significativas no desenvolvimento de aplicativos, através da separação das camadas, possibilitando implementar com maior facilidade e clareza questões programáticas importantes como a persistência de dados, controle de segurança, comunicação em rede e fluxo de visualização. Muitos problemas podem surgir quando mistura-se o código de acesso a dados, código da lógica de negocio e código da apresentação. A aplicação neste contexto torna-se difícil de manter, pois esta mistura de códigos torna o objeto muito dependente de outras partes forçando o desenvolvedor caso seja necessária uma simples modificação, editar o código em um nível muito profundo e complexo fazendo com que as chances de ocorrer um erro em outra parte do sistema seja muito provável. A complexidade neste nível aumenta significantemente. Com a divisão do código pode-se realizar a modificação do layout de uma pagina em uma aplicação Web, sem necessitar modificar nenhuma parte da lógica da aplicação. Uma vez o projeto estando bem dividido pode-se por exemplo contratar um designer profissional para a implementação do layout da pagina sendo que este profissional não necessita ser um expert na área de programação de componentes da lógica do negocio.
  • 33. 34 Com o modelo MVC, torna-se mais definido separação das camadas do sistema, sendo que o modelo requisita que seja cumprida determinada regra: O Controller despacha as solicitações ao Model; A View observa o Model. Devido os frameworks JBoss Seam e Ruby on Rails serem voltados para desenvolvimento de aplicativos web, será realizado a seguir uma breve explanação sobre Servidores web.
  • 34. 35 6 SERVIDORES WEB Segundo Whatis (2009, p.1, tradução nossa), "Um Servidor Web é um programa que, utilizando-se do modelo Cliente/Servidor e o protocolo HTTP, disponibiliza arquivos que formam as paginas para usuários Web”. Em outras palavras, um Servidor Web é um programa de computador que é responsável por aceitar requisições HTTP de clientes e enviar respostas HTTP por meio de conteúdo pré-definidos como textos, imagens e links com outras requisições. Abaixo podemos verificar algumas das funcionalidades do Apache Web Server segundo Focalinux(2007, p.1).  Possui suporte a scripts cgi usando linguagens como Perl, PHP, Shell Script, ASP, etc.  Suporte a autorização de acesso podendo ser especificadas restrições de acesso separadamente para cada endereço/arquivo/diretório acessado no servidor.  Autenticação requerendo um nome de usuário e senha válidos para acesso a alguma página/sub-diretório/arquivo (suportando criptografia via Crypto e MD5).  Negociação de conteúdo, permitindo a exibição da página Web no idioma requisitado pelo Cliente Navegador.  Suporte a tipos mime.  Personalização de logs.  Mensagens de erro.  Suporte a virtual hosting (é possível servir 2 ou mais páginas com endereços/ portas diferentes através do mesmo processo ou usar mais de um processo para controlar mais de um endereço).  Suporte a IP virtual hosting.  Suporte a name virtual hosting.  Suporte a servidor Proxy ftp e http, com limite de acesso, caching (todas flexivelmente configuráveis).  Suporte a proxy e redirecionamentos baseados em URLs para endereços Internos.  Suporte a criptografia via SSL,Certificados digitais  Módulos DSO (Dynamic Shared Objects) permitem adicionar/remover funcionalidades e recursos sem necessidade de recompilação do programa. Webdevelopersnotes (2009, p.1) fala que, "O mais famoso e popular de todos os servidores Web é o Apache, desenvolvido pela Fundação Apache. Apache não é somente free, mas ele também esta disponível para vários sistemas operacionais incluindo Windows, Macintosh e Linux/Unix."
  • 35. 36 A seguir teremos um breve contato com este Web Server. 6.1 APACHE HTTP SERVER Segundo Alecrim (2006, p.1), "Entre os servidores Web, o Apache é o mais conhecido e usado. Este título foi adquirido devido a sua excelente performance, segurança, compatibilidade com diversas plataformas e todos os seus recursos”. O Apache Server é um software livre e que é desenvolvido e implementado por vários voluntários e desenvolvedores no mundo todo. Abaixo estão algumas características citadas por Focalinux (2009, p.1), que fazem esse servidor Web o preferido entre os administradores de sistemas:  Possui suporte a scripts cgi usando linguagens como Perl, PHP, Shell Script, ASP, etc.  Suporte a autorização de acesso podendo ser especificadas restrições de acesso separadamente para cada endereço/arquivo/diretório acessado no servidor.  Autenticação requerendo um nome de usuário e senha válidos para acesso a alguma página/sub-diretório/arquivo (suportando criptografia via Crypto e MD5).  Negociação de conteúdo, permitindo a exibição da página Web no idioma requisitado pelo Cliente Navegador.  Suporte a tipos mime.  Personalização de logs.  Mensagens de erro.  Suporte a virtual hosting (é possível servir 2 ou mais páginas com endereços/ portas diferentes através do mesmo processo ou usar mais de um processo para controlar mais de um endereço).  Suporte a IP virtual hosting.  Suporte a name virtual hosting.  Suporte a servidor Proxy ftp e http, com limite de acesso, caching (todas flexivelmente configuráveis).  Suporte a proxy e redirecionamentos baseados em URLs para endereços Internos.  Suporte a criptografia via SSL,Certificados digitais
  • 36. 37 Módulos DSO (Dynamic Shared Objects) permitem adicionar/remover funcionalidades e recursos sem necessidade de recompilação do programa. 6.2 TOMCAT Segundo Apache (2009, p.1), "Apache TomCat é uma implementação das tecnologias Java Servlet e Java Server Page". TomCat é um servidor Web Java, mais especificamente, um contêiner de servlets. O servidor Web TomCat portanto, utiliza-se da plataforma Apache para o servidor Web e implementa a funcionalidade de contêiner Servlet, ou seja, consegue administrar a inclusão de componentes servlets e Java Server Pages no servidor em processá-los, permitindo assim os benefícios da plataforma java para Web. 6.3 JBOSS Segundo Jboss (2009), “O Servidor de Aplicação Jboss é uma implementação opensource de um conjunto de serviços na especificação Java EE”. Seu desenvolvimento foi iniciado em março de 1999 e primeiramente foi delineado como um container EJB (Enterprise Java Beans), mas ao longo dos anos tornou-se um servidor de aplicações completo que atualmente encontra-se em um alto grau de maturação. Nada mais é do que uma aplicação desenvolvida para possibilitar a implantação de aplicações web multi-camadas desenvolvidas com tecnologia Java. Não podemos resumi-lo a apenas isso. Jboss é uma plataforma que disponibiliza toda a infra-estrutura de uma aplicação de pequena a grande dimensão com utilização de outras tecnologias da especificação JEE como JSP, Servlets, JNDI, EJB entre muitas outras da especificação. Pelo fato de ser desenvolvido em Java é multi-plataforma e fácil de se instalar em qualquer sistema operacional que suporte Java. Devido ao seu código fonte ser
  • 37. 38 disponibilizado através da licença GNU, torna-se uma grande vantagem para o desenvolvedor, tendo a possibilidade de alterar e configurar o servidor de acordo com as suas necessidades. Jboss em 2002 conquistou o premio da JavaWorld na categoria Best Java Server Application Server estando inclusive na frente de produtos comerciais cujas licenças não são adquiridas por menos de milhares de dólares. Em meados de 2005 com a fama junto com TomCat na briga de servidores Java e após especulações de que a grande Oracle teria a intenção de adquirir o JBoss, a Red Hat anunciou a aquisição da fornecedora do código do Jboss por cerca de 350 milhões de dólares em dinheiro e ações. Um dos pontos importantes sobre o diferencial do Jboss de outros Servidores de Aplicações existentes no mercado, trata-se de como foi projetada a sua arquitetura pensando- se no seu desempenho. Segundo RedHat (2009, p.1), “O servidor JBoss inicia apenas um container para o JMX MBeans server, e então carrega sua configuração baseada nos serviços definidos no arquivo de configuração jboxx-service.xml passado para o servidor através da linha de comando”. O Jboss é arquitetado através de microkernels JMX, onde todos os módulos que compõem o servidor e ainda as próprias aplicações são componentes (Mbeans) que são plugados ou substituídos em runtime não havendo assim a necessidade de se reiniciar o servidor toda a vez que se deseja adicionar ou alterar algum componente do servidor. Esta propriedade do servidor Jboss é denominada Hot Deploy que acaba proporcionando uma grande robustez e flexibilidade ao servidor. Este elevado grau de modularidade beneficia o desenvolvedor da aplicação de várias maneiras. Um código já pequeno pode ser ainda mais minimizado para suportar as aplicações que devem ter uma pequena exigência. Por exemplo, se Passivação EJB é desnecessária na sua aplicação, basta ter o recurso fora do servidor. Se você decidir mais tarde implantar o recurso, basta apenas ativar o recurso do servidor. Esta facilidade permite que o desenvolvedor personalize o ambiente do servidor de acordo com as necessidades de suas aplicações e economizando recursos de hardware do servidor. Podemos destacar alguns destes módulos, por exemplo, Jboss Server (Servidor), Jboss JMX (Gerenciamento dos MBeans) Jboss CMP (Persistência), Jboss MQ (Filas de Mensagens), Jboss SX (Segurança, Autorização e Autenticação), Jboss TX (Transações Distribuídas), Jboss CX (Conectores), Servidor Web (TomCat, Jetty).
  • 38. 39 Jboss (2009) afirma que, Jboss AOP não é somente um framework, mas também um conjunto de pacotes que são aplicados por meio de anotações, expressões ou dinamicamente em tempo de execução. Alguns desses pacotes incluem cachê, comunicação assíncrona, transações, segurança e muitas outras funcionalidades. O Jboss a partir da versão 4.0 já disponibiliza um framework denominado AOP (Aspect-Oriented-Programming) que possibilita que os programadores adicionem facilmente em seus projetos funcionalidades como transação, persistência e replicação de cache a partir de seus objetos Java comuns sem a necessidade de se criar um EJB para tal. Portanto este framework transforma um objeto comum Java em um EJB e permite que o desenvolvedor possa focar-se no desenvolvimento da lógica de negocio. A seguir, será definido o que é um framework, para que ele serve e suas vantagens. No final do capitulo será citado alguns exemplos de frameworks mais conhecidos pelos programadores.
  • 39. 40 7 FRAMEWORKS O framework serve para resolver problemas semelhantes de um determinado domínio, composto por um conjunto de classes e interfaces que devem ser flexíveis e extensíveis para permitir a construção de aplicações com menos esforço, ditando apenas as semelhanças de cada aplicação. Segundo Fayad e Schmidt (1997, p.1), “Framework é um conjunto de classes que colaboram para realizar uma responsabilidade para um domínio de um subsistema da aplicação”. Um framework é criado a partir das similaridades funcionais de várias aplicações, elas devem ter alguma similaridade grande, ou seja, pertencer a um mesmo domínio de problema. Pode se dizer que um framework é uma aplicação quase completa, mas com alguns pedaços faltando. Algumas vantagens de se utilizar um Framework são:  Maior facilidade para a detecção de erros e estabilizando a aplicação, visto que frameworks são peças mais concisas de software  Podemos nos concentrar mais com a abstração de soluções do problema que estamos tratando, focando apenas no necessário, ao invés de inventar a roda.  Torna mais eficiente a resolução dos problemas e a compatibilidade entre as aplicações.  Otimização de recursos.  Menos manutenção.  Como todos os itens acima ocasionam uma maior produtividade, podemos garantir que também teremos um maior lucro, pois teremos uma antecipação da entrega, e uma maior satisfação dos clientes. Exemplos de Frameworks MVC mais conhecidos:  VRaptor  WebWork  Struts  Spring  IBM SERVLETMANAGER  Oracle9iAS MVC Framework
  • 40. 41  WebFlow em WebLogic Portal 4.0 da BEA  Tapestry  Turbine Exemplos de Frameworks conhecidos para Persistência com o Banco de Dados:  Hibernate  Prevayler  TOPLINK  COCOBASE Agora que foi mostrado o que é um framework, falaremos sobre o Jboss Seam, que será o framework utilizado neste projeto para linguagem de programação Java, mais adiante falaremos também sobre o framework que será utilizado para a linguagem Ruby. 7.1 JBOSS SEAM Jboss Seam trata-se de um framework que foi desenvolvido por Gavin King, criador do Hibernate. O framework Jboss Seam tem a finalidade de realizar a integração entre componentes EJB3 e JSF através de componentes visuais. Não há distinção entre a camada de apresentação e os componentes de lógica de negocio no Seam. Segundo Duckett (2008, p.1), Gavin King é o fundador do Hibernate e Jboss Seam, projetos open source que pretendem fazer a vida de um desenvolvedor Web mais fácil [...]. Enterprise Java Beans (EJB3) são componentes de negocio e Java Server Faces (JSF) são componentes visuais. A sua integração não é definida na especificação da plataforma JavaEE 5 e o Jboss Seam foi desenvolvido a principio para solucionar este problema que dificulta o desenvolvimento de aplicações Java para Web. Sommers (2006) diz que, “Um dos principais problemas que o Seam tenta resolver é a questão da profunda integração da plataforma EE 5 para o ponto de vista do modelo de programação. A plataforma EE tem esses poderosos recursos, e seria ótimo se esses recursos trabalhassem juntos dentro de um único ambiente”.
  • 41. 42 Adicionalmente á esta funcionalidade Jboss Seam é fornecida em sua API a possibilidade de integração com outras tecnologias como AJAX, jBMP, Web Services, JMS, Portlets etc. Segundo Jcp (2009, p.1), "O propósito desta especificação é unificar componentes JSF com componentes EJB, resultando em uma significante simplificação do modelo de programação para aplicações baseadas na web". Devido a sua grande aceitação junto à comunidade Java, foi criada um conceito denominado JSR299 – WebBeans para padronizar o modelo de programação do Seam na plataforma Java EE 5. As empresas envolvidas neste esforço são Jboss, Google, Oracle, Borland e Sun. Podemos dizer que o Jboss Seam faz todo o trabalho sujo da integração entre componentes EJB3 com componentes JSF, permitindo que o desenvolvedor foque-se no domínio de negocio que esta sendo desenvolvido. Antes do Seam, a única maneira de gerenciar o estado de uma Aplicação Web era através da sessão HTTP. Seam disponibiliza ao desenvolvedor, vários contextos de diferentes granularidades de escopo de conversação libertando o desenvolvedor de certas limitações que o HTTP session possuíam. Os contextos Seam são muito semelhantes aos contextos de uma aplicação Web baseada em Java EE (componentes Servlets e JSP). Podemos entender por contextos como espaços reservados no servidor para armazenagem de objetos dos usuários da aplicação Web. Estes Objetos são referenciados por uma String única para cada usuário e através dela podemos ter acesso aos dados deste objeto. Jboss (2009, p.1) diz que, “Os contextos básicos do Seam são: Stateless context, Event (or request) context, Page context, Conversation context, Session context, Business process context, Application context”. A usabilidade destes contextos é a mesma que os contextos JEE padrão porem, estes novos contextos possuem um comportamento diferente e específico para determinadas funções. Outra funcionalidade disponibilizada no framework Seam é o gerenciamento de processos de negocio através do jBPM, permitindo um desenvolvimento otimizado para esta tecnologia. Os escopos existentes na especificação JEE são: page, request, session e application. Jboss Seam define novos contextos para complementar os já existentes, são eles: stateless, event, page, conversation, session, business process e application. A usabilidade destes contextos é a mesma que os contextos JEE padrão porem, estes novos contextos possuem um comportamento diferente e específico para determinadas funções. Outra funcionalidade
  • 42. 43 disponibilizada no framework Seam é o gerenciamento de processos de negocio através do jBPM, permitindo um desenvolvimento otimizado para esta tecnologia. Segundo RedHat (2009, p.1), "jBPM provê sofisticada funcionalidade para workflow14 e gerencia de tarefas". A implementação de funcionalidade CRUD em aplicações JEE torna-se muito facilitado através dos scripts de criação de projetos disponibilizado pelo Seam, onde por exemplo indicamos o tipo de banco a ser utilizado alguns outros dados para a conexão e automaticamente através de uma ferramenta de engenharia reversa o framework realiza a leitura dos dados do banco de dado e cria as classes entities automaticamente para as tabelas. Neste capitulo foi apresentado o framework Jboss Seam que se integra ao Java, o capítulo a seguir falará sobre o framework que será utilizado neste projeto para a linguagem de programação Ruby, conhecido como Ruby on Rails. 7.2 RUBY ON RAILS Ruby on Rails trata-se de um framework desenvolvido por David Heinemeier Hansson. Ruby on Rails foi escrito na linguagem Ruby e tem como objetivo proporcionar o desenvolvimento ágil de aplicações web. Desde julho de 2004 este framework foi liberado como um projeto open source e desde então vem sendo aperfeiçoado por uma comunidade que a cada dia cresce e coopera para o desenvolvimento da mesma. Segundo E-Genial (2009) Rails foi projetado para:  Ser uma solução de desenvolvimento completa;  Permitir que suas camadas se comunicassem da forma mais transparente possível;  Ser uniforme, escrito totalmente apenas em uma linguagem;  Seguir a arquitetura MVC (Model-View-Controller). E-Genial (2009), afirma ainda que “O Rails, ou Ruby on Rails, ou ainda RoR, pode também ser chamado de um "meta-framework", pois têm em sua estrutura outros 5 frameworks: 14 Workflow (em português: Fluxo de Trabalho) É a tecnologia que possibilita automatizar processos, racionalizando-os e potencializando-os por meio de dois componentes implícitos: organização e tecnologia..(Idoc 2010, p.1 ).
  • 43. 44  Active Record;  Action Pack;  Action Mailer;  Active Support;  Active Resource” De acordo com RailsGuide (2009, p.1) A filosofia Rails é fundamentada em alguns princípios: DRY - Não repita você mesmo – Sugere que escrever o mesmo código várias vezes é uma prática ruim. Convention Over Configuration (Convenção sobre a Configuração) – diz que Rails supõe o que e como o programador deseja fazer alguma coisa ao invés de deixá-lo implementar intermináveis arquivos de configuração. A filosofia Convention over Configuration de Ruby on Rails, torna o processo de desenvolvimento de uma aplicação Web mais fácil e rápida. Esta filosofia tem como objetivo minimizar os arquivos de configurações tão difundidos em outros frameworks atualmente no mercado. Por exemplo, suponhamos que a variável carro de uma aplicação web deve ser persistida na coluna carro do banco de dados, então o programador necessita editar as configurações em um arquivo XML realizando uma espécie de link entre essa variável e a coluna do banco e dados. Dependendo da complexidade da aplicação e de suas camadas, inúmeros arquivos de configuração deverão ser configurados tornando assim muito dispendiosa o trabalho do programador. Ruby on Rails escapa neste caso da configuração através da naming conventions. Por exemplo, uma variável chamada "carro" esta automaticamente ligada a uma tabela chamada "carros". Vários aspectos em Rails tentam minimizar estes inúmeros arquivos de configuração permitindo que mais rapidamente já se inicie o processo de desenvolvimento propriamente dito. Outro aspecto levantado é o Dont Repeat Your Self que tem como principio evitar informações duplicadas no código, permitindo que o desenvolvedor possa focar-se no que realmente interessa e não ficar perdendo tempo em digitar informações repetidas devido à burocracia da linguagem ou framework utilizado. Na programação de computadores a repetição é ruim e nos levará ao erro. Também referido como "Uma Vez e apenas Uma Vez", o DRY tem como principio que você precisa apenas expressar uma peça particular de informação uma vez no sistema. A duplicação é normalmente desnecessária especialmente em linguagens dinâmicas como Ruby. (Brad Ediger, 2007, tradução nossa)
  • 44. 45 Em um projeto padrão com banco de dados, um arquivo de configuração ira indicar ao programa como é que estão organizadas as tabelas do banco de dados, qual é a ligação entre as tabelas, atributos, chaves primárias entre outros dados. A partir deste arquivo todo o programa estará apto a persistir os dados e realizar outras ações. Caso o nome de um único campo de uma tabela esteja errado, já não será possível executar o programa e o programador deverá localizar onde esta o erro e arrumá-lo. Caso seja alterada alguma tabela, o programador deverá alterar o respectivo arquivo atualizando as alterações realizadas no banco. No entanto, se analisarmos, estes arquivos de configurações não passam de uma repetição desnecessária e que tendem a nos levar ao erro, pois o aplicativo poderia acessar o banco e realizar a verificação de todas as tabelas e seus atributos e deduzir a formatação que está a base de dados. Outro fator que não deve ser esquecido é que com esta repetição, toda alteração realizada no banco deve ser refletida nos arquivos de configuração e dentro da lógica do aplicativo, assim despendendo tempo do programador e mais trabalho para todos. Com esse trabalho árduo é natural que o programador sinta-se desencorajado a realizar alterações e com isso não respondendo adequadamente as necessidades de atualizações impostas por um possível cliente. Apresentado as linguagens Java e Ruby e seus frameworks Jboss Seam e Ruby on Rails, será mostrado no próximo capítulo uma comparação com as características principais de cara linguagem.
  • 45. 46 8 JAVA X RUBY Como Java e Ruby são as linguagens de programação base que este projeto irá abordar, Java para Jboss Seam e Ruby para Ruby on Rails, citamos abaixo uma lista com as principais características dessas linguagens. Características Java Ruby Orientada a Objetos (OO) X X Sintaxe Simples X Tipos Primitivos X Grande quantidade de Frameworks X Linguagem Compilada X Linguagem Interpretada X X OpenSource X X Suporte a Web X X Programação Estática X Programação Dinâmica X Garbage Collector X X Closures X Metaprogramação X MVC X X Tratamento de Exceções X X Quadro 7 - Exemplo de Comparação Java x Ruby – Elaboração dos autores, 2010.
  • 46. 47 9 PONTOS A SEREM COMPARADOS 9.1 CURVA DE APRENDIZADO Quando falamos de curva de aprendizagem, estamos falando da dificuldade de se adaptar a uma determinada linguagem de programação, seja ela de alto ou baixo nível. Muitas pessoas não encaram tal linguagem de programação pela sua fama de curva de aprendizagem ser muito grande, e ter um mundo novo e complexo ou não se ter muitos recursos para poder se adaptar a essa linguagem, o que de fato não deve ser encarado desta maneira, pois varias linguagem onde a curva de aprendizagem é alta, estão maduras o suficiente para uma aplicação segura e com alto desempenho. 9.2 TEMPO DE DESENVOLVIMENTO O tempo de desenvolvimento é um ponto importante a ser analisado. Este é um aspecto que evidencia a produtividade de uma linguagem ou framework. O tempo necessário para o desenvolvimento de um aplicativo está diretamente relacionado à simplicidade da linguagem, robustez e facilidade de suportes, como api, livros e comunidades. 9.3 FACILIDADE DE MANUTENÇÃO Segundo Anquetil (2008, p.1), A manutenção de software é uma atividade extremamente importante na prática das organizações de software correspondendo a 90% ou mais de toda atividade de programação de sistemas. Isto quer dizer que para se ter uma boa manutenção, é necessário que a linguagem de programação permita isto, ou seja, a linguagem tem que ser clara e de fácil entendimento, tanto para o próprio programador como para outros programadores de fora que irão fazer a manutenção do software. Para IEEE (1998, p.1) manutenção de software “é caracterizada pela modificação de um produto de software já entregue ao cliente, para a correção de eventuais erros, melhora em seu desempenho, ou qualquer outro atributo, ou ainda para adaptação desse produto a um ambiente Modificado.”.
  • 47. 48 Esta fase envolve: * Mudanças no software para corrigir defeitos e deficiências que foram encontrados durante a utilização pelo usuário * Novas funcionalidades para melhorar a aplicabilidade e usabilidade do software. 9.4 PERFORMANCE Performance é uma característica que deve ser analisada durante todo o processo de criação de um software. Se um software é produzido sem a preocupação com a performance, o tempo de execução irá decair muito ou a necessidade de hardwares mais potentes será requerida. Para se saber se o software tem essa característica, boa ou não, precisamos ter como base outros softwares para poder se comparar as duas situações, só assim ficará claro a diferença entre as duas aplicações e a sua performance perante a outra. Para se calcular a performance de um software é feito um teste chamado Benchmarks, que são testes de desempenho para várias características do software, desde a sua robustez até seu tempo de resposta. 9.5 TAMANHO DO CÓDIGO O Tamanho do código está relacionado à facilidade de manutenção e ao tempo de desenvolvimento de uma aplicação. Pode-se através desta métrica verificar o nível de trabalho empregado para o desenvolvimento de uma aplicação.
  • 48. 49 10 ANÁLISE COMPARATIVA DAS FERRAMENTAS JBOSS SEAM E RUBY ON RAILS 10.1 METODOLOGIA PARA DESENVOLVIMENTO DO TRABALHO Procurando obter conhecimento atualizado e útil no processo de desenvolvimento deste projeto, os materiais de estudo e pesquisas foram obtidos através da Internet, e-books e professores. Devido ao fato de Ruby on Rails ser uma tecnologia totalmente nova aos autores, primeiramente um estudo foi realizado para adquirir o conhecimento necessário no desenvolvimento deste projeto. Durante o curso de graduação, teve-se um breve contato com JEE, no entanto um estudo mais aprofundado das diversas tecnologias existentes no universo JEE e principalmente em Jboss Seam foi realizado pela equipe. O desenvolvimento de protótipos empregando as tecnologias estudadas foi algo freqüente durante este projeto, pois somente através destes protótipos foi possível avaliar os diversos fatores presentes no desenvolvimento e planejamento de determinado problema do mundo real. O estudo desenvolvido nos proporcionou o entendimento de algumas dificuldades encontradas na fase de implementação, no ponto de vista das duas tecnologias, Jboss Seam e Ruby on Rails. Através desse estudo foi apresentado uma comparação de aspectos relevantes como Curva de aprendizado, Tempo de desenvolvimento, Facilidade de manutenção, Performance e Tamanho do código. Através desse projeto, foi apresentada uma crítica de ambas as tecnologias, evidenciando suas principais características positivas e seus pontos negativos. O desenvolvimento de uma pequena aplicação em ambos os frameworks, Jboss Seam e Ruby on Rails, exemplificou alguns aspetos levantados durante os estudos. A visão geral do sistema, assim como o caso de uso, requisitos funcionais e não funcionais, referencias cruzadas, mapa do site e os wireframes podem ser vistos nos Apêndices A,B,C,D,E e F respectivamente. Para a comparação da curva de aprendizado, foi levado em conta a facilidade do entendimento de cada framework até estar apto à desenvolver o aplicativo. O tempo de desenvolvimento foi medido e comparado de acordo com as horas necessárias para o aplicativo ficar totalmente completo em ambas as tecnologias.
  • 49. 50 Para a análise da facilidade de manutenção foi determinada a inclusão de duas funcionalidades para cada aplicativo. As funcionalidades definidas foram, envio de e-mail e upload/download de arquivos. Uma das comparações mais complicadas de se realizar neste projeto, foi referente à performance entre os dois frameworks. Esta comparação deveria ser realizada utilizando-se um método que pudesse ser confiável e desejavelmente de uma forma única para ambos os frameworks. Através de pesquisas, foi localizado um aplicativo Web que possibilitaria esta comparação entre os frameworks. Trata-se de um aplicativo Web denominado New Relic (http://www.newrelic.com), que tem como objetivo o debug da aplicação em runtime. Este aplicativo Web para debug permite a visualização de várias métricas do programa Web como, por exemplo, uso de processador, tempo de resposta, tempo das transações com acesso ao banco de dados, tempo de execução de eventos entre outras métricas relativas a outros quesitos. O New Relic é configurável em vários servidores Web estando, no entanto limitado às plataformas Ruby e Java. Para configuração do New Relic é necessário apenas realizar o download do Agente New Relic e configurar o servidor Web utilizado conforme orientações da equipe do New Relic para o que agente possa ser inicializado juntamente com o Servidor de Aplicativos. Após a configuração ser realizada e o servidor inicializado, o agente New Relic registra as métricas e envia para o servidor New Relic, permitindo então a visualização das métricas no site do aplicativo. Trata-se de uma ferramenta utilizada por grandes empresas para analise dos seus aplicativos Web. Empresas como 37signals, at&t, ATLASSIAN, CBS Interactive, The Washington Post entre mais de quatro mil utilizam-se deste aplicativo. Por fim, foi comparado o tamanho do código necessário para o desenvolvimento das aplicações em ambos os frameworks.
  • 50. 51 11 ANÁLISE DOS RESULTADOS 11.1 Curva de Aprendizado  Ruby on Rails Mesmo Ruby on Rails sendo algo totalmente novo para os autores desse projeto, a curva de aprendizado foi considerada pequena, devido às facilidades que a linguagem Ruby oferece e a grande legibilidade dos códigos. Um exemplo de legibilidade do código pode ser visto abaixo: class Service < ActiveRecord::Base belongs_to :account has_many :tasks, :dependent=>:destroy validates_associated :account validates_presence_of :name,:account,:description,:value end Quadro 8 - Exemplo de legibilidade de código Ruby on Rails – Elaboração dos autores, 2010 O bloco de código acima se refere ao model da classe de serviço. belongs_to :account, indica que o serviço pertence a uma conta. has_many :tasks, indica que serviço tem muitas tarefas(contratos) , e o dependent => :destroy indica que caso o serviço for deletado, a task(contrato) também será deletada. Um exemplo de facilidade seria a criação da tabela da classe acima no banco de dados. Para gerar essa tabela o seguinte comando é utilizado: ruby script/generate scaffold Service account:references name:string description:text Quadro 9 – Script de criação do scaffold em Ruby on Rails – Elaboração dos autores, 2010 Feito isso, basta apenas migrar os dados para o banco com o seguinte comando. rake db:migrate Quadro 10 – Comando de migração para o banco de dados – Elaboração dos autores, 2010 Outro ponto que abstrai bastante o programador das configurações são as convenções que o Rails sugere, facilitando ainda mais a curva de aprendizado para o programador.
  • 51. 52 O tempo de aprendizado para poder estar apto a desenvolver o sistema de testes para esse projeto em Ruby on Rails, foi de 9 semanas. Porém vale ressaltar que este ponto é bastante relativo e varia muito de uma pessoa para outra.  Jboss Seam Devemos levar em consideração o fato que os autores deste projeto já tiveram contato com a linguagem de programação Java durante o curso de graduação nas disciplinas Programação I, II e III. Mesmo contando com esta experiência na linguagem Java foi encontrada certa dificuldade no aprendizado da utilização do framework Seam, tornando a curva de aprendizagem um pouco mais acentuada, com tempo total de 14 semanas. Devido ao fato de Jboss Seam abstrair um grande número de tecnologias, como por exemplo, Java Server Faces, JPA, RichFaces, Hibernate torna-se necessário que o desenvolvedor tenha uma breve noção sobre cada tecnologia e como cada uma esta incorporada ao framework. Um fator que interfere no aprendizado é a pouca documentação em português, dificultando a assimilação da documentação disponível.  Considerações finais da curva de aprendizado Ruby on Rails no ponto de vista dos autores destacou-se neste quesito por sua maior facilidade de aprendizado. 11.2 Tempo de Desenvolvimento  Ruby on Rails Depois de muito estudo, freqüentando fóruns, lendo livros e e-books, foi dado inicio ao desenvolvimento do sistema para testes. O sistema apresentado é o mesmo desde o inicio do estudo do framework, e o tempo gasto para o desenvolvimento do mesmo em Ruby on Rails foi de vinte horas no total. Com o entendimento dos problemas que aconteceram
  • 52. 53 durante o desenvolvimento e o tempo gasto com buscas e pesquisas para resolver tais desvios, os autores estimam um remake do mesmo projeto em aproximadamente dez horas de desenvolvimento ou menos.  Jboss Seam A fase de desenvolvimento foi realizada concorrentemente à assimilação do conteúdo de livros, sites e e-books. O processo de desenvolvimento no Jboss Seam teve seu start pela implementação do banco de dados. Após o banco de dados estar implementado, através da perspectiva Bottom-up foi realizado o Scaffolding com a ferramenta Seam-gen15. Após este processo começou a ser desenvolvido e configurado conforme as necessidades da aplicação definida. Através da ferramenta Seam-gen, o desenvolvedor tem a capacidade de iniciar o desenvolvimento rapidamente, pois vários dos pacotes de classes de componentes, artefatos de configuração são automaticamente gerados para o ambiente definido na execução do Seam-gen. Após a realização destes passos, a assimilação do conteúdo teórico foi necessário para dar continuidade ao desenvolvimento. Não se trata apenas do estudo do Framework Seam, mas de todas as tecnologias inclusas. As tecnologias inseridas neste projeto são JPA, RichFaces, Java Server Faces, Java Mai e Hibernate. A integração entre estas tecnologias é realizado pelo Framework Seam, o necessário então é saber utilizá-las de acordo com as necessidades. O tempo necessário para o desenvolvimento do mesmo foi de 45 horas. Como já citado e sendo importante salientar, o start do desenvolvimento se deu de uma forma rápida através do Seam-gen, no entanto a continuação esqueleto criado foi o principal desafio. Com a experiência adquirida durante a fase de desenvolvimento, é estimado que em aproximadamente 20 horas fosse possível desenvolve-lo até a fase atual. 15 Seam-gen é uma fabrica de aplicações. Simplificando, é uma ferramenta que tem como finalidade criar o projeto esqueleto, permitindo que o desenvolvedor tenha seu foco direcionado ao desenvolvimento com o mínimo de tempo gasto realizando configurações e instalações. (Traduçao Nossa) – Manning Seam in Action Capitulo 2 pagina 35
  • 53. 54  Considerações finais do tempo de desenvolvimento O desenvolvimento utilizando-se Ruby on Rails tornou-se mais fácil e mais rápido devido à simplicidade do código e a agilidade que as convenções ao invés de configurações oferecem e também pela não necessidade de reiniciar o servidor quando se modifica o código fonte. Isso tudo simplifica e possibilita a agilidade o processo de desenvolvimento e aprendizado. 11.3 Facilidade de manutenção Com o sistema pronto, o próximo passo era a comparação na facilidade de manutenção de Ruby on Rails e JBoss Seam. Para abordar esse tópico, os autores dispuseram de incrementar no sistema a possibilidade do usuário poder fazer upload de arquivos e envio de e-mails. O cenário para essas opções ficou da seguinte maneira:  O usuário Empresa pode fazer upload de arquivos para anexar aos seus serviços oferecidos, tais como, Termo de Contrato, Formulários, fotos, etc.  O usuário Cliente poderá então, apenas, fazer download desses anexos.  A parte de e-mail foi implementada juntamente com o Contrato.  Quando um Cliente contrata algum serviço de qualquer Empresa, um e-mail é enviado para ambas as partes, com todos os dados desse contrato. Quadro 11 - Exemplo de Comparação Java x Ruby – Elaboração dos autores, 2010  Ruby on Rails Em Ruby on Rails esses dois aprimoramento do sistema foi muito fácil. O tempo para programar essas ferramentas foi de quatro horas contando com pesquisa e desenvolvimento. Em Ruby on Rails, tanto no upload como no envio de e-mail, foi necessário a instalação de plugins. Para upload o plugin usado foi o paperclip, disponível em (http://github.com/thoughtbot/paperclip). Para a instalação do plugin, deve-se abrir o prompt de comando e entrar na pasta do projeto criado. Feito isso basta digitar a linha de comando abaixo: ruby script/plugin install git://github.com/thoughtbot/paperclip.git Quadro 12 Script para instalar plugin – Elaboração dos autores, 2010
  • 54. 55 Isso irá baixar o plugin diretamente do repositório oficial do paperclip e instalá-lo. Uma das configurações que o paperclip oferece e o filtro de tipo de arquivos para envio. Para esse sistema, foi configurado o envio apenas de .pdf, .doc e .jpg. Esse filtro é feito apenas com esse código abaixo: validates_attachment_content_type :arquivo, :content_type => %w(application/msword, application/pdf, image/jpg) Quadro 13 – Código para filtrar extensões de arquivos do paperclip – Elaboração dos autores, 2010 E para o envio de e-mail foi utilizado o plugin action_mailer_optional_tls, disponível em (http://github.com/collectiveidea/action_mailer_optional_tls). Para a instalação do plugin, deve-se abrir o prompt de comando e entrar na pasta do projeto criado. Feito isso basta digitar a linha de comando abaixo: ruby script/plugin install git://github.com/collectiveidea/action_mailer_optional_tls.git Quadro 14 – Script para instalar plugin – Elaboração dos autores, 2010 Após instalado foram necessário apenas essas 4 configurações listadas abaixo: 1. Especificar o modo de envio dos e-mails: config.action_mailer.default_content_type = 'text/html' config.action_mailer.smtp_settings = { :tls => true, :address => "smtp.gmail.com", :port => "587", :authentication => :plain, :user_name => "login@gmail.com", :password => "senha" } Quadro 15 – Configuração do servidor de e-mail em Ruby on Rails – Elaboração dos autores, 2010 2. Criar uma classe informando quem receberá o e-mail, o assunto do e-mail e o conteúdo.
  • 55. 56 class ContractNotifier < ActionMailer::Base def create_notification(task) recipients %("#{task.customer.name}" <#{task.customer.email}>, "#{task.firm.name}" <#{task.firm.email}>) subject "[Ruby on Rails] Novo serviço contratado!" body :task => task end end Quadro 16 Configuração de envio de e-mail em Ruby on Rails – Elaboração dos autores, 2010 Recipients se refere a quem será enviado o e-mail. Exemplo, “TCC” <tcc@unisul.br>. Subject é o assunto do e-mail. Body é o texto que será impresso no e-mail. 3. Criar uma classe com o nome de create_nofitication, que é o nome do método criado no exemplo acima. Essa nova classe que irá constar o corpo do e-mail, ou seja, todo texto que será enviado. Como no exemplo abaixo: Olá <%= @task.firm.name %>, O cliente <%= @task.customer.name %> contratou o seu serviço de "<%= @task.service.name %>". Dados do serviço: Nome: <%= @task.service.name %> Descrição: <%= @task.service.description %> Valor: R$<%= @task.service.value %> Dados do cliente: Nome: <%= @task.customer.name %> E-mail: <%= @task.customer.email %> Endereço: <%= @task.customer.address %> CPF: <%= @task.customer.account.cpf_cnpj %> Telefone: <%= @task.customer.account.phone %> --- Ruby on Rails - Sistema de Testes Data: <%= Time.now %> Quadro 17 – Exemplo de mensagem a ser enviada em Ruby on Rails – Elaboração dos autores, 2010 O código acima enviaria um e-mail como esse:
  • 56. 57 Olá Empresa01, O cliente José Pereira contratou o seu serviço de "Programação para Web". Dados do serviço: Nome: Programação para Web Descrição: Criação de sites na em geral. Valor: R$400.0 Dados do cliente: Nome: José Pereira E-mail: josepereira@unisul.br Endereço: rua De Sempre, Vila Nova, Imbituba, Santa Catarina, Brasil CPF: 056102301-82 Telefone: (48)3255-0000 --- Ruby on Rails - Sistema de Testes Data: Mon May 17 12:39:55 Quadro 18 – Exemplo de e-mail enviado em Ruby on Rails – Elaboração dos autores, 2010 4. Após essas configurações, basta chamar o método juntamente após a criação de um contrato entre Cliente e Empresa, usando o exemplo abaixo: ContractNotifier.deliver_create_notification(@task) Quadro 19 Comando para enviar e-mail em Ruby on Rails – Elaboração dos autores, 2010 ContractNotifier = Nome da Classe com os dados de envio. deliver = método do ActionMailer que informa que será enviado um e-mail. create_notification = Nome do método dentro da classe ContractNotifier, que recebe como parâmetro o serviço contratado no momento.  Jboss Seam A implementaçao destas funcionalidades através do framework Seam, foi razoavelmente rápida. O tópico upload/download de arquivos foi mais trabalhoso para se realizar.
  • 57. 58 O framework Seam prove suporte para se trabalhar com emails. As configurações necessárias para se implementar esta funcionalidade são mínimas. Primeiramente devemos configurar o acesso ao servidor SMTP desejado para o envio do email. Esta configuração é realizada no arquivo Components.xml, localizado na pasta WEB-INF. Abaixo pode-se verificar como deve ser esta configuração; <mail:mail-session host="smtp.gmail.com" password="senhaemail" port="587" username="email@gmail.com"/> Quadro 20 - Exemplo da configuração do serviço de e-mail– Elaboração dos autores, 2010 Após realizada esta configuração, foi criado um componente Seam identificado como emailService, na qual possui um método sendMessage() que realiza toda a ação de envio de e- mail. Abaixo o código fonte do método sendMessage(); @Asynchronous public void sendMessage(@Duration long delay, String template,List l,Cliente c,Servicos s) { this.serv=s; this.cli=c; for (int i = 0; i < l.size(); i++) { rep=(Representante)l.get(i); System.out.println("Email representante: "+rep.getUsuario().getEmail()); try { //Contexts.getEventContext().set("info", infoNeededForTemplate); System.out.println("Renderizando"); renderer.render(template); System.out.println("Renderizado"); } catch (Exception e) { // suppress information. //logger.error(e.getMessage()); e.printStackTrace(); } } } Quadro 21 - Exemplo do método de envio de e-mail– Elaboração dos autores, 2010 Nota-se a inclusão da anotação @Asynchronous antes da definição do método. Está anotação indica que este método será assíncrono e proporcionará ao usuário mais rapidez na exibição da pagina. A objeto/método responsável pela renderização da pagina e envio é o renderer.render(String template). Durante a implementação desta funcionalidade foi verificado que o usuário ao executar a ação de contratar um serviço, aguardava a renderização da pagina de email, a conexão ao servidor SMTP configurado, o envio do email para somente após este processo ser
  • 58. 59 exibida a pagina de serviço contratado. Este processo tornava-se demorado no entanto, com a adição desta anotação antes do método, a renderização do email é realizado em background e o usuário não nota este comportamento durante a contratação do serviço. A implementação do layout do e-mail é realizado através de uma taglib apropriada (xmlns:m="http://jboss.com/products/seam/mail") para tal. Abaixo se pode visualizar o arquivo que renderiza o email da aplicação; <m:message xmlns="http://www.w3.org/1999/xhtml" xmlns:m="http://jboss.com/products/seam/mail" xmlns:h="http://java.sun.com/jsf/html" xmlns:s="http://jboss.com/products/seam/taglib" xmlns:p="http://jboss.com/products/seam/pdf"> <m:from name="Sistema Web Seam"/> <m:to name="#{emailService.rep.nome}">#{emailService.rep.usuario.email}</m:to> <m:subject>Sistema Web - Seam</m:subject> <m:body> <p><h:outputText value="Novo Servico Solicitado! " style="FONT-SIZE: x-large; FONT-WEIGHT: bold; COLOR: #0080ff;" /></p> <p><h:outputText value="Ola " />#{emailService.rep.nome},</p> <p><h:outputText value="O cliente " />#{emailService.cli.nome},<h:outputText value="contratou o seu servico do tipo '" />#{emailService.serv.tipoServico.descricao}<h:outputText value="'." /></p> <p><h:outputText value="Dados do Servico: " style="FONT-WEIGHT: bold; COLOR: #0080ff;" /></p> <p><h:outputText value="Tipo: " style="FONT-WEIGHT: bold;" />#{emailService.serv.tipoServico.descricao}</p> <p><h:outputText value="Nome: " style="FONT-WEIGHT: bold;" />#{emailService.serv.descricao}</p> <p></p> <p><h:outputText value="Dados do Cliente: " style="FONT-WEIGHT: bold; COLOR: #0080ff;" /></p> <p><h:outputText value="Nome:" style="FONT-WEIGHT: bold;" />#{emailService.cli.nome}</p> <p><h:outputText value="Email: " style="FONT-WEIGHT: bold;" />#{emailService.cli.usuario.email}</p> <p><h:outputText value="Endereco: " style="FONT-WEIGHT: bold;" />#{emailService.end}</p> <p><h:outputText value="CPF: " style="FONT-WEIGHT: bold;" />#{emailService.cli.cpf}</p> <p>Mensagem Automatica, por favor, nao responda.</p> <p></p>
  • 59. 60 <p></p> <s:graphicImage id="image" value="/layout/seam.png" fileName="seam.png"> </s:graphicImage> <p><b style="COLOR: #0080ff;">Powered by SEAM FRAMEWORK</b></p> </m:body> </m:message> Quadro 22 - Exemplo do arquivo de renderização de e-mails – Elaboração dos autores, 2010 Abaixo podemos visualizar a pagina HTML enviada; Novo Servico Solicitado! Ola Roberto Carlos Bender, O cliente Guilherme Serna Martins,contratou o seu servico do tipo 'Segurança'. Dados do Servico: Tipo: Segurança Nome: Instalaçao de Cameras (C/S Audio) Dados do Cliente: Nome:Guilherme Serna Martins Email: mawcor@gmail.com Endereco: Rua Lucio Machado, Vila Nova, Imbituba, SC, Brasil, 88780000 CPF: 04999335913 Mensagem Automatica, por favor, nao responda. Powered by SEAM FRAMEWORK Quadro 23 - Exemplo do e-mail gerado – Elaboração dos autores, 2010 O tempo quantificado para o desenvolvimento desta funcionalidade foi de 1 hora e meia. Como já dito anteriormente, o upload e download de arquivos necessitou-se de um tempo maior para se programar. Para tal foi necessário criar uma tabela no banco de dados
  • 60. 61 para registrar as informações de cada upload realizado. Na pesquisa por soluções, preferiria que os dados ficassem salvos no sistema de arquivos do servidor ou local na rede, mas devido ao tempo disponível para o desenvolvimento optei por realizar da forma como consegui fazer, salvar os dados do arquivo em uma tabela do banco de dados. Abaixo se pode ver o código fonte da renderizaçao do componente Upload; <h:form enctype="multipart/form-data"> <rich:panel> <f:facet name="header">Upload Attachment</f:facet> <s:decorate id="fileUploadDecoration" template="layout/edit.xhtml"> <ui:define name="label">Attachment</ui:define> <s:fileUpload id="file" data="#{attachmentHome.instance.data}" contentType="#{attachmentHome.instance.contentType}" fileName="#{attachmentHome.instance.name}" fileSize="#{attachmentHome.instance.size}" /> </s:decorate> Quadro 24 - Exemplo do arquivo da view – Elaboração dos autores, 2010 Uma vez o atributo data da tag s:fileUpload configurada para o atributo data da instancia attachmentHome basta apenas chamar o método persist() para realizar o upload do arquivo. Para a realização do download foi criado um outro componente Seam denominado downloadAttachment, na qual esta definido o método download() abaixo; public String download() { Attachment attachment = entityManager.find(Attachment.class, attachmentId); HttpServletResponse response = (HttpServletResponse)extCtx.getResponse(); response.setContentType(attachment.getContentType()); response.addHeader("Content-disposition", "attachment; filename="" + attachment.getName() +"""); try { ServletOutputStream os = response.getOutputStream(); os.write(attachment.getData()); os.flush(); os.close(); facesContext.responseComplete(); } catch(Exception e) { log.error("nFailure : " + e.toString() + "n"); } return null; } Quadro 25 - Exemplo do método para download – Elaboração dos autores, 2010 Através do método entityManager.find() e possível localizar o id do anexo solicitado e por meio do os.write() obter os dados do arquivo solicitado. O tempo quantificado para a realização desta funcionalidade foi de 3 horas.
  • 61. 62  Considerações finais da facilidade de manutenção Através destas implementações propostas procuramos avaliar a facilidade de adicionarmos novas funcionalidades nos projetos atuais. Foi verificado que ambos os frameworks permitiram inserir as funcionalidades propostas de forma fácil. No framework Ruby on Rails estas funcionalidades foram obtidas através das instalações de plugins para permitir as funcionalidades de Upload e envio de emails. Na plataforma JBoss Seam, no entanto foi apenas necessário incluir taglibs apropriadas para tais funcionalidades não necessitando realizar nenhuma instalação ou download de arquivos de terceiros. Pode-se então concluir que tanto JBoss Seam quanto Ruby on Rails possuem facilidade de manutenção equivalentes, sendo que JBoss Seam não necessita de instalação de plugins para essas funcionalidades. 11.4 Performance Performance é um termo muito complexo na qual envolve muitos fatores como, Sistema Operacional utilizado, quantidade de memória, processador, tecnologia empregada, fatores estes que podem ocasionar o mascaramento da realidade se não for corretamente analisados. Para a realização da comparação entre estas tecnologias de desenvolvimento definimos alguns pontos importantes.  Utilizar um único servidor para ambos os frameworks. Ou seja, mesmo hardware e SO (Processador Intel Core 2 Quad Q8200, 2.33Ghz 4gb DDR2/800Mhz, Windows 7 32bits).  Utilização do mesmo SGBD (PostgreSQL 8.4).  Acessar a aplicação remotamente através da rede para não haver interferências externas no servidor de aplicação. Como já citado, utilizamos a aplicação Web New Relic para a medição das métricas de desempenho em ambos ambientes. Realizamos os seguintes testes nas aplicações:  Autenticação no Sistema  Logout no Sistema  Criação de 1 serviço
  • 62. 63  Contratar 1 serviço  Criar 1 usuário  Criar 100 Usuários  Criar 1000 Usuários  Criar 100 Serviços  Criar 1000 Serviços A configuração dos ambientes de desenvolvimento foram: Jboss Seam Ruby on Rails Versão da Linguagem Java 1.6.0_20 Ruby 1.8.7 Versão do Framework 2.2.0.GA Rails 2.3.8 IDE Eclipse GALILEO 3.5.2 NetBeans 6.8 Banco de Dados PostgreSQL 8.4 PostgreSQL 8.4 Servidor JBoss 5.1.0.GA Mongrel 1.1.5 Quadro 26 – Configuração dos ambientes de desenvolvimento. Elaboração dos autores, 2010. 11.4.1 Teste - Login Neste teste proposto, iremos realizar o login no sistema. Na realização deste procedimento, o sistema deverá verificar se as credenciais inseridas na pagina de login são realmente de usuários cadastrados e após criar a sessão para o usuário. Neste teste está sendo medido o desempenho do evento gerado ao se clicar no botão Login.
  • 63. 64 Gráfico 1 – Tempo de resposta na realização do login. Elaboração dos autores, 2010. Gráfico 2 – Utilização do processador na realização do login. Elaboração dos autores, 2010. Considerações Finais Podemos claramente notar a rapidez de execução na plataforma Ruby on Rails nesta operação. A versão 1.9.1da linguagem Ruby obteve um resultado melhor em comparação com a versão 1.8.7. A plataforma Java foi em média 849% mais lento que o Ruby on Rails (versão 1.9.1 do Ruby) em tempo de execução.
  • 64. 65 Java também obteve um processamento muito maior para executar esta tarefa conforme pode-se verificar no Gráfico 2. 11.4.2 Teste – Logout Este teste proposto tem como objetivo registrar as métricas do servidor no evento do botão Sair, na qual o servidor deve processar este evento, realizando a finalização da sessão do usuário e exibir a pagina de login. Gráfico 3 – Tempo de resposta na realização do logout. Elaboração dos autores, 2010.
  • 65. 66 Gráfico 4 - Utilização do processador na realização do logout. Elaboração dos autores, 2010. Considerações Finais Neste processo verificamos a rapidez em que Ruby on Rails executa o logout no servidor. Ruby on Rails executa está tarefa muito mais rapidamente que o ambiente Java, obteve um tempo de resposta mais rápido e um processamento muito menor do que no ambiente Java. Ruby on Rails executou a tarefa mais rapidamente e utilizando menos processamento. 11.4.3 Teste – Criar Serviço Neste teste, serão registradas as métricas do software na execução da criação de um serviço. Trata-se da inclusão do registro no banco de dados e a exibição da pagina informando que o serviço foi criado com sucesso.
  • 66. 67 Gráfico 5 – Tempo de resposta na criação de um serviço. Elaboração dos autores, 2010. Gráfico 6 – Utilização do processador na criação de um serviço. Elaboração dos autores, 2010. Considerações Finais Podemos verificar que o ambiente Ruby on Rails obteve um tempo de resposta muito melhor que o ambiente Java. Java obteve a média de 334,6 ms de tempo de resposta
  • 67. 68 contra 139 ms de Ruby on Rails utilizando a versão 1.8.7 da linguagem Ruby e 59,2 ms utilizando a versão 1.9.1 da linguagem Ruby conforme pode-se verificar no Gráfico 7 abaixo. Gráfico 7 – Média do tempo de resposta na criação de um serviço. Elaboração dos autores, 2010. A plataforma Ruby destacou-se também por utilizar muito pouco o processador, uma média de 0,37% na versão Ruby 1.8.7 e 0,0174% na versão 1.9.1 conforme verifica-se no Gráfico 8 abaixo. Gráfico 8 - Média do tempo de resposta na criação de um serviço. Elaboração dos autores, 2010.
  • 68. 69 Ruby on Rails obteve um tempo de resposta e processamento muito melhor que a plataforma Java neste teste. 11.4.4 Teste – Contratar Serviço Neste teste proposto, é registrado as métricas no evento de criação de um serviço. Trata-se de uma inclusão no banco de dados do serviço contratado, do envio de uma mensagem de e-mail ao usuário da empresa fornecedora do serviço e da exibição da página informando que o serviço foi contratado com sucesso. Gráfico 9– Tempo de resposta na contratação de um serviço. Elaboração dos autores, 2010.
  • 69. 70 Gráfico 10 – Utilização do processador na contratação de um serviço. Elaboração dos autores, 2010. Considerações Finais Podemos verificar neste teste que a plataforma Java obteve melhores resultados no tempo de resposta à ação de contratação de serviço. Este cenário foi obtido devido á facilidade encontrada na plataforma Java na configuração de eventos assíncronos. O evento chamado para enviar o e-mail aos destinatários foi configurado para ser executado de forma assíncrona, ou seja, o envio de e-mail é enviado após a renderização da página de confirmação do serviço contratado. Esta característica permitiu que o Java se sobressaísse sobre a plataforma Ruby on Rails, uma vez que na execução deste comando no Ruby on Rails o usuário aguarda o envio de e-mail para somente após receber a confirmação. Na plataforma Java, o envio de email é executado em background e o usuário obtém uma resposta de que uma mensagem de e-mail será enviada. Neste teste não foi possível realizar o teste com a versão 1.9.1 da plataforma Ruby devido a incompatibilidades apresentadas com a versão 1.8.7. Java neste teste se destacou no tempo de resposta devido a sua facilidade de implementação da funcionalidade de eventos assíncronos através de anotações na assinatura do evento de envio de email.
  • 70. 71 11.4.5 Teste - Criar Usuário O teste proposto foi a criação de um usuário. Para a criação do usuário são inseridas informações sobre o usuário do sistema, informações pessoais e endereço. Gráfico 11 – Tempo de resposta na criação de um usuário. Elaboração dos autores, 2010. Gráfico 12 – Utilização do processador na criação de um usuário. Elaboração dos autores, 2010. Considerações Finais
  • 71. 72 Neste teste verificamos que Ruby on Rails obteve um melhor tempo de resposta e um menos consumo de processamento. 11.4.6 Teste – Criar 100 Usuários Neste teste são criados cem usuários através de um script. Poderemos verificar o desempenho das plataformas na execução em massa de inclusões no banco de dados. Gráfico 13 – Tempo de resposta na criação de cem usuários. Elaboração dos autores, 2010. Gráfico 14 – Utilização do processador na criação de cem usuários. Elaboração dos autores, 2010.
  • 72. 73 Considerações Finais Podemos verificar através dos resultados obtidos que a plataforma Java obteve melhores resultados do que a plataforma Ruby. A aplicação desenvolvida com o framework Jboss Seam obteve um desempenho muito melhor do que o aplicativo desenvolvido com o framework Ruby on Rails. Com a atualização da plataforma Ruby da versão 1.8.7 para a versão 1.9.1 obtivemos uma diferença enorme dos resultados entre as plataformas Ruby. O desempenho da plataforma Ruby 1.9.1 foi muito melhor no tempo de resposta. Pode-se notar também que a plataforma Ruby 1.9.1 faz mais utilização do processador do que a versão 1.8.7. Neste teste, Java obteve um resultado muito melhor do que a plataforma Ruby. 11.4.7 Teste – Criar 100 Serviços Neste teste são criados cem serviços através de um script. Poderemos verificar o desempenho das plataformas na execução em massa de inclusões no banco de dados. Gráfico 15 – Tempo de resposta na criação de cem serviços. Elaboração dos autores, 2010.
  • 73. 74 Gráfico 16 – Utilização do processador na criação de cem serviços. Elaboração dos autores, 2010. Considerações Finais A plataforma Java obteve um resultado um pouco melhor do que a plataforma Ruby. Assim como no exemplo anterior do item 10.2.4.6, a atualização da plataforma Ruby da versão 1.8.7 para a versão 1.9.1 proporcionou uma grande diferença nos resultados. A versão 1.9.1 da linguagem Ruby obteve um desempenho muito melhor do que a versão 1.8.7. Neste teste proposto, Java obteve melhor resultado no tempo de resposta em comparação com a plataforma Ruby. 11.4.8 Teste – Criar 1000 Serviços Neste teste proposto serão criados mil serviços através de um script desenvolvido. Poderemos verificar o desempenho dos ambientes na execução de tarefas em massa.
  • 74. 75 Gráfico 17 – Tempo de resposta na criação de mil serviços. Elaboração dos autores, 2010. Gráfico 18 – Utilização do processador na criação de mil serviços. Elaboração dos autores, 2010. Considerações Finais Assim como nos outros testes já mostrados, a atualização da plataforma Ruby da versão 1.8.7 para a versão 1.9.1 proporcionou um alto ganho de desempenho. No entanto, a plataforma Java continuou obtendo melhores resultados na execução de tarefas em massa. Java neste teste obteve melhores resultados no tempo de resposta. No quesito uso do processador, Ruby na versão 1.9.1 obteve melhor utilização do processador.
  • 75. 76 11.4.9 Teste – Criar 1000 Usuários Neste teste proposto iremos realizar a criação de mil usuários através de um script desenvolvido. Poderemos verificar a performance dos ambientes na execução de ações em massa. Gráfico 19 – Tempo de resposta na criação de mil serviços. Elaboração dos autores, 2010. Gráfico 20 – Utilização do processador na criação de mil usuários. Elaboração dos autores, 2010. Considerações Finais
  • 76. 77 Na criação de mil usuários, Java mostrou ter mais habilidade em executar tarefas em massa e ser uma linguagem rápida. Ruby, no entanto teve um desempenho inferior obtendo maiores tempo de resposta. 11.5 Tamanho do código  Ruby on Rails Ruby on Rails oferece um comando para verificar o tamanho de sua aplicação. Para usá-lo você terá que entrar na pasta do projeto Rails, através do prompt de comando, e digitar o seguinte código: rake stats Com esse comando, o prompt exibirá uma tela semelhante a essa: Nome Linhas Classes Métodos Controllers 660 9 51 Helpers 26 0 1 Models 76 8 2 View 654 26 0 Total 1416 43 54 Quadro 27 - Métricas do ambiente de desenvolvimento Ruby on Rails. Elaboração dos autores, 2010.  Jboss Seam Abaixo foi feito um levantamento aproximado da quantidade de linhas do código fonte e outras métricas do ambiente Jboss Seam neste projeto. Nome Linhas Classes/Arquivos Métodos Controllers 2961 34 274 Models 87 12 190 View 4998 43 0 Configurações 956 40 0 Total 9002 129 464 Quadro 28 - Métricas do ambiente de desenvolvimento Jboss Seam. Elaboração dos autores, 2010.
  • 77. 78 Considerações finais do Tamanho do código Através das tabelas poderemos verificar que o ambiente Ruby on Rails possui valores muito menores. Podemos então avaliar que o ambiente Ruby on Rails é mais rápido de se realizar alterações e de se escrever tornando-o melhor para a implementação através de um menor consumo de tempo na digitação e compreensão do código fonte.
  • 78. 79 12 CONCLUSÕES Através do trabalho proposto foi realizado um estudo de dois frameworks atuais, Ruby on Rails e Jboss Seam. De acordo com o propósito do trabalho, foi possível identificar fatores positivos e negativos de cada framework proporcionando ao leitor a capacidade de optar ou não pela utilização de um dos frameworks apresentados. De acordo com o primeiro item da comparação mostrado no capitulo 3, a curva de aprendizagem foi menos acentuada em Ruby on Rails do que no Jboss Seam. Como já explicado no Capitulo 10.2.2 obteve-se o tempo de desenvolvimento mais rápido na plataforma Ruby on Rails. Foi definido para a medição da facilidade de manutenção, a inclusão de novos recursos ao sistema. De acordo com o capitulo 10.2.3 as funcionalidades Envio de email e upload e download de arquivos foram definidas para implementação. Tanto em Java como em Ruby on Rails este item de comparação foi relativamente fácil e rápido. Inicialmente foi analisada a curva de aprendizado, onde não foram encontradas muitas dificuldades na linguagem Ruby e no Framework Ruby on Rails. Verificou-se neste projeto que a plataforma Jboss Seam possui aproximadamente nove mil e duas linhas de código e em Ruby on Rails possui aproximadamente mil duzentos e sessenta e oito linhas de código. Jboss Seam, portanto possui aproximadamente seiscentos e dez por cento mais linhas de código do que Ruby on Rails. Deve ser levado em consideração o fato de que Jboss Seam através do Seam-gen realiza a criação de praticamente 70% do código fonte automaticamente, ou seja, a argumentação de que a quantidade de código implica no aumento da complexidade e diminuição da velocidade da implementação deve ser muito bem avaliada, afinal grande parte é gerada automaticamente, sem praticamente nenhum esforço do programador. Percebeu-se que o framework Ruby on Rails teve dificuldades na manipulação de uma grande carga de dados como se pode verificar nos gráficos 21 e 22 abaixo.
  • 79. 80 Gráfico 21 – Média do tempo de resposta na criação de cem usuários. Elaboração dos autores, 2010. Gráfico 22 – Média do tempo de resposta na criação de mil usuários. Elaboração dos autores, 2010. As figuras acima mostraram uma deficiência no framework Ruby on Rails utilizando-se a versão 1.8.7 do Ruby, obtendo a marca de 238.105,2 ms para inserção de 1000 usuários no banco de dados. Este resultado não foi satisfatório e devido a este fato uma nova solução foi pesquisada e encontrada. Com a atualização da linguagem Ruby para versão 1.9.1, registrou- se uma melhora surpreendente na performance da execução de grande carga de dados e também nos outros testes executados. Cabe salientar que não houve alteração na versão do
  • 80. 81 framework Ruby on Rails. Através deste resultado, evidenciou-se a dependência que o framework tem da performance de sua linguagem. Com o aumento da carga de dados, verificou-se que Ruby on Rails na versão 1.8.7 não obteve seu desempenho proporcional ao tempo esperado. No teste exibido no gráfico 21, obteve-se 13932,6 ms na execução dos dados. Com o aumento de carga em 10 vezes, o tempo estimado seria de aproximadamente 139000 ms, o que não ocorreu de acordo com os resultados do gráfico 22, obtendo-se um valor de aproximadamente setenta por cento maior do que o esperado. Com a atualização do Ruby 1.8.7 para a versão 1.9.1, este resultado caiu de setenta por cento a mais da versão 1.8.7 para aproximadamente quatorze por cento mais rápido do que o tempo esperado com um ganho de desempenho de oitenta e cinco por cento. Java, assim como a versão de Ruby 1.9.1 obteve um comportamento satisfatório, atendendo proporcionalmente o aumento da demanda de carga. O desempenho obtido no ambiente Java na criação de 100 usuário foi de 1257,4 ms. Na criação de 1000 usuários o resultado estimado seria de 125740 ms no entanto obteve-se 10068,2 um rendimento de aproximadamente vinte por cento a menos do que o esperado. Abaixo pode-se verificar as médias obtidas nos testes de criação de 100 e 1000 serviços. Gráfico 23 – Média do tempo de resposta na criação de cem serviços. Elaboração dos autores, 2010.
  • 81. 82 Gráfico 24 – Média do tempo de resposta na criação de mil serviços. Elaboração dos autores, 2010. Assim como no exemplo anterior, pode-se claramente verificar a melhora de performance da plataforma Ruby com a sua atualização para a versão 1.9.1. O desempenho da plataforma Ruby na versão 1.8.7 foi de aproximadamente cinco por centro melhor do que o resultado esperado. O desempenho da plataforma Ruby na versão 1.9.1 foi de aproximadamente doze por cento melhor do que o resultado esperado. O desempenho da plataforma Java foi de aproximadamente cinqüenta e três por centro melhor do que o resultado esperado. Java destacou-se e nos surpreendeu com seu desempenho em relação ao Ruby on Rails quando submetido ao processamento severo de grande quantidade de dados. Java conseguiu efetuar as tarefas em um tempo muito menor do que o esperado e isso nos força a crer, ser o Java uma linguagem com indicação para utilização em ambientes de grande processamento e manipulação de dados. Ruby, no entanto se mostrou veloz nas requisições e renderização de páginas, mas deficiente no processamento de grande carga de dados. Com as afirmações acima, obteve-se o seguinte quadro de comparações: JBoss Seam Ruby on Rails Maior facilidade no 14 semanas 9 semanas aprendizado da tecnologia
  • 82. 83 Ruby on Rails. Facilidade de manutenção 4 horas. 4 horas. equivalentes. Ruby on Rails se destacou por sua simplicidade na 9002 linhas de código. 1416 linhas de código. sintaxe e menor quantidade de códigos JBoss Seam destacou-se na Criação de 1000 Usuários = Criação de 1000 Usuários = manipulação de uma grande 10.068,2 ms 238.105,2 ms carga de dados. Dependência que os Melhor performance do mesmo aplicativo, apenas frameworks possuem de suas atualizando a versão do ruby 1.8.7 para a versão 1.9.1. linguagens. Ruby on Rails foi veloz na manipulação de requisições e Logout do sistema = 164 ms Logout do sistema = 64 ms renderização de páginas. Quadro 29 – Quadro de Conclusões. Elaboração dos autores, 2010.
  • 83. 84 13 TRABALHOS FUTUROS.  Migrar o software desenvolvido da versão Ruby on Rails 2.3.8 para a versão Ruby on Rails 3.0.  Migrar o software desenvolvido da versão Jboss Seam 2.0 para a versão Jboss Seam 3.0  Realizar testes no Sistema Operacional Linux.
  • 84. 85 APÊNDICE
  • 85. 86 APÊNCIDE A - Visão geral do Sistema Trata-se de um sistema protótipo, para web, que permitirá o cadastro de usuários em dois tipos diferentes, Empresa e Cliente. A Empresa será capaz de se registrar e atualizar seu cadastro se necessário e através do link “Criar novo Serviço” poderá oferecer seus serviços para os clientes que se cadastrarem no sistema. Além dessa função no menu, a Empresa terá outros dois links para acesso, que são: -Ver meus Serviços solicitados: Mostra todos os serviços cadastrados da Empresa logada. -Ver meus Clientes: Lista todos os Clientes que contrataram o Serviço da Empresa logada. Caso o usuário for um Cliente, ele será capaz de “Solicitar um Serviço”, que listará todos os serviços oferecidos de todas as empresas cadastradas no sistema. Também estará disponível no menu de Cliente o link “Ver meus Serviços solicitados”, que mostrará todos os serviço que o cliente logado contratou. Além da função “Editar Perfil” onde o Cliente irá fazer todas as modificações necessárias para atualizar seu cadastro no sistema.
  • 86. 87 APÊNCIDE B - Casos de uso Figura 3 – Caso de Uso de Empresa. Fonte: Nossa (2010) Figura 4 – Caso de Uso de Cliente. Fonte: Nossa (2010)
  • 87. 88 APÊNCIDE C - Análise de requisitos funcionais e não funcionais. F1 – Autenticação no Sistema Oculto ( ) Descrição: O sistema deve permitir que o usuário autentique-se e tenha autorização para realizar as ações estabelecidas. Requisitos não Funcionais Nome Restrição Categoria Desejável Permanente NF 1.1 Dados Os usuários necessitarão saber Segurança ( ) (X) de acesso seus logins e senha de acesso cadastrados. NF 1.2 Pagina Todo o processo de autenticação, Interface () (X) Única assim como exibição de mensagens de erros será exibido em uma mesma pagina. Quadro 30 - Requisitos F1 – Elaboração dos autores, 2010. F2 – Exibir Informações Cadastrais Oculto ( ) Descrição: O sistema irá permitir que os usuários verifiquem os seus dados cadastrais. Requisitos não Funcionais Nome Restrição Categoria Desejável Permanente NF 2.1 Os usuários só terão acesso a Segurança ( ) (X) Controle de esta função caso estejam Acesso autenticados no sistema. NF 2.2 Botão Em cada pagina haverá um Interface () (X) Solicitar botão na qual permitira alterar os Alteração dados cadastrais. Quadro 31 - Requisitos F2 – Elaboração dos autores, 2010. F3 – Solicitar Alteração Cadastral Oculto ( ) Descrição: O sistema irá permitir que os clientes possam alterar os seus dados cadastrais. Requisitos não Funcionais Nome Restrição Categoria Desejável Permanente NF 3.1 Os usuários só terão acesso a Segurança () (X) Controle de esta função caso estejam Acesso autenticados no sistema. Quadro 32 - Requisitos F3 – Elaboração dos autores, 2010. F4 – Solicitar novo Serviço Oculto ( ) Descrição: O sistema irá permitir que os clientes realizem contratos de serviços das empresas Requisitos não Funcionais Nome Restrição Categoria Desejável Permanente NF 4.1 Os usuários só terão acesso a Segurança () (X) Controle de esta função caso estejam Acesso autenticados no sistema. NF 4.2 Tipos O sistema ira apresentar tipos Especificação ( ) (X) de Serviços cadastrados de serviços na qual
  • 88. 89 o cliente poderá solicitar, portanto pode-se futuramente aumentar essa quantidade. Quadro 33 - Requisitos F4 – Elaboração dos autores, 2010. F5 – Ver meus Serviços solicitados Oculto ( ) Descrição: O sistema irá permitir que o cliente visualize os serviços que ele contratou. Requisitos não Funcionais Nome Restrição Categoria Desejável Permanente NF 5.1 Os usuários só terão acesso a Segurança () (X) Controle de esta função caso estejam Acesso autenticados no sistema. NF 5.2 Dados Cada serviço contratado é Especificação ( ) (X) do Serviço listado, mostrando o nome do serviço, o valor do serviço e o nome da empresa que ofereceu tal serviço. Quadro 34 - Requisitos F5 – Elaboração dos autores, 2010. F6 – Criar novo Serviço Oculto ( ) Descrição: O sistema irá permitir que a empresa cadastre um novo serviço para oferecer aos clientes. Requisitos não Funcionais Nome Restrição Categoria Desejável Permanente NF 6.1 Os usuários só terão acesso a Segurança () (X) Controle de esta função caso estejam Acesso autenticados no sistema. NF 6.2 Cada serviço terá que ser Especificação ( ) (X) Registro inserido o seu nome, descrição e valor em reais. NF 6.3 Edição Cada serviço cadastrado poderá / Exclusão posteriormente ser alterado ou excluído pela Empresa. Quadro 35 - Requisitos F6 – Elaboração dos autores, 2010. F7 - Ver meus Serviços oferecidos Oculto ( ) Descrição: O sistema permitira que a empresa veja todos os seus serviços cadastrados. Requisitos não Funcionais Nome Restrição Categoria Desejável Permanente NF 7.1 Os usuários só terão acesso a Segurança () (X) Controle de esta função caso estejam Acesso autenticados no sistema. NF 7.2 Dados Cada serviço cadastrado é Especificação ( ) (X) do Serviço listado, mostrando o nome do serviço,a descrição do serviço e o valor em reais do serviço. Quadro 36 - Requisitos F7 – Elaboração dos autores, 2010.
  • 89. 90 F8 - Ver meus Clientes Oculto ( ) Descrição: O sistema permitira que a empresa visualize todos os cliente que contrataram seus serviços cadastrados. Requisitos não Funcionais Nome Restrição Categoria Desejável Permanente NF 8.1 Os usuários só terão acesso a Segurança () (X) Controle de esta função caso estejam Acesso autenticados no sistema. NF 8.2 Dados O sistema exibirá todos os Especificação do Serviço serviços que foram contratados. NF 8.3 Dados O sistema exibirá todos os Especificação ( ) (X) do Cliente clientes que contrataram os serviços da empresa. Quadro 37 - Requisitos F8 – Elaboração dos autores, 2010.
  • 90. 91 APÊNCIDE D - Referências Cruzadas Nome Atores Descrição Referencias Cruzadas Autenticar Cliente O usuário deve inserir seu login e F1 Usuário ou senha para autenticação e ter seu Empresa acesso permitido no sistema web. Solicitar Cliente Cliente poderá contratar um serviço F1,F4,F5,F6 Serviços cadastrado no sistema. Criar novo Empresa Empresa poderá cadastrar um novo F1,F4, F6, F7, F8 Serviço serviço que ela oferece. Quadro 38 - Referencias Cruzadas – Elaboração dos autores, 2010.
  • 91. 92 APÊNCIDE E - Mapa do site Figura 5 – Mapa do site. Fonte: Nossa (2010)
  • 92. 93 APÊNCIDE F - Wireframes Página de Autenticação Figura 6 – Tela de login. Fonte: Nossa (2010)
  • 93. 94 Página de registro Figura 7 – Tela de registro. Fonte: Nossa (2010)
  • 94. 95 Página inicial do usuário Empresa Figura 8 – Tela inicial do usuário Empresa. Fonte: Nossa (2010) Criar novo Serviço Figura 9 – Tela para criar novo Serviço (Usuário Empresa). Fonte: Nossa (2010)
  • 95. 96 Ver meus Serviços oferecidos Figura 10 – Tela para ver os Serviços oferecidos (Usuário Empresa). Fonte: Nossa (2010) Ver meus Clientes Figura 11 – Tela para ver Clientes (Usuário Empresa). Fonte: Nossa (2010)
  • 96. 97 Página inicial do usuário Cliente Figura 12 – Tela inicial do usuário Cliente. Fonte: Nossa (2010) Solicitar novo Serviço Figura 13 – Tela para solicitar novo Serviço(usuário Cliente). Fonte: Nossa (2010)
  • 97. 98 Ver meus Serviços Solicitados Figura 14 – Tela para ver os Serviços solicitados(usuário Cliente). Fonte: Nossa (2010)
  • 98. 99 REFERENCIAS BIBLIOGRÁFICAS ALECRIM, Emerson. Conhecendo o Servidor Apache (HTTP Server Project). Disponível em <http://www.infowester.com/servapach.php> Acesso em 19 mai 2009. ANQUETIL,Nicolas. Manutenção de Software. Disponível em <http://www.ucb.br/prg/professores/anquetil/manutencao.php> Acesso em 23 jun 2009. APACHE. Apache Tomcat. Disponível em <http://tomcat.apache.org> Acesso em 19 mai 2009. AZAMBUJA. Trabalho da Semana do SBRC. Disponível em <http://professores.faccat.br/azambuja/index_paradigmas.htm>. Acesso em 12 de maio de 2009, p.1. BORLAND. Customer Profile, Sigma-Aldrich. Disponível em <http://www.borland.com/br/customers/profiles/sigma_aldrich.html>. Acesso em 20 mai 2009. BORTOLASSI,Giuliano. Conhecendo o JEE – Part2. Disponível em <http://jeenoob.blogspot.com/2007/01/conhecendo-o-jee-part2.html> Acesso em 17 mai 2009. DEVDAILY. Using the Runtime method to invoke the garbage collector. Disponível em <http://www.devdaily.com/java/edu/pj/pj010008/pj010008.shtml> Acesso em 16 mai 2009. DUCKETT, Chris. Developer Spotlight: Hitting the Seam with Gavin King. Disponível em <http://www.builderau.com.au/program/java/soa/Developer-Spotlight-Hitting-the-Seam-with- Gavin-King/0,339024620,339285612,00.htm> Acesso em 16 mai 2009. EDIGER, Brad. Advanced Rails. O'Reilly, 2007. 354 p. E-GENIAL. O QUE É RUBY ON RAILS?, Camadas MVC. Disponível em <http://www.egenial.com.br/cursorails/ruby_on_rails> Acesso em: 20 mai 2009. FACCAT. As primeiras máquinas. Disponível em <http://professores.faccat.br/assis/hcomp /PrimeirasMaquinas.html> Acesso em 17 mai 2009.
  • 99. 100 FAYAD, Mohamed; Schmidt, Douglas. Object-Oriented Application Frameworks. Communications of the ACM, New York, v. 40, n. 10, p. 32-38, Oct. 1997. FIALHO JR, Mozart. Dicionário de Informática – Interpretador. 2 Ed. Goiânia: Terra, 2002, p.117. ______. Dicionário de Informática – Linguagem de Maquina. 2 Ed. Goiânia: Terra, 2002, p.123. ______. Dicionário de Informática – Linguagem de Programação. 2 Ed. Goiânia: Terra, 2002, p.123. ______. Dicionário de Informática – Sistema Binário. 2 Ed. Goiânia: Terra, 2002, p.170. FLYNT, Clif. Tcl/Tk, A Developer's Guide. 2. Ed. San Francisco, 2003. FOCALINUX , Características do Apache. Disponível em < http://focalinux.cipsga.org.br/guia/avancado/ch-s-apache.htm >. Acesso em 13 jun 2010. FOLHA ONLINE. Entenda o que é o código-fonte de um programa. Disponível em < http://www1.folha.uol.com.br/folha/informatica/ult124u7618.shtml >. Acesso em 5 mai. 2009. HERCULIANI, Cristóvam Emilio. Desenvolvimento de um Software de autoria para alunos deficientes não-falantes nas atividades de contos e recontos de histórias. Marilia, 2007, p.40. HUSTON. A.B.WATLEY CASE STUDY. Disponivel em < http://in.sun.com/sunnews/success/consolidation/onlinestock.html > . Acesso em 13 jun 2010. ICEA. Instituto de Controle do Espaço Aéreo, Módulo V – Linguagens. Disponível em <http://www.icea.gov.br/ead/anexo/23101.htm> Acesso em 17 mai 2009. IDOC. Conceito de Workflow. Disponível em < www.idoc.inf.br/pdf/Workflow.pdf > Acesso em 28 Jun 2010.
  • 100. 101 JAVAFREE. Java. Disponível em < http://javafree.uol.com.br/wiki/java > Acesso em 27 Jun 2010. ______. Tutorial Java 2: Características Básicas. Disponível em <http://www. javafree.org/artigo/871496/Tutorial-Java-2-Caracteristicas-Basicas.html>. Acesso em 10 mai. 2009. JBOSS. Chapter 3. The contextual component model. Disponível em <http://docs.jboss.org/seam/1.2.1.GA/reference/en/html/concepts.html#d0e2518> Acesso em 18 mai 2009. ______. Framework for Organizing Cross Cutting Concerns. Disponível em <http://www.jboss.org/jbossaop/>. Acesso em 20 mai 2009. JCP. JSRs: Java Specification Requests. Disponível em <http://jcp.org/en/jsr/ detail?id=299>. Acesso em 20 mai 2009. MATZ. An Interview with the Creator of Ruby. Disponível em < http://linuxdevcenter.com/pub/a/linux/2001/11/29/ruby.html >. Acesso em 13 jun 2010. ______. More code browsing questions. Disponível em < http://blade.nagaokaut.ac.jp/cgi- bin/scat.rb/ruby/ruby-talk/2773 >. Acesso em 13 jun 2010. NGUYEN, Binh. Compiled Language. Disponível em <http://linux.about.com/cs/linux101 /g/compiledlanguag.htm>. Acesso em 13 de maio de 2009, p.1. PRADO, Alexandro dos Anjos. JEE - Um caminho prazeroso e interessante! Disponível em <http://www.devmedia.com.br/articles/viewcomp.asp?comp=3747>. Acesso em 14 de maio de 2009. PRICE, Ana Maria de Alencar & TORCANI, Simào Sirineu. Implementação de Linguagens de Programação: Compiladores. Porto Alegre, 2001, 197 pgs. RAILSGUIDE. Getting Started with Rails. Disponível em <http://guides.rubyonrails.org /getting_started.html>. Acesso em 11 de maio de 2009. REDHAT. Seam and jBPM: the todo list example. Disponível em <http://www.redhat.com /docs/manuals/jboss/jboss-eap-4.2/doc/seam/Seam_Reference_Guide/Seam_Tutorial- Seam_and_jBPM_the_todo_list_example.html> Acesso em 19 mai 2009.
  • 101. 102 ______. Using JMX as a Microkernel. Disponível em <http://www.redhat.com/docs/en- US/JBoss_Enterprise_Application_Platform/4.3.0.cp04/html/Server_Configuration_Guide/Th e_JBoss_JMX_Microkernel-Using_JMX_as_a_Microkernel.html>. Acesso em 20 mai 2009. ROESLER, Wolfram. The Hello World Collection. Disponível em <http://www.roesler- ac.de/wolfram/hello.htm>. Acesso em 30 jun 2010. Ruby-Lang. Ver tudo como objeto. Disponível em < http://www.ruby-lang.org/pt/sobre-o- ruby/ >. Acesso em 13 jun 2010. SANTOS, Elomar Nascimento dos. Um pouco mais sobre o Ruby. Disponível em <http://www.elomarns.com/blog/ruby/um-pouco-mais-sobre-o-ruby> Acesso em 17 mai 2009. SAUVÉ, Jacques Philippe. FRAMEWORKS. Disponível em < http://www.dsc.ufcg.edu.br/~jacques/cursos/map/html/frame/oque.htm>. Acesso em 27 Jun. 2010. SOMMERS, Frank. Gavin King Explains JBoss Seam. Disponível em <http://www.artima.com/forums/flat.jsp?forum=276&thread=164452> Acesso em 17 mai 2009. SUN. Web-Tier Application Framework Design. Disponível em <http://java.sun.com/blueprints/guidelines/designing_enterprise_applications_2e/web- tier/web-tier5.html>. Acesso em 14 de maio de 2009. ______. About the Java EE Containers. Disponível em < http://docs.sun.com/app/docs/doc/819-3658/ablmt?l=en&a=view > Acesso em 26 Jun 2010. ______. Model-View-Controller. Disponível Disponível em <http://java.sun.com/blueprints/guidelines/designing_enterprise_applications_2e/web- tier/web-tier5.html>. Acesso em 13 jun 2010. URUBATAN, Rodrigo. Java EE 5 - servidores de aplicação. Disponível em <http://www.urubatan.com.br/java-ee-5-servidores-de-aplicacao/> Acesso em 17 mai 2009. VENNERS, Bill. Garbage Collection, Chapter 9 of Inside the Java Virtual Machine. Disponível em <http://www.artima.com/insidejvm/ed2/gc.html> Acesso em 13 mai 2009.
  • 102. 103 WANGENHEIM, Aldo Von. O que é um Algoritimo?. Disponível em < http://www.inf.ufsc.br/~awangenh/ICC/icc-aula2.pdf >. Acesso em 27 Jun. 2010. WEBDEVELOPERSNOTES. What is web server - a computer of a program?. Disponível em <http://www.webdevelopersnotes.com/basics/what_is_web_server.php> Acesso em 19 mai 2009. WHATIS. Web server. Disponível em <http://whatis.techtarget.com/definition/ 0,,sid9_gci213606,00.html> Acesso em 19 mai 2009.

×