Paulo Jorge da Silva Maia - Universidade do...

Universidade do MinhoEscola de EngenhariaDepartamento de Informática

Paulo Jorge da Silva Maia

Ruby on Rails versus Java WEB

Estudo comparativo arquitetural e metodológico

20 de Novembro de 2016

Universidade do MinhoEscola de EngenhariaDepartamento de Informática

Paulo Jorge da Silva Maia

Ruby on Rails versus Java WEB

Estudo comparativo arquitetural e metodológico

Master dissertationMaster Degree in Computer Science

Dissertation supervised byF. Mário Junqueira Martins

20 de Novembro de 2016

A G R A D E C I M E N T O S

Gostaria de expressar os meus agradecimentos a todas as pessoas, que de forma direta ouindireta, contribuíram para a realização e conclusão desta dissertação. No entanto, gostariade realçar e deixar um agradecimento especial às seguintes pessoas. Ao meu orientadorProfessor F. Mário Martins, pela orientação, disponibilidade, e sobretudo pela paciênciadespendida durante a realização desta dissertação.

Aos meus pais, pelas oportunidades que me proporcionam a longo de todo o meu per-curso académico, pela confiança depositada em mim durante a licenciatura e o mestrado,pelo incentivo e compreensão que sempre me deram.

Por fim, também gostaria de deixar os meus agradecimentos a todos os meus colegase amigos que me acompanharam durante o percurso académico, em especial ao AndréNogueira e ao Diogo Barbosa, que sempre me ajudaram a melhorar.

i

A B S T R A C T

The methodological development of multi-tier Web applications, satisfying the MVC mo-del and implementing a layer containing data persistence supported by relational databases,has been supported mainly by two major development platforms: Java WEB and .NET. Theemergence of the open source Framework Ruby on Rails, when the creation of Web applica-tions is a key area of Engineering Software, requires a detailed analysis of the characteristicsof this third platform. This work is fundamental to comparatively study the software te-chnologies and architectures proposed by Ruby on Rails versus technologies Java Web (i.eApache Struts2), and the methodologies and supporting technologies underlying both de-velopment environments.

iii

R E S U M O

O desenvolvimento metodológico de aplicações Web multi-camada, satisfazendo o modeloMVC e contendo uma camada de persistência de dados suportada por bases de dadosrelacionais, tem sido suportada fundamentalmente por duas grandes plataformas de de-senvolvimento: Java Web e .NET. O aparecimento do open source Framework Ruby onRails, num momento em que a criação de aplicações Web é uma área fundamental daEngenharia de Software, obriga a uma análise detalhada das características desta terceiraplataforma. Este trabalho tem por objetivo fundamental estudar de forma comparativa asarquiteturas de software e tecnologias propostas por Ruby on Rails versus as tecnologiasJava Web (i.e Apache Struts2) e, ainda, comparar as metodologias e tecnologias de suporteao desenvolvimento subjacentes a ambos os ambientes.

v

C O N T E Ú D O

1 introducão 3

1.1 Motivação 3

1.2 Objetivos 3

1.3 Estrutura do Documento 4

2 linguagens e frameworks 7

2.1 Breve introdução histórica das Linguagens 7

2.2 Frameworks de desenvolvimento Web 7

3 estado da arte 9

3.1 O Modelo MVC 9

3.2 Implementações MVC 10

3.2.1 Action-Based (Push-MVC) 10

3.2.2 Component-Based (Pull-MVC) 10

3.3 Java Platform, Enterprise Edition - JEE 11

3.3.1 Linguagem de Programação Java 11

3.3.2 Componentes (APIs) 14

3.3.3 Diferença entre Application Server e Container 16

3.3.4 Apache Struts2 - Framework 18

3.3.5 Componentes - Apache Struts2 18

3.4 Ruby on Rails 19

3.4.1 Ruby on Rails - Framework 20

3.4.2 Linguagem de programação Ruby 21

3.4.3 Componentes 23

3.4.4 Metodologia 27

4 integrated development environment - ide 29

4.1 Características essenciais de um Editor/IDE 29

4.2 JetBrains Rubymine 30

4.3 Netbeans 31

5 aplicações desenvolvidas 33

5.1 Affable Bean 33

5.2 Serviço de Taxis e Rent-a-Car - SeTaRe 34

5.2.1 Descrição de AirPort Taxi Transfers 35

5.2.2 Descrição de Rental Cars 35

5.3 Modelação UML 35

vii

viii Conteúdo

5.4 Implementação 37

5.4.1 Serviço de Rent-a-Car 37

5.4.2 Serviço de Táxis 39

6 análise comparativa 41

6.1 Método de Comparação 41

6.1.1 Investigação 41

6.1.2 Implementação 41

6.1.3 Avaliação 42

6.2 Critérios de Avaliação 42

6.2.1 Critérios de Avaliação – Fase I 43

6.2.2 Critérios de Avaliação – Fase II 44

6.3 Síntese de Critérios 45

7 resultados 47

7.1 Configuração Inicial 47

7.2 Documentação e Comunidade 52

7.3 Complexidade 53

7.4 Design Patterns 54

7.4.1 Model View Controller - MVC 54

7.4.2 Convention over Configuration - CoC 57

7.4.3 Inversion of Control - IoC 59

7.4.4 Don’t Repeat Yourself - DRY 63

7.5 Ecossistema do framework 63

7.5.1 Bibliotecas 63

7.5.2 Internacionalização - I18n 64

7.5.3 Asynchronous JavaScript and XML - AJAX 65

7.5.4 Scaffolding 66

7.5.5 Segurança 67

7.5.6 Testes 69

7.6 Extensibilidade 70

7.7 Suporte e Manutenção 71

8 conclusão 73

L I S TA D E F I G U R A S

Figura 1 Modelo MVC 10

Figura 2 Esquema de compilação e execução Java 12

Figura 3 Diagrama estrutural da plataforma Java 14

Figura 4 Modelo esquemático da metodologia Agile 28

Figura 5 The Affable Bean - Aplicação de compras online 33

Figura 6 Aplicações utilizadas no levantamento de requisitos 34

Figura 7 Diagrama de Casos de Uso - SeTaRe 36

Figura 8 Página Index - Aluguer de Carros 37

Figura 9 Página de resultados - Aluguer de Carros 38

Figura 10 Página de pagamento - Aluguer de Carros 38

Figura 11 Página Index - Aluguer de Taxis 39

Figura 12 Página de resultados - Aluguer de Taxis 39

Figura 13 Página de pagamento - Aluguer de Taxis 40

Figura 14 Estrutura de ficheiros em Struts2 48

Figura 15 Estrutura do ficheiros Rails 50

Figura 16 Arquitetura MVC - Struts2 55

Figura 17 Arquitetura MVC - Rails 56

Figura 18 Formas de implementação de IoC em JEE 60

ix

L I S TA D E TA B E L A S

Tabela 1 Alguns dos Application Servers Java mais utilizados no mercado 17

Tabela 2 Síntese dos critérios a avaliar 45

Tabela 3 Mapeamento URL relativa a uma Action Class 57

Tabela 4 Mapeamento do Action Result Code numa View Template (JSP) 58

Tabela 5 Rotas RESTful geradas automaticamente 58

Tabela 6 Mapeamento de Rotas REST em Rails 59

xi

L I S TA D E L I S TA G E N S

3.1 Procura utilizando métodos da Classe . . . . . . . . . . . . . . . . . . . . . . . 24

3.2 Procura utilizando clausula where . . . . . . . . . . . . . . . . . . . . . . . . . . 24

3.3 Método do objeto order(linha) . . . . . . . . . . . . . . . . . . . . . . . . . . . . 24

7.1 Criação de Setare através do generator rails new . . . . . . . . . . . . . . . . . 49

7.2 Criação de um Controller e View utilizando generator Rails . . . . . . . . . . 50

7.3 Configuração da Base de Dados em Rails . . . . . . . . . . . . . . . . . . . . . 51

7.4 Criação de Model através de Rails generator . . . . . . . . . . . . . . . . . . . 51

7.5 Definição de rotas http em Rails . . . . . . . . . . . . . . . . . . . . . . . . . . 58

7.6 Definição dos Beans com Spring . . . . . . . . . . . . . . . . . . . . . . . . . . 61

7.7 Struts2 Action com IoC . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 61

7.8 Injeção de Dependências em Ruby . . . . . . . . . . . . . . . . . . . . . . . . . 62

7.9 Definição de dependências utilizando Maven . . . . . . . . . . . . . . . . . . . 64

7.10 Definição de dependências utilizando RubyGems . . . . . . . . . . . . . . . . 64

7.11 Definição de formato de resposta em Struts2 . . . . . . . . . . . . . . . . . . . 66

7.12 Tipos de formatos de resposta em Rails . . . . . . . . . . . . . . . . . . . . . . 66

7.13 Utilização do generator scaffold . . . . . . . . . . . . . . . . . . . . . . . . . . 66

7.14 Conversão SQL resultante do uso de Query Builder de Rails . . . . . . . . . . 67

7.15 Proteção contra SQL Injection com Named Queries . . . . . . . . . . . . . . . 68

7.16 Criteria Queries em Struts2 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 69

xiii

Lista de Listagens 1

1

I N T R O D U C Ã O

1.1 motivação

Recentemente toda a comunidade informática, em especial nos Estados Unidos, vem se-guindo com curiosidade o aparecimento do Framework open-source Ruby on Rails (Rails),uma plataforma de desenvolvimento de aplicações Web tendo por base a linguagem de pro-gramação orientada pelos objetos Ruby, satisfazendo o modelo MVC e com capacidade degerir persistência. Esta plataforma foi divulgada ao público em 2005. Assim, no universodo desenvolvimento de aplicações Web, que continua a ter uma expansão muito signifi-cativa, dado que a maioria das empresas estão atualmente a converter as suas aplicaçõesdesktop para aplicações Web e até para aplicações móveis, surge a necessidade de analisare avaliar, quer do ponto de vista arquitetural quer do ponto de vista da metodologia dedesenvolvimento, esta nova alternativa, tanto mais que a mesma reclama ser, do pontode vista da eficácia de desenvolvimento, muito superior a .NET e superior às tecnologiasJava Web. Rails é um Meta-Framework constituído por Frameworks mais pequenos queabordam camadas e aspetos específicos típicos das aplicações Web.

1.2 objetivos

O desenvolvimento de novos projetos Web, tem entre outros aspetos, ser rico em funcionali-dades, extensível e de fácil manutenção. Uma grande parte dos Frameworks Web existentessão adequados apenas para projetos de pouca complexidade. Entre estes, existe um númeroparticularmente elevado de Frameworks Web open-source, o que faz com que exista algumaapreensão quanto à utilização dos mesmos no desenvolvimento de aplicações em situaçõesdo mundo real. Portanto como pré-requisito, pretende-se que o Framework de desenvol-vimento escolhido seja amplamente utilizado, de modo que este já seja considerado umaplataforma estável.

A presente dissertação tem como propósito, comparar o Framework Ruby on Rails (Rails)que apresenta uma expansão significativa no desenvolvimento de aplicações Web, comum Framework que tem como base as tecnologias Java Enterprise Edition (JEE). De uma

3

4 Capítulo 1. introducão

maneira geral, Rails é conhecido por focar-se no desenvolvimento rápido e ágil, enquantoJEE foca-se na flexibilidade e integração com IT empresarial. Desta forma pretende-se que aescolha do Framework JEE para comparar com Rails, seja tomada mediante as necessidadesdo projeto a desenvolver.

JEE apresenta uma vasta oferta de Frameworks de desenvolvimento web, desde nívelmais baixo de abstração utilizando a API Java Servlets, Frameworks pure-MVC, ou atémesmo Full-Stacks.

Considerou-se que uma boa opção de tecnologia JEE escolhida como base de comparaçãocom Rails seria o Framework Apache Struts2 (Struts2), que é um Pure-MVC Framework.

Tendo em conta que existem como outras opções Frameworks Full-Stack, o principal ar-gumento na escolha deste Framework nesta comparação, surge da necessidade de entenderqual o valor acrescentado em utilizar um Framework em que nós oferece ferramentas es-pecíficas para cada tarefa, mas que nos restringe em termos de flexibilidade, enquanto quepodemos utilizar um Framework mais simplificado, mas que nos oferece a liberdade de pa-rametrizar quais os componentes tecnológicos que pretendemos incorporar sem restriçõesa uma determinada tecnologia, como é o caso de Struts2.

No âmbito do estudo, foram ainda desenvolvidas duas aplicações Web, uma utilizandoRails e outra utilizando Struts2, que permitiram tecer considerações com base em determi-nados critérios de avaliação que foram definidos.

1.3 estrutura do documento

A presente dissertação apresenta num capítulo inicial o Estado da Arte, este por sua vez,encontra-se divido em três subcapítulos, que abordam na ordem descrita, o modelo MVC,a plataforma JEE e por último a Framework Rails.

No subcapítulo do Modelo MVC é dedicado à importância da implementação do modeloMVC e à forma como este revolucionou a estrutura das aplicações, sendo demonstrado,como é feita a implementação do modelo.

No subcapítulo JEE - Struts2, e de Rails, são abordadas de uma forma geral todas ascomponentes inerentes às respetivas plataformas, sendo introduzidas historicamente, de-monstrando a evolução das mesmas até ao atual momento. Em cada um dos subcapítulossão também abordados isoladamente nas respetivas secções os aspetos e características daslinguagens de desenvolvimento, e os diversos componentes que as caracterizam.

Após a caracterização dos Frameworks, existe ainda um capítulo dedicado à importânciados IDEs, abordando a importância dos mesmos no desenvolvimento de aplicações, ondesão abordados os dois IDEs escolhidos, nomeadamente RubyMine para o desenvolvimentoem Rails e Netbeans para o desenvolvimento de aplicações em Struts2.

1.3. Estrutura do Documento 5

De seguida, é apresentado um capítulo que apresenta as aplicações desenvolvidas, assimcomo o conjunto de principais requisitos de que são resultado, e as funcionalidades queimplementam.

Depois de demonstradas as aplicações desenvolvidas encontram-se um capítulo que de-monstra como foi definido o método comparativo, bem como os critérios de avaliação ine-rentes.

De seguida, é apresentado o capítulo de resultados que surge como o mais importanteda presente dissertação que abrange cada critério de avaliação definido, expondo as formasde implementação e comparando-as.

Por final, encontra-se uma conclusão resultante do estudo efetuado, tecendo considera-ções acerca do aspetos mais e menos fortes dos dois Frameworks.

2

L I N G U A G E N S E F R A M E W O R K S

2.1 breve introdução histórica das linguagens

Quando usamos os termos Ruby e Java, devemos salientar que estas apenas são lingua-gens. Java foi inicialmente desenvolvida pela Sun Microsystems e lançada no ano de 1995.Ruby foi desenvolvida como sendo um projeto do Governo japonês lançado também noano de 1995. Contudo, uma aplicação Web não é apenas construido recorrendo à lingua-gem, mas através da linguagem conjugada com um Framework de desenvolvimento. Oobjetivo do Framework é facilitar a construção de uma aplicação, fornecendo ferramentaspré-construídas e técnicas bem definidas e procedimentos para fazer as coisas como a vali-dação da entrada de utilizadores, gestão de conexões à base de dados, gestão dos pedidosde encaminhamento de utilizadores para o bloco de código pretendido que irá processaro pedido, fornecendo a estrutura (scaffolding) de uma aplicação rapidamente, etc. Prati-camente todos as aplicações Web modernas são desenvolvidos recorrendo a um ou maisFrameworks. O uso de um Framework permite que o programador se concentre apenas nósrequisitos da aplicação e não nos aspetos comuns a todas as aplicações (e.g forma como de-terminada linguagem acede à base de dados). Usando um Framework, este permite que oprogramador se concentre na implementação da lógica de negócio, e não nos aspetos maiscomuns que praticamente todas as aplicações partilham, acelerando o desenvolvimento.

2.2 frameworks de desenvolvimento web

Existem duas grandes categorias concetuais de Frameworks:

• Frameworks Full-Stack

• Frameworks Model View Controller (MVC)

7

8 Capítulo 2. linguagens e frameworks

Full-Stack

Frameworks Full-Stack abordam o desenvolvimento Web das aplicações Web do início aofim. Têm normalmente uma infraestrutura ou componentes que abordam o paradigmaMVC, que tratam da interação com a base de dados, implementando o CRUD da aplicação.De uma forma geral possuí toda a tecnologia que trata da interação entres os diversos com-ponentes da aplicação, deixando apenas a parte lógica para a equipa de desenvolvimento.

• VANTAGENS

As equipas de desenvolvimento não precisam de preocupar-se em como integrar coma base de dados, ou como integrar com um sistema de mensagens. É um conjuntode bibliotecas conjuntas que adotam um estilo de desenvolvimento padronizado, queassegura que o programador não tenha de escrever o código de configuração (Glue-Code) para interligar as camadas.

• DESVANTAGENS

Alguns Frameworks sugerem ou obrigam determinadas tecnologias, o que significaque se perde alguma liberdade de escolha. Assim torna-se difícil mudar alguns com-ponentes, e caso seja necessário, acaba por se perder algumas funcionalidades proje-tadas para funcionar com o conjunto completo.

Frameworks Pure-MVC

