SlideShare uma empresa Scribd logo
1 de 103
Baixar para ler offline
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
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
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.
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.
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.
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
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
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
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
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.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
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)
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;
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.
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.
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.
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.
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).
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)
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).
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)
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.
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)
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).
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.
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
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).
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).
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.
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
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.
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.
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.
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."
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
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
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).
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.
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
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”.
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
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 ).
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)
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.
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.
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.”.
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.
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.
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.
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.
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
Comparação JBoss Seam x Ruby on Rails
Comparação JBoss Seam x Ruby on Rails
Comparação JBoss Seam x Ruby on Rails
Comparação JBoss Seam x Ruby on Rails
Comparação JBoss Seam x Ruby on Rails
Comparação JBoss Seam x Ruby on Rails
Comparação JBoss Seam x Ruby on Rails
Comparação JBoss Seam x Ruby on Rails
Comparação JBoss Seam x Ruby on Rails
Comparação JBoss Seam x Ruby on Rails
Comparação JBoss Seam x Ruby on Rails
Comparação JBoss Seam x Ruby on Rails
Comparação JBoss Seam x Ruby on Rails
Comparação JBoss Seam x Ruby on Rails
Comparação JBoss Seam x Ruby on Rails
Comparação JBoss Seam x Ruby on Rails
Comparação JBoss Seam x Ruby on Rails
Comparação JBoss Seam x Ruby on Rails
Comparação JBoss Seam x Ruby on Rails
Comparação JBoss Seam x Ruby on Rails
Comparação JBoss Seam x Ruby on Rails
Comparação JBoss Seam x Ruby on Rails
Comparação JBoss Seam x Ruby on Rails
Comparação JBoss Seam x Ruby on Rails
Comparação JBoss Seam x Ruby on Rails
Comparação JBoss Seam x Ruby on Rails
Comparação JBoss Seam x Ruby on Rails
Comparação JBoss Seam x Ruby on Rails
Comparação JBoss Seam x Ruby on Rails
Comparação JBoss Seam x Ruby on Rails
Comparação JBoss Seam x Ruby on Rails
Comparação JBoss Seam x Ruby on Rails
Comparação JBoss Seam x Ruby on Rails
Comparação JBoss Seam x Ruby on Rails
Comparação JBoss Seam x Ruby on Rails
Comparação JBoss Seam x Ruby on Rails
Comparação JBoss Seam x Ruby on Rails
Comparação JBoss Seam x Ruby on Rails
Comparação JBoss Seam x Ruby on Rails
Comparação JBoss Seam x Ruby on Rails
Comparação JBoss Seam x Ruby on Rails
Comparação JBoss Seam x Ruby on Rails
Comparação JBoss Seam x Ruby on Rails
Comparação JBoss Seam x Ruby on Rails
Comparação JBoss Seam x Ruby on Rails
Comparação JBoss Seam x Ruby on Rails
Comparação JBoss Seam x Ruby on Rails
Comparação JBoss Seam x Ruby on Rails
Comparação JBoss Seam x Ruby on Rails
Comparação JBoss Seam x Ruby on Rails
Comparação JBoss Seam x Ruby on Rails

Mais conteúdo relacionado

Mais procurados

Java web fj21-- apostila da caelum
Java web fj21-- apostila da caelumJava web fj21-- apostila da caelum
Java web fj21-- apostila da caelumAgenor Neto
 
Automação de Testes de Regressão - Selenium
Automação de Testes de Regressão - SeleniumAutomação de Testes de Regressão - Selenium
Automação de Testes de Regressão - SeleniumMaiele Ranzan
 
Caelum ruby-on-rails-rr71
Caelum ruby-on-rails-rr71Caelum ruby-on-rails-rr71
Caelum ruby-on-rails-rr71Ana Luiza
 
