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

Figura 1– Funcionamento do Compilador. Fonte: Azambuja (2004, p1)

Alguns exemplos de linguagens compiladas são:

Ada

BASIC

C

C++

COBOL

Cobra

Delphi

Fortran

Pascal

Visual Basic

Visual Prolog

Exemplo simples de código fonte de algumas linguagens de programação compilada:

C++ Delphi

main() { cout << "Hello World!" << endl; return 0; }

Begin WriteLn('Hello World'); End.

Quadro 1 - Exemplo C++ e Delphi – Fonte Roesler (2010, p1)

Programa Fonte

Analisador Léxico

Analisador Sintático

Analisador Semântico e Gerador

de Código Intermediário

Gerador de Código

Programa Objetivo

Tabela de Símbolos Otimizador

23

Pascal Visual Basic6

program HelloWorld(output); begin WriteLn('Hello World!'); end.

Private Sub Form_Load() Print "Hello World" End Sub

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

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

C#

Java

JavaScript

Lua

PHP

Python

Ruby

Scheme

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)

Programa Fonte

Analisador Léxico

Analisador Sintático

Analisador Semântico Tabela de Símbolos

Interpretação

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

BASIC

C

Euphoria

JavaScript

Lua

PHP

Python

Ruby

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

53

durante o desenvolvimento e o tempo gasto com buscas e pesquisas para resolver tais desvios,

os autores estimam um remake do mesmo projeto em aproximadamente dez horas de

desenvolvimento ou menos.

Jboss Seam

A fase de desenvolvimento foi realizada concorrentemente à assimilação do conteúdo

de livros, sites e e-books. O processo de desenvolvimento no Jboss Seam teve seu start pela

implementação do banco de dados. Após o banco de dados estar implementado, através da

perspectiva Bottom-up foi realizado o Scaffolding com a ferramenta Seam-gen15. Após este

processo começou a ser desenvolvido e configurado conforme as necessidades da aplicação

definida.

Através da ferramenta Seam-gen, o desenvolvedor tem a capacidade de iniciar o

desenvolvimento rapidamente, pois vários dos pacotes de classes de componentes, artefatos

de configuração são automaticamente gerados para o ambiente definido na execução do

Seam-gen.

Após a realização destes passos, a assimilação do conteúdo teórico foi necessário para

dar continuidade ao desenvolvimento. Não se trata apenas do estudo do Framework Seam,

mas de todas as tecnologias inclusas.

As tecnologias inseridas neste projeto são JPA, RichFaces, Java Server Faces, Java

Mai e Hibernate. A integração entre estas tecnologias é realizado pelo Framework Seam, o

necessário então é saber utilizá-las de acordo com as necessidades.

O tempo necessário para o desenvolvimento do mesmo foi de 45 horas. Como já

citado e sendo importante salientar, o start do desenvolvimento se deu de uma forma rápida

através do Seam-gen, no entanto a continuação esqueleto criado foi o principal desafio. Com

a experiência adquirida durante a fase de desenvolvimento, é estimado que em

aproximadamente 20 horas fosse possível desenvolve-lo até a fase atual.

15 Seam-gen é uma fabrica de aplicações. Simplificando, é uma ferramenta que tem como finalidade criar o projeto esqueleto, permitindo que o desenvolvedor tenha seu foco direcionado ao desenvolvimento com o mínimo de tempo gasto realizando configurações e instalações. (Traduçao Nossa) – Manning Seam in Action Capitulo 2 pagina 35

54

Considerações finais do tempo de desenvolvimento

O desenvolvimento utilizando-se Ruby on Rails tornou-se mais fácil e mais rápido devido

à simplicidade do código e a agilidade que as convenções ao invés de configurações oferecem

e também pela não necessidade de reiniciar o servidor quando se modifica o código fonte.

Isso tudo simplifica e possibilita a agilidade o processo de desenvolvimento e aprendizado.

11.3 Facilidade de manutenção

Com o sistema pronto, o próximo passo era a comparação na facilidade de manutenção

de Ruby on Rails e JBoss Seam. Para abordar esse tópico, os autores dispuseram de

incrementar no sistema a possibilidade do usuário poder fazer upload de arquivos e envio de

e-mails. O cenário para essas opções ficou da seguinte maneira:

O usuário Empresa pode fazer upload de arquivos para anexar aos seus serviços

oferecidos, tais como, Termo de Contrato, Formulários, fotos, etc.

O usuário Cliente poderá então, apenas, fazer download desses anexos.

A parte de e-mail foi implementada juntamente com o Contrato.

Quando um Cliente contrata algum serviço de qualquer Empresa, um e-mail é enviado

para ambas as partes, com todos os dados desse contrato.

Quadro 11 - Exemplo de Comparação Java x Ruby – Elaboração dos autores, 2010

Ruby on Rails

Em Ruby on Rails esses dois aprimoramento do sistema foi muito fácil. O tempo para

programar essas ferramentas foi de quatro horas contando com pesquisa e desenvolvimento.

Em Ruby on Rails, tanto no upload como no envio de e-mail, foi necessário a instalação

de plugins.

Para upload o plugin usado foi o paperclip, disponível em