Os Frameworks MVC são tipicamente os mais populares no desenvolvimento Web, estessão estruturados em torno da estrutura de uma aplicação Web reutilizável. Reutilização édiscutida com o modelo, com objetos de domínio do negócio, ou com controlador que tratade processar os pedidos.

• VANTAGENS

São geralmente referidos como Frameworks leves, o que significa que existe uma me-nor complexidade, e menos rígidos quanto à utilização de determinadas tecnologias,ficando ao encargo do programador saber se quer integrar ou não.

• DESVANTAGENS

Geralmente tem de ser escrito o código de configuração da aplicação(Glue-Code) sem-pre que um novo plugin é adicionado.

3

E S TA D O D A A RT E

3.1 o modelo mvc

O grande desafio das equipas de desenvolvimento de aplicações é cada vez mais, produ-zir aplicações seguras, eficientes, de fácil manutenção, reutilizáveis e em prazos cada vezmenores.

Em 1979, Trygve Reenskaug surgiu com uma nova arquitetura para o desenvolvimentode aplicações. Na sua implementação, as aplicações repartiam-se em três tipos de compo-nentes: Models, Views e Controllers.

O sucesso para o desenvolvimento de aplicações com tecnologia orientada a objetos estáintimamente ligada à arquitetura que usamos para construir uma aplicação.

A organização em camadas é a chave para a independência entre os componentes e estaindependência é que vai atingir os objetivos de eficiência, escalabilidade, reutilização efacilidade de manutenção.

A arquitetura MVC fornece uma maneira de dividir a funcionalidade envolvida na ma-nutenção e apresentação dos dados de uma aplicação. Esta foi originalmente desenvolvidapara mapear as tarefas tradicionais de entrada, processamento, e saída para o modelo de in-teração com o utilizador. Usando o modelo MVC torna-se mais fácil mapear estes conceitosno domínio de aplicações Web multi-camadas.

Na arquitetura MVC o Model representa os dados da aplicação e as regras do negócioque comandam o acesso e a modificação dos dados.

A View liga o conteúdo de uma parte particular do Model e encaminha para o Controlleras ações do utilizador, obtendo os dados do Model por via do Controller definindo como osdados devem ser apresentados.

O Controller define o comportamento da aplicação, interpretando as ações do utilizadore encaminhando para determinado Model. Num cliente de aplicações Web essas ações doutilizador poderiam ser cliques de botões ou seleções de menus. As ações realizadas peloModel incluem ativar processos de negócio ou alterar o estado do Model. Com base na açãodo utilizador e no resultado do processamento do Model, o Controller seleciona determinadaView a ser mostrada como parte da resposta à solicitação do utilizador. Normalmente um

9

10 Capítulo 3. estado da arte

Figura 1: Modelo MVC

Controller trata de um conjunto de funcionalidades relacionadas. Na figura 1, pode serobservado o esquema abstrato das ligações entre os diversos componentes M-V-C. [1]

3.2 implementações mvc

Existem algumas formas de implementar a estrutura do modelo MVC. No entanto, existemdois tipos principais de arquiteturas concorrentes sobre como um Framework MVC deve serimplementado. Os dois tipos mais comuns de implementação que podem ser encontradossão:

3.2.1 Action-Based (Push-MVC)

Os Frameworks baseados em ações são os mais comuns. A ideia é que, quando um pedidovem do cliente para o servidor, existe um gestor de pedidos que funciona como um con-trolador. Este gestor envia os dados do pedido para o model, que de seguida envia para aview.

3.2.2 Component-Based (Pull-MVC)

Frameworks baseados em componentes focando-se num desenvolvimento rico do interface.Afasta-se do ligeiramente do conceito de processamento de pedido e adota um conceitobaseado na geração da View. Com Frameworks MVC baseados em componentes, é daresponsabilidade da view obter dados a partir dos vários Controllers e gerir-se a si própria.Em vez de ter o Controller, a dar todos os dados pretendidos, é a view que tem a função deextrair (puxar) todos os dados dos Controllers.

3.3. Java Platform, Enterprise Edition - JEE 11

3.3 java platform , enterprise edition - jee

As aplicações Web de hoje em dia já possuem regras de negócio bastante complicadas.Codificar essas regras representam já um grande trabalho. Além dessas regras, conhecidascomo requisitos funcionais de uma aplicação, existem outros requisitos que precisam seralcançados através da infraestrutura que são por exemplo, a persistência na base de dados,transações, acesso remoto, web services1, gestão de threads, gestão de conexões HTTP, cachede objetos, gestão de sessões web, entre outros. Estes são chamados de requisitos não-funcionais.

Se tivéssemos de ser os responsáveis por escrever código que trate desses outros requisi-tos, teríamos muito mais trabalho a fazer. Tendo isto em vista, a empresa tecnológica Suncriou uma série de especificações que, quando implementadas, podem ser usadas pelosprogramadores para tirar proveito e reutilizar toda a infraestrutura já preparada.

Java Platform, Enterprise Edition ou apenas Java EE, é uma plataforma de desenvolvi-mento para servidores da linguagem de programação Java.

O nome J2EE era usado nas versões mais antigas, até a 1.4. Hoje, o nome correto éJava EE, por uma questão de marketing, mas basta uma rápida pesquisa na Internet paraencontrar muitas referências ao antigo termo J2EE.

Esta plataforma fornece uma API e um ambiente em tempo de execução para o desenvol-vimento de softwares empresariais, incluindo serviços de rede web, aplicações de larga es-cala, aplicações multi-camadas, aplicações escaláveis e seguras. Java EE estende a Java Plat-form, Standard Edition (Java SE), fornecendo uma API para mapeamento objeto-relacional,arquiteturas multi-camada distribuídas e web services. A plataforma incorpora um desenhoamplamente baseado em componentes modulares que executam num Application Server(será abordada a importância dos Application Servers no subcapítulo 3.3.3).

3.3.1 Linguagem de Programação Java

Java é uma linguagem de programação orientada a objetos desenvolvida na década de 90

por uma equipa de programadores chefiada por James Gosling, na empresa Sun Microsys-tems. Ao contrário das linguagens convencionais, que são compiladas para código nativo,a linguagem Java é compilada para bytecode que é executado por uma máquina virtual.

1 Web service: é uma solução utilizada na integração de sistemas e na comunicação entre aplicações diferentes.


Figura 2: Esquema de compilação e execução Java

Máquina Virtual

Java é multi-plataforma. Quando um programa Java é compilado, um código intermediárioé gerado, chamado de bytecode2. Este bytecode é interpretado pelas máquinas virtuais java(JVMs) para a maioria dos sistemas operativos. A máquina virtual é a responsável por criarum ambiente multi-plataforma, ou seja, se alguém construir um sistema operacional novo,basta criar uma máquina virtual java que traduza os bytecodes para código nativo. Todas asaplicações java poderão depois ser executadas sem problemas.

Entre outras funções, a máquina virtual java também é responsável por carregar de formasegura todas as classes do programa, verificar se os bytecodes aderem a especificação JVM ese eles não violam a integridade e a segurança do sistema.

A figura 3 mostra como acontece a compilação e a execução de um programa Java. A par-tir do código Java que está num arquivo .java, o compilador javac gera o bytecode arquivo.class.Após isto uma máquina virtual java executa o bytecode e o programa.

2 Bytecode: o código de um programa de computador escrito na linguagem Java é compilado para uma formaintermediária de código denominada bytecode, que é interpretada pelas Máquinas Virtuais Java (JVMs).


As três grandes edições

Java divide-se em três grandes edições:

• Java 2 Standard Edition (J2SE): É a tecnologia Java para computadores pessoais (desk-top), e arquiteturas com poder de processamento e memória consideráveis. VáriasAPIs acompanham esta versão e tantas outras podem ser transferidas opcionalmenteno site da Sun. É com elas que a maioria das aplicações são construídas e executadas.O J2SE possui duas divisões:

– Java Development Kit (JDK) ou Standard Development Kit (SDK): um conjuntode ferramentas de desenvolvimento, que suporta a construção de aplicações emJava.

– Java Runtime Edition JRE: uma versão mais leve da JDK pois é preparada para oambiente de execução, ou seja, é esta versão que executa nos sistemas construídoscom SDK.

• Java 2 Mobile Edition (J2ME): É a tecnologia Java para dispositivos móveis com limi-tações de memória ou processamento. Possui APIs simples e leves para economizarespaço, memória e processamento. São utilizadas para sistemas móveis, palm tops,pocket pcs, smartphones, javacards entre outros. O J2ME divide-se em dois gruposde bibliotecas:

– Connected Limited Device Configuration (CLDC): Para telemóveis e smartpho-nes, que são mais limitados

– Connected Device Configuration (CDC): Para Palmtops e Pocket pcs e algunsdispositivos mais poderosos.

• Java Enterprise Edition (JEE): É a tecnologia Java para aplicações empresariais quepodem estar na Internet ou não. Possui um grande número de APIs onde a segurançaé a principal preocupação.

A Plataforma JEE baseia-se na plataforma Java SE, desta forma, na figura 3 abaixo, érepresentada a plataforma Java em forma de diagrama concetual das tecnologias fornecidaspelo Java Development Kit (JDK).


Figura 3: Diagrama estrutural da plataforma Java

3.3.2 Componentes (APIs)

As aplicações multi-camada são por norma difíceis de programar, pois implicam complexaslinhas de código para abordar transações, manutenção de estados, processos e concorrência,recursos e outros detalhes de baixo nível. A arquitetura JEE é baseada em componentes eindependente da plataforma, tornando as aplicações fáceis de escrever porque a lógica donegócio é organizada em componentes reutilizáveis. Além disso, o servidor JEE forneceserviços subjacentes sob a forma de um container para cada tipo de componente. Destaforma sem ser necessário desenvolver estes serviços, o programador torna-se livre para seconcentrar em resolver o problema em questão. O JEE possui dezenas de APIs para imple-mentar todo o tipo de serviços existentes na web. Algumas das principais especificaçõesou APIs disponibilizadas pelo JEE [2]:

• Java Servlets: A API Java Servlet (javax.servlet) proporciona ao programador a possi-bilidade de adicionar conteúdo dinâmico num servidor web utilizando a plataformaJava. Desta forma o programador possui uma interface para o servidor web (ou ser-vidor de aplicação), através de uma API. As aplicações baseadas em Servlets geramconteúdo dinâmico (normalmente HTML) e interagem com os clientes, utilizando omodelo requisição-resposta (Request-Response).

• JavaServer Pages (JSP): é uma tecnologia que ajuda os programadores a criarem pá-ginas web geradas dinamicamente baseadas em HTML, XML ou outros tipos de do-


cumentos. É similar ao PHP, mas usa a linguagem de programação Java. Para imple-mentar e executar JavaServer Pages, é necessário um servidor web compatível comum Servlet Container (este assunto será abordado com maior pormenor no subcapítulo3.3.3), como Apache Tomcat, Jetty ou Glassfish.

• Java Server Faces (JSF): É uma especificação para criar interfaces gráficas de aplicaçõesweb. O seu objetivo é sistematizar o que as interfaces web têm em comum, apoiandoo programador nesse sentido. Com relativa facilidade permite desenvolver interfacesweb ricas e interativas (cujas aplicações são denominadas RIA - Rich Internet Applica-tion). Executa do lado do servidor e é totalmente orientada ao componente, para alémde uma série de componentes (abstrações dos componentes HTML), prevê validação,gestão de estado, conversores, modelo de eventos, etc.

• Enterprise Javabeans Components (EJB): É um modelo do lado do servidor que en-capsula a lógica de negócio da aplicação.

• Java Database Connectivity (JDBC): é um conjunto de classes e interfaces que fazemo envio de instruções SQL para uma qualquer base de dados relacional.

• Java Persistence Arquitecture (JPA): É uma especificação que descreve a gestão dosdados relacionais nas aplicações.

• Java API for XML Web Services (JAX-WS): Simplifica a criação e instalação de web-services e clientes de web-services.

• Java API for XML Binding (JAX-B): Permite mapear as classes Java em representaçõesXML. JAXB fornece duas grandes funcionalidades: a capacidade de converter objetosJava em XML e vice-versa.

• Java Autenthication and Authorization Service (JAAS): O principal objetivo de JAASé a separação de preocupações na autenticação do utilizador, para que possam sergeridas independentemente.

• Java Transaction API (JTA): Especifica interfaces Java entre um gestor de transaçõese as partes envolvidas no sistema de distribuição das transações (gestor de recursos,servidor da aplicação, e aplicações transacionais).

• Java Message Service (JMS): É uma API da linguagem Java para middleware3 orien-tado à mensagens. Através da API JMS duas ou mais aplicações podem se comunicarpor mensagens.

3 É um programa que faz a mediação entre software e demais aplicações. É utilizado para mover ou transportarinformações e dados entre programas de diferentes protocolos de comunicação, plataformas e dependênciasdo sistema operativo.


• Java Naming and Directory Interface (JNDI): É uma API para acesso a serviços de di-retórios, que permite que aplicações cliente descubram e obtenham dados ou objetosatravés de um nome.

• Java Management Extensions (JMX): É uma tecnologia Java que fornece ferramentaspara a gestão e monitorização de aplicações, objetos do sistema, dispositivos e redesorientadas a serviço.

Para além das especificações acima mencionadas existem muitas mais, que podem serencontradas no o site do Java Community Process4, explicando tudo sobre as Java SpecificationRequests (JSR), isto é, os novos pedidos de bibliotecas e especificações para Java, tanto paraJava SE, e Java EE.

A última versão disponível da especificação do JEE é a versão 7, lançada em 12 de ju-nho de 2013. É uma versão ainda muito recente, com poucas ferramentas e servidoresdisponíveis. A versão mais usada no mercado é a versão 6, de 2009.

Das APIs anteriormente mencionadas JSP, JPA e Servlets são sem dúvida as especifi-cações essenciais que qualquer programador Java precisa para desenvolver aplicações web.Mesmo usando frameworks e bibliotecas que facilitam o trabalho para a Web, conhecer bemestas especificações é certamente um diferencial, e fará com que se entenda motivações edificuldades, auxiliando decisões arquiteturais e a modelação.

3.3.3 Diferença entre Application Server e Container

Para desenvolver aplicações JEE, baseamo-nos nas suas especificações, contudo é necessárioutilizar um servidor que as implemente. Neste contexto é importante distingir o conceitoApplication Server e Container.

Existem diversos servidores famosos compatíveis com a especificação do J2EE 1.4, JEE5 e 6, e já alguns para JEE 7. O JBoss é um dos líderes do mercado e tem a vantagemde ser gratuito e open source. Alguns softwares implementam apenas uma parte dessasespecificações do JEE, como o Apache Tomcat, que só implementa JSP e Servlets (como foireferido no subcapítulo anterior, estas são duas das principais especificações), portanto nãoé totalmente correto chamar-lhe servidor. [2]

A tabela 1 abaixo mostra alguns dos servidores com maior relevância no mercado atual.

4 Java Specifications Requests: http://www.jcp.org/


Empresa Nome do Servidor Gratuito Versão da PlataformaOracle/Sun GlassFish Server Open Source Edition 4.0 X JEE 7

RedHat JBoss Application Server 7.x X JEE 6

Apache Apache Geronimo X JEE 6

Oracle/BEA Oracle WebLogic Server 8.x - JEE 6

IBM IBM WebSphere Application Server - JEE 6

SAP SAP NetWeaver Application Server - JEE 6 Web Profile

Tabela 1: Alguns dos Application Servers Java mais utilizados no mercado

Desta forma, a partir do JEE 6 foi criado o termo "application server web profile", para poder-se referenciar servidores que não oferecem tudo, mas um grupo menor de especificações,consideradas essenciais para o desenvolvimento web.

Dentre as várias especificações, o JEE possui algumas funcionalidades específicas paralidar com o desenvolvimento web que são Servlet, JSP, JSTL e JSF.

Ao servidor que suporta estas funcionalidades nucleares dá-se o nome de Servlet Contai-ner. Este não é necessariamente JEE Web Profile nem o JEE completo. É indicado a quem nãoprecisa de tudo o que o JEE ofereçe e está interessado apenas na parte web (boa parte dasaplicações de médio porte encaixam-se nessa categoria). No mercado atual Apache Tomcat,é talvez o servlet container mais famoso.

Mapeamento Objeto-Relacional como auxiliar do Model

Atualmente em JEE existem duas importantes ORMs que são Hibernate e EclipseLink, queapresentam diferenças na sua implementação. Tal como foi referido anteriormente existemdeterminadas APIs que apenas podem ser implementadas por um servidor com suporteàs funcionalidades completas do JEE. Os EJBs são um dos casos, em que é necessário umservidor como Glassfish ou JBoss. Caso seja usado o Framework Hibernate poderá ser imple-mentado utilizando Apache Tomcat, pois este não implementa EJBs. No caso de EclipseLinké necessário um servidor que ofereça todas as potencialidades.

• No caso de se pretender implementar o Framework ORM EclipseLink, o IDE permite-nos que sejam geradas automaticamente, as Entity Classes a partir da base de dados,implementando desta forma a JPA (Java Persistence Architecture) para cada tabela e asSession Beans para cada classe Entidade anteriormente gerada, implementando Enter-prise Java Beans em forma de Session facades para cada entidade, com os métodos deacesso básicos (CRUD5) incluídos .

• No caso de se pretender implementar o Framework ORM Hibernate, este não ne-cessita obrigatoriamente que exista um servidor aplicacional para que possa ser im-