Tcc Mauricio Bento Ghem 2009 - Versão Final
Tcc Mauricio Bento Ghem 2009 - Versão FinalTcc Mauricio Bento Ghem 2009 - Versão Final
Tcc Mauricio Bento Ghem 2009 - Versão Finalimpalador69
 
ESTRATÉGIA DE REAÇÃO EM CALL CENTER: UMA PROPOSTA DE ARQUITETURA
ESTRATÉGIA DE REAÇÃO EM CALL CENTER: UMA PROPOSTA DE ARQUITETURAESTRATÉGIA DE REAÇÃO EM CALL CENTER: UMA PROPOSTA DE ARQUITETURA
ESTRATÉGIA DE REAÇÃO EM CALL CENTER: UMA PROPOSTA DE ARQUITETURASabrina Mariana
 
Manual Quiz Faber
Manual Quiz FaberManual Quiz Faber
Manual Quiz Faberguestf9adc5
 
TCC Virgilio Rocha Ximenes
TCC Virgilio Rocha XimenesTCC Virgilio Rocha Ximenes
TCC Virgilio Rocha XimenesVirgilio Ximenes
 
50718286 apostila-de-asp-net-c-e-visual-basic-net
50718286 apostila-de-asp-net-c-e-visual-basic-net50718286 apostila-de-asp-net-c-e-visual-basic-net
50718286 apostila-de-asp-net-c-e-visual-basic-netThais Rodrigues
 
Tunelamento
TunelamentoTunelamento
TunelamentoTiago
 

Mais procurados (18)

Linguagem C
Linguagem CLinguagem C
Linguagem C
 
Caelum Java
Caelum JavaCaelum Java
Caelum Java
 
Java web fj21-- apostila da caelum
Java web fj21-- apostila da caelumJava web fj21-- apostila da caelum
Java web fj21-- apostila da caelum
 
ink2canvas
ink2canvasink2canvas
ink2canvas
 
Automação de Testes de Regressão - Selenium
Automação de Testes de Regressão - SeleniumAutomação de Testes de Regressão - Selenium
Automação de Testes de Regressão - Selenium
 
Samba
SambaSamba
Samba
 
Caelum ruby-on-rails-rr71
Caelum ruby-on-rails-rr71Caelum ruby-on-rails-rr71
Caelum ruby-on-rails-rr71
 
Tcc Mauricio Bento Ghem 2009 - Versão Final
Tcc Mauricio Bento Ghem 2009 - Versão FinalTcc Mauricio Bento Ghem 2009 - Versão Final
Tcc Mauricio Bento Ghem 2009 - Versão Final
 
ESTRATÉGIA DE REAÇÃO EM CALL CENTER: UMA PROPOSTA DE ARQUITETURA
ESTRATÉGIA DE REAÇÃO EM CALL CENTER: UMA PROPOSTA DE ARQUITETURAESTRATÉGIA DE REAÇÃO EM CALL CENTER: UMA PROPOSTA DE ARQUITETURA
ESTRATÉGIA DE REAÇÃO EM CALL CENTER: UMA PROPOSTA DE ARQUITETURA
 
Manual Quiz Faber
Manual Quiz FaberManual Quiz Faber
Manual Quiz Faber
 
Arduhack rev2
Arduhack rev2Arduhack rev2
Arduhack rev2
 
Monografia - UNISUL
Monografia - UNISULMonografia - UNISUL
Monografia - UNISUL
 
TCC Virgilio Rocha Ximenes
TCC Virgilio Rocha XimenesTCC Virgilio Rocha Ximenes
TCC Virgilio Rocha Ximenes
 
Qemu
QemuQemu
Qemu
 
50718286 apostila-de-asp-net-c-e-visual-basic-net
50718286 apostila-de-asp-net-c-e-visual-basic-net50718286 apostila-de-asp-net-c-e-visual-basic-net
50718286 apostila-de-asp-net-c-e-visual-basic-net
 
Vim
VimVim
Vim
 