(http://github.com/thoughtbot/paperclip). Para a instalação do plugin, deve-se abrir o prompt

de comando e entrar na pasta do projeto criado. Feito isso basta digitar a linha de comando

abaixo:

ruby script/plugin install git://github.com/thoughtbot/paperclip.git Quadro 12 Script para instalar plugin – Elaboração dos autores, 2010

55

Isso irá baixar o plugin diretamente do repositório oficial do paperclip e instalá-lo.

Uma das configurações que o paperclip oferece e o filtro de tipo de arquivos para envio. Para

esse sistema, foi configurado o envio apenas de .pdf, .doc e .jpg. Esse filtro é feito apenas

com esse código abaixo:

validates_attachment_content_type :arquivo, :content_type =>

%w(application/msword, application/pdf, image/jpg) Quadro 13 – Código para filtrar extensões de arquivos do paperclip – Elaboração dos autores, 2010

E para o envio de e-mail foi utilizado o plugin action_mailer_optional_tls, disponível

em (http://github.com/collectiveidea/action_mailer_optional_tls). Para a instalação do plugin,

deve-se abrir o prompt de comando e entrar na pasta do projeto criado. Feito isso basta digitar

a linha de comando abaixo:

ruby script/plugin install git://github.com/collectiveidea/action_mailer_optional_tls.git Quadro 14 – Script para instalar plugin – Elaboração dos autores, 2010

Após instalado foram necessário apenas essas 4 configurações listadas abaixo:

1. Especificar o modo de envio dos e-mails:

config.action_mailer.default_content_type = 'text/html' config.action_mailer.smtp_settings = { :tls => true, :address => "smtp.gmail.com", :port => "587", :authentication => :plain, :user_name => "login@gmail.com", :password => "senha" }

Quadro 15 – Configuração do servidor de e-mail em Ruby on Rails – Elaboração dos autores, 2010

2. Criar uma classe informando quem receberá o e-mail, o assunto do e-mail e o

conteúdo.

56

class ContractNotifier < ActionMailer::Base def create_notification(task) recipients %("#{task.customer.name}" <#{task.customer.email}>, "#{task.firm.name}" <#{task.firm.email}>) subject "[Ruby on Rails] Novo serviço contratado!" body :task => task end end

Quadro 16 Configuração de envio de e-mail em Ruby on Rails – Elaboração dos autores, 2010

Recipients se refere a quem será enviado o e-mail. Exemplo, “TCC” <tcc@unisul.br>.

Subject é o assunto do e-mail.

Body é o texto que será impresso no e-mail.

3. Criar uma classe com o nome de create_nofitication, que é o nome do método

criado no exemplo acima. Essa nova classe que irá constar o corpo do e-mail, ou

seja, todo texto que será enviado. Como no exemplo abaixo:

Olá <%= @task.firm.name %>, O cliente <%= @task.customer.name %> contratou o seu serviço de "<%= @task.service.name %>". Dados do serviço: Nome: <%= @task.service.name %> Descrição: <%= @task.service.description %> Valor: R$<%= @task.service.value %> Dados do cliente: Nome: <%= @task.customer.name %> E-mail: <%= @task.customer.email %> Endereço: <%= @task.customer.address %> CPF: <%= @task.customer.account.cpf_cnpj %> Telefone: <%= @task.customer.account.phone %> --- Ruby on Rails - Sistema de Testes Data: <%= Time.now %>

Quadro 17 – Exemplo de mensagem a ser enviada em Ruby on Rails – Elaboração dos autores, 2010

O código acima enviaria um e-mail como esse:

57

Olá Empresa01, O cliente José Pereira contratou o seu serviço de "Programação para Web". Dados do serviço: Nome: Programação para Web Descrição: Criação de sites na em geral. Valor: R$400.0 Dados do cliente: Nome: José Pereira E-mail: josepereira@unisul.br Endereço: rua De Sempre, Vila Nova, Imbituba, Santa Catarina, Brasil CPF: 056102301-82 Telefone: (48)3255-0000 --- Ruby on Rails - Sistema de Testes Data: Mon May 17 12:39:55

Quadro 18 – Exemplo de e-mail enviado em Ruby on Rails – Elaboração dos autores, 2010

4. Após essas configurações, basta chamar o método juntamente após a criação de

um contrato entre Cliente e Empresa, usando o exemplo abaixo:

ContractNotifier.deliver_create_notification(@task) Quadro 19 Comando para enviar e-mail em Ruby on Rails – Elaboração dos autores, 2010

ContractNotifier = Nome da Classe com os dados de envio.

deliver = método do ActionMailer que informa que será enviado um e-mail.

create_notification = Nome do método dentro da classe ContractNotifier, que recebe como

parâmetro o serviço contratado no momento.

Jboss Seam

A implementaçao destas funcionalidades através do framework Seam, foi

razoavelmente rápida. O tópico upload/download de arquivos foi mais trabalhoso para se

realizar.

58

O framework Seam prove suporte para se trabalhar com emails. As configurações

necessárias para se implementar esta funcionalidade são mínimas.

Primeiramente devemos configurar o acesso ao servidor SMTP desejado para o envio

do email. Esta configuração é realizada no arquivo Components.xml, localizado na pasta

WEB-INF. Abaixo pode-se verificar como deve ser esta configuração;

<mail:mail-session host="smtp.gmail.com" password="senhaemail"

port="587" username="email@gmail.com"/> Quadro 20 - Exemplo da configuração do serviço de e-mail– Elaboração dos autores, 2010

Após realizada esta configuração, foi criado um componente Seam identificado como

emailService, na qual possui um método sendMessage() que realiza toda a ação de envio de e-

mail.

Abaixo o código fonte do método sendMessage();

@Asynchronous public void sendMessage(@Duration long delay, String template,List l,Cliente c,Servicos s) { this.serv=s; this.cli=c; for (int i = 0; i < l.size(); i++) { rep=(Representante)l.get(i); System.out.println("Email representante: "+rep.getUsuario().getEmail()); try { //Contexts.getEventContext().set("info", infoNeededForTemplate); System.out.println("Renderizando"); renderer.render(template); System.out.println("Renderizado"); } catch (Exception e) { // suppress information. //logger.error(e.getMessage()); e.printStackTrace(); } } }

Quadro 21 - Exemplo do método de envio de e-mail– Elaboração dos autores, 2010

Nota-se a inclusão da anotação @Asynchronous antes da definição do método. Está

anotação indica que este método será assíncrono e proporcionará ao usuário mais rapidez na

exibição da pagina. A objeto/método responsável pela renderização da pagina e envio é o

renderer.render(String template).

Durante a implementação desta funcionalidade foi verificado que o usuário ao

executar a ação de contratar um serviço, aguardava a renderização da pagina de email, a

conexão ao servidor SMTP configurado, o envio do email para somente após este processo ser

59

exibida a pagina de serviço contratado. Este processo tornava-se demorado no entanto, com a

adição desta anotação antes do método, a renderização do email é realizado em background e

o usuário não nota este comportamento durante a contratação do serviço.

A implementação do layout do e-mail é realizado através de uma taglib apropriada

(xmlns:m="http://jboss.com/products/seam/mail") para tal. Abaixo se pode visualizar o

arquivo que renderiza o email da aplicação;

<m:message xmlns="http://www.w3.org/1999/xhtml" xmlns:m="http://jboss.com/products/seam/mail" xmlns:h="http://java.sun.com/jsf/html" xmlns:s="http://jboss.com/products/seam/taglib" xmlns:p="http://jboss.com/products/seam/pdf"> <m:from name="Sistema Web Seam"/> <m:to name="#{emailService.rep.nome}">#{emailService.rep.usuario.email}</m:to> <m:subject>Sistema Web - Seam</m:subject> <m:body> <p><h:outputText value="Novo Servico Solicitado! " style="FONT-SIZE: x-large; FONT-WEIGHT: bold; COLOR: #0080ff;" /></p> <p><h:outputText value="Ola " />#{emailService.rep.nome},</p> <p><h:outputText value="O cliente " />#{emailService.cli.nome},<h:outputText value="contratou o seu servico do tipo '" />#{emailService.serv.tipoServico.descricao}<h:outputText value="'." /></p> <p><h:outputText value="Dados do Servico: " style="FONT-WEIGHT: bold; COLOR: #0080ff;" /></p> <p><h:outputText value="Tipo: " style="FONT-WEIGHT: bold;" />#{emailService.serv.tipoServico.descricao}</p> <p><h:outputText value="Nome: " style="FONT-WEIGHT: bold;" />#{emailService.serv.descricao}</p> <p></p> <p><h:outputText value="Dados do Cliente: " style="FONT-WEIGHT: bold; COLOR: #0080ff;" /></p> <p><h:outputText value="Nome:" style="FONT-WEIGHT: bold;" />#{emailService.cli.nome}</p> <p><h:outputText value="Email: " style="FONT-WEIGHT: bold;" />#{emailService.cli.usuario.email}</p> <p><h:outputText value="Endereco: " style="FONT-WEIGHT: bold;" />#{emailService.end}</p> <p><h:outputText value="CPF: " style="FONT-WEIGHT: bold;" />#{emailService.cli.cpf}</p> <p>Mensagem Automatica, por favor, nao responda.</p> <p></p>

60

<p></p> <s:graphicImage id="image" value="/layout/seam.png" fileName="seam.png"> </s:graphicImage> <p><b style="COLOR: #0080ff;">Powered by SEAM FRAMEWORK</b></p> </m:body> </m:message>

Quadro 22 - Exemplo do arquivo de renderização de e-mails – Elaboração dos autores, 2010

Abaixo podemos visualizar a pagina HTML enviada;

Novo Servico Solicitado!

Ola Roberto Carlos Bender,

O cliente Guilherme Serna Martins,contratou o seu servico do tipo 'Segurança'.

Dados do Servico:

Tipo: Segurança

Nome: Instalaçao de Cameras (C/S Audio)

Dados do Cliente:

Nome:Guilherme Serna Martins

Email: mawcor@gmail.com

Endereco: Rua Lucio Machado, Vila Nova, Imbituba, SC, Brasil, 88780000

CPF: 04999335913

Mensagem Automatica, por favor, nao responda.

Powered by SEAM FRAMEWORK

Quadro 23 - Exemplo do e-mail gerado – Elaboração dos autores, 2010

O tempo quantificado para o desenvolvimento desta funcionalidade foi de 1 hora e

meia.

Como já dito anteriormente, o upload e download de arquivos necessitou-se de um

tempo maior para se programar. Para tal foi necessário criar uma tabela no banco de dados

61

para registrar as informações de cada upload realizado. Na pesquisa por soluções, preferiria

que os dados ficassem salvos no sistema de arquivos do servidor ou local na rede, mas devido

ao tempo disponível para o desenvolvimento optei por realizar da forma como consegui fazer,

salvar os dados do arquivo em uma tabela do banco de dados.

Abaixo se pode ver o código fonte da renderizaçao do componente Upload;

<h:form enctype="multipart/form-data"> <rich:panel> <f:facet name="header">Upload Attachment</f:facet> <s:decorate id="fileUploadDecoration" template="layout/edit.xhtml"> <ui:define name="label">Attachment</ui:define> <s:fileUpload id="file" data="#{attachmentHome.instance.data}" contentType="#{attachmentHome.instance.contentType}" fileName="#{attachmentHome.instance.name}" fileSize="#{attachmentHome.instance.size}" /> </s:decorate>

Quadro 24 - Exemplo do arquivo da view – Elaboração dos autores, 2010

Uma vez o atributo data da tag s:fileUpload configurada para o atributo data da

instancia attachmentHome basta apenas chamar o método persist() para realizar o upload do

arquivo.

Para a realização do download foi criado um outro componente Seam denominado

downloadAttachment, na qual esta definido o método download() abaixo;

public String download() { Attachment attachment = entityManager.find(Attachment.class, attachmentId); HttpServletResponse response = (HttpServletResponse)extCtx.getResponse(); response.setContentType(attachment.getContentType()); response.addHeader("Content-disposition", "attachment; filename=\"" + attachment.getName() +"\""); try { ServletOutputStream os = response.getOutputStream(); os.write(attachment.getData()); os.flush(); os.close(); facesContext.responseComplete(); } catch(Exception e) { log.error("\nFailure : " + e.toString() + "\n"); } return null; }

Quadro 25 - Exemplo do método para download – Elaboração dos autores, 2010

Através do método entityManager.find() e possível localizar o id do anexo solicitado e

por meio do os.write() obter os dados do arquivo solicitado.

O tempo quantificado para a realização desta funcionalidade foi de 3 horas.

62

Considerações finais da facilidade de manutenção

Através destas implementações propostas procuramos avaliar a facilidade de

adicionarmos novas funcionalidades nos projetos atuais. Foi verificado que ambos os

frameworks permitiram inserir as funcionalidades propostas de forma fácil. No framework

Ruby on Rails estas funcionalidades foram obtidas através das instalações de plugins para

permitir as funcionalidades de Upload e envio de emails. Na plataforma JBoss Seam, no

entanto foi apenas necessário incluir taglibs apropriadas para tais funcionalidades não

necessitando realizar nenhuma instalação ou download de arquivos de terceiros.

Pode-se então concluir que tanto JBoss Seam quanto Ruby on Rails possuem facilidade de

manutenção equivalentes, sendo que JBoss Seam não necessita de instalação de plugins para

essas funcionalidades.

11.4 Performance

Performance é um termo muito complexo na qual envolve muitos fatores como,

Sistema Operacional utilizado, quantidade de memória, processador, tecnologia empregada,

fatores estes que podem ocasionar o mascaramento da realidade se não for corretamente

analisados.

Para a realização da comparação entre estas tecnologias de desenvolvimento definimos

alguns pontos importantes.

Utilizar um único servidor para ambos os frameworks. Ou seja, mesmo hardware e SO

(Processador Intel Core 2 Quad Q8200, 2.33Ghz 4gb DDR2/800Mhz, Windows 7 32bits).

Utilização do mesmo SGBD (PostgreSQL 8.4).

Acessar a aplicação remotamente através da rede para não haver interferências externas no

servidor de aplicação.

Como já citado, utilizamos a aplicação Web New Relic para a medição das métricas de

desempenho em ambos ambientes.

Realizamos os seguintes testes nas aplicações:

Autenticação no Sistema

Logout no Sistema

Criação de 1 serviço

63

Contratar 1 serviço

Criar 1 usuário

Criar 100 Usuários

Criar 1000 Usuários

Criar 100 Serviços

Criar 1000 Serviços

A configuração dos ambientes de desenvolvimento foram:

Jboss Seam Ruby on Rails

Versão da Linguagem Java 1.6.0_20 Ruby 1.8.7

Versão do Framework 2.2.0.GA Rails 2.3.8

IDE Eclipse GALILEO 3.5.2 NetBeans 6.8

Banco de Dados PostgreSQL 8.4 PostgreSQL 8.4

Servidor JBoss 5.1.0.GA Mongrel 1.1.5 Quadro 26 – Configuração dos ambientes de desenvolvimento. Elaboração dos autores, 2010.

11.4.1 Teste - Login

Neste teste proposto, iremos realizar o login no sistema. Na realização deste

procedimento, o sistema deverá verificar se as credenciais inseridas na pagina de login são

realmente de usuários cadastrados e após criar a sessão para o usuário.

Neste teste está sendo medido o desempenho do evento gerado ao se clicar no botão

Login.

64

Gráfico 1 – Tempo de resposta na realização do login. Elaboração dos autores, 2010.

Gráfico 2 – Utilização do processador na realização do login. Elaboração dos autores, 2010.

Considerações Finais

Podemos claramente notar a rapidez de execução na plataforma Ruby on Rails nesta

operação. A versão 1.9.1da linguagem Ruby obteve um resultado melhor em comparação com

a versão 1.8.7. A plataforma Java foi em média 849% mais lento que o Ruby on Rails (versão

1.9.1 do Ruby) em tempo de execução.

65

Java também obteve um processamento muito maior para executar esta tarefa

conforme pode-se verificar no Gráfico 2.

11.4.2 Teste – Logout

Este teste proposto tem como objetivo registrar as métricas do servidor no evento do

botão Sair, na qual o servidor deve processar este evento, realizando a finalização da sessão

do usuário e exibir a pagina de login.

Gráfico 3 – Tempo de resposta na realização do logout. Elaboração dos autores, 2010.

66

Gráfico 4 - Utilização do processador na realização do logout. Elaboração dos autores, 2010.

Considerações Finais

Neste processo verificamos a rapidez em que Ruby on Rails executa o logout no

servidor. Ruby on Rails executa está tarefa muito mais rapidamente que o ambiente Java,

obteve um tempo de resposta mais rápido e um processamento muito menor do que no

ambiente Java. Ruby on Rails executou a tarefa mais rapidamente e utilizando menos

processamento.

11.4.3 Teste – Criar Serviço

Neste teste, serão registradas as métricas do software na execução da criação de um

serviço. Trata-se da inclusão do registro no banco de dados e a exibição da pagina informando

que o serviço foi criado com sucesso.

67

Gráfico 5 – Tempo de resposta na criação de um serviço. Elaboração dos autores, 2010.

Gráfico 6 – Utilização do processador na criação de um serviço. Elaboração dos autores, 2010.

Considerações Finais

Podemos verificar que o ambiente Ruby on Rails obteve um tempo de resposta

muito melhor que o ambiente Java. Java obteve a média de 334,6 ms de tempo de resposta

68

contra 139 ms de Ruby on Rails utilizando a versão 1.8.7 da linguagem Ruby e 59,2 ms

utilizando a versão 1.9.1 da linguagem Ruby conforme pode-se verificar no Gráfico 7 abaixo.

Gráfico 7 – Média do tempo de resposta na criação de um serviço. Elaboração dos autores, 2010.

A plataforma Ruby destacou-se também por utilizar muito pouco o processador, uma

média de 0,37% na versão Ruby 1.8.7 e 0,0174% na versão 1.9.1 conforme verifica-se no

Gráfico 8 abaixo.

Gráfico 8 - Média do tempo de resposta na criação de um serviço. Elaboração dos autores, 2010.

69

Ruby on Rails obteve um tempo de resposta e processamento muito melhor que a

plataforma Java neste teste.

11.4.4 Teste – Contratar Serviço

Neste teste proposto, é registrado as métricas no evento de criação de um serviço.

Trata-se de uma inclusão no banco de dados do serviço contratado, do envio de uma

mensagem de e-mail ao usuário da empresa fornecedora do serviço e da exibição da página

informando que o serviço foi contratado com sucesso.

Gráfico 9– Tempo de resposta na contratação de um serviço. Elaboração dos autores, 2010.

70

Gráfico 10 – Utilização do processador na contratação de um serviço. Elaboração dos autores, 2010.

Considerações Finais

Podemos verificar neste teste que a plataforma Java obteve melhores resultados no

tempo de resposta à ação de contratação de serviço. Este cenário foi obtido devido á

facilidade encontrada na plataforma Java na configuração de eventos assíncronos.

O evento chamado para enviar o e-mail aos destinatários foi configurado para ser

executado de forma assíncrona, ou seja, o envio de e-mail é enviado após a renderização da

página de confirmação do serviço contratado. Esta característica permitiu que o Java se

sobressaísse sobre a plataforma Ruby on Rails, uma vez que na execução deste comando no

Ruby on Rails o usuário aguarda o envio de e-mail para somente após receber a confirmação.

Na plataforma Java, o envio de email é executado em background e o usuário obtém uma

resposta de que uma mensagem de e-mail será enviada.

Neste teste não foi possível realizar o teste com a versão 1.9.1 da plataforma Ruby

devido a incompatibilidades apresentadas com a versão 1.8.7.

Java neste teste se destacou no tempo de resposta devido a sua facilidade de

implementação da funcionalidade de eventos assíncronos através de anotações na assinatura

do evento de envio de email.

71

11.4.5 Teste - Criar Usuário

O teste proposto foi a criação de um usuário. Para a criação do usuário são inseridas

informações sobre o usuário do sistema, informações pessoais e endereço.

Gráfico 11 – Tempo de resposta na criação de um usuário. Elaboração dos autores, 2010.

Gráfico 12 – Utilização do processador na criação de um usuário. Elaboração dos autores, 2010.

Considerações Finais

72

Neste teste verificamos que Ruby on Rails obteve um melhor tempo de resposta e um

menos consumo de processamento.

11.4.6 Teste – Criar 100 Usuários

Neste teste são criados cem usuários através de um script. Poderemos verificar o

desempenho das plataformas na execução em massa de inclusões no banco de dados.

Gráfico 13 – Tempo de resposta na criação de cem usuários. Elaboração dos autores, 2010.

Gráfico 14 – Utilização do processador na criação de cem usuários. Elaboração dos autores, 2010.

73

Considerações Finais

Podemos verificar através dos resultados obtidos que a plataforma Java obteve

melhores resultados do que a plataforma Ruby.

A aplicação desenvolvida com o framework Jboss Seam obteve um desempenho muito

melhor do que o aplicativo desenvolvido com o framework Ruby on Rails.

Com a atualização da plataforma Ruby da versão 1.8.7 para a versão 1.9.1 obtivemos

uma diferença enorme dos resultados entre as plataformas Ruby. O desempenho da plataforma

Ruby 1.9.1 foi muito melhor no tempo de resposta. Pode-se notar também que a plataforma

Ruby 1.9.1 faz mais utilização do processador do que a versão 1.8.7.

Neste teste, Java obteve um resultado muito melhor do que a plataforma Ruby.

11.4.7 Teste – Criar 100 Serviços

Neste teste são criados cem serviços através de um script. Poderemos verificar o

desempenho das plataformas na execução em massa de inclusões no banco de dados.

Gráfico 15 – Tempo de resposta na criação de cem serviços. Elaboração dos autores, 2010.

74

Gráfico 16 – Utilização do processador na criação de cem serviços. Elaboração dos autores, 2010.

Considerações Finais

A plataforma Java obteve um resultado um pouco melhor do que a plataforma

Ruby. Assim como no exemplo anterior do item 10.2.4.6, a atualização da plataforma Ruby da

versão 1.8.7 para a versão 1.9.1 proporcionou uma grande diferença nos resultados. A versão

1.9.1 da linguagem Ruby obteve um desempenho muito melhor do que a versão 1.8.7.

Neste teste proposto, Java obteve melhor resultado no tempo de resposta em

comparação com a plataforma Ruby.

11.4.8 Teste – Criar 1000 Serviços

Neste teste proposto serão criados mil serviços através de um script desenvolvido.

Poderemos verificar o desempenho dos ambientes na execução de tarefas em massa.

75

Gráfico 17 – Tempo de resposta na criação de mil serviços. Elaboração dos autores, 2010.

Gráfico 18 – Utilização do processador na criação de mil serviços. Elaboração dos autores, 2010.

Considerações Finais

Assim como nos outros testes já mostrados, a atualização da plataforma Ruby da

versão 1.8.7 para a versão 1.9.1 proporcionou um alto ganho de desempenho. No entanto, a

plataforma Java continuou obtendo melhores resultados na execução de tarefas em massa.

Java neste teste obteve melhores resultados no tempo de resposta. No quesito uso do

processador, Ruby na versão 1.9.1 obteve melhor utilização do processador.

76

11.4.9 Teste – Criar 1000 Usuários

Neste teste proposto iremos realizar a criação de mil usuários através de um script

desenvolvido. Poderemos verificar a performance dos ambientes na execução de ações em

massa.

Gráfico 19 – Tempo de resposta na criação de mil serviços. Elaboração dos autores, 2010.

Gráfico 20 – Utilização do processador na criação de mil usuários. Elaboração dos autores, 2010.

Considerações Finais

77

Na criação de mil usuários, Java mostrou ter mais habilidade em executar tarefas em massa e

ser uma linguagem rápida. Ruby, no entanto teve um desempenho inferior obtendo maiores

tempo de resposta.

11.5 Tamanho do código

Ruby on Rails

Ruby on Rails oferece um comando para verificar o tamanho de sua aplicação. Para

usá-lo você terá que entrar na pasta do projeto Rails, através do prompt de comando, e digitar

o seguinte código: rake stats

Com esse comando, o prompt exibirá uma tela semelhante a essa:

Nome Linhas Classes Métodos

Controllers 660 9 51

Helpers 26 0 1

Models 76 8 2

View 654 26 0

Total 1416 43 54 Quadro 27 - Métricas do ambiente de desenvolvimento Ruby on Rails. Elaboração dos autores, 2010.

Jboss Seam

Abaixo foi feito um levantamento aproximado da quantidade de linhas do código fonte e outras métricas do ambiente Jboss Seam neste projeto.

Nome Linhas Classes/Arquivos Métodos

Controllers 2961 34 274

Models 87 12 190

View 4998 43 0

Configurações 956 40 0

Total 9002 129 464 Quadro 28 - Métricas do ambiente de desenvolvimento Jboss Seam. Elaboração dos autores, 2010.

78

Considerações finais do Tamanho do código Através das tabelas poderemos verificar que o ambiente Ruby on Rails possui valores

muito menores. Podemos então avaliar que o ambiente Ruby on Rails é mais rápido de se

realizar alterações e de se escrever tornando-o melhor para a implementação através de um

menor consumo de tempo na digitação e compreensão do código fonte.

79

12 CONCLUSÕES

Através do trabalho proposto foi realizado um estudo de dois frameworks atuais, Ruby

on Rails e Jboss Seam. De acordo com o propósito do trabalho, foi possível identificar fatores

positivos e negativos de cada framework proporcionando ao leitor a capacidade de optar ou

não pela utilização de um dos frameworks apresentados.

De acordo com o primeiro item da comparação mostrado no capitulo 3, a curva de

aprendizagem foi menos acentuada em Ruby on Rails do que no Jboss Seam.

Como já explicado no Capitulo 10.2.2 obteve-se o tempo de desenvolvimento mais rápido na

plataforma Ruby on Rails.

Foi definido para a medição da facilidade de manutenção, a inclusão de novos recursos ao

sistema. De acordo com o capitulo 10.2.3 as funcionalidades Envio de email e upload e

download de arquivos foram definidas para implementação. Tanto em Java como em Ruby on

Rails este item de comparação foi relativamente fácil e rápido.

Inicialmente foi analisada a curva de aprendizado, onde não foram encontradas muitas

dificuldades na linguagem Ruby e no Framework Ruby on Rails.

Verificou-se neste projeto que a plataforma Jboss Seam possui aproximadamente nove

mil e duas linhas de código e em Ruby on Rails possui aproximadamente mil duzentos e

sessenta e oito linhas de código. Jboss Seam, portanto possui aproximadamente seiscentos e

dez por cento mais linhas de código do que Ruby on Rails. Deve ser levado em consideração

o fato de que Jboss Seam através do Seam-gen realiza a criação de praticamente 70% do

código fonte automaticamente, ou seja, a argumentação de que a quantidade de código

implica no aumento da complexidade e diminuição da velocidade da implementação deve ser

muito bem avaliada, afinal grande parte é gerada automaticamente, sem praticamente nenhum

esforço do programador.

Percebeu-se que o framework Ruby on Rails teve dificuldades na manipulação de uma

grande carga de dados como se pode verificar nos gráficos 21 e 22 abaixo.

80

Gráfico 21 – Média do tempo de resposta na criação de cem usuários. Elaboração dos autores, 2010.

Gráfico 22 – Média do tempo de resposta na criação de mil usuários. Elaboração dos autores, 2010.

As figuras acima mostraram uma deficiência no framework Ruby on Rails utilizando-se a

versão 1.8.7 do Ruby, obtendo a marca de 238.105,2 ms para inserção de 1000 usuários no

banco de dados. Este resultado não foi satisfatório e devido a este fato uma nova solução foi

pesquisada e encontrada. Com a atualização da linguagem Ruby para versão 1.9.1, registrou-

se uma melhora surpreendente na performance da execução de grande carga de dados e

também nos outros testes executados. Cabe salientar que não houve alteração na versão do

81

framework Ruby on Rails. Através deste resultado, evidenciou-se a dependência que o

framework tem da performance de sua linguagem.

Com o aumento da carga de dados, verificou-se que Ruby on Rails na versão 1.8.7 não obteve

seu desempenho proporcional ao tempo esperado. No teste exibido no gráfico 21, obteve-se

13932,6 ms na execução dos dados. Com o aumento de carga em 10 vezes, o tempo estimado

seria de aproximadamente 139000 ms, o que não ocorreu de acordo com os resultados do

gráfico 22, obtendo-se um valor de aproximadamente setenta por cento maior do que o

esperado. Com a atualização do Ruby 1.8.7 para a versão 1.9.1, este resultado caiu de setenta

por cento a mais da versão 1.8.7 para aproximadamente quatorze por cento mais rápido do

que o tempo esperado com um ganho de desempenho de oitenta e cinco por cento.

Java, assim como a versão de Ruby 1.9.1 obteve um comportamento satisfatório,

atendendo proporcionalmente o aumento da demanda de carga. O desempenho obtido no

ambiente Java na criação de 100 usuário foi de 1257,4 ms. Na criação de 1000 usuários o

resultado estimado seria de 125740 ms no entanto obteve-se 10068,2 um rendimento de

aproximadamente vinte por cento a menos do que o esperado.

Abaixo pode-se verificar as médias obtidas nos testes de criação de 100 e 1000 serviços.

Gráfico 23 – Média do tempo de resposta na criação de cem serviços. Elaboração dos autores, 2010.

82

Gráfico 24 – Média do tempo de resposta na criação de mil serviços. Elaboração dos autores, 2010.

Assim como no exemplo anterior, pode-se claramente verificar a melhora de

performance da plataforma Ruby com a sua atualização para a versão 1.9.1.

O desempenho da plataforma Ruby na versão 1.8.7 foi de aproximadamente cinco por centro

melhor do que o resultado esperado.

O desempenho da plataforma Ruby na versão 1.9.1 foi de aproximadamente doze por cento

melhor do que o resultado esperado.

O desempenho da plataforma Java foi de aproximadamente cinqüenta e três por centro melhor

do que o resultado esperado.

Java destacou-se e nos surpreendeu com seu desempenho em relação ao Ruby on Rails

quando submetido ao processamento severo de grande quantidade de dados. Java conseguiu

efetuar as tarefas em um tempo muito menor do que o esperado e isso nos força a crer, ser o

Java uma linguagem com indicação para utilização em ambientes de grande processamento e

manipulação de dados.

Ruby, no entanto se mostrou veloz nas requisições e renderização de páginas, mas deficiente

no processamento de grande carga de dados.

Com as afirmações acima, obteve-se o seguinte quadro de comparações:

JBoss Seam Ruby on Rails

Maior facilidade no

aprendizado da tecnologia 14 semanas 9 semanas

83

Ruby on Rails.

Facilidade de manutenção

equivalentes. 4 horas. 4 horas.

Ruby on Rails se destacou

por sua simplicidade na

sintaxe e menor quantidade

de códigos

9002 linhas de código. 1416 linhas de código.

JBoss Seam destacou-se na

manipulação de uma grande

carga de dados.

Criação de 1000 Usuários =

10.068,2 ms

Criação de 1000 Usuários =

238.105,2 ms

Dependência que os

frameworks possuem de suas

linguagens.

Melhor performance do mesmo aplicativo, apenas

atualizando a versão do ruby 1.8.7 para a versão 1.9.1.

Ruby on Rails foi veloz na

manipulação de requisições e

renderização de páginas.

Logout do sistema = 164 ms Logout do sistema = 64 ms

Quadro 29 – Quadro de Conclusões. Elaboração dos autores, 2010.

84

13 TRABALHOS FUTUROS.

Migrar o software desenvolvido da versão Ruby on Rails 2.3.8 para a versão Ruby on Rails 3.0.

Migrar o software desenvolvido da versão Jboss Seam 2.0 para a versão Jboss Seam 3.0

Realizar testes no Sistema Operacional Linux.

85

APÊNDICE

86

APÊNCIDE A - Visão geral do Sistema

Trata-se de um sistema protótipo, para web, que permitirá o cadastro de usuários em

dois tipos diferentes, Empresa e Cliente.

A Empresa será capaz de se registrar e atualizar seu cadastro se necessário e através do

link “Criar novo Serviço” poderá oferecer seus serviços para os clientes que se cadastrarem

no sistema. Além dessa função no menu, a Empresa terá outros dois links para acesso, que

são:

-Ver meus Serviços solicitados: Mostra todos os serviços cadastrados da Empresa

logada.

-Ver meus Clientes: Lista todos os Clientes que contrataram o Serviço da Empresa

logada.

Caso o usuário for um Cliente, ele será capaz de “Solicitar um Serviço”, que listará

todos os serviços oferecidos de todas as empresas cadastradas no sistema. Também estará

disponível no menu de Cliente o link “Ver meus Serviços solicitados”, que mostrará todos os

serviço que o cliente logado contratou. Além da função “Editar Perfil” onde o Cliente irá fazer

todas as modificações necessárias para atualizar seu cadastro no sistema.

87

APÊNCIDE B - Casos de uso

Figura 3 – Caso de Uso de Empresa. Fonte: Nossa (2010)

Figura 4 – Caso de Uso de Cliente. Fonte: Nossa (2010)

88

APÊNCIDE C - Análise de requisitos funcionais e não funcionais.

F1 – Autenticação no Sistema Oculto ( ) Descrição: O sistema deve permitir que o usuário autentique-se e tenha autorização para realizar as ações estabelecidas. Requisitos não Funcionais Nome Restrição Categoria Desejável Permanente NF 1.1 Dados de acesso

Os usuários necessitarão saber seus logins e senha de acesso cadastrados.

Segurança ( ) (X)

NF 1.2 Pagina Única

Todo o processo de autenticação, assim como exibição de mensagens de erros será exibido em uma mesma pagina.

Interface ( ) (X)

Quadro 30 - Requisitos F1 – Elaboração dos autores, 2010.

F2 – Exibir Informações Cadastrais Oculto ( ) Descrição: O sistema irá permitir que os usuários verifiquem os seus dados cadastrais. Requisitos não Funcionais Nome Restrição Categoria Desejável Permanente NF 2.1 Controle de Acesso

Os usuários só terão acesso a esta função caso estejam autenticados no sistema.

Segurança ( ) (X)

NF 2.2 Botão Solicitar Alteração

Em cada pagina haverá um botão na qual permitira alterar os dados cadastrais.

Interface ( ) (X)

Quadro 31 - Requisitos F2 – Elaboração dos autores, 2010.

F3 – Solicitar Alteração Cadastral Oculto ( ) Descrição: O sistema irá permitir que os clientes possam alterar os seus dados cadastrais. Requisitos não Funcionais Nome Restrição Categoria Desejável Permanente NF 3.1 Controle de Acesso

Os usuários só terão acesso a esta função caso estejam autenticados no sistema.

Segurança ( ) (X)

Quadro 32 - Requisitos F3 – Elaboração dos autores, 2010.

F4 – Solicitar novo Serviço Oculto ( ) Descrição: O sistema irá permitir que os clientes realizem contratos de serviços das empresas Requisitos não Funcionais Nome Restrição Categoria Desejável Permanente NF 4.1 Controle de Acesso

Os usuários só terão acesso a esta função caso estejam autenticados no sistema.

Segurança ( ) (X)

NF 4.2 Tipos de Serviços

O sistema ira apresentar tipos cadastrados de serviços na qual

Especificação ( ) (X)

89

o cliente poderá solicitar, portanto pode-se futuramente aumentar essa quantidade.

Quadro 33 - Requisitos F4 – Elaboração dos autores, 2010.

F5 – Ver meus Serviços solicitados Oculto ( ) Descrição: O sistema irá permitir que o cliente visualize os serviços que ele contratou. Requisitos não Funcionais Nome Restrição Categoria Desejável Permanente NF 5.1 Controle de Acesso

Os usuários só terão acesso a esta função caso estejam autenticados no sistema.

Segurança ( ) (X)

NF 5.2 Dados do Serviço

Cada serviço contratado é listado, mostrando o nome do serviço, o valor do serviço e o nome da empresa que ofereceu tal serviço.

Especificação ( ) (X)

Quadro 34 - Requisitos F5 – Elaboração dos autores, 2010.

F6 – Criar novo Serviço Oculto ( ) Descrição: O sistema irá permitir que a empresa cadastre um novo serviço para oferecer aos clientes. Requisitos não Funcionais Nome Restrição Categoria Desejável Permanente NF 6.1 Controle de Acesso

Os usuários só terão acesso a esta função caso estejam autenticados no sistema.

Segurança ( ) (X)

NF 6.2 Registro

Cada serviço terá que ser inserido o seu nome, descrição e valor em reais.

Especificação ( ) (X)

NF 6.3 Edição / Exclusão

Cada serviço cadastrado poderá posteriormente ser alterado ou excluído pela Empresa.

Quadro 35 - Requisitos F6 – Elaboração dos autores, 2010.

F7 - Ver meus Serviços oferecidos Oculto ( ) Descrição: O sistema permitira que a empresa veja todos os seus serviços cadastrados. Requisitos não Funcionais Nome Restrição Categoria Desejável Permanente NF 7.1 Controle de Acesso

Os usuários só terão acesso a esta função caso estejam autenticados no sistema.

Segurança ( ) (X)

NF 7.2 Dados do Serviço

Cada serviço cadastrado é listado, mostrando o nome do serviço,a descrição do serviço e o valor em reais do serviço.

Especificação ( ) (X)

Quadro 36 - Requisitos F7 – Elaboração dos autores, 2010.

90

F8 - Ver meus Clientes Oculto ( ) Descrição: O sistema permitira que a empresa visualize todos os cliente que contrataram seus serviços cadastrados. Requisitos não Funcionais Nome Restrição Categoria Desejável Permanente NF 8.1 Controle de Acesso

Os usuários só terão acesso a esta função caso estejam autenticados no sistema.

Segurança ( ) (X)

NF 8.2 Dados do Serviço

O sistema exibirá todos os serviços que foram contratados.

Especificação

NF 8.3 Dados do Cliente

O sistema exibirá todos os clientes que contrataram os serviços da empresa.

Especificação ( ) (X)

Quadro 37 - Requisitos F8 – Elaboração dos autores, 2010.

91

APÊNCIDE D - Referências Cruzadas

Nome Atores Descrição Referencias

Cruzadas Autenticar Usuário

Cliente ou Empresa

O usuário deve inserir seu login e senha para autenticação e ter seu acesso permitido no sistema web.

F1

Solicitar Serviços

Cliente Cliente poderá contratar um serviço cadastrado no sistema.

F1,F4,F5,F6

Criar novo Serviço

Empresa Empresa poderá cadastrar um novo serviço que ela oferece.

F1,F4, F6, F7, F8

Quadro 38 - Referencias Cruzadas – Elaboração dos autores, 2010.

92

APÊNCIDE E - Mapa do site

Figura 5 – Mapa do site. Fonte: Nossa (2010)

93

APÊNCIDE F - Wireframes

Página de Autenticação

Figura 6 – Tela de login. Fonte: Nossa (2010)

94

Página de registro

Figura 7 – Tela de registro. Fonte: Nossa (2010)

95

Página inicial do usuário Empresa

Figura 8 – Tela inicial do usuário Empresa. Fonte: Nossa (2010)

Criar novo Serviço

Figura 9 – Tela para criar novo Serviço (Usuário Empresa). Fonte: Nossa (2010)

96

Ver meus Serviços oferecidos

Figura 10 – Tela para ver os Serviços oferecidos (Usuário Empresa). Fonte: Nossa (2010)

Ver meus Clientes

Figura 11 – Tela para ver Clientes (Usuário Empresa). Fonte: Nossa (2010)

97

Página inicial do usuário Cliente

Figura 12 – Tela inicial do usuário Cliente. Fonte: Nossa (2010)

Solicitar novo Serviço

Figura 13 – Tela para solicitar novo Serviço(usuário Cliente). Fonte: Nossa (2010)

98

Ver meus Serviços Solicitados

Figura 14 – Tela para ver os Serviços solicitados(usuário Cliente). Fonte: Nossa (2010)

99

REFERENCIAS BIBLIOGRÁFICAS

ALECRIM, Emerson. Conhecendo o Servidor Apache (HTTP Server Project). Disponível em <http://www.infowester.com/servapach.php> Acesso em 19 mai 2009. ANQUETIL,Nicolas. Manutenção de Software. Disponível em <http://www.ucb.br/prg/professores/anquetil/manutencao.php> Acesso em 23 jun 2009. APACHE. Apache Tomcat. Disponível em <http://tomcat.apache.org> Acesso em 19 mai 2009. AZAMBUJA. Trabalho da Semana do SBRC. Disponível em <http://professores.faccat.br/azambuja/index_paradigmas.htm>. Acesso em 12 de maio de 2009, p.1. BORLAND. Customer Profile, Sigma-Aldrich. Disponível em <http://www.borland.com/br/customers/profiles/sigma_aldrich.html>. Acesso em 20 mai 2009. BORTOLASSI,Giuliano. Conhecendo o JEE – Part2. Disponível em <http://jeenoob.blogspot.com/2007/01/conhecendo-o-jee-part2.html> Acesso em 17 mai 2009. DEVDAILY. Using the Runtime method to invoke the garbage collector. Disponível em <http://www.devdaily.com/java/edu/pj/pj010008/pj010008.shtml> Acesso em 16 mai 2009. DUCKETT, Chris. Developer Spotlight: Hitting the Seam with Gavin King. Disponível em <http://www.builderau.com.au/program/java/soa/Developer-Spotlight-Hitting-the-Seam-with-Gavin-King/0,339024620,339285612,00.htm> Acesso em 16 mai 2009. EDIGER, Brad. Advanced Rails. O'Reilly, 2007. 354 p. E-GENIAL. O QUE É RUBY ON RAILS?, Camadas MVC. Disponível em <http://www.egenial.com.br/cursorails/ruby_on_rails> Acesso em: 20 mai 2009. FACCAT. As primeiras máquinas. Disponível em <http://professores.faccat.br/assis/hcomp /PrimeirasMaquinas.html> Acesso em 17 mai 2009.

100

FAYAD, Mohamed; Schmidt, Douglas. Object-Oriented Application Frameworks. Communications of the ACM, New York, v. 40, n. 10, p. 32-38, Oct. 1997. FIALHO JR, Mozart. Dicionário de Informática – Interpretador. 2 Ed. Goiânia: Terra, 2002, p.117. ______. Dicionário de Informática – Linguagem de Maquina. 2 Ed. Goiânia: Terra, 2002, p.123. ______. Dicionário de Informática – Linguagem de Programação. 2 Ed. Goiânia: Terra, 2002, p.123. ______. Dicionário de Informática – Sistema Binário. 2 Ed. Goiânia: Terra, 2002, p.170. FLYNT, Clif. Tcl/Tk, A Developer's Guide. 2. Ed. San Francisco, 2003. FOCALINUX , Características do Apache. Disponível em < http://focalinux.cipsga.org.br/guia/avancado/ch-s-apache.htm >. Acesso em 13 jun 2010. FOLHA ONLINE. Entenda o que é o código-fonte de um programa. Disponível em < http://www1.folha.uol.com.br/folha/informatica/ult124u7618.shtml >. Acesso em 5 mai. 2009. HERCULIANI, Cristóvam Emilio. Desenvolvimento de um Software de autoria para alunos deficientes não-falantes nas atividades de contos e recontos de histórias. Marilia, 2007, p.40. HUSTON. A.B.WATLEY CASE STUDY. Disponivel em < http://in.sun.com/sunnews/success/consolidation/onlinestock.html > . Acesso em 13 jun 2010. ICEA. Instituto de Controle do Espaço Aéreo, Módulo V – Linguagens. Disponível em <http://www.icea.gov.br/ead/anexo/23101.htm> Acesso em 17 mai 2009. IDOC. Conceito de Workflow. Disponível em < www.idoc.inf.br/pdf/Workflow.pdf > Acesso em 28 Jun 2010.

101

JAVAFREE. Java. Disponível em < http://javafree.uol.com.br/wiki/java > Acesso em 27 Jun 2010. ______. Tutorial Java 2: Características Básicas. Disponível em <http://www. javafree.org/artigo/871496/Tutorial-Java-2-Caracteristicas-Basicas.html>. Acesso em 10 mai. 2009. JBOSS. Chapter 3. The contextual component model. Disponível em <http://docs.jboss.org/seam/1.2.1.GA/reference/en/html/concepts.html#d0e2518> Acesso em 18 mai 2009. ______. Framework for Organizing Cross Cutting Concerns. Disponível em <http://www.jboss.org/jbossaop/>. Acesso em 20 mai 2009. JCP. JSRs: Java Specification Requests. Disponível em <http://jcp.org/en/jsr/ detail?id=299>. Acesso em 20 mai 2009. MATZ. An Interview with the Creator of Ruby. Disponível em < http://linuxdevcenter.com/pub/a/linux/2001/11/29/ruby.html >. Acesso em 13 jun 2010. ______. More code browsing questions. Disponível em < http://blade.nagaokaut.ac.jp/cgi-bin/scat.rb/ruby/ruby-talk/2773 >. Acesso em 13 jun 2010. NGUYEN, Binh. Compiled Language. Disponível em <http://linux.about.com/cs/linux101 /g/compiledlanguag.htm>. Acesso em 13 de maio de 2009, p.1. PRADO, Alexandro dos Anjos. JEE - Um caminho prazeroso e interessante! Disponível em <http://www.devmedia.com.br/articles/viewcomp.asp?comp=3747>. Acesso em 14 de maio de 2009. PRICE, Ana Maria de Alencar & TORCANI, Simào Sirineu. Implementação de Linguagens de Programação: Compiladores. Porto Alegre, 2001, 197 pgs. RAILSGUIDE. Getting Started with Rails. Disponível em <http://guides.rubyonrails.org /getting_started.html>. Acesso em 11 de maio de 2009. REDHAT. Seam and jBPM: the todo list example. Disponível em <http://www.redhat.com /docs/manuals/jboss/jboss-eap-4.2/doc/seam/Seam_Reference_Guide/Seam_Tutorial-Seam_and_jBPM_the_todo_list_example.html> Acesso em 19 mai 2009.

102

______. Using JMX as a Microkernel. Disponível em <http://www.redhat.com/docs/en-US/JBoss_Enterprise_Application_Platform/4.3.0.cp04/html/Server_Configuration_Guide/The_JBoss_JMX_Microkernel-Using_JMX_as_a_Microkernel.html>. Acesso em 20 mai 2009. ROESLER, Wolfram. The Hello World Collection. Disponível em <http://www.roesler-ac.de/wolfram/hello.htm>. Acesso em 30 jun 2010. Ruby-Lang. Ver tudo como objeto. Disponível em < http://www.ruby-lang.org/pt/sobre-o-ruby/ >. Acesso em 13 jun 2010. SANTOS, Elomar Nascimento dos. Um pouco mais sobre o Ruby. Disponível em <http://www.elomarns.com/blog/ruby/um-pouco-mais-sobre-o-ruby> Acesso em 17 mai 2009. SAUVÉ, Jacques Philippe. FRAMEWORKS. Disponível em < http://www.dsc.ufcg.edu.br/~jacques/cursos/map/html/frame/oque.htm>. Acesso em 27 Jun. 2010. SOMMERS, Frank. Gavin King Explains JBoss Seam. Disponível em <http://www.artima.com/forums/flat.jsp?forum=276&thread=164452> Acesso em 17 mai 2009. SUN. Web-Tier Application Framework Design. Disponível em <http://java.sun.com/blueprints/guidelines/designing_enterprise_applications_2e/web-tier/web-tier5.html>. Acesso em 14 de maio de 2009. ______. About the Java EE Containers. Disponível em < http://docs.sun.com/app/docs/doc/819-3658/ablmt?l=en&a=view > Acesso em 26 Jun 2010. ______. Model-View-Controller. Disponível Disponível em <http://java.sun.com/blueprints/guidelines/designing_enterprise_applications_2e/web-tier/web-tier5.html>. Acesso em 13 jun 2010. URUBATAN, Rodrigo. Java EE 5 - servidores de aplicação. Disponível em <http://www.urubatan.com.br/java-ee-5-servidores-de-aplicacao/> Acesso em 17 mai 2009. VENNERS, Bill. Garbage Collection, Chapter 9 of Inside the Java Virtual Machine. Disponível em <http://www.artima.com/insidejvm/ed2/gc.html> Acesso em 13 mai 2009.

103

WANGENHEIM, Aldo Von. O que é um Algoritimo?. Disponível em < http://www.inf.ufsc.br/~awangenh/ICC/icc-aula2.pdf >. Acesso em 27 Jun. 2010. WEBDEVELOPERSNOTES. What is web server - a computer of a program?. Disponível em <http://www.webdevelopersnotes.com/basics/what_is_web_server.php> Acesso em 19 mai 2009. WHATIS. Web server. Disponível em <http://whatis.techtarget.com/definition/ 0,,sid9_gci213606,00.html> Acesso em 19 mai 2009.