5 CRUD é a designação técnica para as operações básicas de interação com a base de dados: Create(Criar),Read(Ler), Update(Atualizar) e Delete(Apagar)


plementado, como acontece no caso do EclipseLink, podendo ser ser implementadopor um Servlet Container. Contudo, existe algum esforço de configuração acrescido,dado que terão que ser implementados manualmente os DAOs6 que são uma diretacorrespondência às Session Facades (Session Beans) criadas pelo EclipseLink.

3.3.4 Apache Struts2 - Framework

Apache Struts2 é um Framework Web open-source de desenvolvimento de aplicações JavaEE. Este utiliza e estende a API Java Servlet, encorajando que as aplicações desenvolvidasadotem a arquitetura do padrão MVC.

O Framework Struts foi originalmente desenvolvida por Craig R. McClanahan em 2001,passando depois a ser gerida pela Apache Software Foundation em 2002. Struts proporci-onou uma excelente estrutura para desenvolvimento de aplicações através da combinaçãoda API Java Server Pages e de Servlets, permitindo criar um ambiente de desenvolvimentoextensível. No entanto, com a crescente demanda de aplicação web, Struts não se conseguiumanter firme, e necessitou de ser reestruturado. Em 2005 Struts funde-se com o FrameworkWebWork da OpenSymphony (outro Framework Java EE) uniu esforços conjuntos para de-senvolver um Framework avançado com todos os recursos de desenvolvimento possíveispara tornar o desenvolvimento completamente amigável criando assim o Apache Struts2.[3]

3.3.5 Componentes - Apache Struts2

Struts2 é um Framework pure-MVC. Desta forma, os componentes que o constituem repre-sentam papéis importantes na implementação do padrão MVC [4]

• StrutsPrepareAndExecuteFilter - Constitui o Controller, verificando cada pedido eencaminhando para a devida localização onde deverá ser processado.

• Actions - Representam o Model e são responsáveis pelo comportamento que será exe-cutado a fim de responder um determinado pedido.

• Interceptors - Estes componentes atuam como filtros que executam antes e após opedido ser processado. São utilizados para desempenhar as funções comuns (e.gvalidações de login e de sessão).

6 DAO (Data Access Objects), é um padrão para persistência de dados que permite separar regras de negóciodas regras de acesso à base de dados.

3.4. Ruby on Rails 19

• ActionContext - Representa o contexto de execução de uma Action, contendo todosos dados relacionados com a Action e do próprio Framework (ValueStack, Session, Re-quests,etc.).

• ValueStack - Representa a área de armazenamento que mantém todos os dados asso-ciados com o processamento do pedido. Desta forma não é necessário passar os dadosde forma individual entre os vários componentes (classes) que estão envolvidos nesteprocessamento.

• Object-Graph Navigation Language - OGNL - É a linguagem de expressões quepermite obter e atualizar propriedades dos objetos, permitindo a manipulação depropriedades existentes na ValueStack.

• Results - Cada Action define um ou mais Results. Após a execução de uma Action,o Result indica o template que será responsável pela apresentação dos dados aosutilizados, constituindo a View.

3.4 ruby on rails

Ruby on Rails (vulgarmente chamado de apenas Rails) é um excelente exemplo de um pro-jeto open-source bem sucedido. No entanto, não podemos discutir Rails sem antes discutir alinguagem de programação Ruby.

É um equívoco comum pensar que Ruby e Ruby on Rails são a mesma coisa. Emboraintimamente relacionados, estes são distintos. Quando alguém diz Ruby, refere-se nor-malmente à linguagem de programação em si. Ruby on Rails é uma full-stack7 para odesenvolvimento de aplicações Web que foi criada com recurso a Ruby.

Rails ajudou a impulsionar movimentos como o Test Driven Development, mais conhe-cido como TDD8, Pair Programming e outras metodologias ágeis. Desempenhou um papelimportante no que diz respeito à adoção de Ruby no que diz respeito à escolha dos progra-madores.

Neste capítulo, pode ler-se uma breve história sobre a linguagem Ruby e aprender algu-mas das características. Em seguida, será apresentado como Rails passou a ser consideradapor muitos uma das estruturas mais reconhecidas e emergentes para o desenvolvimentode aplicações web. Depois de apresentar os principais conceitos envolvidos no frameworkRails são dedicadas secções à estrutura e componentes do Framework.

7 Full-Stack, é entendido como sendo uma super-Framework, que agrega Frameworks mais pequenas e especifi-cas que permitem assim desenvolver aplicações, sem ter de recorrer a outras fontes externas.

8 Test Driven Development (TDD), é uma técnica de desenvolvimento de software que se baseia num ciclocurto de repetições, primeiro o programador escreve um caso de teste automatizado que define uma melhoriadesejada ou uma nova funcionalidade, apoós isto é produzido código que possa ser validado pelo teste paraposteriormente o código ser refeito sob padrões aceitáveis.


3.4.1 Ruby on Rails - Framework

História

Em 2001, David Heinemeier Hansson (o criador de Ruby on Rails) foi contratado por JasonFried para construir uma ferramenta de gestão de projetos baseado em ambiente web, o queacabou se tornando a 37signals9 software como um serviço denominado por Base-Camp10.Hansson decidiu iniciar o projeto através do desenvolvimento de uma framework webpersonalizada usando a linguagem de programação Ruby para evitar o que ele via comocodificação repetitiva inerente as plataformas como Java. Ruby era quase desconhecidona época. A framework que Hansson criou mais tarde foi lançada como um projeto open-source, independente da ferramenta de gestão de projetos. O nome deste framework webopen-source dado foi Ruby on Rails.

Em 2005, Hansson chamou a atenção da comunidade com um famoso vídeo chamado"Fazer um blog em 15 minutos.", onde mostrava uma introdução sobre desenvolvimentocom Rails. No mesmo ano, a sua criação fez com que ganhasse o prémio Google-O’ReillyBest Hacker. O sucesso de Ruby on Rails é considerado por muitos, como o maior respon-sável pela aceitação em massa da linguagem Ruby. Desde então foram criados frameworksdirecionados para a programação em linguagem Ruby, dando especial ênfase à frameworkMERB11, que dividia alguns dos programadores. No entanto, em 23 dezembro de 2008 ,foi anunciado (por Hansson no site de Ruby on Rails) que MERB seria fundida em Rails 3,sendo assim terminada a duplicação desnecessária em ambas as comunidades, e fechandoo debate sobre quando escolher um sobre o outro. As melhores ideias, de ambos os la-dos foram escolhidas para criar um projeto melhor e mais forte. Este é um bom exemplode como funciona a comunidade open-source de Ruby, sendo esta uma vantagem em com-paração com, por exemplo, o mundo Java, onde se pode encontrar dezenas de diferentesframeworks para os mesmos fins. Pela razão de existirem tantas opções, os programadoresacabam confusos e por fazerem parte de diferentes comunidades ficam divididos. O apa-rente problema é existir por parte das comunidades, um objetivo comum, mas "remam"emdireções opostas e devido a isso, á menos colaboração e o progresso é mais lento. Embora,com uma incrível crescente exponencial nos últimos anos, o que pode levar a novas e dife-rentes formas de pensar, essa grande divisão não parece estar a acontecer na comunidadeRails. [5]

9 37signals é uma empresa de aplicações web privada com sede em Chicago, Illinois. A empresa foi co-fundadaem 1999 por Jason Fried, Carlos Segura, e Ernest Kim.

10 Base-Camp é uma ferramenta de gestão de projetos baseado na web desenvolvido pela 37signals e lançado em2004.

11 Merb é um framework MVC que utiliza a linguagem Ruby.


Princípios

A filosofia Rails inclui vários princípios de orientação [6]:

• MVC - Model View Controller: Rails usa a arquitetura MVC destina-se a ser utilizadocom uma metodologia de desenvolvimento ágil, oferecendo aos programadores umambiente de desenvolvimento de aplicações Web rápida.

• CoC - Convetion over Configuration: Através de um boa convenção de nomes dadosaos Models, Contollers e Views o Rails ajusta cada pormenor, sem que seja necessáriorecorrer a extensos arquivos de configuração.

• DRY - Don‘t Repeat Yourself: Escrever o mesmo código várias vezes é uma coisamá, por isso DRY é um princípio de desenvolvimento de software que visa reduzir arepetição de informações de todos os tipos.

• REST - Representational State of Transfer): Um padrão para aplicações Web quepermite organizar a aplicação em torno de recursos e normas HTTP descobrindo qualé o caminho mais rápido.

3.4.2 Linguagem de programação Ruby

‘Ruby is simple in appearance, but is very complex inside, just like our human body”

Yukihiro Matsumoto, criador da Linguagem Ruby

Ruby é uma linguagem de programação dinâmica e orientada a objetos open-source. Nãoé apenas livre para usar, mas também de copiar, modificar e distribuir. Ruby foi criado porYukihiro Matsumoto (também conhecido como Matz) ao abrigo de um projeto do Governojaponês e lançado publicamente em 1995. Ruby obteve uma aceitação em massa por partedos utilizadores em 2006. O ideal seguido por Matsumoto foi misturar partes de suas lin-guagens favoritas (Perl, Smalltalk, Eiffel, Ada, e Lisp), equilibrando a programação funcionalcom a programação imperativa para criar uma linguagem multi-paradigma. O objetivoera criar uma linguagem natural. Matsumoto acredita que as pessoas desejam expressar-sequando programam. Os programadores não querem lutar contra a linguagem. As lingua-gens de programação devem fazer-se sentir ao programador de maneira natural. Ruby estábaseada no “Princípio da menor surpresa”, o que significa que a linguagem se comportada maneira que se espera. [7]

Interpretador Ruby

Antes da linguagem Ruby se tornar popular, existia apenas um interpretador disponívelescrito pelo próprio Matz, em C. É um interpretador simples, sem nenhuma gestão de


memória muito complexa, nem características modernas de interpretadores como a com-pilação em tempo de execução (conhecida como JIT12). Hoje a versão mais difundida é a2.0, também conhecida como YARV (Yet Another Ruby VM), já baseada em uma máquinavirtual com recursos mais avançados.

Com a popularização da linguagem Ruby, principalmente após o surgimento do Rubyon Rails, implementações alternativas da linguagem foram a surgindo. A maioria delassegue uma tendência natural de serem baseados numa Máquina Virtual invés de sereminterpretadores simples. Algumas implementações possuem até compiladores completos,que transformam o código Ruby em alguma linguagem intermediária a ser interpretadapor uma máquina virtual.

A principal vantagem das máquinas virtuais é facilitar o suporte em diferentes platafor-mas. Além disso, ter código intermediário permite otimização do código em tempo deexecução, feito através da JIT.

Alguns dos interpretadores alternativos mais conhecidos são [8]:

• JRuby - Foi a primeira implementação alternativa completa da versão 1.8.6 do Rubye é a principal implementação da linguagem Java para a JVM. Com o tempo ganhoucompatibilidade com as versões 1.8.7 e 1.9.3 na mesma implementação. Como roda naJVM, não é um simples interpretador, já que também opera nos modos de compilaçãoAOT (Ahead Of Time) e JIT (Just In Time). Uma de suas principais vantagens é ainteroperabilidade com código Java existente, além de aproveitar todas as vantagensde uma das plataformas de execução de código mais maduras (Garbage Collector,Threads nativas, entre outras).

• IronRuby - A comunidade .Net também não ignorou o sucesso da linguagem e pa-trocinou o projeto IronRuby, que era mantido pela própria Microsoft. IronRuby foium dos primeiros projetos verdadeiramente de código aberto dentro da Microsoft.Em 2010 a Microsoft parou de manter o projeto e a versão atual do IronRuby, 1.1.3,implementa apenas até o Ruby 1.9.2.

• Rubinius - Criada por Evan Phoenix, Rubinius é um dos projetos que tem recebidomais atenção da comunidade Ruby, por ter o objetivo de criar a implementação deRuby com a maior parte possível do código em Ruby. Além disso, trouxe ideias demáquinas virtuais do SmallTalk, possuindo um conjunto de instruções (bytecode) pró-prio e implementada em C/C++. O Rubinius está sempre atualizado com as últimasversões do Ruby e roda no MacOS X e em sistemas Unix/Linux. No Windows aindanão é suportada.

• Ruby Enterprise Edition - Foi criada para melhorar a performance de aplicaçõesRails e diminuir a quantidade de memória utilizada, Ninh Bui, Hongli Lai e Tinco

12 JIT - Just in Time, significa conversão em tempo de execução.


Andringa, modificaram o interpretador Ruby e lançaram com o nome de Ruby En-terprise Edition. As principais modificações no REE foram no comportamento doGarbage Collector, fazendo com que funcione com o recurso de Copy on Write13 dispo-nível na maioria dos sistemas operativos baseados em UNIX.

Principais características

Em Ruby, tudo são objetos. Mesmo os tipos de dados básicos, como números ou valoresbooleanos, o que faz com que todas as operações que são realizadas num objeto sejammétodos, e que cada método retorne um objeto.

Ruby é uma linguagem dinâmica com tipagem forte, interpretada em tempo de execuçãocom Duck-Typing14

O Ruby suporta somente a herança simples, mas dispõe da estrutura funcional Moduleque implementa o conceito de módulos (Modules), que agem como coleções de métodos.As classes podem conter determinados módulos, herdando todos os seus métodos. Destaforma ruby consegue obter a capacidade da herança múltipla.

3.4.3 Componentes

Active Model

Em geral, nas aplicações que são desenvolvidas, pretendemos que as informações sejamguardadas numa base de dados relacional. Sistemas de entrada de dados, guardam enco-mendas, linhas de encomenda, detalhes dos clientes, etc, em tabelas de base de dados. Atémesmo as aplicações que normalmente utilizam texto não estruturado, como web-blogs,frequentemente utilizam bases de dados como sendo o seu back-end para armazenamentode dados.

Embora não seja imediatamente aparente a partir do SQL 15 aceder aos dados, os bancosde dados relacionais são concebidos em torno de teoria dos conjuntos matemáticos. Ape-sar disso ser bom do ponto de vista conceptual, torna-se difícil combinar bases de dadosrelacionais com linguagens de programação orientadas a objetos. Falar de objetos é falarde conjuntos de dados e de operações, e falar de bases de dados é falar de atribuições de

13 Copy on Write é uma estratégia de otimização, que decorre do entendimento que, quando várias tarefas separa-das usam cópias idênticas da mesma informação, ou seja, os dados armazenados na memória do computadorou armazenamento em disco, não é necessário criar cópias separadas das informações de cada processo, emvez disso são atribuídos apontadores para o mesmo recurso.

14 Duck typing, em linguagens de programação orientadas por objetos é um estilo de escrita dinâmica na progra-mação, em que os métodos de objetos e as suas propriedades determinam a validade da semântica, invés deherdar de uma determinada classe ou implementação de uma interface específica.

15 Structured Query Language, é a linguagem de pesquisa declarativa padrão para base de dados relacional.Muitas das características originais do SQL foram inspiradas na álgebra relacional.


valores. Operações que são fáceis de expressar em termos relacionais são por vezes difíceisde codificar num sistema orientado a objetos, sendo que o inverso também é verdadeiro.[9]

Com o evolução das programação orientada a objetos, os programadores têm trabalhadona melhor forma de conciliar os pontos de vista relacional e orientados a objetos dos seusdados. O Rails mapeia os dados relacionais em objetos.

Mapeamento Objeto-Relacional - ORM16

As bibliotecas ORM mapeiam as tabelas da base de dados em classes. Se a base de dadostem uma tabela Orders, a aplicação vai ter uma classe chamada Order. As linhas nesta tabelacorrespondem a objetos da Classe, uma encomenda (order), em particular é representadacomo um objeto da Classe Order. Dentro desse objeto, os atributos são usados para obtere definir as colunas individuais. O objeto Order possui métodos para obter e definir osvalores. As classes Rails que envolvem as tabelas da base de dados fornecem um conjuntode métodos à classe que executam operações ao nível das tabelas. Podemos por exemploprecisar de encontrar a encomenda com um ID em particular, sendo que isto pode serimplementado como um método da classe que retorna o objeto Order correspondente. Emcódigo Ruby pode ser feito como é demonstrado no excerto de código 3.1 abaixo.

1 order = Order.find (1)

2 puts "Customer #{ order.customer_id}, amount=$ #{order.amount}"

Código 3.1: Procura utilizando métodos da Classe

Por vezes os métodos de classe podem também devolver coleções de objetos, como podeser visto no excerto de código 3.2.

1 Order.where (:name => 'dave' ).each do |order|

2 puts order.amount

3 end

Código 3.2: Procura utilizando clausula where

Os objetos que correspondem a linhas individuais de uma tabela têm métodos que atuamsobre essa mesma linha. Um exemplo de um método usualmente utilizado é save(), que é aoperação que guarda a linha na base de dados. Um exemplo é demonstrado no excerto decódigo abaixo.

1 Order.where (:name => 'dave' ).each do |order|

2 order.pay_type = "Purchase order"

16 Object-Relational Mapping, é uma técnica de desenvolvimento utilizada para reduzir a impedância da pro-gramação orientada aos objetos utilizando bancos de dados relacionais. As tabelas do banco de dados sãorepresentadas através de classes e os registos de cada tabela são representados como instâncias das classescorrespondentes.


3 order.save

4 end

5 %

Código 3.3: Método do objeto order(linha)