Squid
SquidSquid
Squid
 
Tunelamento
TunelamentoTunelamento
Tunelamento
 

Semelhante a Comparação JBoss Seam x Ruby on Rails

Desenvolvimento de sites responsivos utilizando o framework Bootstrap com apl...
Desenvolvimento de sites responsivos utilizando o framework Bootstrap com apl...Desenvolvimento de sites responsivos utilizando o framework Bootstrap com apl...
Desenvolvimento de sites responsivos utilizando o framework Bootstrap com apl...joselialcosta
 
Implementacao e desempenho da virtualizacao no dcomp ufs
Implementacao e desempenho da virtualizacao no dcomp ufsImplementacao e desempenho da virtualizacao no dcomp ufs
Implementacao e desempenho da virtualizacao no dcomp ufsEdward David Moreno
 
Fabio virtualizacao (1)
Fabio   virtualizacao (1)Fabio   virtualizacao (1)
Fabio virtualizacao (1)gsabatke
 
A UTILIZAÇÃO DE METODOLOGIAS ÁGEIS PARA A ENTREGA DE SERVIÇOS DE INFRAESTRUTU...
A UTILIZAÇÃO DE METODOLOGIAS ÁGEIS PARA A ENTREGA DE SERVIÇOS DE INFRAESTRUTU...A UTILIZAÇÃO DE METODOLOGIAS ÁGEIS PARA A ENTREGA DE SERVIÇOS DE INFRAESTRUTU...
A UTILIZAÇÃO DE METODOLOGIAS ÁGEIS PARA A ENTREGA DE SERVIÇOS DE INFRAESTRUTU...Marcelo Dieder
 
TCC - METODOLOGIA SCRUM APLICADA AOS PROCESSOS DE GERÊNCIA E DESENVOLVIMENTO ...
TCC - METODOLOGIA SCRUM APLICADA AOS PROCESSOS DE GERÊNCIA E DESENVOLVIMENTO ...TCC - METODOLOGIA SCRUM APLICADA AOS PROCESSOS DE GERÊNCIA E DESENVOLVIMENTO ...
TCC - METODOLOGIA SCRUM APLICADA AOS PROCESSOS DE GERÊNCIA E DESENVOLVIMENTO ...Juliano Oliveira
 
Jspservlets
JspservletsJspservlets
JspservletsTiago
 
plano_de_projeto_controlart_final
plano_de_projeto_controlart_finalplano_de_projeto_controlart_final
plano_de_projeto_controlart_finaluserrx
 
Proj uml restaurante online
Proj uml restaurante onlineProj uml restaurante online
Proj uml restaurante onlineEvandro Gf
 
Desenvolvimento de-robo-movel (1)
Desenvolvimento de-robo-movel (1)Desenvolvimento de-robo-movel (1)
Desenvolvimento de-robo-movel (1)Levi Germano
 
plano_de_projeto_controlart_rascunho
plano_de_projeto_controlart_rascunhoplano_de_projeto_controlart_rascunho
plano_de_projeto_controlart_rascunhouserrx
 
Pasta pablo mota
Pasta pablo motaPasta pablo mota
Pasta pablo motaPablo Mota
 
Análise de ferramentas para gestão de regras de negócio em sistemas de inform...
Análise de ferramentas para gestão de regras de negócio em sistemas de inform...Análise de ferramentas para gestão de regras de negócio em sistemas de inform...
Análise de ferramentas para gestão de regras de negócio em sistemas de inform...Bruno Dadalt Zambiazi
 
Aplicac3a7c3a3o da-abordagem-gqm-para-a-definic3a7c3a3o-de-um-processo-de-eng...
Aplicac3a7c3a3o da-abordagem-gqm-para-a-definic3a7c3a3o-de-um-processo-de-eng...Aplicac3a7c3a3o da-abordagem-gqm-para-a-definic3a7c3a3o-de-um-processo-de-eng...
Aplicac3a7c3a3o da-abordagem-gqm-para-a-definic3a7c3a3o-de-um-processo-de-eng...JADSON SANTOS
 
Monografia - Engenharia de software baseada em modelos um estudo sobre WebML ...
Monografia - Engenharia de software baseada em modelos um estudo sobre WebML ...Monografia - Engenharia de software baseada em modelos um estudo sobre WebML ...
Monografia - Engenharia de software baseada em modelos um estudo sobre WebML ...Gabriel Cabral
 
Html course for_visually_impaired_persons
Html course for_visually_impaired_personsHtml course for_visually_impaired_persons
Html course for_visually_impaired_personsRicardo Schmidt
 
Plano de projeto: Bichos do Campus na Web
Plano de projeto: Bichos do Campus na WebPlano de projeto: Bichos do Campus na Web
Plano de projeto: Bichos do Campus na WebJorge Roberto
 
K19 k23-integracao-de-sistemas-com-webservices-jms-e-ejb
K19 k23-integracao-de-sistemas-com-webservices-jms-e-ejbK19 k23-integracao-de-sistemas-com-webservices-jms-e-ejb
K19 k23-integracao-de-sistemas-com-webservices-jms-e-ejbVinicius Fonseca
 

Semelhante a Comparação JBoss Seam x Ruby on Rails (20)

Desenvolvimento de sites responsivos utilizando o framework Bootstrap com apl...
Desenvolvimento de sites responsivos utilizando o framework Bootstrap com apl...Desenvolvimento de sites responsivos utilizando o framework Bootstrap com apl...
Desenvolvimento de sites responsivos utilizando o framework Bootstrap com apl...
 
Implementacao e desempenho da virtualizacao no dcomp ufs
Implementacao e desempenho da virtualizacao no dcomp ufsImplementacao e desempenho da virtualizacao no dcomp ufs
Implementacao e desempenho da virtualizacao no dcomp ufs
 
Fabio virtualizacao (1)
Fabio   virtualizacao (1)Fabio   virtualizacao (1)
Fabio virtualizacao (1)
 
A UTILIZAÇÃO DE METODOLOGIAS ÁGEIS PARA A ENTREGA DE SERVIÇOS DE INFRAESTRUTU...
A UTILIZAÇÃO DE METODOLOGIAS ÁGEIS PARA A ENTREGA DE SERVIÇOS DE INFRAESTRUTU...A UTILIZAÇÃO DE METODOLOGIAS ÁGEIS PARA A ENTREGA DE SERVIÇOS DE INFRAESTRUTU...
A UTILIZAÇÃO DE METODOLOGIAS ÁGEIS PARA A ENTREGA DE SERVIÇOS DE INFRAESTRUTU...
 
TCC - METODOLOGIA SCRUM APLICADA AOS PROCESSOS DE GERÊNCIA E DESENVOLVIMENTO ...
TCC - METODOLOGIA SCRUM APLICADA AOS PROCESSOS DE GERÊNCIA E DESENVOLVIMENTO ...TCC - METODOLOGIA SCRUM APLICADA AOS PROCESSOS DE GERÊNCIA E DESENVOLVIMENTO ...
TCC - METODOLOGIA SCRUM APLICADA AOS PROCESSOS DE GERÊNCIA E DESENVOLVIMENTO ...
 
Jspservlets
JspservletsJspservlets
Jspservlets
 
ARTIGO CLUSTER DE ALTA DISPONIBILIDADE EM SISTEMAS LINUX
ARTIGO CLUSTER DE ALTA DISPONIBILIDADE EM SISTEMAS LINUXARTIGO CLUSTER DE ALTA DISPONIBILIDADE EM SISTEMAS LINUX
ARTIGO CLUSTER DE ALTA DISPONIBILIDADE EM SISTEMAS LINUX
 