Desta forma a camada ORM mapeia as tabelas em Classes, linhas em objetos, e colunasem atributos desses objetos. Os métodos da Classe são utilizados para executar operaçõesao nível das tabelas, e os métodos de instância executam operações em linhas das tabelas.

Active Record

Active Record é a camada ORM nativa de Rails. Esta segue o modelo ORM padrão (tabelasmapeadas para classes, linhas para objetos, e colunas para atributos de objeto). Difereda maioria das outras bibliotecas ORM na forma como está configurado. O Active Recorddiminui a quantidade de configuração que o programador necessita de fazer. Active Recordalivia-nos das dificuldades de lidar com a base de dados subjacente, deixando-nos livrespara trabalhar na lógica de negócio da aplicação.

Action Pack: Action Controller e Action View

A View e o Controller são partes do MVC que estão intimamente ligadas. O Controllerfornece os dados à View, e recebe os eventos das páginas geradas pelas Views. Devido aestas interações, o suporte para as Views e para os Controllers são agrupados no mesmopacote como um componente único. Pensar que Rails baralha o conceito da View com ode Controller devido à combinação dos dois num único componente é errado. Na realidadeé o contrário, pois permite ter a separação de que precisamos exatamente para escreveraplicações web com clareza no código de controlo e na lógica de apresentação.

Action View

Em Rails a View é normalmente responsável pela criação de toda ou quase toda a parte daresposta que é exibida no web-browser, processado por uma aplicação, ou até enviada comoemail. Na sua forma mais simples, a View é um pedaço de código HTML que exibe textoestático. Contudo esta foi desenvolvida essencialmente para se poder incluir conteúdodinâmico criado por um determinado método de uma ação no controlador. Em Rails,o conteúdo dinâmico é gerado por templates, destes existem três tipos. O esquema detemplates mais comum, é o chamado ERB ou Ruby embebido, incorpora pedaços de códigoRuby dentro da View, esta é em alguns aspetos semelhante ao modo como é feito noutrosframeworks web, como PHP ou JSP. Embora esta abordagem seja muito flexível, algunsprogramadores estão preocupados que seja violado o principio da separação de camadas


do MVC. Ao incorporar código na View, corre-se o risco de adicionar lógica que deve serfeita apenas no Model ou no Controller. Como em tudo, enquanto o seu uso for criteriosoe com moderação esta é uma boa prática, mas o seu excessivo uso pode tornar-se umproblema. A manutenção de uma separação clara das preocupações é parte do trabalho doprogramador.

Tal como é usado conjuntamente com HTML o ERB pode também ser usado para cons-truir fragmentos de JavaScript17 no servidor, que serão posteriormente executados no web-browser. Desta forma é permido ao programador criar mais facilmente interfaces AJAX18

dinâmicas.

Em Rails é também possível construir documentos XML19, através do construtor XMLfornecido por Rails que utiliza código Ruby. Desta forma a estrutura do código XMLgerado segue automaticamente a estrutura do código.

Action Controller

Em Rails o Controller, é o centro lógico da aplicação da aplicação. Coordena a interação entreo utilizador, as views e o model. Contudo Rails trata da maioria das interações, permitindoque o código que o programador escreva se concentre apenas nas funcionalidades ao nívelda aplicação. Desta forma o código do controller torna-se bastante fácil de desenvolver ede manter. O controller, é também importante, pelo seu papel no auxilio de outros serviçoscomo encaminhar pedidos externos para ações internas, tratando dos URLs com bastantefacilidade. Gere a cache20, o que aumenta a performance substancialmente. Gere módulosauxiliares, que estendem as capacidades dos templates de visualização sem aumentar acomplexidade do código. Gere as sessões, dando aos utilizadores a impressão de interaçãocontínua com a aplicação.

Action Mailer

É um Framework para a criação de serviços de e-mail, que pode ser usada para enviare-mails com base em modelos flexíveis, ou para receber e processar e-mails recebidos.

17 JavaScript é uma linguagem de programação interpretada que foi originalmente implementada como parte dosweb-brwosers para que scripts pudessem ser executados do lado do cliente e interagissem com o utilizadorsem a necessidade deste script passar pelo servidor.

18 AJAX, Asynchronous Javascript and XML é o uso metodológico de tecnologias como Javascript e XML, pro-vidas por web-browsers, para tornar páginas Web mais interativas com o utilizador, através de solicitaçõesassíncronas de informações.

19 XML: eXtensible Markup Language é uma recomendação da W3C para gerar linguagens de marcação paranecessidades especiais.

20 Cache é um dispositivo de acesso rápido, interno a um sistema, que serve de intermediário entre um operadorde um processo e o dispositivo de armazenamento ao qual esse operador acede.


Active Support

Active Support é o componente de Rails responsável pelo fornecimento de extensões delinguagem Ruby e ferramentas de utilizade variada. Através do Active Support é possi-vel oferecer uma linha de fundo mais rica ao nível da linguagem, orientada tanto para odesenvolvimento de aplicações Rails, e ao seu desenvolvimento.

3.4.4 Metodologia

Rails é um Framework Agile21. É difícil ou até talvez impossível encontrar em algumacomunidade a disponibilizar tutoriais que ensinem outras metodologias que não sejamágeis. A razão é simples e subtil, pois agilidade é parte da forma como foi desenvolvida oFramework.

Olhando para os valores expressos no manifesto Agile, podemos observar um conjuntode quatro preferências [10]:

• Indivíduos e interações sobre processos e ferramentas

• O Software funciona sobre documentação

• A colaboração com o cliente é mais do que negociação de contratos

• Responder a mudanças é mais importante do que seguir um plano

Rails é sobre os indivíduos e as suas interações, não existindo conjuntos de ferramentaspesadas, nem configurações complexas, e sem complexos processos de elaboração. Destaforma trata-se de pequenos grupos de programadores a utilizar os seus editores favoritose a usar código Ruby. Isto leva à transparência, o que o programador desenvolve reflete-seimediatamente no que o cliente vê, tratando-se de um processo intrinsecamente interativo.

Rails encoraja a colaboração do cliente. Quando os clientes vêm o quão rapidamenteum projeto responde à mudança, eles começam a confiar que a equipa de desenvolvimentoconsegue desenvolver o que é necessário, e não apenas o que foi solicitado.

21 Agile é um conjunto de metodologias de desenvolvimento de software.


Figura 4: Modelo esquemático da metodologia Agile

Tudo isto prende-se à ideia de o projeto ser capaz de responder à mudança. A maneiraque o Rails honra o princípio DRY significa que as alterações em aplicações Rails, temum impacto muito menor do que se as mesmas alterações fossem necessárias em outrasestruturas.

4

I N T E G R AT E D D E V E L O P M E N T E N V I R O N M E N T - I D E

No desenvolvimento de software para além da Linguagem e da Framework utilizados,é por vezes esquecida a importância do ambiente de desenvolvimento ou IDE. Desde àmuito que os IDE’s no que diz respeito a POO, tornaram-se ferramentas muito importan-tes no desenvolvimento. Contudo existe ainda alguma controvérsia à volta desta questão,pois alguns entusiastas existentes em qualquer comunidade defendem que um verdadeiroprogramador não necessita de IDE. Esta é uma discussão que não será abordada neste ca-pítulo, embora irão ser demonstrados algumas das mais valias inerentes ao uso de um IDEno desenvolvimento de aplicações em Rails.

Ruby on Rails, é um projeto open-source e foi concebido com à particularidade de nãoser necessário um qualquer IDE especifico para o desenvolvimento de aplicações web dealto-nível, podendo o programador usufruir da totalidade das funcionalidades recorrendo aum simples editor de texto. Com a exponencial utilização deste Framework, foram criadosplugins específicos para Rails que muniram aquilo que era apenas um editor de texto comfuncionalidades que apenas poderiam ser encontradas nos IDE’s. A escolha do ambientede desenvolvimento deve ser pessoal e aquela que cada utilizador se sinta mais confortável,seja um simples editor de texto ou um IDE complexo.

4.1 características essenciais de um editor/ide

Embora a escolha do editor ou IDE seja pessoal existem algumas funcionalidades essenciaisque devem de ser asseguradas em ambos as tecnologias:

• Suporte para a verificação de sintaxe da linguagem Ruby e HTML.

• Suporte indentação automática. Isto é mais do que uma característica estética, a auto-indentação no código enquanto se escreve é a melhor maneira de detetar determinadacondição termina no sitio certo. Ser capaz de re-indentar é importante quando dese-jamos refazer o código e mover código de sitio.

29

30 Capítulo 4. integrated development environment - ide

• Boa navegação pelos arquivos. Uma aplicação minimamente complexa contém deze-nas de arquivos contidos em diversos diretórios. É necessário portanto, um ambienteque ajude à rápida navegação entre os diferentes ficheiros.

• Suporte à inserção de código é uma importante funcionalidade. Ter auto complete dosprincipais métodos e estruturas do código é importante ao fim de dois ou três cliques.Alguns nomes tendem a ser longos, um bom editor vai deixar digitar os primeiroscaracteres e em seguida sugerir conclusões possíveis.

4.2 jetbrains rubymine

A maioria dos programadores de Ruby on Rails não usam IDE,(embora alguns dos am-bientes após alguns plugins implementados num editor de texto consigam chegar perto),e verifica-se que este não é tanto um problema como se poderia pensar. Com outras lin-guagens menos expressivas, os programadores dependem de IDE’s para fazer muito dotrabalho duro que consiste em gerar código, ajudar com a navegação, e compilando deuma forma incremental para se irem observando os alertas de erro. Contudo foram sendocriados IDEs específicos, tanto gratuitos como pagos, que tentavam dar mais valias ao usode um pacote completo de funcionalidades, as quais nem sempre poderiam ser obtidasatravés de plugins.

Os IDE’s com maior popularidade são:

• Aptana Studio, que é desenvolvido em cima do conhecido Eclipse

• Komodo, trata-se de um IDE de linguagens dinâmicas como é o caso de Ruby

• Rubymine, um IDE de uso comercial, mas que se encontra disponível gratuitamenteno âmbito de projetos académicos ou projetos open-source

• NetBeans - Ruby on Rails plugin, contudo o seu suporte foi descontinuado depois daversão 7.0.

O IDE escolhido para o desenvolvimento das aplicações em Ruby on Rails foi o Ruby-mine, por ser mais completo em relação a qualquer um dos anteriores referidos. Para alémdas funcionalidades comuns a quase todos os IDE’s o Rubymine permite um conjunto defuncionalidades que não se consegue obter nos outros [11]:

• Refactoring - facilmente se consegue renomear uma variável ou método, ou extrair umexcerto de código de um método assim escrevendo um código mais limpo, o queatualmente não pode ser feito por nenhum plugin para editores de texto normais.

4.3. Netbeans 31

• Executar Rake tasks e os Generators de Ruby on Rails. Não é uma coisa muito impor-tante, mas ser capaz de executa-los diretamente no RubyMine poupa tempo e evita alinha de comandos.

• Debugger - apresenta o mais completo debugger de código Ruby, sendo uma funciona-lidade também inexistente, nos editores de texto. Desta forma, quando as aplicaçõessão complexas e um erro persiste, o debug visual evita os habituais prints para identi-ficar o problema.

• Controlo de Versões - permite efetuar o controlo de versões dos mais conceituadossistemas (SVN, GIT, GitHub,etc.), sem que para isso seja necessário instalar outrossoftwares. Oferece também um ambiente gráfico agradável que permite a resoluçãode eventuais conflitos.

• Visualizador de Base de Dados - é possível consultar o modelo de dependências ine-rente as relações entre tabelas definidas nos Modelos.

4.3 netbeans

O NetBeans é um IDE open-source para desenvolvimento de aplicações escrito em Java. Estefoi o ambiente de desenvolvimento escolhido para o desenvolvimento das aplicações JavaWeb.

Por ser um ambiente de desenvolvimento maduro, e de referência a nível mundial, nãoforam pensadas outras opções, pois este oferece uma gama de ferramentas que garantemum ambiente de trabalho profissional, em que encontrando-se à disposição todas as fun-cionalidades enunciadas no subcapitulo 4.1 e 4.2, para o desenvolvimento de aplicaçõesmóveis, desktop e web, utilizando a linguagem Java [12].

Tal como referido no capitulo anterior, o NetBeans também apresentava suporte ao de-senvolvimento de aplicações Ruby on Rails, contudo foi descontinuado, por essa razão foiescolhido o Rubymine invés do NetBeans.

5

A P L I C A Ç Õ E S D E S E N V O LV I D A S

Tal como foi referido na introdução da presente dissertação, o estudo comparativo dastecnologias baseou-se no desenvolvimento de duas aplicações web, sendo que cada umadas aplicações foi implementada em RoR e JEE.

5.1 affable bean

Affable Bean foi a primeira aplicação desenvolvida. Teve origem num tutorial de desen-volvimento web disponibilizado pela comunidade do IDE Netbeans e visa demonstrar aimplementação de uma aplicação web standard de E-Commerce, fornecendo um serviço decompra de produtos alimentares [13]. Este tutorial foi utilizado como projeto de iniciação,pois são demonstrados alguns dos aspetos importantes das tecnologias JEE.

Figura 5: The Affable Bean - Aplicação de compras online

33

34 Capítulo 5. aplicações desenvolvidas

Dada a escolha do Framework Struts2 para desenvolvimento em JEE, este projeto surgiuao mesmo tempo como conveniente e auxiliar no estudo do Framework Struts2, pois AffableBean implementa a API Java Servlets, que é o principal responsável pela implementaçãoMVC em Struts2.

No que diz respeito ao desenvolvimento em Rails, o desenvolvimento deste projeto foitambém de grande relevância, pois dado não existir nenhum conhecimento prévio da lin-guagem Ruby nem do Framework Rails em si, este foi um ótimo projeto para iniciar aprática de desenvolvimento.

Pelas razões acima mencionadas, Affable Bean não foi diretamente considerada para finscomparativos de avaliação e conclusão, contudo é de salientar que teve um importantepapel na aprendizagem das diferentes tecnologias.

5.2 serviço de taxis e rent-a-car - setare

Após a implementação de Affable Bean, e com a aquisição de conhecimentos básicos sobreas duas tecnologias foi possível implementar com melhores práticas de desenvolvimento asegunda aplicação SeTaRe. A ideia da conceção desta aplicação, nasceu da necessidade dedesenvolver uma aplicação com alguma complexidade algorítmica, para que se pudessemcomparar mais objetivamente as tecnologias. Dado que, o objetivo da aplicação desen-volvida apenas foi servir de objeto de comparação entre as tecnologias, a idealização econceção da aplicação foi baseada em aplicações já existentes. Desta forma efetuou-se umaanálise das aplicações web de aluguer de automóveis e de taxis para que as aplicações finaisdesenvolvidas fossem o mais possível um template. Após a análise das aplicações existentesno mercado, foram escolhidas com base na popularidade de utilização, as aplicações webAirPort Taxi Transfers [14] e Rental Cars [15], de aluguer de táxis e de carros respetivamentemostradas na figura 6.

Figura 6: Aplicações utilizadas no levantamento de requisitos

5.3. Modelação UML 35

5.2.1 Descrição de AirPort Taxi Transfers

No lado esquerdo da figura 6, encontra-se uma aplicação web com o objetivo de permitir aoutilizador reservar um táxi. Para tal, é feita uma pesquisa de táxis livres usando uma listade países disponíveis e das cidades associadas, o número de passageiros desejados e a dataem que se pretende o serviço. Também é dada a hipótese de reservar um táxi com umadata de retorno, ou seja, o mesmo táxi irá fazer o percurso inverso na data escolhida. Háque apontar que os táxis existentes em cada cidade podem variar, isto é, algumas cidadespoderão não conseguir responder às necessidades do utilizador, quer em termos de númerode passageiros ou preço dos táxis desocupados.

5.2.2 Descrição de Rental Cars

No lado direito da figura 6, encontra-se outra aplicação web com um objetivo semelhanteà anterior. Neste website, é dado ao utilizador a hipótese de alugar carros, como normal-mente acontece nos aeroportos onde existem agências que fornecem este serviço. O aluguerdo carro é feito, como anteriormente, através de uma pesquisa de carros disponíveis usandopara tal uma lista de países e de cidades associadas a cada país como filtro. A única dife-rença para a pesquisa, referida acima, é que os carros pertencem sempre a uma ou maisagências de aluguer e que cada agência nem sempre se encontra em todos as cidades dis-poníveis no sistema. Há que referir também a possibilidade de devolver o carro alugadonuma cidade diferente daquela onde foi alugado.

5.3 modelação uml

Tal como acontece na conceção de qualquer projeto de engenharia de software, depois deentender quais os principais requisitos da aplicação e antes de iniciar o processo de desen-volvimento em si, é necessário efetuar algum trabalho de modelação das funcionalidadespretendidas.

Para representar melhor os requisitos de SeTaRe, foi utilizado um diagrama de Casos deUso UML. A figura 7 demonstra de um alto nível de abstração o conjunto de funcionalida-des que o sistema terá de implementar agrupados por dois tipos de utilizadores (atores),registados em sistema, e os não registados. Decidiu-se que a aplicação estaria protegidapor um mecanismo que autenticação, e que apenas utilizadores devidamente registados eautenticados (login/logout) poderiam ter acesso às funcionalidades da aplicação.


Figura 7: Diagrama de Casos de Uso - SeTaRe

A todos os utilizadores registados é possível:

• Gerir Perfil - O utilizador poderá alterar os dados do seu perfil pessoal (adicionar ouremover dados);

• Procurar Viaturas - O utilizador poderá escolher a procura de Carros ou Taxis. Qual-quer que seja a escolha do utilizador, será apresentado um formulário para que sejamintroduzidos os parâmetros de procura pretendidos (i.e Locais e datas de entrega ede recolha dos veículos).

• Selecionar Extras - Após a submissão do formulário de procura será apresentado aoutilizador um listagem de resultados com as viaturas disponíveis (Taxis ou Carrosrespetivamente) para os parâmetros de seleção. Caso o utilizador esteja interessadoem algum dos resultados, poderá selecionar o resultado pretendido prosseguindocom a reserva, onde serão de seguida apresentados alguns serviços extra tais como apossibilidade de pedir um condutor extra para o veículo (nos Carros) ou transporteespecial para animais (nos Taxis);

• Reservar Viatura - Caso o utilizador pretenda continuar e concluir a reserva, seráapresentada uma página com o resumo dos dados da reserva e o montante final a serpago para que o serviço seja finalizado. O Pagamento é feito de forma eletrónica eapós validação dos dados, a reserva fica automaticamente concluída, sendo que ume-mail de confirmação do serviço é enviado para o utilizador;

5.4. Implementação 37

• Consultar Reservas - O utilizador consulta a informação relativa a todas as reservasanteriormente efetuadas.

5.4 implementação

Neste subcapítulo serão apresentadas as funcionalidades principais de SeTaRe, sendo im-portante notar novamente que apesar de serem as mesmas páginas de apresentação foramdesenvolvidas duas aplicações (em Rails e Struts2).

5.4.1 Serviço de Rent-a-Car

Na figura 8 é apresentada a página inicial de procura de veículos que implementa partedo Use-Case Procurar Viatura. Nesta página são pedidos ao utilizador um conjunto deparâmetros de entrada (País, Cidade, Agência, e data e hora de levantamento e entrega daviatura) que permitiram efetuar uma procura na base de dados da aplicação.

Figura 8: Página Index - Aluguer de Carros

Na figura 9 que segue abaixo, é apresentada a página de resultados após efetuar umadeterminado procura. Nesta página serão listados todos os veículos que se encontram dis-poníveis para aluguer, assim como todas as suas particularidades (e.g tipo de combustível,tipo de caixa de velocidades, existência de ar condicionado) e o preço cobrado pelo aluguer.


Figura 9: Página de resultados - Aluguer de Carros

Na figura 10 que segue abaixo, é apresentada a página relativa ao pagamento da respetivareserva de uma viatura, onde é mostrado o resumo da reserva pendente, e são pedidos osdados do cartão relativos ao pagamento para que seja efetuada a reserva pretendida. Apósvalidado o pagamento, é enviado automaticamente um e-mail ao utilizador de modo aconfirmar a reserva.

Figura 10: Página de pagamento - Aluguer de Carros

5.4. Implementação 39

5.4.2 Serviço de Táxis

Na figura 11 é apresentada a página inicial de procura de táxis que implementa tambémparte do Use-Case Procurar Viatura. Nesta página são pedidos ao utilizador um conjuntode parâmetros de entrada (País, Cidade, Ponto de Interesse, número de passageiros, e datae hora pretendida para o serviço) que permitiram efetuar uma procura na base de dadosda aplicação.

Figura 11: Página Index - Aluguer de Taxis

Na figura 12 que segue abaixo, é apresentada a página de resultados após efetuar umadeterminado procura. Nesta página serão listados todos os táxis que se encontram dispo-níveis para efetuar o serviço, assim como todas as suas particularidades (e.g número depassageiros possível, número de bagagens possível) e o preço cobrado pelo serviço.

Figura 12: Página de resultados - Aluguer de Taxis


Na figura 13 que segue abaixo, é apresentada a página relativa ao pagamento do respetivoserviço, onde é mostrado o resumo da reserva pendente, e são pedidos os dados do cartãorelativos ao pagamento para que seja efetuada a reserva pretendida. Após validado opagamento, é enviado automaticamente um e-mail ao utilizador de modo a confirmar areserva.

Figura 13: Página de pagamento - Aluguer de Taxis

6

A N Á L I S E C O M PA R AT I VA

6.1 método de comparação

Para se poder efetuar uma avaliação efetiva de cada Framework foi definido um conjuntode processos, que se subdivide em 3 fases. A primeira fase trata-se da Investigação, seguidada Implementação, e concluindo com a Avaliação.

6.1.1 Investigação

A fase de investigação foi das fases mais morosas. Grande parte do trabalho desenvol-vido durante esta fase pode ser observado nos capítulos 2 e 3, e consistiu da procura deinformação sobre as duas plataformas de desenvolvimento. Contudo, esta não se prendecompletamente aos capítulos 2 e 3, pois foi acompanhando em simultâneo a fase seguintede implementação.

6.1.2 Implementação

Com o objetivo de comparar os dois Frameworks da forma mais justa, foram desenvolvi-das duas aplicações web utilizando ambos os Frameworks. Como foi referido em capítulosanteriores, uma das aplicações é um modelo standard de uma aplicação de compras online,e a segunda é uma aplicação de aluguer de veículos, mais complexa em termos algorítmi-cos. Desta forma procurar-se-á abranger todas as funcionalidades essenciais que qualqueraplicação web empresarial deverá ter. Tal como foi referido na seção anterior, esta faseteve como base, os processos de investigação, pois no decorrer da implementação foi sendonecessário recorrer à documentação e à comunidade, para que todos os problemas de imple-mentação fossem superados e, consequentemente, implementadas todas as funcionalidadespretendidas.

41

42 Capítulo 6. análise comparativa

6.1.3 Avaliação

Para se poder avaliar um Framework de desenvolvimento web, muitos fatores devem serconsiderados. A equipa de desenvolvimento, o gestor de projeto, ou um empresário, po-dem ter diferentes perspetivas e consequentes necessidades específicas que vão variandode projeto para projeto. Além disso, os Frameworks de desenvolvimento são influenciadospor um grande número de fatores voláteis, tais como fatores sociais, percetivos e contextu-ais, que não se enquadram convenientemente para uma avaliação técnica tornando difícilavaliar cada Framework de uma forma objetiva. Após as anteriores fases de investigaçãoe simultânea implementação das aplicações, foi eleito um conjunto de critérios de avalia-ção, que permitisse comparar cada um dos Frameworks equitativamente, tendo como baseargumental os protótipos desenvolvidos. No subcapítulo seguinte serão abordados comdetalhe todos os critérios que se consideraram como relevantes. É importante referir, quenesta fase apenas foi considerada para efeitos de avaliação e comparação a implementaçãoda segunda aplicação SeTaRe. Tal como referido no capitulo anterior Affable Bean, serviuapenas de projeto de teste, uma vez que era um projeto simples, e nunca tinha havido ne-nhuma experiência prévia com a linguagem Ruby nem com o Framework Rails. No caso deJEE foi também importante, pois esta não foi desenvolvida utilizando nenhum Framework,mas sim utilizando a API Java Servlets para implementação do modelo MVC. Desta formatornou-se bastante mais fácil ter noção do funcionamento interno de Struts2, uma vez queeste é já uma implementação de Java Servlets.

6.2 critérios de avaliação

Quando nos focamos em cada um dos Frameworks, existe normalmente a tendência parase elaborar uma longa lista de funcionalidades que o Framework oferece ao programadorpara facilitar o processo de desenvolvimento. Apesar disso, falta ainda uma lista unificadados recursos mais usados, o que indicaria, se um Framework tem a capacidade de ajudaro programador a desenvolver determinada tarefa. Isto pode também levar à incapacidadede fazer a escolha adequada, se um Framework realmente cumpre as necessidades ou não,portanto, existe uma necessidade de nivelar o confronto para os Frameworks, através daintrodução de uma lista de características que os mesmos devem oferecer [16]. Os recursosque devem ser incluídos na lista necessitam de abranger as funcionalidades geralmenteutilizadas em aplicações web e mais especificamente, as funcionalidades que facilitam odesenvolvimento rápido e ágil, através da redução do esforço de desenvolvimento [17].Quais os critérios, e o porquê de terem sido escolhidos, será abordado nas secções seguintes.

6.2. Critérios de Avaliação 43

6.2.1 Critérios de Avaliação – Fase I

Os critérios de avaliação foram separados em duas partes distintas. A primeira parte, con-siste num conjunto de critérios, em que as equipas de desenvolvimento tendem a focar-senuma primeira fase, para a tomada de decisão para a escolha do Framework ideal. Éimportante em qualquer equipa, estar preparado para iniciar um novo projeto e ser-se ra-pidamente produtivo. Na primeira fase da tomada de decisão, a equipa pretende sabero quão rápido se poderá iniciar a prototipagem de uma aplicação, o quanto complexo oFramework é, a facilidade de utilização e a consequente curva de aprendizagem, e o estadoda documentação existente assim como a comunidade que o suporta.

Configuração Inicial

Iniciar-se num novo ambiente de desenvolvimento, nunca é uma tarefa fácil, porém osFrameworks estão cada vez mais evoluídos e alguns veem já preparados com um conjuntode opções standard por definição, que nos permitem começar a desenvolver, sem ter deperder tempo com configurações complexas.

Documentação e Comunidade

Para que um Framework continue a melhorar, especialmente quando se trata de projetosOpen-Source, que não são financiados por nenhuma grande empresa, existem dois fato-res que são extremamente importantes. O primeiro consiste em oferecer uma excelentedocumentação, para que os novos utilizadores possam rapidamente atingir um nível deconhecimento elevado. Em segundo lugar surge a necessidade de criar e fomentar umagrande comunidade de interação. (Exemplo: NetBeans e Github). Ter de aprender umanova linguagem de programação, ou um Framework, é algo que todos os programadoreseventualmente terão que fazer, mas a quantidade de dificuldades com que se irão deparardepende de alguns fatores, como a disponibilidade de documentação, assim como tutori-ais e livros, e sem esquecer a experiência do programador. Este critério está muitas vezestambém ligado, com a facilidade de utilização do Framework, pois é importante enten-der o mecanismo de funcionamento, para que se possa aprender mais e obter resultadosrapidamente.

Complexidade

Neste critério será explorada a construção dos Frameworks. Abordar-se-ão as peças existen-tes em cada Framework e como a complexidade o pode afetar. É importante para a equipa,saber quantas tecnologias precisa de saber para usar determinado Framework. Existemtambém outras considerações ao escolher o Framework, tais como, se as características e be-

44 Capítulo 6. análise comparativa

nefícios adicionais superam a complexidade extra da aplicação. A curva de aprendizagemserá também um aspeto importante a abordar, tendo em conta que quanto mais alto nívelos Frameworks são, maior é o nível de abstração.

6.2.2 Critérios de Avaliação – Fase II

Após olhar para os parâmetros anteriormente definidos, a equipa tende agora a focar-senos resultados que o Framework poderá alcançar durante o desenvolvimento. Nesta fase,deseja saber-se o quão bom é o ecossistema do Framework, quais as ferramentas que estãodisponíveis, qual o rendimento e a escalabilidade que se pode esperar, e como é a plata-forma em termos de manutenção e suporte a longo termo.

Design Patterns

Neste critério serão abordados os Design Patterns arquiteturais através dos quais os Fra-meworks têm como base na construção das suas aplicações. Serão apresentados os prin-cipais princípios de desenvolvimento e quais os mecanismos intrínsecos que existem nosFrameworks para que sejam alcançados.

Ecossistema do Framework

O Ecossistema do Framework abrange o quão extenso o Framework apresenta-se, as suasferramentas e funcionalidades, e ainda a forma como é possível integrar com outras tecno-logias. Muito frequentemente, um Ecossistema grande, pode significar complexidade, masnem sempre é o caso. Este critério abordará também todas as ferramentas práticas de quese dispõe para desenvolver subdividindo-se em:

• Bibliotecas

• Internacionalização - I18n

• AJAX

• Scaffolding

• Segurança

• Testes

Extensibilidade

Tal como foi referido anteriormente, aquilo que escolhemos no desenvolvimento, tem de sersuportado durante a produção. A capacidade de crescimento e extensão são importantes

6.3. Síntese de Critérios 45

fatores, pois nenhuma equipa deseja asfixiar as suas aplicações, por causa da escolha doFramework. Neste critério são abrangidos as formas como os Frameworks respondem aocrescimento, e de que formas é possível garantir a fácil inteligibilidade do código.

Suporte e Manutenção

A escolha do Framework normalmente é uma decisão que perdura a média ou a longoprazo, por isso, é importante que este seja periodicamente revisto e atualizado. A manu-tenção e o suporte que é dado a um Framework é também dos fatores mais importantes,nomeadamente no que diz respeito aos mecanismos de segurança, pois todos os dias sãoexploradas novas formas de piratear as aplicações. O histórico de versões e de atualizaçõesdo Framework (Releases), é também uma forma de elucidar a equipa de desenvolvimentosobre o quão estável se apresenta.

6.3 síntese de critérios

Critério de Avaliação Fase I Fase IIConfiguração InicialDocumentação e ComunidadeComplexidadeDesign PatternsEcossistema do FrameworkExtensibilidadeSuporte e Manutenção

Tabela 2: Síntese dos critérios a avaliar

7

R E S U LTA D O S

Neste capítulo serão abordados em detalhe os critérios de avaliação definidos no capítuloanterior. Cada critério de avaliação aborda as formas de resolução abrangidas por cadatecnologia Struts2 e Rails. No entanto, considerando que em alguns aspetos, a maneiracomo as tecnologias abordam os problemas está intimamente ligada, não se efetuou umaseparação para evitar uma replicação da informação.

7.1 configuração inicial

No processo de configuração inicial dos Frameworks serão omitidas as tarefas e os procedi-mentos necessários de instalação das tecnologias, (linguagens, servidores, Frameworks, etc.)focando-nos apenas no processo de iniciação do desenvolvimento em si, após a instalaçãodos componentes.

Struts2

Como foi referido, não serão abordadas as tarefas de instalação da tecnologias, no entantoserão enunciadas todas as versões das tecnologias utilizadas na implementação da aplica-ção:

• Framework - Struts2 2.3.16

• ORM - Hibernate 4.3.6

• Servidor - Apache Tomcat 8.0

• Linguagem - Java 7

O IDE NetBeans proporcionou uma configuração inicial do projeto bastante fácil. Noentanto a versão do Framework por definição não era a mais atual, sendo que no casose procedeu a uma atualização manual de algumas bibliotecas, substituindo-as pelas mais

47

48 Capítulo 7. resultados

recentes, tendo sempre em atenção as respetivas dependências que mudam ligeiramenteconsoante a versão.

A estrutura automaticamente criada por um projeto Struts2 segue a estrutura descritana especificação JEE. A figura 14 a seguir mostra uma estrutura de ficheiros gerada pelacriação da aplicação SeTaRe.

Figura 14: Estrutura de ficheiros em Struts2

Em Struts2, a estrutura gerada é um pouco ambígua apresentando-se como pouco intui-tiva do ponto de vista de localização especifica dos futuros componentes.

Em WEB-INF estão contidos todos os recursos que não podem ser diretamente acedidospelo utilizador. O seu conteúdo inclui:

• /WEB-INF/pastas/ * - O diretório para Views e seus componentes (CSS, JavaScript,etc).

• /WEB-INF/web.xml e /WEB-INF/sun-web.xml - arquivos baseados em XML que especi-ficam a configuração da aplicação da Web, incluindo mapeamentos da base de dados,parâmetros de inicialização e restrições de segurança.