plano_de_projeto_controlart_final
plano_de_projeto_controlart_finalplano_de_projeto_controlart_final
plano_de_projeto_controlart_final
 
Proj uml restaurante online
Proj uml restaurante onlineProj uml restaurante online
Proj uml restaurante online
 
Desenvolvimento de-robo-movel (1)
Desenvolvimento de-robo-movel (1)Desenvolvimento de-robo-movel (1)
Desenvolvimento de-robo-movel (1)
 
plano_de_projeto_controlart_rascunho
plano_de_projeto_controlart_rascunhoplano_de_projeto_controlart_rascunho
plano_de_projeto_controlart_rascunho
 
Pasta pablo mota
Pasta pablo motaPasta pablo mota
Pasta pablo mota
 
Monografia - Padrões Web
Monografia - Padrões WebMonografia - Padrões Web
Monografia - Padrões Web
 
Análise de ferramentas para gestão de regras de negócio em sistemas de inform...
Análise de ferramentas para gestão de regras de negócio em sistemas de inform...Análise de ferramentas para gestão de regras de negócio em sistemas de inform...
Análise de ferramentas para gestão de regras de negócio em sistemas de inform...
 
Aplicac3a7c3a3o da-abordagem-gqm-para-a-definic3a7c3a3o-de-um-processo-de-eng...
Aplicac3a7c3a3o da-abordagem-gqm-para-a-definic3a7c3a3o-de-um-processo-de-eng...Aplicac3a7c3a3o da-abordagem-gqm-para-a-definic3a7c3a3o-de-um-processo-de-eng...
Aplicac3a7c3a3o da-abordagem-gqm-para-a-definic3a7c3a3o-de-um-processo-de-eng...
 
Ct java vi_2010_16
Ct java vi_2010_16Ct java vi_2010_16
Ct java vi_2010_16
 
Monografia - Engenharia de software baseada em modelos um estudo sobre WebML ...
Monografia - Engenharia de software baseada em modelos um estudo sobre WebML ...Monografia - Engenharia de software baseada em modelos um estudo sobre WebML ...
Monografia - Engenharia de software baseada em modelos um estudo sobre WebML ...
 
Html course for_visually_impaired_persons
Html course for_visually_impaired_personsHtml course for_visually_impaired_persons
Html course for_visually_impaired_persons
 
Plano de projeto: Bichos do Campus na Web
Plano de projeto: Bichos do Campus na WebPlano de projeto: Bichos do Campus na Web
Plano de projeto: Bichos do Campus na Web
 
K19 k23-integracao-de-sistemas-com-webservices-jms-e-ejb
K19 k23-integracao-de-sistemas-com-webservices-jms-e-ejbK19 k23-integracao-de-sistemas-com-webservices-jms-e-ejb
K19 k23-integracao-de-sistemas-com-webservices-jms-e-ejb
 

Último

Gerenciando a Aprendizagem Organizacional
Gerenciando a Aprendizagem OrganizacionalGerenciando a Aprendizagem Organizacional
Gerenciando a Aprendizagem OrganizacionalJacqueline Cerqueira
 
Educação São Paulo centro de mídias da SP
Educação São Paulo centro de mídias da SPEducação São Paulo centro de mídias da SP
Educação São Paulo centro de mídias da SPanandatss1
 
Currículo escolar na perspectiva da educação inclusiva.pdf
Currículo escolar na perspectiva da educação inclusiva.pdfCurrículo escolar na perspectiva da educação inclusiva.pdf
Currículo escolar na perspectiva da educação inclusiva.pdfIedaGoethe
 
Cenários de Aprendizagem - Estratégia para implementação de práticas pedagógicas
Cenários de Aprendizagem - Estratégia para implementação de práticas pedagógicasCenários de Aprendizagem - Estratégia para implementação de práticas pedagógicas
Cenários de Aprendizagem - Estratégia para implementação de práticas pedagógicasRosalina Simão Nunes
 
QUARTA - 1EM SOCIOLOGIA - Aprender a pesquisar.pptx
QUARTA - 1EM SOCIOLOGIA - Aprender a pesquisar.pptxQUARTA - 1EM SOCIOLOGIA - Aprender a pesquisar.pptx
QUARTA - 1EM SOCIOLOGIA - Aprender a pesquisar.pptxIsabellaGomes58
 
LEMBRANDO A MORTE E CELEBRANDO A RESSUREIÇÃO
LEMBRANDO A MORTE E CELEBRANDO A RESSUREIÇÃOLEMBRANDO A MORTE E CELEBRANDO A RESSUREIÇÃO
LEMBRANDO A MORTE E CELEBRANDO A RESSUREIÇÃOColégio Santa Teresinha
 
cartilha-pdi-plano-de-desenvolvimento-individual-do-estudante.pdf
cartilha-pdi-plano-de-desenvolvimento-individual-do-estudante.pdfcartilha-pdi-plano-de-desenvolvimento-individual-do-estudante.pdf
cartilha-pdi-plano-de-desenvolvimento-individual-do-estudante.pdfIedaGoethe
 
Apresentação | Eleições Europeias 2024-2029
Apresentação | Eleições Europeias 2024-2029Apresentação | Eleições Europeias 2024-2029
Apresentação | Eleições Europeias 2024-2029Centro Jacques Delors
 
O Universo Cuckold - Compartilhando a Esposas Com Amigo.pdf
O Universo Cuckold - Compartilhando a Esposas Com Amigo.pdfO Universo Cuckold - Compartilhando a Esposas Com Amigo.pdf
O Universo Cuckold - Compartilhando a Esposas Com Amigo.pdfPastor Robson Colaço
 
Intolerância religiosa. Trata-se de uma apresentação sobre o respeito a diver...
Intolerância religiosa. Trata-se de uma apresentação sobre o respeito a diver...Intolerância religiosa. Trata-se de uma apresentação sobre o respeito a diver...
Intolerância religiosa. Trata-se de uma apresentação sobre o respeito a diver...LizanSantos1
 
FCEE - Diretrizes - Autismo.pdf para imprimir
FCEE - Diretrizes - Autismo.pdf para imprimirFCEE - Diretrizes - Autismo.pdf para imprimir
FCEE - Diretrizes - Autismo.pdf para imprimirIedaGoethe
 
HORA DO CONTO4_BECRE D. CARLOS I_2023_2024
HORA DO CONTO4_BECRE D. CARLOS I_2023_2024HORA DO CONTO4_BECRE D. CARLOS I_2023_2024
HORA DO CONTO4_BECRE D. CARLOS I_2023_2024Sandra Pratas
 
Aula 13 8º Ano Cap.04 Revolução Francesa.pptx
Aula 13 8º Ano Cap.04 Revolução Francesa.pptxAula 13 8º Ano Cap.04 Revolução Francesa.pptx
Aula 13 8º Ano Cap.04 Revolução Francesa.pptxBiancaNogueira42
 
Mesoamérica.Astecas,inca,maias , olmecas
Mesoamérica.Astecas,inca,maias , olmecasMesoamérica.Astecas,inca,maias , olmecas
Mesoamérica.Astecas,inca,maias , olmecasRicardo Diniz campos
 
Programa de Intervenção com Habilidades Motoras
Programa de Intervenção com Habilidades MotorasPrograma de Intervenção com Habilidades Motoras
Programa de Intervenção com Habilidades MotorasCassio Meira Jr.
 
Bingo da potenciação e radiciação de números inteiros
Bingo da potenciação e radiciação de números inteirosBingo da potenciação e radiciação de números inteiros
Bingo da potenciação e radiciação de números inteirosAntnyoAllysson
 
A galinha ruiva sequencia didatica 3 ano
A  galinha ruiva sequencia didatica 3 anoA  galinha ruiva sequencia didatica 3 ano
A galinha ruiva sequencia didatica 3 anoandrealeitetorres
 