• /SourcePackages/* - o diretório onde ficam armazenados os componentes como Actions,Interceptors, DAOs, POJOs, etc. É onde está contida a camada de negócio e de dadosda aplicação.

Tendo em conta a estrutura da aplicação gerada, foi necessária alguma personalização.Foram criados packages específicos para Actions, DAOs e Model.

A criação de componentes específicos de Struts2 pré-configurados tais como Actions eViews utilizando NetBeans não é possível, sendo necessário efetuar a configuração manualdos componentes. A criação das Actions é feita através de classes JAVA comuns que temde ser posteriormente configuradas para respeitar a lógica de Struts2. No entanto após aimplementação das classes e interfaces necessários para implementar Struts2, poderá serimplementado um plugin de convenções de nomes que permite evitar configurações xmlpara interligar as Actions com as Views criadas, tal como será posteriormente explicado nodesign pattern Convention over Configuration em 7.4.2.

7.1. Configuração Inicial 49

No desenvolvimento de Struts2 foi utilizado o ORM Hibernate como camada de gestãoda persistência. Em Struts2, tendo em conta que já havia sido desenvolvida a aplicação emRails, utilizou-se o modelo de Base de Dados existente para construir o Model da aplicação.Através de Hibernate foi possível criar as classes Entidade do Model a partir das tabelas deBase de Dados já existentes.

Rails

As versões das tecnologias utilizadas na implementação da aplicação:

• Framework - Ruby on Rails 4.1.4

• Linguagem - Ruby 2.0.0p647

• Servidor - WebBrick 1.3.1

Apesar Rails não necessitar de um IDE para agilizar as tarefas que são necessárias fazercomo foi referido no capítulo 4, o IDE RubyMine implementa os scripts de que Rails dispõe,chamados generators, projetados para tornar as tarefas de desenvolvimento bastante maisfáceis, criando tudo o que é necessário para iniciar determinada tarefa. Assim todas astarefas feitas pelos generators de Rails são apresentados através de um menu de botõesbastante mais amigável do que a linha de comandos.

De seguida serão apresentados e explicados alguns dos generators que RubyMine imple-menta. Através do generator apresentado no excerto de código 7.1 é possível criar umaaplicação Rails sendo instaladas e configuradas todas as dependências do novo projeto, as-sim como também é criada uma estrutura de diretórios bem organizada, onde é facilmentepercetível mesmo ao programador mais inexperiente os lugares onde se situa o quê.

$ rails new Setare

Código 7.1: Criação de Setare através do generator rails new

Após a execução do comando acima apresentado é gerada a estrutura de ficheiros que sepode ver na figura 15.

No caso de Rails a estrutura de diretórios criados dispensa por completo descrições deta-lhadas, dado ser incrivelmente explicito, sendo possível compreender rapidamente a estru-tura lógica de diretórios criada.


Figura 15: Estrutura do ficheiros Rails

É agora possível criar os componentes de desenvolvimento específicos tais como os Con-trollers e as Views (componentes mínimos considerando que ainda não existe lógica de ne-gócio (Model)). No exemplo do excerto 7.2 é demonstrado através de um Rails generator aforma simples como podem ser criados o Controller Home e a View Index.

$ rails generate controller home index

Código 7.2: Criação de um Controller e View utilizando generator Rails

Desta forma o uso do generate controller criará um Controller chamado HomeController queimplementará uma action index, e criará também um diretório chamado Home que contéma página index.html.erb, dentro da pasta View já existente.

A comunicação com a Base de Dados em Rails é também umas das particularidadesmuito importantes durante a fase de configuração inicial. Tal como é apresentado na figura15 da estrutura de ficheiros da aplicação, Rails criou um arquivo de configuração da Basede Dados, localizado em config/database.yml.

7.1. Configuração Inicial 51

Por definição a Base de Dados de ligação é SQLite3, porém pode ser facilmente feita aalteração dessa configuração para outros tipos de Bases de Dados, como por exemplo mysqlcomo pode ser visto no excerto 7.3.

development:

adapter: mysql2

encoding: utf8

database: Setare_development

pool: 5

username: root

password: admin

test:

adapter: mysql2

encoding: utf8

database: Setare_test

pool: 5

username: root

password: admin

production:

adapter: mysql2

encoding: utf8

database: Setare_production

pool: 25

username: root

password: admin

reconnect: true

Código 7.3: Configuração da Base de Dados em Rails

No ficheiro de configuração database.yml, são configuradas três ligações diferentes: deve-lopment, test e production, associados respetivamente às bases de dados Setare_development,Setare_test e Setare_production.

A conceção e desenvolvimento do Model está diretamente ligada à metodologia de desen-volvimento que se utiliza. Rails encoraja um estilo de desenvolvimento ágil e iterativo, eportanto prevê que a Base de Dados que suportará a persistência da aplicação deverá seridealizada, mas não criada em primeiro lugar. Invés disso, deve ser suportada por iteraçõesque acompanham o progresso de desenvolvimento da aplicação.

Em Rails o Model é suportado através do componente ActiveRecord (descrito no sub-capítulo 3.4.3). Através do uso do generator que é apresentado no excerto 7.4 é possívelcriar a classe User do Model com o atributo name do tipo string.

$rails generate model User name:string

Código 7.4: Criação de Model através de Rails generator


Através do generator 7.4 são criados um conjunto de ficheiros de apoio entre os quais sedestacam, a classe User e um ficheiro chamado Migration.

Migrations é uma funcionalidade do ActiveRecord que permite informar a Base de Dadosatravés de linguagem Ruby, quais as tabelas que têm de ser criadas ou alteradas. Destaforma, Migrations, funcionam como um mecanismo de controlo de versões da Base deDados, pois será a aplicação Rails que ditará a estrutura que a Base de Dados terá de ter.

7.2 documentação e comunidade

Para que haja um melhoramento continuo dos Frameworks, em especial quando não sãosuportados por grandes corporações empresariais, são importantes dois fatores:

• Dispor de um boa e organizada documentação, para que os novos utilizadores possamatingir um nível expert no menor tempo possível;

• Garantir a proliferação de uma comunidade crescente e com espírito de entreajuda.

Struts2

A própria documentação oficial em Struts2 não se apresenta organizada da melhor forma.Existem alguns guias, tutoriais e livros de iniciação no site oficial e em websites de terceiros.Após gastar mais tempo do que se poderia esperar, encontra-se realmente bastante informa-ção e até mesmo os mais variados guias detalhados sobre como integrar Struts2 com outrastecnologias como Spring e Hibernate, embora a quantidade de links desativados tais como“wiki pages” do site oficial podem fazer o utilizador sentir-se um pouco desconfortável. Emtermos de comunidade, é grande o suficiente tendo em conta a idade e a popularidade, edesta forma, dificilmente alguém ficará sozinho sem solução à vista para um determinadoproblema. No entanto, em Struts2, apesar da informação existir em grande quantidade [4],o programador pode ficar com a sensação de confusão quando tenta procurar um meca-nismo específico. Isto pode dever-se ao facto de existir uma numerosa base de ferramentasconjugáveis com Struts2, tornando-se mais difícil encontrar informação relativa a um dadoconjunto.

Rails

Como acontece na maioria dos Frameworks open-source, a assistência técnica oficial é quaseinexistente, e por isso, aspetos como a documentação e o suporte da comunidade são fontescruciais para quem desenvolve software. Rails desde à muito que vem construindo umavasta fundação de documentação, desde APIs [18] [19], guias/tutoriais e até mesmo livros.

7.3. Complexidade 53

Juntamente com um grande número de guias de iniciação e de livros, Rails possui tam-bém uma enorme comunidade, que inclui seções de “Step-by-step”, wikis, mailing-list eaté mesmo canais IRC para discutir e esclarecer questões. Desta forma Rails fornece ao pro-gramador um ótimo ponto de partida para iniciar o desenvolvimento. De uma forma geralRails deixa o programador mais confortável no que diz respeito à estrutura organizacionalda documentação.

7.3 complexidade

Struts2

Em Struts2, a aprendizagem focou-se unicamente na lógica de desenvolvimento do Fra-mework dado existir já um conhecimento prévio da linguagem Java. A lógica utilizadapor Struts2 não foi considerada complexa, embora por vezes subsistissem algumas dúvidassobre como fazer determinada tarefa tendo em conta que existiam várias formas. De umamaneira geral pode dizer-se que Struts2 não é leve, mas também não pode ser consideradoum Framework complexo. Um exemplo é a introdução de alguns plugins como é o casode convention-plugin que apadrinha o conceito Convention over Configuration (abordado commaior detalhe no critério de Design Patterns, inerente à 2

a fase dos critérios de Avaliação)que permite escrever as suas Action classes e interliga-las com as suas páginas de resultados,sem que seja necessário uma única linha de configuração em código xml como aconteciaanteriormente. Struts2 é um Pure-MVC com uma arquitetura relativamente simples, semmuitos componentes extras que possam aumentar a complexidade.

Rails

Rails foi desenhado para ser um Framework de desenvolvimento rápido, sendo que rápidoimplica ser fácil de usar e de pouca complexidade. Reforça o seu principal conceito dedesenvolvimento “Convention over Configuration” e fá-lo da melhor maneira. Apesar dejá incluir todas as ferramentas necessárias para desenvolver uma aplicação de início ao fim,pode ser aumentada a sua complexidade através da adição de plugins conhecidos comogems, para que sejam adicionadas novas funcionalidades. Por outro lado, um dos pontosde desvantagem será regra geral o facto de o programador não estar familiarizado coma linguagem Ruby, o que no caso de Struts2 não será tão usual pela grande expansão dalinguagem Java. Ao contrário do que acontece com Struts2 em que já existia conhecimentoda linguagem Java e portanto, todo o esforço foi direcionado para a aprendizagem do Fra-mework em si, em Rails o mesmo não aconteceu. Numa primeira fase foi investido bastantetempo na aprendizagem e treino da linguagem Ruby, e só após algum conhecimento, foi


possível dedicar esforço na aprendizagem do Framework. Apesar de tudo, pode dizer-seque a curva de aprendizagem foi bastante elevado tendo em conta a disponibilidade de cur-sos e tutoriais encontrados online para iniciação da prática de desenvolvimento. Em Railsapesar do completo conjunto de ferramentas, este não é em nada complexo, não sendonecessário configurar praticamente nada (COC), e ao mesmo tempo regendo-se pelo princí-pio da não repetição de código (DRY), que diz que linhas de código iguais só devem estardefinidas num único lugar.

7.4 design patterns

Os design patterns representam formas de resolução para determinados problemas. Noâmbito do desenvolvimento web, estes fornecem igualmente formas de implementação,que definem regras gerais da estruturação dos respetivos componentes assim como a formacomo devem ser implementados. Neste subcapítulo serão abordados os design patternsconsiderados como mais importantes na conceção das aplicações desenvolvidas.

7.4.1 Model View Controller - MVC

Struts2

De uma maneira geral, Struts2 é um Framework pull-MVC (também conhecido como component-based). O design pattern MVC em Struts2 é concebido através de 4 componentes principais(descritos no subcapítulo 3.3.4):

• Actions

• Interceptors

• ActionContext/ ValueStack

• Results

Tal como abordado no subcapítulo 3.2, a arquitetura pull-MVC é ligeiramente diferentedo tradicional, uma vez que a Action toma o papel do Model invês de Controller.

O Controller é implementado através do filtro StrutsPrepareAndExecuteFilter, o Model é im-plementado através das Actions classes e Interceptors, e a View pelos Results. Num quartonível de abstração existe ainda ActionContext que funciona como uma plataforma de ar-mazenamento de dados que permite interligar os outros componentes. Para além doscomponentes acima mencionados, existem ainda outros componentes que dizem respeitoa configurações aplicacionais que dizem respeito às Actions e Results. O diagrama apresen-tado na figura 16 descreve o fluxo de um pedido desde que chega ao servidor até que sejagerada a respetiva resposta.

7.4. Design Patterns 55

Figura 16: Arquitetura MVC - Struts2

Fluxo de processamento do pedido [20]:

1. O Cliente (Browser) envia uma mensagem ao servidor a pedir um determinado re-curso (e.g uma página).

2. O filtro StrutsPrepareAndExecuteFilter verifica o pedido, e caso alguma Action devaser invocada, delega o controlo num sub-componente chamado ActionProxy que porsua vez consulta os ficheiros de configuração (i.e struts.xml), iniciando o processo deActionInvocation.

3. Durante o processo de ActionInvocation são invocados os Interceptors e de seguida aAction. Na Action são efetuadas as operações pretendidas que podem ou não envolverligações à base de dados. Após concluídas as operações necessárias os dados resul-tantes (scope variables data) são guardados na ValueStack do Action Context. Após oprocessamento da Action são novamente invocados os Interceptors.

4. StrutsPrepareAndExecuteFilter verifica o código de resultado definido na Action e pro-cura uma correspondência em struts.xml, invocando o Result definido.

5. No Result é feita a construção da página. A página (i.e JSP) acede ao ActionContext,obtendo assim todos os dados das variáveis definidas na Action anteriormente. Apósa página ser processada, esta é enviada como resposta ao Cliente.


Rails

Rails é um Framework push-MVC (também conhecido como action-based). O design patternMVC em Rails é concebido através de 4 componentes principais (descritos no subcapítulo3.4.3):

• ActionDispatch

• ActionController

• ActionView

• ActiveRecord

Figura 17: Arquitetura MVC - Rails

O Controller é implementado através dos componentes ActionDispatch e ActionController,o Model através de ActiveRecord, e a View pelo ActionView. O diagrama apresentado nafigura 17 descreve o fluxo de um pedido desde que chega ao servidor até que seja gerada arespetiva resposta.

Fluxo de processamento do pedido:

1. O Cliente (Browser) envia uma mensagem ao servidor a pedir um determinado re-curso (e.g uma página).

2. O Rails Router verifica o recurso pedido e encaminha-o para o Controller específico.

3. O Controller interage com a base de dados através dos métodos das classes do Model.


4. O Controller envia os resultados sob forma de variáveis de instância para a View (tem-plate ERB.HTML).

5. A View gera a página e envia a resposta de volta ao Controller.

6. O Controller envia a resposta ao Cliente.

7.4.2 Convention over Configuration - CoC

CoC é um paradigma de software que procura diminuir a número de configurações que sãonecessárias efetuar para interligar os diferentes componentes das aplicações. Desta formao programador ganha simplicidade na construção de código e pode focar-se unicamentenas funcionalidades a desenvolver. Este paradigma é alcançado através da definição de umconjunto de convenções de nomes no ato de criação dos diversos componentes (Classes,Páginas Web, etc.).

Struts2

Por definição Struts2 não incorpora o Design Pattern CoC, sendo necessário que sejam de-finidas as configurações manualmente em struts.xml de cada componente. Apesar não seruma funcionalidade embutida por defeito, esta é disponibilizada sob forma de um pluginoficial chamado Convention-Plugin que permite evitar quase por completo o uso de códigode configuração. Utilizando este plugin é possível definir através de uma nomenclatura denomes a localização de Actions, Results, Interceptors, etc.

A utilização deste plugin é automática desde que os seguintes requisitos sejam cumpridos:

• As Action Classes tem de ficar armazenadas em packages e ou sub-packages que conte-nham os termos struts2, action, actions;

• O nome das Action Classes deve terminar em "Action";

• As Actions Classes tem de implementar o o Interface Action ou herdar a classe Action-Support.

Na seguinte tabela 3 abaixo pode ser compreendido com maior detalhe a lógica de ma-peamento entre o URL e a Action Class.

URL Action Class/cars actions.CarsAction

Tabela 3: Mapeamento URL relativa a uma Action Class


Na Action Class tal como referido anteriormente na descrição do fluxo de pedido emStruts2, na Action Class é definido um código de resultado (Result Code). Quando se uti-lizam os códigos de resultados definidos por convenção não é necessário definir a corres-pondência (JSP Template). Para que a convenção seja respeita é também necessário que ostemplates JSP estejam dentro do diretório "WEB-INF/content/template-name.jsp". Na tabela 4

abaixo apresentada o exemplo em seguimento do anterior exemplo da tabela 3.

Action Result Code View Template (JSP)SUCCESS WEB-INF/content/cars.jspINPUT WEB-INF/content/cars-input.jspERROR WEB-INF/content/cars-error.jsp

Tabela 4: Mapeamento do Action Result Code numa View Template (JSP)

Rails

Ao contrário do que acontece com Struts2, Rails não necessita de nenhum plugin extra àsua distribuição standard para que implemente configurações através de convenções. Con-tudo tal como em Struts2, é também possível definir manualmente as interligações entrecomponentes sempre que seja necessário efetuar um desvio da convenção de nomes.

No ficheiro de configuração routes.rb, que surge como primeiro filtro sempre que algumpedido é efetuado, define-se os recursos de um determinado URL. No exemplo abaixo podeser visto um exemplo para a definição das rotas para o recurso cars.

1 resource :cars

Código 7.5: Definição de rotas http em Rails

Rails é um Framework que incentiva por definição o uso do design pattern REST, fazendocom que a definição efetuada na listagem de código 7.5 gere automaticamente as rotas quese podem observar na tabela 5.

Método HTTP URLGET /carsGET /cars/newPOST /carsGET /cars/:idGET /cars/:id/editPATCH/PUT /cars/:idDELETE /cars/:id

Tabela 5: Rotas RESTful geradas automaticamente


À semelhança do que acontece em Struts2, os templates de resultados têm de estar numdiretório de ficheiros específico, no caso de Rails é em: "app/views/cars/index.html.erb", onde"cars" é a pasta que contém todos os resultados para esse recurso. Sempre algum dos URLsda tabela 6 seja pedido e os respetivos componentes respeitem as regras anteriormentedefinidas, as convenções assumem as configurações de interligação.

URL Controller Name Action Method Template Result/cars CarsController index app/views/cars/index.html.erb/cars/new CarsController new app/views/cars/new.html.erb/cars/:id CarsController show app/views/cars/show.html.erb/cars/:id/edit CarsController edit app/views/cars/edit.html.erb/cars CarsController create N/A/cars/:id CarsController update N/A/cars/:id CarsController destroy N/A

Tabela 6: Mapeamento de Rotas REST em Rails

7.4.3 Inversion of Control - IoC

O desenvolvimento de aplicações web não se baseia apenas na etapa de desenvolvimento.Durante anos, a etapa de conceção foi muitas vezes negligenciada, mas nos dias que corremé uma fase fundamental para o sucesso na conceção de software. Para tal, é necessárioque existam preocupações sobre vários atributos do software, como por exemplo, a suatestabilidade e extensibilidade. São estes aspetos que influenciam a arquitetura do mesmo.Para que se verifiquem os atributos de qualidade mencionados, é necessário que exista,entre outros, um baixo nível de acoplamento entre as classes. Neste subcapítulo serãoabordadas algumas formas de implementar IoC com o objetivo de alcançar uma arquiteturade software de baixo acoplamento.

Inversão de Controlo como padrão arquitetural permite:

• Existir um fraco acoplamento da execução de determinadas tarefas da implementação;

• Cada módulo foca-se apenas no propósito para o qual foi desenhado;

• Os módulos mantêm-se apenas fiéis aos seus contratos (interfaces), não fazendo pre-sunções acerca de outros;

• Alterações efetuadas em módulos, não deverão afetar outros módulos ou afetar omenos possível.

O IoC é, portanto, um paradigma arquitetural, que tem como objetivo, dar um maiorcontrolo aos componentes principais da aplicação, que são os que fazem com que as tarefasse processem.


Struts2

Struts2 não dispõe de mecanismos integrados por defeito para a implementação de IoC,contudo existem um conjunto de opções conhecidas para a implementação deste design pat-tern. Por esta razão a implementação de software efetuada não contemplou IoC por nãoser um padrão standard por defeito. Apesar de tudo foi feito um trabalho extra com ointuito de entender qual a relação entre custo/beneficio na implementação de IoC. Apósalgum estudo verificou-se que uma das soluções conhecidas, e talvez a melhor aceite naimplementação IoC no âmbito do desenvolvimento empresarial é a integração do SpringFramework. Spring Framework é composto por um container que tem como função a cria-ção (instanciação) de classes aplicacionais, e define as dependências entre elas através deum arquivo de configuração. Desta forma o Spring Framework permite atingir o objetivoinicialmente abordado do baixo acoplamento entre classes [21].

Nas tecnologias JEE existem várias formas de implementar IoC. Na figura 18 são apresen-tadas algumas formas de implementação de IoC, entre as quais se encontra a ser utilizadapor Spring Framework conhecida como Dependency Injection - DI através de Setter Injection.

Figura 18: Formas de implementação de IoC em JEE

Tal como referido, a implementação de SeTaRe efetuada em Struts2 não contempla IoC,dado que o objetivo desta dissertação prende-se ao estudo das tecnologias no seu estadomais standard. Contudo será demonstrado quais as mudanças a serem feitas com o objetivode tornar a aplicação mais independente entre si.

Implementação IoC

A implementação é possível através da utilização e rápida configuração do plugin struts2-spring-plugin.

Através deste plugin, podem ser definidas todas as dependências entre os diferentes Beans,através do ficheiro de configuração applicationContext que funciona como Container. No


exemplo 7.6 é apresentada da dependência do LoginAction que tem como propriedade ouser DAO.

...

<bean id="beanUserDAO" class="dao.impl.UserDAO">

<property name="sessionFactory" ref="sessionFactory" />

</bean >

<bean id="beanLogin" class="actions.LoginAction" scope="prototype">

<property name="userDAO" ref="beanUserDAO" />

</bean >

...

Código 7.6: Definição dos Beans com Spring

Para que seja respeitado o IoC é também efetuar alterações ao nível dos DAOs (Model).Os DAOs passam agora a implementar Interfaces. Desta forma através de Setter Injectioné possível que as dependências sejam injetadas nas Actions sem que sejam criadas novasinstâncias através de código, como é apresentado no exemplo 7.7.

public class LoginAction extends ActionSupport{

...

private IUserDAO userDAO;

public void setUserDAO(IUserDAO userDAO) {

this.userDAO = userDAO;

}

...

public String execute () throws Exception {

userDAO.findByEmail("[email protected]");

...

}

}

Código 7.7: Struts2 Action com IoC

Assim, o Spring gere as dependências automaticamente, injetando-as em tempo de exe-cução quando são necessárias.

Rails

Rails por definição não apresenta ou sugere qualquer tipo de mecanismo para implementa-ção IoC como acontece com Struts2. Como já foi referido no início do subcapítulo 8.4.3 , oIoC é um design pattern, que tem como objetivo quebrar o forte acoplamento entre classes,nomeadamente no que diz respeito à criação de novas instâncias de uma classe dentro deoutra. Este acoplamento liga o objeto criado com qualquer implementação. Em linguagens


estáticas quando referenciamos uma classe pelo nome (ato de criação “new”) não existe am-biguidade, o que significa que estamos perante um caso de acoplamento apertado da classe.Em linguagens dinâmicas “new X” serve apenas como um espaço reservado para instanciarqualquer classe definida como “X” num determinado ponto de execução, o que significaque estamos perante um caso de fraco acoplamento, pois a única ligação é o nome “X”. Noseguinte exemplo de código 7.8 poderá ser compreendida a dinâmica da linguagem Rubyna injeção da dependência Agency [22].

class Car

attr_reader :brand , :day_price , :agency

def initialize(brand , day_price , year , agency)

@brand = brand

@day_price = day_price

@agency = agency

end

def final_cost(total_days = 1)

(day_price * total_days) * agency.tax

end

end

Car expects a 'Duck' that knows 'tax'

Car.new("Ferrari", "300", Agency.new(1, "Europcar", 1.23)).final_cost (3)

Código 7.8: Injeção de Dependências em Ruby

A Classe Car utiliza a variável @agency para receber a dependência e o método agencypara aceder a propriedades do objeto. Desta forma Car não sabe nem se interessa se oobjeto é uma instância da Classe Agency. A Classe Car apenas sabe que detém um objetoque responde a tax.

De uma maneira geral IoC permite que sejam feitas ligações dinâmicas (Dinamic Binding)e que a linguagem se torne dinâmica (em Java, é possível alcançar através de configuraçõesXML ou annotations). Desta forma pode afirmar-se que os Containers IoC são de algumaforma desnecessários quando se trata de linguagens dinâmicas, como é o caso de Ruby,pois tratam-se de funcionalidades já de alguma forma consideradas nativas. No entantoIoC e DI são conceitos igualmente importantes tanto em linguagens dinâmicas ou estáticas,pelas mesmas razões [23]. Ao contrário do que acontece em Java, Ruby não necessita deIoC containers nem de DI Frameworks adicionais, pelo que os princípios são igualmenteúteis.

“Frameworks de DI são desnecessários. Em ambientes mais rígidos, têm o seuvalor. Em ambientes ágeis como Ruby, não muito. Os padrões em si podem ser

7.5. Ecossistema do framework 63

aplicáveis, mas cuidado para não cair na armadilha de pensar que precisamosde uma ferramenta especial para tudo. É importante lembrar que Ruby é comoplasticina! Vamos mantê-lo assim.” - Jamis Buck

7.4.4 Don’t Repeat Yourself - DRY

DRY é um principio de desenvolvimento que foca-se essencialmente na redução da dupli-cação de código. A filosofia deste principio enfatiza que a informação deve ser duplicadao menos possível, pois a duplicação aumenta a dificuldade de mudança, diminui a cla-reza e leva a que sejam criadas oportunidades de inconsistência. A escrita de código querespeite este principio pode ser feita através de componentes reutilizáveis, permitindo aoprogramador de software evitar as operações de "copia e cola". Tanto em Struts2 comoRails, este é um principio fortemente encorajado pelas regras de implementação de ambosos Frameworks. Por este ser um principio transversal a todo o tipo de desenvolvimento deaplicações informáticas, não serão abordados individualmente.

Em ambos os Frameworks é possível a reutilização de código nos diversos componentesM-V-C. Os Frameworks apresentam mecanismos como é os caso dos templates de resultadoparciais que são definidos num só lugar e incluídos em diversas outros templates - Dry View ea utilização de Interceptors em Struts2 e do ApplicationController em Rails permite que sejamefetuadas operações de verificação em todas as Actions (em Struts2) e Controllers (em Rails)- Dry Controller. Para além destes mecanismos em ambas as linguagens dos Frameworks épossível conceber funções e classes genéricas que permitam uma reutilização sucessiva docódigo. Desta forma o princípio DRY faz com que seja mais fácil dar manutenção a grandessistemas de software.

7.5 ecossistema do framework

7.5.1 Bibliotecas

Atualmente no setor do desenvolvimento de software, a produtividade é um fator quedeixa de ser refletido apenas pela quantidade de código que é implementado nas equipasde desenvolvimento, passando também a contemplar a capacidade de incorporar funciona-lidades feitas por terceiros. Por isso é cada vez mais frequente, que os Frameworks emer-gentes disponibilizem para além da sua implementação standard um conjunto de pluginsfacilmente personalizáveis, que permitem a extensão das aplicações através da incorporaçãode novas funcionalidades.

Struts2


Em Struts2 (Java) estes plugins têm o nome de JARs. Estes ficheiros são pacotes de classese de configurações que podem estender, alterar ou adicionar funcionalidades extras aopróprio Framework. A instalação de um JAR é feita através da colocação do ficheiro numdiretório específico da aplicação. É importante denotar que existe sempre a necessidade deverificar a existência de dependências em relação ao outros JARs, o que terá que ser feitomanualmente caso existam. Apesar disto existe forma de solucionar este inconvenienteatravés do uso de uma ferramenta de gestão de dependências chamado Maven. Mavendispõe de um ficheiro chamado pom.xml, onde apenas é necessário definir a referência aoplugin desejado, sendo que serão automaticamente descarregadas todas as dependências aele inerentes. No excerto 7.9 é apresentado um exemplo da definição de uma dependência.

<dependency >

<groupId >org.apache.struts </groupId >

<artifactId >struts2 -convention -plugin </ artifactId >

<version >2.3.30 </ version >

</dependency >

Código 7.9: Definição de dependências utilizando Maven

No entanto isto requer que no início da configuração inicial invés de ser criado umprojeto Java Web, seja criado um projeto do tipo Maven, ou então terá que ser efetuadauma migração para o novo projeto.

RailsEm Rails (Ruby) estes plugins são disponibilizados na forma de GEMs. No entanto, ao

contrário do que acontece em Java, Ruby possui por definição um sistema de gestão depacotes chamado RubyGems que facilita a criação, a partilha e a instalação de plugins, assimcomo a garantia de instalação automática das suas dependências. Desta forma Rails apenaspossui na sua estrutura um ficheiro de definição de GEMs chamado Gemfile (que pode servisto na figura 15). No excerto 7.10 abaixo é apresentado um exemplo de definição de umaGEM.

gem 'devise ' , '~> 3.2.4 '

Código 7.10: Definição de dependências utilizando RubyGems

7.5.2 Internacionalização - I18n

Internacionalização (I18n) refere-se à capacidade de uma aplicação alternar entre idiomasde uma forma fácil, adaptando a aplicação a uma determinada região. Esta funcionalidadetem um caráter cada vez mais importante, pois é utilizada para que as aplicações possamsatisfazer um público cada vez maior, acompanhando assim a globalização. Através deste


recurso é possível alcançar um novo nível de utilidade, simplificando o desenvolvimentode aplicações multilingue.

Tanto Struts2 como Rails disponibilizam este mecanismo internacionalização de formasmuito similares. Cada Framework define uma localização para criação de arquivos deconfiguração que devem respeitar uma nomenclatura específica relativamente ao nome doarquivo. Cada arquivo contém as propriedades definidas como pares chave-valor. Na Viewsão utilizadas Tags específicas que permitem invocar a tradução dos elementos para seremapresentados no idioma pretendido.

7.5.3 Asynchronous JavaScript and XML - AJAX

AJAX não é apenas um tecnologia, é um conjunto de várias tecnologias. AJAX incorpora acapacidade de:

• Alterar estilos (CSS);

• Apresentação dinâmica de conteúdo através da Manipulação do DOM 1;

• Manipulação e troca de informações através de XML ou JSON;

• Obtenção de dados através de pedidos HTTP;

• Utilização de JavaScript ou JQuery, como linguagem de ligação entre componentes.

AJAX permite que sejam obtidos dados para atualizar uma determinada página, sem terde efetuar o recarregamento total dos conteúdos da página, ao contrário do que acontecenas arquiteturas convencionais em que a cada pedido são descarregados todos os recursos.

AJAX foi utilizado nas duas implementações de SeTaRe em algumas das funcionalidades.Um exemplo disso que pode ser apresentado é o da figura 8, em que o processo de procuraencadeado, que requer a introdução e seleção de vários dados, nomeadamente a escolhade um país, de uma cidade desse país, e de uma agência disponível nessa mesma cidade.Desta forma quando é selecionado determinado país, é efetuado a uma Action um pedidode consulta das cidades do país selecionado, que retorna como resposta uma lista. Essa listaé depois carregada e apresentada como lista de opções de seleção ao utilizador, tornandoassim a página mais interativa, sem o habitual recarregamento total da página.

Struts2No caso específico de SeTaRe, o objetivo do pedido é apenas obter como resultado uma

lista (cf. Map<id,nome>) das cidades. Por essa razão a melhor abordagem foi enviar comoresposta um objeto do tipo JSON. Struts2 dispõe de um plugin chamado struts2-json-plugin,que permite fazer o serialize do atributo da Action class que contem os métodos de leitura

1 Arvore estrutural das páginas, constituída por elementos HTML, XHTML e XML.


e de escrita, num objeto do tipo JSON. Por fim, apenas é necessário que se defina o tipode resultado de resposta da Action como JSON, o que pode ser feito a partir de uma JavaAnnotation como se apresenta no excerto 7.11.

@Result(type = "json")

Código 7.11: Definição de formato de resposta em Struts2

RailsEm Rails a implementação de pedidos AJAX é ainda mais simplificada do que em Struts2,

uma vez que não é necessária a inclusão de nenhum plugin adicional. Rails implementa umserviço inteligente que interpreta o cabeçalho do pedido HTTP submetido pelo cliente, e de-termina automaticamente qual o formato de resposta que necessita. Desta forma tal comoé apresentado no excerto 7.12, podemos definir vários formatos de resposta, que Rails irácompreender se um cliente pretende uma página HTML, um objeto JSON ou até mesmouma lista de cidades em formato XML.

def cities

@cities = Country.find_by(city: city[:id])

respond_to do |format|

format.html { redirect_to(cities_list_url) }

format.json { render :json => @cities}

format.xml { render xml: @cities.to_xml(include: @cities) }

end

end

Código 7.12: Tipos de formatos de resposta em Rails

7.5.4 Scaffolding

Scaffolding é uma forma rápida, fácil e direta de gerar partes das aplicações. Alguns Fra-meworks disponibilizam esta funcionalidade de gerar código automaticamente apenas atra-vés do executar de um comando. Struts2 não dispõe desta funcionalidade na sua distribui-ção standard nem de plugins que permitam alcançar o efeito. Pelo contrário, Rails dispõeda funcionalidade por definição. Esta funcionalidade é definida pela execução do genera-tor apresentado no excerto 7.13, que permite que sejam criados todos os componentes queimplementam o modelo MVC.

$ rails generate scaffold car

Código 7.13: Utilização do generator scaffold


Embora esta não seja considerada um funcionalidade crucial, tem o seu valor quandoestamos perante aplicações que implementam um elevado número de operações CRUD(Create, Read, Update, Delete), pois Scaffolding permite gerar o Controller, Model e todas aspáginas (Views) associadas a cada operação. Desta forma pode considerar-se que no âmbitodos princípios ágeis pelos quais Rails se rege, esta poderá ser uma boa abordagem parafacilitar o desenvolvimento de um protótipo inicial ou até para provar um determinadoconceito sem um gasto elevado de tempo.

7.5.5 Segurança

Em geral os Frameworks Web oferecem um conjunto de funcionalidades de segurança queprotegem as aplicações contra os mais diversos tipos de ataques. Neste tópico serão abor-dados os mais conhecidos problemas de segurança: SQLinjection, Cross-Site Scripting (XSS)e a Gestão de Sessões.

Rails

• SQL Injection

Em Rails a proteção contra este tipo de ataques é tratada pelo componente ActiveRecord. Este módulo fornece mecanismos que funcionam como interfaces com a basede dados chamados de sanitization helpers e query builders que moderam assim todasas operações críticas que possam ser efetuadas na base de dados. Este mecanismosutilizam uma abordagem de lista negra de expressões, que verificam as expressões edescartam os caracteres SQL especiais [24]. No desenvolvimento em Rails, raramenteé necessário escrever queries SQL, sendo geradas e executadas automaticamente. Porexemplo para guardar um alteração na base de dados, o Active Record dispõe dométodo save, que quando utilizado gera automaticamente a expressão SQL para fazero INSERT ou UPDATE e executa-a de seguida. O método save aplica a si mesmo averificação dos valores dos atributos do Model. Quando se efetuam operações manuaistal como consultar informações da base de dados, o utilizador por utilizar os QueryBluilders. Por exemplo a consulta de carros do SeTaRe:

1 Car.where(model: , 'coupé').limit (10).all

2 // convertido SQL:

3 SELECT * FROM cars WHERE model = ''coupé'' LIMIT 10

Código 7.14: Conversão SQL resultante do uso de Query Builder de Rails

• XSS - Cross Site Scripting


A proteção XSS é implementada através dos módulos Action View e Active Support.A implementação é semelhante à da proteção contra SQL Injection. Mais uma vez, aestrutura usa uma abordagem de lista negra, e fornece sanitization helpers e buildersque são usados para construir código HTML comum, tais como links entre páginase formulários. O mecanismo mais importante é o método escape html, que descartaos caracteres HTML considerados perigosos (& ,>, <, ,̈ )́. Outros mecanismos muitoimportantes, são sanitize css e escape javacript que atuam nos blocos de código CSS eJS utilizando expressões regulares para que a manipulação do lado cliente não sejapossível.

• Gestão de Sessões

Rails dispõe também de algumas medidas de proteção contra ataques de manipula-ção de sessões fornecidas nos componentes Action Controller e Action Dispatch. Railsutiliza um valor de hash imprevisível de 32 bytes MD5 como identificador de sessão, epermite que os ataques de fixação de sessão sejam evitados através de um session resethelper. Rails não tem pré-definida uma estrutura de autenticação, e dado o esforço queseria necessário para implementar manualmente, os programadores recorrem à utili-zação de GEMs como o Devise (tal como foi utilizado em SeTaRe) que implementamtodo o pacote de mecanismos de gestão. Estas bibliotecas implementam a proteção eo reset de sessões automaticamente.

Struts2

• SQL Injection

Struts2 por si só não dispõe de mecanismos de proteção contra SQL Injection uma vezque se trata de um Framework Pure-MVC. Tal como em Rails estes mecanismos sãofornecidos pelo componente Active Record, em Struts2 é Hibernate que é responsávelpor proteger este tipo de ataques. Através do Hibernate é também possível executarqueries SQL nativas utilizando Named Parameters. Os Named Parameters fazem a ligaçãodo valor passado como argumento, ex:

1 ...

2 q = entityManager.createQuery(''SELECT c FROM Car e WHERE c.

licensePlate = ':id' '')

3 q.setParameter(''id'', licensePlate)

4 ...

Código 7.15: Proteção contra SQL Injection com Named Queries

Desta forma "licensePlate"é atribuida ao "id"no comando SQL fazendo com que os ca-racteres perigosos sejam automaticamente descartados pelo driver JDBC. Outra forma


poderá ser através do uso da API Criteria, que fornece um tipo de escrita segura ori-entada a objetos. Esta é baseada num modelo de classes Entidada para além da APIde escrita de queries. Desta forma é possível que sejam desenvolvidas queries que ocompilador de Java verifica e valida quando compila ex:

1 session.createCriteria(Car.class , ''car'').add(Restrictions.eq(''

licensePlate '', licensePlate))

Código 7.16: Criteria Queries em Struts2

• XSS - Cross Site Scripting

A proteção contra XSS em Struts2 é implementada pela API JSP que disponibiliza umconjunto de tags que permitem a validação de inputs e outputs. Alguns exemplossão: <s:textfield/>; <s:textarea/>; <s:property/>. Estas tags tal como em Rails permitemque se descartem os caracteres especiais ‘<’, ‘>’ and ‘”’. Apesar desta proteção básicafornecida pelos estes componentes, não existe nenhuma tag no Struts2 que garanta aproteção em contexto de código JS ou CSS, o que implica que o programador tenhade recorrer a outras bibliotecas para garantir a segurança da aplicação.

• Gestão de Sessões

Struts2 fornece mecanismos de gestão de sessões que são implementados através deInterceptors dedicados, ou através da implementação da Interface SessionAware nasAction Classes. Estes mecanismos permitem gerir as sessões dos objetos HTTP, bemcomo manipular de forma segura os dados que são armazenados através dos métodosclear(), invalidate(), remove(), put(), get(), etc.

7.5.6 Testes

A habilidade de fazer testes no código que é desenvolvido permite validar as funcionali-dades que são implementadas, garantindo que a aplicação está a funcionar corretamente.Atualmente a prática de testes considerada melhor aceite pelos Frameworks é Test DrivenDevelopment conhecida pela sigla TDD. TDD é uma técnica através da qual são utilizadostestes unitários autónomos para que o design do software seja conduzido e forçado a tornar-se mais independente. Com os testes tradicionais, um teste é considerado bem sucedidoquando um ou mais defeitos são encontrados, enquanto que utilizando TDD tem-se umanoção clara do sucesso do teste quando este não possuí falhas. Assim TDD aumenta aconfiança de que o código desenvolvido, quando preenche os requisitos do sistema.

Struts2


Apesar de não terem sido efetuados testes unitários na implementação de SeTaRe, Struts2

dispõe de um plugin JUnit que permite facilitar o desenvolvimento de testes unitários nasAction Classes. Este plugin fornece uma Classe StrutsTestCase que serve de base para testaros componentes de Struts2.

Rails

Tal como na implementação em Struts2, em Rails também não foram desenvolvidos ne-nhum tipo de testes unitários. No entanto em Rails, para além de não ser necessário acres-centar nenhum plugin extra, esta é uma prática fortemente encorajada desde o começo dodesenvolvimento. Um exemplo disso é a criação automática de ficheiros dedicados ao testefuncional dos componentes sempre que um novo Controller ou Model são gerados.

7.6 extensibilidade

Extensibilidade é um princípio de software definido pelo crescimento futuro das aplicações.Este princípio arquitetural define-se pela capacidade de estender o software e pelo nívelde esforço necessário para implementar a extensão pretendida. As extensões podem serefetuadas através da adição de novas funcionalidades ou através da modificação de fun-cionalidades já existentes. Regra geral, as aplicações de software são desenvolvidas paraterem uma duração prolongada e para suportarem a introdução de novas funcionalidades.Desta forma o objetivo do principio da extensibilidade é permitir a mudança, minimizandoo impacto nas funcionalidades já existentes.

Em Rails ou em Struts2, o princípio da extensibilidade é atingido não através de ummecanismo específico, mas por toda uma inclusão de princípios, como os que foram anteri-ormente falados como são exemplo disso CoC e DRY. Todos estes princípios de desenvolvi-mento pretendem contribuir para a organização do código desenvolvido fazendo com queo código se torne facilmente inteligível, eficiente e flexível [25].

No entanto em Stuts2, a gestão do código como por exemplo a definição de Classes é fácildevido à linguagem de programação estática (Java). Utilizando o IDE NetBeans, podemosprocurar o local específico onde métodos e Classes estão definidas, invés de procurar algohipotético como em Rails (Ruby), onde a gestão do código tal como os nomes das classes de-finidas pode ser considerada difícil de entender devido ao seu tipo de linguagem dinâmica.Através da dinâmica da linguagem Ruby pode facilmente tornar-se confuso, assumir comcertezas sobre o que estamos a escrever e a alterar, tendo em conta que não existem avisosde um compilador estático como acontece em Java. Em Struts2, o IoC embora tenha umaforma algo rígida de implementação, esta define uma forma standard de alcançar o baixoacoplamento entre os componentes. Enquanto que em Rails existe uma maior liberdade,sendo que a forma de implementação fica ao critério de programador. Desta forma casonão sejam definidas práticas de desenvolvimento nas equipas este fator pode representar

7.7. Suporte e Manutenção 71

uma enorme dificuldade na gestão do código assim como perda desnecessária de tempona compreensão a estrutura existente. A linguagem Ruby apresenta esta componente dinâ-mica muito poderosa que permite agilizar e interligar rapidamente os componentes, maspode revelar-se traiçoeira assim que o desenvolvimento código atinja um nível consideradode crescimento.

7.7 suporte e manutenção

O suporte e a manutenção prestada aos Frameworks é um fator de grande importância naescolha de tecnologias. Apesar de tanto Struts2 e Rails se apresentarem como Frameworksmaduros e com provas dadas pelas aplicações que se encontram atualmente no mercado,a garantia de suporte ao nível de atualizações futuras é um ponto crucial. Existem varia-dos casos de Frameworks usados por pequenas empresas, que de repente deixam de obtersuporte, causando a asfixia dos seus projetos e levando-os a ter que migrar o código paraoutras tecnologias. Nos Frameworks Struts2 e Rails, os membros da comunidade de desen-volvimento são encorajados a melhorar a qualidade dos Frameworks. Desta forma sempreque algum erro factual ou até erros relacionados com problemas de segurança graves sãodetetados, estes são reportados às equipas de manutenção dos Frameworks que tratamrapidamente de disponibilizar atualizações sobre a forma de um patch que será incluídoposteriormente assim que uma nova versão seja disponibilizada. Dada a ampla utilizaçãodos mesmos, mesmo quando o erro/problema encontrado não apresenta solução instantâ-nea, é normalmente encontrada um solução para contornar o problema.

Em ambos os Frameworks estudados, para além da manutenção regular, de versão paraversão, são disponibilizadas e adicionadas novas funcionalidades aos Frameworks que per-mitem aumentar a produtividade.

À data da produção deste documento, ambos os Frameworks sofreram atualizações paraversões mais recentes do que as que foram utilizadas na implementação de SeTaRe. Struts2

dispõe de uma nova versão 2.5.2, disponível desde 7 de Julho de 2016 e Rails com a versão5.0.0.1, disponível desde 1 de Agosto de 2016. Este facto, por si só, revela que ambos osFrameworks podem ser considerados confiáveis no que diz respeito ao investimento paradesenvolvimento de aplicações Web, por fornecerem um suporte adequado e credível.

8

C O N C L U S Ã O

No final deste trabalho, ficou bem claro que o desenvolvimento de aplicações Web, comrecurso à utilização de Frameworks é cada vez mais uma tarefa imprescindível.

Tal como referido no capítulo introdutório, existem atualmente inúmeros Frameworksde desenvolvimento Web. Este documento relata, o estudo, a avaliação, e comparaçãodos Frameworks Ruby on Rails e Apache Struts2, este último pertencente ao universo dastecnologias Java Enterprise Edition.

Numa fase inicial foi efetuado o estudo de cada uma das tecnologias, o que permitiuconhecer quais os componentes pelas quais são constituídas e quais os princípios de desen-volvimento pelos quais se regem.

A comparação de Frameworks de desenvolvimento web revelou-se um desafio, dada ainexistência de uma forma sistemática bem definida no que diz respeito aos critérios deavaliação a usar. A fim de alcançar objetividade, foram definidos critérios que se conside-raram os mais aptos para serem testados e avaliados. No entanto é de notar que existemfatores inevitáveis que influenciam sempre os resultados, tais como:

• A ordem de implementação de cada uma das aplicações Web, que influência de umaforma indireta os tempos em desenvolvimento, pois é mais provável que seja despen-dido mais tempo para implementar na primeira tecnologia escolhida para desenvol-ver, do que na seguinte.

• O conhecimento tecnológico já existente. O conhecimento prévio da tecnologia ou departes dela, podem influenciar o processo de aprendizagem.

À parte os fatores mencionados, foram definidos um conjunto de critérios de avaliaçãoque se consideram importantes para as equipas de desenvolvimento, divididos em doisgrupos. Numa primeira fase, foram definidos os critérios de avaliação relativamente à com-plexidade dos Frameworks e configurações necessárias para dar início ao desenvolvimento,a facilidade de utilização e consequente curva de aprendizagem, e o estado da documenta-ção existente, assim como a comunidade que lhes dá suporte. Numa segunda fase foramavaliados os resultados que os Frameworks permitem alcançar durante o desenvolvimento,

73

74 Capítulo 8. conclusão

nomeadamente a estrutura arquitetural de desenvolvimento e a qualidade dos recursosdisponibilizados pelo ecossistema dos Frameworks.

Tanto Struts2 como Rails permitiram a implementação das aplicações de uma forma fa-cilitada, disponibilizando na maioria dos casos ferramentas de apoio ao desenvolvimentode cada tarefa específica. De uma forma geral e através da análise dos critérios definidos,chega-se à conclusão de que um Framework não é melhor que o outro no geral, mas simem pontos específicos, portanto para ser feita a seleção do Framework ideal é necessárioanalisar todo o contexto onde o Framework será utilizado. Rails apresenta-se como umadistribuição bem definida que engloba todos os componentes necessários ao desenvolvi-mento, incentivando o desenvolvimento de acordo com determinadas práticas consideradasas mais corretas (cf. conventions). Através destas, é possível iniciar o desenvolvimento quasede imediato, mesmo apenas com um conhecimento básico da tecnologia. Struts2, pelo con-trário, apenas implementa a arquitetura básica do padrão MVC, não incitando nenhum tipode nomenclatura específica de desenvolvimento. Assim surge a principal diferença entreos dois Frameworks, que demonstra que Rails é um ótimo Framework para pequenos e mé-dios projetos que pretendam ser rapidamente desenvolvidos, enquanto Struts2 oferece umaestrutura fortemente parametrizada, que se encontra preparada para integrar com todas asAPIs de JEE, estando preparada para assumir o controlo em projetos de médio e grandeporte.

Apesar de tudo, uma consideração final retirada deste estudo, é que ao mesmo tempoque JEE oferece um vasto leque de tecnologias como opções para o desenvolvimento, istopode também surgir como um inconveniente. Por isto, pode afirmar-se que existe umafalha na indefinição de um standard de combinação de tecnologias para utilização. É co-mum encontrarem-se livros ou tutoriais em que para obter as mesmas finalidades se usaum conjunto de tecnologias diferentes, o que torna particularmente difícil definir com cla-reza quais os primeiros passos a dar na conceção de software. Por não existir pelo menosuma forma standard de desenvolver em JEE, como acontece com Rails, perde-se por vezesdemasiado tempo com pormenores. Uma possível solução passaria por definir uma distri-buição standard de desenvolvimento completa (e. g (Facelets (JSF API) + Struts2 (ServletsAPI) + Hibernate (JPA API) + Tomcat (API Server)), o que faria com que uma melhor do-cumentação fosse produzida, contribuindo para uma aceitação ainda maior por parte dasequipas de desenvolvimento que pretendam desenvolver utilizando JEE. Quanto a Rails,esta tecnologia demonstrou estar cada vez mais estável e madura e começa a tomar um im-portante papel no desenvolvimento Web, deixando de ser considerada como apenas maisuma ferramenta de conceção de protótipos, como aconteceu nos últimos anos.

A título pessoal, acrescento ainda que o estudo que efetuei durante o período de desen-volvimento da presente dissertação, foi efetuado em paralelo com um projeto numa bolsade investigação ao abrigo de uma parceria entre a Bosch Car Multimedia BrgP e a Universi-

75

dade do Minho, projeto HMIExcel: "Shaping the future UMinho e Bosch”, que me permitiucolocar em prática e testar os conhecimentos aprendidos sobre Struts2.

B I B L I O G R A F I A

[1] F. M. Martins, Notas Teóricas de Arquitecturas de Software, Universidade do Minho, De-partamento de Informática, MEI, ACS, 2012-2013.

[2] Oracle, “Java platform, enterprise edition (java ee) technical documentation,” http://docs.oracle.com/javaee/.

[3] “Apache struts2 guides,” https://struts.apache.org/docs/guides.html.

[4] “Apache struts2 api,” http://struts.apache.org/maven/struts2-core/apidocs/.

[5] D. T. Sam Ruby, David Heinemeier Hansson, Agile Web Development with Rails 4. Prag-matic Bookshelf, 2013.

[6] M. Hartl, Ruby on Rails 4 Tutorial: Learn Rails by Example. Addison-Wesley ProfessionalRuby Series, 2013.

[7] D. Flanagan and Y. Matsumoto, The Ruby Programming Language, 1st ed. O’Reilly,2008.

[8] “Documentação da linguagem ruby,” https://www.ruby-lang.org/pt/documentation/.

[9] “Documentação de ruby on rails,” http://api.rubyonrails.org/.

[10] “Manifesto for agile software development,” http://agilemanifesto.org/.

[11] JetBrains, “Rubymine ide,” https://www.jetbrains.com/ruby/features/, 2013.

[12] Oracle, “Netbeans ide,” https://netbeans.org/features/index.html.

[13] NetBeans, “The affable beans - e-commerce web application,” https://netbeans.org/kb/docs/javaee/ecommerce/design.html.

[14] “Airport taxi transfers,” http://airportstaxitransfers.com/.

[15] “Rental cars - aluguer de carros,” http://www.rentalcars.com/.

[16] J. Offutt, “Quality attributes of web software applications,” IEEE, Agosto 2002.

[17] L. D. J. I. Fernández-Villamor and C. A. Iglesias, “A comparison model for agile webframeworks,” 2008.

77

http://docs.oracle.com/javaee/

http://docs.oracle.com/javaee/

https://struts.apache.org/docs/guides.html

http://struts.apache.org/maven/struts2-core/apidocs/

https://www.ruby-lang.org/pt/documentation/

https://www.ruby-lang.org/pt/documentation/

http://api.rubyonrails.org/

http://agilemanifesto.org/

https://www.jetbrains.com/ruby/features/

https://netbeans.org/features/index.html

https://netbeans.org/kb/docs/javaee/ecommerce/design.html

https://netbeans.org/kb/docs/javaee/ecommerce/design.html

http://airportstaxitransfers.com/

http://www.rentalcars.com/

78 Bibliografia

[18] “Ruby on rails guides,” http://guides.rubyonrails.org/.

[19] “Ruby on rails api,” http://api.rubyonrails.org/.

[20] D. Newton, Apache Struts 2 Web Application Development, Junho 2009.

[21] J. C. HaiLan Pan and C. Wu, “The network platform based on struts2 + jpa + springframework,” IEEE, Setembro 2010.

[22] S. Metz, Practical Object-Oriented Design in Ruby: An Agile Primer, 1st ed. Addison-Wesley Professional, 2012.

[23] M. Fowler, Patterns of Enterprise Application Architecture. Addison-Wesley Professional,2002.

[24] P. K. Michael Bächle, “Ruby on rails,” IEEE, Novembro 2007.

[25] S. J. Lok Fang Fang Stella and B. Wadhwa, “A comparative study of maintainability ofweb applications on j2ee, .net and ruby on rails,” IEEE, Outubro 2008.

http://guides.rubyonrails.org/

http://api.rubyonrails.org/

Date post:	22-Aug-2020
Category:	Documents
Upload:	others
View:	0 times
Download:	0 times

Paulo Jorge da Silva Maia - Universidade do...

Documents