HORA DO CONTO5_BECRE D. CARLOS I_2023_2024
HORA DO CONTO5_BECRE D. CARLOS I_2023_2024HORA DO CONTO5_BECRE D. CARLOS I_2023_2024
HORA DO CONTO5_BECRE D. CARLOS I_2023_2024Sandra Pratas
 
Investimentos. EDUCAÇÃO FINANCEIRA 8º ANO
Investimentos. EDUCAÇÃO FINANCEIRA 8º ANOInvestimentos. EDUCAÇÃO FINANCEIRA 8º ANO
Investimentos. EDUCAÇÃO FINANCEIRA 8º ANOMarcosViniciusLemesL
 
geografia 7 ano - relevo, altitude, topos do mundo
geografia 7 ano - relevo, altitude, topos do mundogeografia 7 ano - relevo, altitude, topos do mundo
geografia 7 ano - relevo, altitude, topos do mundonialb
 

Último (20)

Gerenciando a Aprendizagem Organizacional
Gerenciando a Aprendizagem OrganizacionalGerenciando a Aprendizagem Organizacional
Gerenciando a Aprendizagem Organizacional
 
Educação São Paulo centro de mídias da SP
Educação São Paulo centro de mídias da SPEducação São Paulo centro de mídias da SP
Educação São Paulo centro de mídias da SP
 
Currículo escolar na perspectiva da educação inclusiva.pdf
Currículo escolar na perspectiva da educação inclusiva.pdfCurrículo escolar na perspectiva da educação inclusiva.pdf
Currículo escolar na perspectiva da educação inclusiva.pdf
 
Cenários de Aprendizagem - Estratégia para implementação de práticas pedagógicas
Cenários de Aprendizagem - Estratégia para implementação de práticas pedagógicasCenários de Aprendizagem - Estratégia para implementação de práticas pedagógicas
Cenários de Aprendizagem - Estratégia para implementação de práticas pedagógicas
 
QUARTA - 1EM SOCIOLOGIA - Aprender a pesquisar.pptx
QUARTA - 1EM SOCIOLOGIA - Aprender a pesquisar.pptxQUARTA - 1EM SOCIOLOGIA - Aprender a pesquisar.pptx
QUARTA - 1EM SOCIOLOGIA - Aprender a pesquisar.pptx
 
LEMBRANDO A MORTE E CELEBRANDO A RESSUREIÇÃO
LEMBRANDO A MORTE E CELEBRANDO A RESSUREIÇÃOLEMBRANDO A MORTE E CELEBRANDO A RESSUREIÇÃO
LEMBRANDO A MORTE E CELEBRANDO A RESSUREIÇÃO
 
cartilha-pdi-plano-de-desenvolvimento-individual-do-estudante.pdf
cartilha-pdi-plano-de-desenvolvimento-individual-do-estudante.pdfcartilha-pdi-plano-de-desenvolvimento-individual-do-estudante.pdf
cartilha-pdi-plano-de-desenvolvimento-individual-do-estudante.pdf
 
Apresentação | Eleições Europeias 2024-2029
Apresentação | Eleições Europeias 2024-2029Apresentação | Eleições Europeias 2024-2029
Apresentação | Eleições Europeias 2024-2029
 
O Universo Cuckold - Compartilhando a Esposas Com Amigo.pdf
O Universo Cuckold - Compartilhando a Esposas Com Amigo.pdfO Universo Cuckold - Compartilhando a Esposas Com Amigo.pdf
O Universo Cuckold - Compartilhando a Esposas Com Amigo.pdf
 
Intolerância religiosa. Trata-se de uma apresentação sobre o respeito a diver...
Intolerância religiosa. Trata-se de uma apresentação sobre o respeito a diver...Intolerância religiosa. Trata-se de uma apresentação sobre o respeito a diver...
Intolerância religiosa. Trata-se de uma apresentação sobre o respeito a diver...
 
FCEE - Diretrizes - Autismo.pdf para imprimir
FCEE - Diretrizes - Autismo.pdf para imprimirFCEE - Diretrizes - Autismo.pdf para imprimir
FCEE - Diretrizes - Autismo.pdf para imprimir
 
HORA DO CONTO4_BECRE D. CARLOS I_2023_2024
HORA DO CONTO4_BECRE D. CARLOS I_2023_2024HORA DO CONTO4_BECRE D. CARLOS I_2023_2024
HORA DO CONTO4_BECRE D. CARLOS I_2023_2024
 
Aula 13 8º Ano Cap.04 Revolução Francesa.pptx
Aula 13 8º Ano Cap.04 Revolução Francesa.pptxAula 13 8º Ano Cap.04 Revolução Francesa.pptx
Aula 13 8º Ano Cap.04 Revolução Francesa.pptx
 
Mesoamérica.Astecas,inca,maias , olmecas
Mesoamérica.Astecas,inca,maias , olmecasMesoamérica.Astecas,inca,maias , olmecas
Mesoamérica.Astecas,inca,maias , olmecas
 
Programa de Intervenção com Habilidades Motoras
Programa de Intervenção com Habilidades MotorasPrograma de Intervenção com Habilidades Motoras
Programa de Intervenção com Habilidades Motoras
 
Bingo da potenciação e radiciação de números inteiros
Bingo da potenciação e radiciação de números inteirosBingo da potenciação e radiciação de números inteiros
Bingo da potenciação e radiciação de números inteiros
 
A galinha ruiva sequencia didatica 3 ano
A  galinha ruiva sequencia didatica 3 anoA  galinha ruiva sequencia didatica 3 ano
A galinha ruiva sequencia didatica 3 ano
 
HORA DO CONTO5_BECRE D. CARLOS I_2023_2024
HORA DO CONTO5_BECRE D. CARLOS I_2023_2024HORA DO CONTO5_BECRE D. CARLOS I_2023_2024
HORA DO CONTO5_BECRE D. CARLOS I_2023_2024
 
Investimentos. EDUCAÇÃO FINANCEIRA 8º ANO
Investimentos. EDUCAÇÃO FINANCEIRA 8º ANOInvestimentos. EDUCAÇÃO FINANCEIRA 8º ANO
Investimentos. EDUCAÇÃO FINANCEIRA 8º ANO
 
geografia 7 ano - relevo, altitude, topos do mundo
geografia 7 ano - relevo, altitude, topos do mundogeografia 7 ano - relevo, altitude, topos do mundo
geografia 7 ano - relevo, altitude, topos do mundo
 

Comparação JBoss Seam x Ruby on Rails

  • 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.
  • 4. 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.
  • 5. 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.
  • 6. 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.
  • 7. 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
  • 8. 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
  • 9. 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
  • 10. 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
  • 11. 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
  • 12. 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
  • 13. 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)
  • 14. 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;
  • 15. 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.
  • 16. 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.
  • 17. 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.
  • 18. 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.
  • 19. 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).
  • 20. 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)
  • 21. 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).
  • 22. 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)
  • 23. 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.
  • 24. 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)
  • 25. 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).
  • 26. 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.
  • 27. 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
  • 28. 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).
  • 29. 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).
  • 30. 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.
  • 31. 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
  • 32. 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.
  • 33. 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.
  • 34. 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.
  • 35. 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."
  • 36. 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
  • 37. 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
  • 38. 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).
  • 39. 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.
  • 40. 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
  • 41. 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”.
  • 42. 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
  • 43. 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 ).
  • 44. 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)
  • 45. 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.
  • 46. 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.
  • 47. 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.”.
  • 48. 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.
  • 49. 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.
  • 50. 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.
  • 51. 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.
  • 52. 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