FACULDADE SETE DE SETEMBRO - FASETE
Curso de Bacharelado em Sistemas de Informação
Jackson Pires de Oliveira Santos Júnior
Integrando Frameworks para Desenvolvimento de
Aplicações RIA (Rich Internet Applications) com Ruby On
Rails e Adobe Flex Utilizando a Arquitetura MVC
JACKSON PIRES DE OLIVEIRA SANTOS JÚNIOR
Integrando frameworks para Desenvolvimento de
Aplicações RIA (Rich Internet Applications) com Ruby On
Rails e Adobe Flex Utilizando a Arquitetura MVC
Monografia apresentada ao Curso de Bacharelado em Sistemas de Informação da Faculdade Sete de Setembro – FASETE como requisito para avaliação conclusiva para obtenção do grau de Bacharel em Sistemas de Informação.
Orientador: Prof . Ryan Ribeiro de Azevedo
.
Paulo Afonso - BA NOV / 2007
JACKSON PIRES DE OLIVEIRA SANTOS JÚNIOR
Integrando Frameworks para Desenvolvimento de
Aplicações RIA (Rich Internet Applications) com Ruby On
Rails e Adobe Flex Utilizando a Arquitetura MVC
Monografia submetida ao corpo docente da Faculdade Sete de Setembro – FASETE, como parte dos requisitos necessários à obtenção da Graduação no Curso de Bacharelado em Sistemas de Informação.
Aprovada por:
________________________________________ Prof. Ryan Ribeiro de Azevedo, MSc. (Orientador)
________________________________________ Thiago Sávio Carbone, MSc.
________________________________________ Igor Medeiros Vanderlei, MSc.
Dedico este trabalho primeiramente a Deus presente em todos os momentos, à minha esposa Daiany que sempre me apoiou em minhas decisões, aos meus pais Jackson e Ruth, razão da minha existência, aos meus irmãos e as pessoas especiais que fazem parte do meu dia-a-dia.
AGRADECIMENTOS
Para a elaboração desta monografia contei com o apoio de muitas pessoas importantes, sem as quais não teria conseguido concluí-la.
Agradeço a Deus pela oportunidade da vida e por estar presente em todos os momentos que precisei.
À minha esposa Daiany Pires, que tem estado sempre ao meu lado me apoiando em todas as decisões e me incentivando na minha caminhada.
A toda minha família, em especial aos meus pai Jackson Pires e Ruth Wanderley que amo tanto e que sempre me mostram o caminho certo a seguir.
Aos meus irmãos, Michelle Wanderley, Priscilla Wanderley e Samuel Wanderley que sempre me encorajam quando necessário.
Aos professores que colaboraram direta e indiretamente para a realização desse trabalho, em especial aos Professores Ryan Ribeiro Azevedo e Eloy Lago Nascimento, profissionais capacitados que não meço minhas palavras para agradecer a atenção e compreensão.
Aos colegas de classe que conquistei ao longo de 4 anos em especial a Igor Costa e Marcus Alves que sempre me ajudaram quando precisei.
E aos demais amigos, familiares que apoiaram para conclusão desse trabalho.
"Aprender é a única coisa de que a mente nunca se cansa, nunca tem medo e nunca se arrepende”. (Leonardo da Vinci)
RESUMO
Com o constante crescimento e evolução das aplicações utilizadas através da Web, empresas e profissionais procuram uma forma de portar suas aplicações para a Internet de forma que elas fiquem disponíveis em qualquer lugar e a qualquer hora, permitindo assim um maior conforto para seus usuários. Diante das novas tecnologias disponíveis para o desenvolvimento de aplicações RIA (Rich Internet Applications), escolheu-se o Ruby on Rails e o Adobe Flex, por se tratarem de tecnologias fortemente comentadas por especialistas nos últimos tempos. Esse trabalho propõe-se a mostrar o funcionamento e integração dos frameworks Ruby on Rails e Adobe Flex como ferramentas para o desenvolvimento de aplicações RIA. Para que esse estudo fosse concluído foram utilizadas pesquisas bibliográficas e também foi utilizado um estudo de caso onde foi desenvolvida uma aplicação piloto que demonstrou a possibilidade de integração entre as tecnologias estudadas. Por fim, observou-se que as tecnologias se integram de forma simples aumentando a produtividade de aplicações ricas para a Internet.
ABSTRACT
With the constant growth and development of applications used by the Web, companies and professionals look for a way to port their applications to the Internet so that they are available anywhere and at any time, thus allowing greater comfort for its users. In the face of new technologies available for the development of applications RIA (Rich Internet Applications), It has been chosen the Ruby on Rails and the Adobe Flex, because they deal with technology heavily commented by experts recently. This work proposes to show the operation and integration of the frameworks Ruby on Rails and Adobe Flex as tools for the development of applications RIA. For this study to be completed, bibliographic research was used and also it was used a case study where a pilot application that was developed showed the possibility of integration between the technologies studied. Finally, it was observed that the technologies integrate themselves in a simple way increasing the productivity of rich applications for the Internet.
LISTA DE FIGURAS
Figura 2.1 – Aplicações em três camadas... 10
Figura 2.2 – Modelo MVC... 11
Figura 3.1 – Site do instalador One Click Installer... 16
Figura 3.2 – Comando “ruby –v” para verificar a versão instalada do Ruby ... 16
Figura 4.1 – Resultado do Rails após o comando “rails Minha_App” ... 24
Figura 4.2 – O diretório app/... 25
Figura 4.3 – Documentação interna da nossa aplicação ... 27
Figura 4.4 – Passos para a criação de Aplicações Web com Ruby on Rails... 31
Figura 5.1 – Arquitetura de uma aplicação Flex ... 34
Figura 5.2 – Tela Inicial de Instalação ... 37
Figura 5.3 – Escolhendo a opção de Instalação... 38
Figura 5.4 – Selecionando o local de instalação ... 39
Figura 5.5 – Instalando o Flash Player para cada browser... 40
Figura 5.6 – Tela de confirmação antes da instalação ... 41
Figura 5.7 – Caixa de diálogo de um novo projeto Flex ... 42
Figura 5.8 – Obtendo o nome do projeto ... 43
Figura 6.1 – Separação da aplicação na arquitetura MVC ... 47
Figura 6.2 – Exemplo do ciclo de comunicação utilizando HTTPService ... 49
Figura 6.3 – Diagrama Entidade Relacionamento BDDOC ... 51
Figura 6.4 – Estrutura de Pastas da Aplicação Piloto BDDOC... 51
Figura 6.5 – Edição do arquivo database.yml... 52
Figura 6.6 – Configuração do arquivo documentos.rb ... 53
Figura 6.7 – Configuração do arquivo area.rb ... 53
Figura 6.8 – Configuração do arquivo tipo.rb... 54
Figura 6.9 – Listagem de tipos ... 55
Figura 6.10 – Listagem de áreas ... 55
Figura 6.11 – Listagem dos documentos... 56
Figura 6.12 – Criação do projeto na pasta public ... 57
Figura 6.13 – Tela de cadastro de documentos ... 58
Figura 6.17 – Componentes de tela preenchidos com o retorno do HTTPService... 60 Figura 6.18 – Funcionalidade de envio de arquivo. ... 61 Figura 6.19 – Função cadastrar(). ... 62 Figura 6.20 – Listagem de trabalhos cadastrados... 63
LISTA DE ABREVIATURAS
AJAX – Asynchronous Javascript and XML API – Application Programming Interface BDDOC –Banco de Dados de Documentos CRUD – Create Read Update Delete DRY – Don't Repeat Yourself
IDE – Integrated Development Environment HTML – Hyper Text Markup Language HTTP – Hiper Text Transference Protocol JSP – Java Server Pages
MVC – Model View Controller
MXML – Macromedia Extensible Markup Language ORM – Object Relational Mapping
PHP – Personal Home Page RIA – Rich Internet Applications RJS – Ruby Javascript
SDK – Software Development Kit SWF – Small Web File
URL – Uniform Resource Locator XML – Extensible Markup Language
SUMÁRIO
CAPÍTULO 1 – INTRODUÇÃO ... 1
1.1 Contextualização ... 1
1.2 Identificação do problema principal e motivação ... 3
1.3 Relevância do tema ... 4 1.4 Objetivos do trabalho ... 5 1.5 Metodologia ... 6 1.6 Organização do trabalho... 6 CAPÍTULO 2 - A ARQUITETURA MVC ... 8 2.1 Introdução ... 8 2.2 Apresentação... 8 2.3 Características do MVC ... 10 2.4 Camadas do MVC... 10 2.5 Vantagens e Desvantagens ... 12 2.6 Discussão ... 12
CAPÍTULO 3 - RUBY – A LINGUAGEM ... 13
3.1. Introdução ... 13 3.2 Histórico ... 13 3.3 Características ... 14 3.4 Vantagens e desvantagens... 15 3.5 Instalação... 15 3.6 Aspectos práticos... 17 3.7 Discussão ... 17
CAPÍTULO 4 - RUBY ON RAILS – O FRAMEWORK ... 18
4.1 Introdução ... 18 4.2 Histórico ... 19 4.3 Características ... 19 4.4 Frameworks do Rails ... 20 4.4.1 Active Mailer ... 20 4.4.2 Action Pack... 21 4.4.3 Active Record ... 21 4.4.4 Action WebService ... 23 4.4.5 Active Support ... 23
4.5 Estrutura de Diretórios ... 24
4.6 Scripts do Ruby on Rails... 28
4.7 Vantagens e desvantagens... 29
4.8 Instalação... 30
4.9 Aspectos práticos... 31
4.9 Discussão ... 32
CAPÍTULO 5 - ADOBE FLEX – O FRAMEWORK ... 33
5.1 Introdução ... 33
5.2 Histórico ... 33
5.2 Características ... 34
5.2.1 MXML ... 35
5.2.1 Action Script 3.0 ... 35
5.3 Programação Dirigida a Eventos ... 36
5.4 Instalação... 36
5.5 Aspectos práticos... 41
5.6 Discussão ... 43
CAPÍTULO 6 - ESTUDO DE CASO ... 45
6.1 Introdução ... 45
6.2 Estrutura Básica da Aplicação Piloto ... 45
6.2.1 Funcionalidades da Aplicação Piloto ... 46
6.3 Definindo o padrão de comunicação entre os frameworks ... 47
6.5 Desenvolvendo o Server-Side ... 50
6.6 Desenvolvendo o Client-Side... 56
6.6.1 Efetivando o cadastro de documentos ... 59
6.6.2 Efetivando a pesquisa de documentos... 62
6.7 Discussão ... 63
CAPÍTULO 7 - CONCLUSÕES... 65
7.1 Introdução ... 65
7.2 Considerações sobre o trabalho realizado... 65
7.3 Identificação de Trabalhos Futuros... 66
7.4 Conclusão Pessoal a Respeito doTrabalho Realizado ... 67
Capítulo 1 Introdução
CAPÍTULO 1 – INTRODUÇÃO
1.1 Contextualização
Nos dias atuais, a Web tem demonstrado sua nova roupagem, o famoso termo Web 2.0 que segundo O’Reilly (2003) é definido como sendo a mudança para uma Internet como plataforma, e um entendimento das regras para obter sucesso nesta nova plataforma, vem se tornando cada vez mais real através de empresas e serviços como a Google (NODA, 2005), Yahoo! (NODA, 2005), Wikipedia (NODA, 2005), que trazem em seus mais diversos serviços e produtos novas formas de interação para o usuário. Entre outras, a regra mais importante é desenvolver aplicativos que aproveitem os efeitos de rede para se tornarem melhores quanto mais são usados pelas pessoas, aproveitando a inteligência coletiva.
Uma das vertentes da Web 2.0 são as aplicações RIA (Rich Internet Applications - Aplicações Ricas para Internet) (O’REILLY, 2003). Essas aplicações prometem levar uma nova experiência ao usuário, com novas formas de interação, como se estivessem em aplicativos standalone1.
“Quando falamos em uma nova experiência, estamos focados na facilidade e interatividade que o usuário vai ter ao usar a aplicação” (FRANCO, 2007).
As aplicações RIA, combinam os benefícios da Web, como o baixo custo de atualizar aplicações, com o uso rico de aplicações standalone. Com as aplicações RIA, não há necessidade de atualização de página, como acontece no modo convencional, assim, as respostas ao usuário são mais rápidas facilitando a integração do usuário com o sistema (FAIN, 2007, p. 01-05).
RIA (Rich Internet Application) é um conceito inovador no modo de pensar e desenvolver na web. Uma aplicação RIA tem como foco principal os usuários, ou seja, levar até eles uma forma rápida e fácil de usabilidade e interatividade, unindo as funcionalidades dos softwares desktop2 com serviços e aplicações Web, proporcionando assim um novo nível de experiência. (FRANCO, 2007)
1
Programas completamente autosuficientes, que não necessitam de software auxiliar para funcionar. Mais detalhes em: <http://pt.wikipedia.org/wiki/Standalone>
2
Desktop, expressão inglesa oriunda de desktop publisher (editor de textos de mesa). Mais detalhes em: <http://pt.wikipedia.org/wiki/Desktop>
Para tal, existem diversas ferramentas no mercado que auxiliam os desenvolvedores no desenvolvimento, depuração e publicação (colocar em modo de produção) dessas aplicações.
Pode-se citar dentre as diversas tecnologias disponíveis no mercado que auxiliam o desenvolvimento de aplicações RIA, os frameworks3 Ruby on Rails (FOWLER, 2006) e Adobe Flex (BROWN, 2007) que juntos podem diminuir consideravelmente o tempo de desenvolvimento de uma aplicação RIA, facilitando o trabalho da equipe de desenvolvimento.
Destaca-se ainda, que os frameworks Ruby on Rails e Adobe Flex utilizam linguagens de programação específicas, tais como: Ruby (OLIVEIRA JUNIOR, 2006) para o Ruby on Rails e Action Script 3 (BROWN, 2007) para o Adobe Flex.
Essas tecnologias utilizam o padrão de arquitetura MVC (Model, View, Controller) (KRASNER & POPE, 1998). Este padrão é bastante utilizado no desenvolvimento de aplicações, pois determina a separação de uma aplicação em três entidades. A entidade Model que é formada por entidades que representam os dados da aplicação. A View que tem por objetivo realizar a apresentação destes dados e capturar os eventos do usuário; sendo representada pelas telas. A entidade Controller que faz a ligação entre a Model e a View, realizando o tratamento dos eventos, atuando sobre a Model e alterando a View para representar a nova forma dos dados.
Nota-se que uma aplicação RIA tem relacionamento direto com o View, o que pode confundir a necessidade do Ruby on Rails para tal solução. No entanto, o uso do framework Ruby on Rails será de suma importância, visto que o mesmo dará suporte ao Adobe Flex como será visto no Capítulo 6.
Diante do exposto, esse trabalho tem como proposta mostrar a possível integração dos frameworks citados, apresentando assim, as facilidades e vantagens de utilizá-los para o desenvolvimento de aplicações RIA utilizando a arquitetura MVC.
Capítulo 1 Introdução
1.2 Identificação do problema principal e motivação
Cada vez mais é possível ler e ouvir pessoas falando sobre usabilidade, design centrado no usuário e outros conceitos. Com o aparecimento de tecnologias como AJAX (EICHORN, 2006) e Adobe Flex, está sendo possível mostrar que o HTML4, por si só, não é capaz de criar experiências mais ricas e intuitivas para os usuários de aplicativos Web (TERRACINI, 2007).
Geralmente quando pensamos em construir uma página, imaginamos página a página. Esse pensamento toma como base um método de desenvolvimento pobre utilizado até mesmo antes da Web (BROW, 2007, p. 1-10).
É um tanto quanto óbvio a importância de se querer melhorar a interface dos aplicativos: é com eles que os usuários interagem. Eles não estão interessados com quais linguagens de programação foi feito, se o framework "x" ou "y" foi utilizado. Eles querem conseguir utilizar o aplicativo e que ele ajude-os a fazer o que eles querem fazer (TERRACINI, 2007).
Segundo Cagan & Vogel,(1997) uma boa experiência em um software significa ser útil, usável e desejável, onde:
Útil: Ajuda os usuários a resolverem problemas importantes de maneira rápida e eficiente, de acordo com suas necessidades;
Usável: Fácil de aprender e usar, de maneira intuitiva e natural para os usuários, com uma qualidade visual agradável passando a sensação de alta qualidade;
Desejável: De acordo com os valores e costumes dos usuários, dando sensação de controle e liberdade.
“O Adobe Flex possui funcionalidades para entrega eficiente de aplicações ricas e de alta performance”. As aplicações baseadas nele permitem que os desenvolvedores estendam todas as suas funcionalidades, criando aplicações mais robustas e integradas com arquiteturas de servidor (FRANCO, 2007).
4
HTML é uma linguagem de marcação utilizada para produzir páginas na Web. Mais detalhes em: <http://pt.wikipedia.org/wiki/Html>
Contudo, o Adobe Flex foi desenvolvido para trabalhar como a camada View de um projeto, necessitando dessa forma de uma tecnologia que a auxilie com procedimentos que sejam executados do lado do servidor.
O Ruby on Rails, por sua vez, é um framework Web de alto nível, ou seja, se propõe a esconder os detalhes menos interessantes do desenvolvimento Web permitindo que o programador se concentre no que realmente é importante, ou seja, na lógica e apresentação de sua aplicação (FERRAZ, 2007)
Rails leva em sua arquitetura o padrão de arquitetura MVC. O molde MVC oferece vantagens significativas no desenvolvimento de aplicativos, através da separação das camadas, possibilitando implementar com maior facilidade e clareza questões programáticas importantes como a persistência de dados, controle de segurança, comunicação em rede e fluxo de visualização (FRANCO, 2007).
Procura-se então, uma forma de poder construir softwares RIA que atendam com plenitude o que os usuários precisam, oferecendo uma experiência positiva no tocante em todos os aspectos (facilidade, design, requisitos, etc).
Diante do exposto, este trabalho tem, portanto, como principal motivação mostrar a possibilidade de integração entre os frameworks (Adobe Flex e Ruby on Rails) utilizando a arquitetura MVC, se houver possibilidade de integração, quais seriam as formas possíveis, e ainda saber se essas ferramentas integradas facilitam o desenvolvimento das aplicações RIA.
1.3 Relevância do tema
Automatizar tarefas e ganhar tempo faz parte do nosso dia a dia, sabemos que ter ferramentas adequadas que nos dê flexibilidade e garantia de um bom suporte é essencial nos dias de hoje para que possamos desenvolver produtos com produtividade e qualidade. Hoje no mercado existe uma infinidade de ferramentas e frameworks que prometem proporcionar isso, mas, o grande problema é garantir flexibilidade de expansão, manutenção e suporte (FRANCO, 2007).
Uma das melhores formas de desenvolvimento Web é usar frameworks, pois estes têm uma estrutura definida que facilita o desenvolvimento da aplicação, habilitando designers e programadores a gastarem mais tempo determinando as
Capítulo 1 Introdução
Nesse contexto, observa-se que existe a necessidade tanto do usuário, para conseguir usar os recursos oferecidos, como do provedor dos serviços, tentando desenvolver soluções que facilitem o trabalho de seus usuários. Tais soluções são muitas vezes alcançadas facilmente quando a utilização de aplicações RIA é empregada.
Para a comunidade acadêmica, bem como profissionais do ramo, esse estudo traz a oportunidade de conhecimento, visto que o assunto abordado utiliza tecnologias que surgiram a poucos anos, e por isso, existe uma grande dificuldade de se encontrar material bibliográfico sobre o assunto.
Este trabalho ainda trará o desenvolvimento de uma aplicação piloto, na qual será possível perceber de forma real como implementar uma aplicação rica para Internet utilizando as tecnologias abordadas.
1.4 Objetivos do trabalho
Este trabalho possui como objetivo geral, mostrar à comunidade acadêmica e profissional a possibilidade de integração dos frameworks Adobe Flex e Ruby on Rails utilizando a arquitetura MVC para desenvolver aplicações RIA.
Este trabalho tem como objetivos específicos:
Apresentar os padrões da arquitetura MVC;
Apresentar o funcionamento do framework Ruby on Rails; Apresentar o funcionamento do framework Adobe Flex;
Apresentar um método para o desenvolvimento de uma aplicação RIA utilizando a arquitetura MVC e integrando os frameworks apresentados.
Dessa forma será possível mostrar como trabalhar com os dois frameworks em conjunto para desenvolver uma aplicação RIA. Para tal será criada uma aplicação piloto, que apesar de simples, demonstrará funcionalidades que são a base para a maioria dos tipos de aplicação que venham a surgir, através dessa integração.
1.5 Metodologia
Para que o trabalho aqui proposto possa ser desenvolvido, foram executadas as seguintes atividades: revisão da literatura, identificando os pontos críticos dos trabalhos analisados, tendo o tema baseado em literatura nacional e internacional, sendo realizada, em parte, durante o início do ano de 2007; participações em cursos de aperfeiçoamento; desenvolvimento de uma aplicação piloto utilizando os recursos aprendidos durante o estudo do tema para promover a integração entre os frameworks. Tal aplicação demonstrará como é feita a comunicação entre os dois frameworks em pelo menos duas situações: envio de mensagens a partir do Adobe Flex para o Ruby on Rails, bem como o contrário. Por fim análise dos resultados obtidos e escrita da monografia.
1.6 Organização do trabalho
O trabalho foi estruturado em sete capítulos. O presente capítulo tem por objetivo permitir ao leitor uma visão geral das tecnologias dos frameworks apresentados e seus benefícios para a comunidade acadêmica e sociedade, justificando a escolha e a relevância do tema e explicando os objetivos do trabalho. Além disso, este capítulo apresenta uma breve visualização dos demais capítulos deste documento, mostrando nos parágrafos a seguir uma breve descrição desses capítulos.
No Capítulo 2 são apresentados os conceitos do padrão arquitetural MVC utilizado nos frameworks e discutindo o seu funcionamento na aplicação piloto que servirá para demonstrar os objetivos deste trabalho.
No Capítulo 3 é analisada a linguagem Ruby que é a base para o framework Ruby on Rails, fundamentando conceitos e apresentando a história e aspectos práticos da linguagem.
No Capítulo 4 é analisado o framework Ruby on Rails, apresentando seu funcionamento, histórico, conceitos e aspectos práticos que ajudarão no desenvolvimento da aplicação piloto.
Capítulo 1 Introdução
No Capítulo 5 é analisado o framework Adobe Flex, onde é apresentado seu histórico, funcionamento, conceitos básicos e linguagens utilizadas para a manipulação do mesmo, tornando possível o desenvolvimento de uma aplicação RIA. Ainda neste capítulo é apresentado como se enquadra esse framework na arquitetura MVC.
No Capítulo 6 é descrito como foi criada a aplicação piloto utilizando os frameworks e a arquitetura MVC. Nessa aplicação será demonstrado como enviar e receber mensagens entre as duas tecnologias, possibilitando assim a criação de qualquer aplicação a partir desses princípios.
No Capítulo 7 são apresentadas as considerações finais do trabalho de monografia e uma conclusão de todo estudo realizado. Neste capítulo também são apresentadas sugestões para trabalhos futuros.
CAPÍTULO 2 - A ARQUITETURA MVC
2.1 Introdução
Este capítulo abordará a arquitetura de desenvolvimento MVC (Model, View, Controller), apresentando seus conceitos e fundamentos, bem como o funcionamento da sua estrutura.
Essa arquitetura divide o sistema em camadas, permitindo uma fácil interação dos desenvolvedores envolvidos em determinado projeto.
Será apresentada também cada uma das camadas que compõe a arquitetura MVC, bem como suas características, vantagens e desvantagens, demonstrando que a arquitetura quando bem utilizada tende a aumentar a produtividade no desenvolvimento de uma aplicação.
2.2 Apresentação
O grande desafio das equipes de desenvolvimento de sistemas é cada vez mais produzir aplicativos eficientes, seguros, de fácil manutenção, reutilizáveis e em prazos cada vez menores (MACORATTI, 2004).
Segundo Balthazar et. al (2006, p. 02), uma organização que consegue trabalhar com sistemas de informação, baseado em um software com alta manutenibilidade, disponibilidade e segurança, tende a ser mais competitivo perante seus concorrentes.
Nesse contexto, vem se destacando alguns conceitos como o desenvolvimento em camadas, a orientação a objetos, a utilização de padrões de projeto e frameworks para o desenvolvimento de sistemas (MACORATTI, 2004).
A fundamentação da divisão das funcionalidades de um sistema em camadas surgiu como alternativa para solucionar problemas existentes nas aplicações de camada única, nas quais, dados e código eram armazenados em um mesmo módulo, dificultando a manutenção dos sistemas devido à grande quantidade de linhas de código em um mesmo local (BALTHAZAR et. al., 2006, p. 2).
Capítulo 2 A Arquitetura MVC
Segundo Macoratti (2004), o advento da Internet foi mais uma forma de separar os sistemas em camadas de modo que eles se tornam mais flexíveis, permitindo que as partes possam ser alteradas de forma independente.
O modelo de três camadas físicas (3-tier) tornou-se um padrão para sistemas corporativos com base na Web, ele divide um aplicativo de modo que a lógica de negócio resida no meio das três camadas físicas. A maior parte do código escrito reside na camada de apresentação e de negócio (MACORATTI, 2004).
Segundo a Wikipedia5, “Model-view-controller (MVC) é um padrão de arquitetura de software”.
O MVC é uma arquitetura de software que separa o modelo de dados da aplicação, a interface do usuário, e o controle de lógica em três componentes distintos. Dessa forma, alterações feitas em um componente causa impactos mínimos nos outros (ROBALINHO, 2006, p. 27).
Este padrão é bastante utilizado no desenvolvimento de aplicações, pois determina a separação de uma aplicação em três entidades. A entidade Model, que é formada por entidades que representam os dados da aplicação. A View, que tem por objetivo realizar a apresentação destes dados e capturar os eventos do usuário, sendo representada pelas telas. A entidade Controller, que faz a ligação entre a Model e a View, realizando o tratamento dos eventos, atuando sobre a Model e alterando a View para representar a nova forma dos dados (KRASNER & POPE, 1998).
Segundo Silva & Moreira (2004), um dos principais objetivos do padrão arquitetural MVC é a organização do código de uma aplicação em camadas para facilitar o desenvolvimento e separação do código, bem como da interface visual, uma vez que cada camada pode ser modificada sem afetar diretamente as outras.
Nota-se então a grande vantagem de se utilizar um desenvolvimento em camadas utilizando a arquitetura MVC, por esta permitir o desenvolvimento de suas camadas separadamente, não perdendo a interação entre as mesmas.
2.3 Características do MVC
Segundo MACORATTI (2004), algumas das características relevantes da arquitetura MVC são:
Alta manutenibilidade devido ao sistema de divisão modular; Possui responsabilidades mais definidas;
Separar a lógica da apresentação;
Reduz o esforço do desenvolvedor na camada de apresentação; Torna a aplicação escalável.
2.4 Camadas do MVC
Agora que é conhecida a idéia de desenvolvimento em camadas para utilização na produção de software, podem-se conhecer as camadas do MVC em detalhe. Verificando a Figura 2.1, podem-se notar as camadas que compõe a arquitetura MVC (Model-View-Controller).
Figura 2.1 – Aplicações em três camadas
Fonte: http://www.macoratti.net/vbn_mvc.htm
A camada de apresentação ou visualização, conhecida como View, transforma o modelo em uma forma adequada para a interação, tipicamente um elemento da interface do usuário (KAWASE, 2006, p. 27).
Segundo Gimenes & Huzita (2005, p. 18), a camada View é responsável por exibir os dados aos usuários através de um dispositivo de saída. Ainda segundo Macoratti (2004), “a camada View não se preocupa como a informação foi obtida ou onde foi obtida, ela apenas exibe a informação”.
Camada de apresentação ou visualização Camada de acesso a dados Camada de lógica de negócios
Capítulo 2 A Arquitetura MVC
A camada de lógica de negócios, conhecida como Controller, representa eventos, geralmente ações do usuário, e realiza mudanças no componente Model e às vezes na View (KAWASE, 2006, p. 28). O Controller aceita entradas assíncronas, por exemplo, do mouse ou teclado, passando as mensagens apropriadas para o Model e View, de modo a permitir a edição dos dados da aplicação (GIMENES & HUZITA, 2005, p. 18).
A camada de acesso a dados, conhecida como Model, representa a informação para um domínio específico no qual a aplicação é executada. Model é apenas um outro nome para a camada de domínio (KAWASE, 2006, p. 27). Ainda segundo Thomas (2005, p. 9), o Model é responsável por manter o estado da aplicação.
O Model contém dados específicos do domínio que serão representados e manipulados a partir das interfaces com o usuário (GIMENES & HUZITA, 2005, p. 18). Kawase (2006, p. 28) informa que muitas aplicações utilizam repositórios de dados como, por exemplo, bancos de dados. MVC não menciona essa camada de dados, pois considera que ela está encapsulada pelo componente Model. O Model é mais do que apenas dados, ele reforça as regras de negócio aplicadas aos dados (THOMAS, 2005, p. 9).
É apresentada na Figura 2.2 a interação entre as camadas do padrão MVC.
Figura 2.2 – Modelo MVC
Fonte: GIMENES & HUZITA, 2005
Controller View Model Mensagens Mensagens Entradas, ex: Teclado e mouse
Em suma, a camada View é responsável por receber a interação do usuário e apresentar às informações na tela. O Controller por sua vez recebe as ações do usuário e, caso necessário, acessa o Model que é o responsável por gerenciar e persistir os dados do sistema.
2.5 Vantagens e Desvantagens
Segundo Macoratti (2004), dentre as diversas vantagens relevantes além das citadas anteriormente, pode-se ainda citar que o MVC:
Trabalha com desenvolvimento em paralelo entre Model, View e Controller É fácil de manter, testar e atualizar sistemas
Também se pode citar algumas desvantagens, começando pela necessidade de trabalhar com pessoal especializado e que tenham bom conhecimento dos padrões MVC (MACORATTI, 2004).
Outra desvantagem é que a concepção do aplicativo geralmente leva mais tempo, visto a necessidade de modelar o sistema de acordo com os padrões MVC (MACORATTI, 2004).
2.6 Discussão
Agora que se tem uma visão geral do padrão de desenvolvimento, pode-se notar a grande vantagem de utilizá-lo para o desenvolvimento de sistemas, corporativos ou não, prezando assim pela qualidade em todos os aspectos do desenvolvimento.
É notório que ao utilizar esse padrão de desenvolvimento a equipe trabalhará em um formato em que seus colaboradores terão ações definidas, pois, como visto nesse capítulo, ao se separar as três camadas, funções e atribuições podem ser entregues a diferentes profissionais, sem ter a complicação de depois organizar tudo no mesmo lugar novamente.
Capítulo 3 Ruby – A Linguagem
CAPÍTULO 3 - RUBY – A LINGUAGEM
3.1 Introdução
É apresentada nesse capítulo a linguagem de programação Ruby, de forma a apresentar as definições, características, histórico, vantagens e desvantagens, instalação e também uma sucinta utilização da mesma.
Segundo Oliveira Júnior (2005, p. 9) Ruby é uma linguagem de script interpretada para programação orientada a objetos de um modo fácil e rápido. Possui sintaxe bastante simples, parcialmente inspirada por linguagens de programação como Eiffel e Ada. Os recursos da linguagem Ruby foram inspirados em linguagens como SmallTalk, Perl e Python.
Segundo Steele (2001), Ruby combina a programação totalmente orientada a objetos de SmallTalk, com o poder de Python e com a utilidade e praticidade de Perl no desenvolvimento de aplicações Web, tudo isso em uma linguagem Open Source6.
3.2 Histórico
A criação da linguagem Ruby foi iniciada pelo japonês Yukihiro Matsumoto, conhecido por “Matz”, em 24 de fevereiro de 1993. Quase dois anos depois, em dezembro de 1994, ficara pronta sua primeira versão alpha da linguagem (STEWART, 2001).
Em 1995, Matz continuou sozinho com o desenvolvimento da linguagem, porém, já em 1996 começava a se formar uma comunidade em torno do seu desenvolvimento, visto que é uma linguagem Open Source. A partir daí, apesar de ainda fazer a maior parte do desenvolvimento sozinho, Matz passou a receber atualizações por parteda comunidade (STEWART, 2001).
Em 2001, a linguagem ganhou reconhecimento no meio especializado quando o renomado programador pragmático Dave Thomas adotou-a como uma de suas linguagens preferidas, lançando o livro que passou a ser conhecido como a bíblia do Ruby (Programming Ruby: The Pragmatic Programmer's Guide) (THOMAS, 2005).
6
Software cujo código fonte é visível publicamente, mais informações disponíveis em: http://pt.wikipedia.org/wiki/Open_Source
O impulso que faltava a linguagem para emplacar de vez foi dado por David Heinemeier Hansson (AKITA, 2006) e seus colaboradores, em 2004, quando desenvolveram o Ruby on Rails, ou simplesmente Rails, um framework de desenvolvimento para Web que será apresentado no Capítulo 4.
3.3 Características
Além do que já foi dito na Seção 3.1, Ruby possui muitos recursos que o caracterizam de modo bastante particular. Segundo Oliveira Júnior (2006, p. 01-03), algumas das características do Ruby são:
Tratamento de Exceções: do mesmo modo que Java e Python, Ruby possui tratamento de exceções para facilitar o tratamento de erros, como toda boa linguagem moderna;
Totalmente orientado a objetos: todo dado em Ruby, sem exceções, é um objeto, inclusive tipos básicos como números;
Sintaxe enxuta: há poucos caracteres, como colchetes, facilitando a leitura; Adaptabilidade dinâmica: pode-se adicionar métodos a uma classe ou
mesmo instâncias de classe em tempo de execução;
Herança única: é menos complexa e mais utilizada. Contudo, da mesma forma que outras linguagens como Java, pode-se simular a herança múltipla, sem cair nos seus problemas, importando um módulo e utilizando seus métodos;
Closures verdadeiras: não são apenas funções sem nome, mas com bindings de váriaveis verdadeiras;
Blocos de códigos: podem ser passados para os métodos, ou ainda convertidos em closures;
Garbage collector: é do tipo marca e limpa. Ele atua em todos os objetos do Ruby;
Tipagem dinâmica: Ruby não precisa de declaração de variáveis, o tipo é definido pela maior semelhança e pode ser alterado em tempo de execução, porém é uma tipagem forte;
Capítulo 3 Ruby – A Linguagem
Multi-threading7: Ruby tem um sistema threading independente do Sistema Operacional.
3.4 Vantagens e desvantagens
Por tudo que já foi exposto no tópico anterior ficam evidentes as vantagens da linguagem, visto que compila boas características comuns das principais linguagens utilizadas no mercado.
Como qualquer outra linguagem o Ruby também tem suas desvantagens, tais como:
Desempenho: por se tratar de uma linguagem puramente interpretada, este é prejudicado (BURD, 2007, p. 34);
O mecanismo de Multi-Threading: é independente do sistema operacional, e portanto simulado, ou seja, gerenciado pelo próprio Ruby causando desta maneira perda de performance. (THOMAS, 2005);
Não tem suporte a UNICODE8 para o sistema de caracteres. (THOMAS, 2005)
3.5 Instalação
A instalação do Ruby é relativamente fácil e pode ser instalada em diversos sistemas operacionais. O pacote de instalação Ruby contém o interpretador, bibliotecas e documentação. (AKITA, 2006, p. 1)
Para a instalação no Windows®9 pode-se fazer o download10 do instalador One Click Installer (Figura 3.1), disponível no site <http://rubyinstaller. rubyforge.org/>. (AKITA, 2006, p. 2) A instalação é simples, basta executar o arquivo descarregado e seguir o passoa-a-passo. (AKITA, 2006, p. 2)
7 Processar mais de uma informação ao mesmo tempo. Mais detalhes em:
<http://pt.wikipedia.org/wiki/Multitarefa>
8 É um padrão que permite aos computadores representar e manipular, de forma consistente, texto. Mais
detalhes em: <http://pt.wikipedia.org/wiki/Unicode>
9 Família de Sistemas Operacionais criados pela Microsoft, mais informações em:
<http://pt.wikipedia.org/wiki/Microsoft_Windows>
Figura 3.1 – Site do instalador One Click Installer
Após efetuada a instalação, o Ruby já estará disponível para uso. Para verificar a versão atual do Ruby instalada no sistema operacional em uso, digita-se “ruby –v” (Figura 3.2) (THOMAS, 2005, p. 2).
Capítulo 3 Ruby – A Linguagem
3.6 Aspectos práticos
Um exemplo de código-fonte na Linguagem Ruby seria o arquivo “oiPessoa.rb” com o seguinte conteúdo:
1 def oiPessoa(nome)
2 resultado = “Ola, ” + nome 3 return resultado
4 end
5 puts oiPessoa(“Jackson”)
Para rodar esse programa, basta chamar na linha de comando:
> ruby oiPessoa.rb
Após rodar esse programa a saída na tela será “Ola, Jackson”.
Este exemplo ilustra de maneira simples, alguns elementos da linguagem Ruby e serve como base para qualquer outro uso da linguagem (JUNQUEIRA & FORTES, 2007, p. 91).
3.7 Discussão
Por tudo que foi apresentado até aqui, nota-se que a linguagem Ruby é totalmente simples, multiplataforma, poderosa, com influência de várias outras linguagens e acima de tudo, uma linguagem nova, permitindo que pessoas que venham a conhecê-la possam interagir e até participar do seu desenvolvimento, já que a mesma é Open Source e ainda encontra-se em constante evolução.
Para nosso estudo o conhecimento da linguagem Ruby torna-se indispensável, pois ela é a base para o funcionamento do framework Ruby on Rails, o qual será demonstrado no próximo capítulo.
CAPÍTULO 4 - RUBY ON RAILS – O FRAMEWORK
4.1 Introdução
É apresentado nesse capítulo o framework Ruby on Rails ou simplesmente Rails, de forma a apresentar as definições, características, histórico, vantagens e desvantagens, instalação e também uma sucinta utilização do mesmo.
Segundo Gimenes & Huzita (2005, p. 17), “Um framework pode ser definido como um projeto de software reutilizável que descreve como um sistema é decomposto em um conjunto de objetos ou componentes”. Segundo a Wikipedia (2007), “no desenvolvimento do software, um framework ou arcabouço é uma estrutura de suporte definida em que um outro projeto de software pode ser organizado e desenvolvido”.
Um framework pode incluir programas de suporte, bibliotecas de código, linguagens de script e outros software para ajudar a desenvolver e juntar diferentes componentes de um projeto de software (WIKIPEDIA, 2007).
Frameworks são projetados com a intenção de facilitar o desenvolvimento de software, habilitando designers e programadores a gastarem mais tempo determinado nas exigências do software do que com detalhes tediosos de baixo nível do sistema (WIKIPEDIA, 2007).
Pode-se então definir que Ruby on Rails é um conjunto de frameworks que ajudarão o desenvolvedor a aumentar a produtividade em seus projetos, ou ainda, segundo o site RubyOnRails11 que é o mantenedor oficial do Rails:
Rails é um framework completo para desenvolvimento de aplicações Web com banco de dados de acordo com o padrão Model View Controller. Rails lhe dá um ambiente de desenvolvimento puramente em Ruby. O Rails é uma plataforma aberta de desenvolvimento Web, escrita em Ruby, para a criação de aplicações reais com satisfação para o desenvolvedor e menos código do que muitas outras plataformas que dependem de configurações XML.
Capítulo 4 Ruby on Rails – O Framework
4.2 Histórico
O Framework Rails foi criado pelo programador David Heinemeier Hansson, também conhecido por DHH. Ele idealizou o Rails quando desenvolvia um sistema chamado Basecamp pela empresa 37Signals (BLACK, 2006). Em julho de 2004 DHH liberou a primeira versão para a comunidade, depois de apenas dois meses de trabalho e pouco mais de 4000 linhas de código (AKITA, 2006).
O primeiro lançamento de Rails deu início a uma comunidade ativa que ajudou a evoluir o framework até a versão final 1.0, liberada 15 meses depois, em 14 de dezembro de 2005. No início de 2006 aconteceu o lançamento da versão 1.1 com mais de 500 correções e novos recursos (AKITA, 2006).
Ruby ganhou Rails para trilhar um caminho concreto no mundo de desenvolvimento de software. Não se trata de um rumor ou boato. É um produto real, que pode ser baixado e usado em projetos reais (AKITA, 2006).
4.3 Características
Além das diversas características citadas na seção anterior pode-se ainda citar:
Segue o conceito de arquitetura MVC: MVC é uma arquitetura que tem o objetivo de separar o código da visualização do usuário facilitando a vida do desenvolvedor e do profissional de design (THOMAS & HANSSON, 2005, p. 01);
Segue o conceito DRY: DRY (Don't Repeat Yourself, Não se repita) é o conceito por trás da técnica de definir nomes, propriedades e códigos em somente um lugar e reaproveitar essas informações em outros (THOMAS & HANSSON, 2005, p. 02);
Segue o conceito Convention over Configuration: na maioria dos casos, usamos convenções no dia-a-dia da programação, em geral para facilitar o entendimento e manutenção por parte de outros desenvolvedores. Sabendo disso, e sabendo que o tempo gasto para configurar XML em alguns frameworks de outras linguagens é extremamente alto, decidiu-se adotar esse conceito. Ele diz basicamente que se devem assumir valores padrão onde existe uma convenção. Caso o desenvolvedor deseje, pode-se sobrescrever essa convenção com o valor necessário (THOMAS & HANSSON, 2005, p. 2); Utiliza ORM (Object Relational Mapping): esse tipo de estrutura tem a
tarefa praticamente de mapear as estruturas da base de dados no sistema facilitando a programação, ou seja, o desenvolvedor não precisa se preocupar com SQL12 e detalhes de banco de dados (THOMAS & HANSSON, 2005, p. 15).
4.4 Frameworks do Rails
Todas as características apresentadas até agora são implementadas pelos diversos frameworks presentes no Rails, são eles: Active Record, Action Pack, Action Mailer, ActiveSupport, Action Webservice. A seguir temos a breve descrição de cada framework.
4.4.1 Active Mailer
Esse framework é responsável pelo envio e recebimento de emails. Nele o framework Action Mailer poderá interagir com o programa construído pelo desenvolvedor, por exemplo, pode-se fazer um blog13 que receba as matérias através de e-mail, não precisando que o usuário efetue seu login14 no site para poder enviar a mensagem (JUNQUEIRA, 2007, p. 95).
Capítulo 4 Ruby on Rails – O Framework
4.4.2 Action Pack
Segundo Junqueria (2007, p. 95) o Action Pack “é responsável por fazer a separação da resposta de uma requisição Web em uma parte de controle (que faz a lógica) e outra de visão (processamento de um template15)”. “Ele é o maestro no despacho adequado de chamadas a métodos, redirecionamento a páginas e tudo que tem a ver com o fluxo de ações pelo aplicativo” (AKITA, 2006, p. 37).
4.4.3 Active Record
Esse framework é responsável por mapear as tabelas da base de dados e os objetos da aplicação, criando assim um modelo de persistência do domínio onde a lógica e os dados são tratados de uma única forma (JUNQUEIRA, 2007, p. 96). “Ele é uma implementação do padrão mapeamento objeto-relacional (ORM – Object Relacional Mapping) chamado Active Record” (JUNQUEIRA, 2007, p. 107)
Segundo Thomas & Hansson (2005, p. 16), por padrão em um banco de dados o Active Record “[...] mapeia tabelas para Classes, linhas para Objetos e colunas para Atributos de objetos”.
“Ele tem vantagens e desvantagens, porém, os créditos de que o Rails representa um grande ganho de produtividade pode ser atribuído, em grande parte, a este pacote” (AKITA, 2006, p. 37).
Ou seja, pode-se dizer que esse framework é responsável pela persistência dos dados (AKITA, 2006).
Junqueira (2007, p. 107) diz que, “A principal contribuição do padrão de projeto ORM ou Active Record é auxiliar em dois problemas: falta de associações e herança”. Algumas das principais funcionalidades do Active Record são:
15
Template (ou "modelo de documento") é um documento sem conteúdo, com apenas a apresentação visual (apenas cabeçalhos por exemplo) e instruções sobre onde e qual tipo de conteúdo deve entrar a cada parcela da apresentação. Mais informações em: <http://pt.wikipedia.org/wiki/Web_template>
Mapeamento automatizado entre as classes e tabelas, atributos e colunas: Apenas utilizando o conceito de “Convention over Configuration” (Seção 4.3) é possível mapear automaticamente a tabela em questão, herdando assim métodos/operações como as de leitura e escrita dos registros no banco de dados.
Associações entre os objetos controlados através de macros simples de metaprogramação: Os principais tipos de associações são: um-para-um, um-para-muitos e muitos-para-muitos. No Rails eles são utilizados com os seguintes comandos: “has_one, has_many, belongs_to, has_many_and_belongs_to_many”. Ao exemplo de uma tabela dependentes pertencer a uma tabela clientes seria utilizado o comando (belongs_to cliente) no model (dependente.rb), dessa forma a associação já seria entendida pela aplicação Rails.
Agregação de objetos de valor controlados por macros simples de metaprogramação: “Caso existam agregações, podem ser utilizadas as macros composed_of”. Essas agregações servem para unir o conteúdo de duas colunas de uma tabela. Um exemplo mais comum é o uso de duas colunas (nome e sobrenome) para armazenar separadamente o nome e sobrenome de um usuário em uma tabela. Dessa forma utiliza-se a macro composed_of para unir a duas colunas e obter o resultado em uma única coluna.
Regras de validação: “Existem várias facilidades para fazer a validação dos dados no servidor. Os validadores geram mensagens para o usuário no caso em que as regras não são satisfeitas”. Os validadores servirão, por exemplo, para certificar que as informações que serão inseridas no banco de dados estão de acordo com as especificações do sistema.
Callbacks: “Calbacks permitem que sejam disparadas ações (lógica) antes ou depois de alteração de estado de um objeto”. Um callback é uma forma de interceptar o momento de execução de uma operação de persistência em um modelo, seja qual ela for, e atuar sobre a mesma de acordo com a necessidade. Exemplos de callbacks são: before_save e before_create.
Capítulo 4 Ruby on Rails – O Framework
Observers: “Observers são classes que respondem aos callbacks para implementar comportamento semelhante ao de triggers fora da classe original”. Um observer escuta os eventos de mudança de um outro objeto. Suporte a transações: O Active Record suporta transações “[...] tanto nos
objetos como no nível do banco de dados”.
Abstação de banco de dados através de adaptadores simples com conector compartilhado: “O Active Record pode se conectar com praticamente qualquer banco de dados, pois utiliza abstração do banco de dados”. Por padrão o Rails traz suporte para os seguintes bancos de dados: MySQL, PostgreSQL, SQLite, Oracle, SQLServer e DB2.(JUNQUEIRA, 2007, p. 107-110)
4.4.4 Action WebService
Segundo Junqueria (2007, p. 95), o Action WebService “fornece mecanismos para publicar APIs16 de Web Service17 interoperacionais com Rails sem dispender muito tempo aprofundando nos detalhes de protocolo”.
Este pacote fornece ao aplicativo funcionalidades para que possa responder como se fosse um Web Service, ou seja, seu aplicativo deixa de ser apenas uma interface gráfica via HTML para se tornar um provedor de APIs a outros sistemas e aplicativos. (AKITA, 2006 p. 37).
4.4.5 Active Support
Segundo Akita (2006, p. 37), o Active Support “é responsável por tomar conta da carga de outras bibliotecas, dependências, recursos avançados como breakpoint em tempo de execução, cache18, logs19, plugins20 e muito mais”.
16
API é um conjunto de rotinas e padrões estabelecidos por um software para utilização de suas funcionalidades por programas aplicativos. Mais detalhes em: <http://pt.wikipedia.org/wiki/API>
17 Web service é uma solução utilizada na integração de sistemas e na comunicação entre aplicações diferentes.
Mais detalhes em: <http://pt.wikipedia.org/wiki/Web_service>
18
Cache é um dispositivo de acesso rápido. Mais detalhes em: <http://pt.wikipedia.org/wiki/Cache>
19 Log é o termo utilizado para descrever o processo de registro de eventos relevantes num sistema
computacional. Mais detalhes em: <http://pt.wikipedia.org/wiki/Log_de_dados>
“É uma coleção de várias classes utilitárias e extensões de bibliotecas padrão que foram consideradas úteis para o Rails” (JUNQUEIRA, 2007, p. 96). O Active Support é um conjunto de bibliotecas que são compartilhadas com os componentes Rails utilizadas para estendê-lo internamente (THOMAS & HANSSON, 2005, p. 242).
4.5 Estrutura de Diretórios
Com o objetivo de organizar as aplicações desenvolvidas com o framework, o Rails utiliza uma estrutura de diretórios bem definida (JUNQUEIRA, 2007, p. 97). Segundo Thomas & Hansson (2005, p. 223), “Rails assume um layout com um número fixo de diretórios”.
É apresentada na Figura 4.1 a estrutura de diretórios que é gerada pelo Rails quando o comando “rails <nome_da_aplicacao>” é executado.
Figura 4.1 – Resultado do Rails após o comando “rails Minha_App”
Fonte: THOMAS & HANSSON, 2005
Analisando a Figura 4.1 pode-se explicar com mais detalhes alguns dos Minha_App
README Informações de instalação e uso Rakefile Gerador de Scripts
app/ Arquivos do Model, View e Controller estão aqui components/ Componentes reusáveis
config/ Parâmetros de conexão com o BD e configurações db/ Informação de Shema e migrações
doc/ Documentação com geração automática lib/ Código compartilhado
log/ Arquivos de Log gerados por sua aplicação
public/ Diretório acessado da Web. Sua aplicação é rodada aqui script/ Scripts utilitários
test/ Testes unitários, funcionais e de integração, fixtures e mocks tmp/ Arquivos temporários em tempo de execução
Capítulo 4 Ruby on Rails – O Framework
Minha_App: É o diretório que contém todo o código específico da aplicação gerada pelo comando “rails Minha_App” (JUNQUEIRA, 2007, p. 97).
app/: Segundo Akita (2006, p. 38), É nessa pasta que estão localizados as classes MVC, dentro dessas pastas (Figura 4.2) “[...] temos dividido em subdiretórios apis/, controllers/, helpers/, models/ e views/”, alguns comentados a seguir.
Figura 4.2 – O diretório app/
Fonte: THOMAS & HANSSON, 2005
⇒ app/controllers/: Armazena os controllers da aplicação desenvolvida. Um detalhe importante é que a nomenclatura utilizada por convenção do Rails é que a seguinte: “<nome>_controller.rb”, ou seja, sempre será o “nome do controller” seguido do caractere underscore, seguido do nome controller (JUNQUEIRA, 2007, p. 97).
⇒ app/views/: Aqui ficam armazenados os arquivos de template que farão parte da view que será mostrado ao usuário (JUNQUEIRA, 2007, p. 98). app/ controllers/ application.rb store_controller.rb helpers/ application_helper.rb store_helper.rb models/ product.rb views/ layouts/ store/ add_to_cart.rjs index.rhtml
⇒ app/models/: Nesse diretório ficam os models do projeto. Esses arquivos também seguem uma convenção, sendo sempre o nome do modelo no singular. Ex: “cliente.rb” (JUNQUEIRA, 2007, p. 98).
components/: Segundo Junqueira (2007, p. 98), o diretório components contém “mini aplicações auto-contidas que podem ser distribuídas junto com controllers, models e views”.
config/: Esse diretório é responsável por reter alguns arquivos de configuração do ambiente Rails, como o mapa de roteamento21, configuração do banco de dados e outras dependências (JUNQUEIRA, 2007, p. 98).
db/: Contém o esquema do banco de dados da aplicação no arquivo shema.rb. E em um subdiretório chamado migrate/ contém a seqüência de migrações para o esquema (JUNQUEIRA, 2007, p. 98). Aqui ficam scripts para gerar e atualizar o esquema do banco de dados, ficando assim mais fácil recriar tabelas e dar carga de dados em ambientes de teste e produção (AKITA, 2006, p. 38).
doc/: Fica aqui a documentação da aplicação que é gerada automaticamente pelo Rails através dos comentários no código fonte (JUNQUEIRA, 2007, p. 98). Utilizando o comando “rake doc:app” será gerada uma documentação em HTML (Figura 4.3) que ficará disponível no diretório doc/.
Capítulo 4 Ruby on Rails – O Framework
Figura 4.3 – Documentação interna da nossa aplicação
Fonte: THOMAS & HANSSON, 2005
lib/: Esse diretório disponibiliza bibliotecas específicas da aplicação. Basicamente códigos personalizados que não façam parte de models, controllers, views ou helpers (JUNQUEIRA, 2007, p. 98).
log/: Quando uma aplicação é rodada, ela gera automaticamente arquivos de Log, que são armazenados por padrão nesse diretório. Aqui ainda são encontrados três principais arquivos (development.log, test.log e production.log) que contém não apenas simples linhas com informações, mas, também trazem, estatísticas de tempo, informações de cache e expansões das expressões executadas pelo banco de dados (THOMAS & HANSSON, 2005, p. 226).
public/: Segundo Junqueira (2007, p. 98), “É o diretório disponível para o servidor Web. Contém subdiretórios para imagens, folhas de estilos e Javascripts”.
script/: Esse diretório engloba os programas (comandos/scripts) que serão utilizados pelos desenvolvedores. A maioria desses scripts são utilizados com argumentos para funcionarem (THOMAS & HANSSON, 2005, p. 227). Abordaremos alguns dos comandos de script com mais detalhes na Seção 4.6.
test/: Segundo Juqueira (2007, p. 98), Sempre que “[...] os scripts de geração são utilizados, arquivos de teste de modelo são criados e colocados neste diretório automaticamente”. Este diretório engloba “uma suíte completa de testes integrados” eles incluem testes unitários, de performance, funcionais, integração dentre outros (AKITA, 2006, p. 39).
tmp/: Esse diretório mantém “[...] arquivos temporários como cache, sessions e locks” (AKITA, 2006, p. 39).
vendor/: Segundo Akita (2006, p. 39), nesse diretório “[...] são instalados plugins e engines” para estender as funcionalidades do Rails.
4.6 Scripts do Ruby on Rails
Para facilitar o desenvolvimento das aplicações, o Ruby on Rails disponibiliza uma série de scripts (que ficam no diretório script/) para auxiliar na geração automática de código e aumentar a velocidade do desenvolvimento (JUNQUEIRA, 2007, p. 102). Alguns deles são detalhados abaixo.
console: Diz Junqueira (2007, p. 102) que este comando “[...] disponibiliza um console para a interação com o ambiente da aplicação Rails, no qual é possível interagir com o modelo do domínio”, testando métodos, inspecionando modelos e manipulando informações do banco de dados. destroy: Destrói arquivos autogerados pelo comando script/generate
(THOMAS & HANSSON, 2005, p. 227).
generate: Dito como o gerador de código. Ele pode criar controllers, models, scaffolds, mailers e Web Services. Com ele também é possível efetuar o download de geradores adicionais (THOMAS & HANSSON, 2005, p. 227).
Capítulo 4 Ruby on Rails – O Framework
server: Esse script roda um servidor Web que já está embutido em uma aplicação Rails, geralmente é utilizado quando a aplicação está sendo desenvolvida (THOMAS & HANSSON, 2005, p. 227).
4.7 Vantagens e desvantagens
Além das vantagens apresentadas até agora pode-se ainda citar segundo Thomas & Hansson (2005):
Rapidez e simplicidade no desenvolvimento de aplicações Web utilizando padrões de software atuais.
No Rails as complicações arquiteturais com bando de dados são esquecidas, pois ele resolverá todos os problemas de persistência.
Rails possui suporte a várias tecnologias Web, como por exemplo, a facilidade de trabalhar com e-mails, Web Services e Ajax.
Possui uma funcionalidade chamada “Migrations” que é responsável pela atualização ou rollbacks22 de banco de dados, facilitando assim o controle entre versões.
Possui uma funcionalidade chamada RJS – Ruby Javascript, que nada mais é que escrever Javascript e Ajax dentro das aplicações Rails utilizando a linguagem Ruby.
Apesar das grandes vantagens o Rails como qualquer outro software possui algumas desvantagens que segundo Baguley (2007) são:
Para fazer um pequeno software no Rails é muito simples, mas para desenvolver grandes aplicações é necessário dominar o framework conhecendo a fundo as suas facetas, ou seja, é necessário dedicar tempo no estudo do framework.
O Rails ainda não é difundido como outras tecnologias como TOMCAT, ASP.Net, etc. Isso em alguns casos dificultará o acesso a bibliotecas, grupos de discussão, fóruns.
22 Rollback faz com que as mudanças nos dados existentes sejão descartadas. Mais detalhes em:
Por não ser ainda tão difundido o Rails ainda não se integra a todos os Servidores Web existentes, isso pode ser uma dificuldade em grandes empresas.
As ferramentas que se integram ao Rails ainda são novas prejudicando o desenvolvimento mais eficiente de programadores já acostumados com IDE’s prontas com recursos como code-completion (complemento automático do código escrito).
4.8 Instalação
Existem diversas formas de se instalar o Rails, mas, após a instalação do Ruby (Seção 3.5) ficará disponível para o usuário um aplicativo de gerenciamento de pacotes denominado “gems”. Através desse gerenciador é possível proceder a instalação do Rails digitando no prompt de comando a seguinte expressão:
> gem install rails –include-dependencies
Após a execução do comando, o instalador acessará o site Ruby Forge23 e efetuará a instalação de todo módulo Rails e suas dependências. Após o termino do procedimento o Rails já estará instalado e pronto para o uso (TATE & HIBBS, 2006, p. 03).
Verifica-se então a enorme facilidade de se instalar o framework a partir do gerenciador de pacotes gems que já vem instalado por padrão na instalação da linguagem Ruby (Seção 3.5).
Capítulo 4 Ruby on Rails – O Framework
4.9 Aspectos práticos
Segundo Junqueira (2007), uma aplicação Rails pode ser criada seguindo quatro passos básicos ilustrados na Figura 4.4.
Figura 4.4 – Passos para a criação de Aplicações Web com Ruby on Rails
Fonte: JUNQUEIRA, 2007
Seguindo os passos apresentados na Figura 4.4, e utilizando-a como roteiro para criação de uma aplicação Web com Ruby on Rails, deve-se considerar que:
Criação do banco de dados: “Esta etapa consiste em criar o banco de dados da aplicação”. Nessa etapa considera-se que o usuário saiba manipular o seu banco de dados preferido e que o mesmo tenha permissão para efetuar os procedimentos de criação do banco de dados.
Criação da estrutura padrão: Após a instalação do framework, “o comando rails pode ser utilizado para criar uma aplicação”. A utilização deste comando é bastante simples, resumindo-se a apenas digitar “rails <nome_da_aplicação>” para que seja gerada a estrutura de diretórios padrão (Seção 4.5) baseado no nome da aplicação.
Configuração do banco de dados: Depois de efetuado os dois primeiros passos para a criação de uma aplicação em Ruby on Rails, deve-se configurar o banco de dados que a aplicação vai utilizar, através do arquivo “config/database.yml” onde é possível definir os parâmetros de acesso ao banco de dados. Criação do banco de dados Criação da estrutura padrão Configuração do banco de dados Criação de scaffolding
Criação de scaffolding: “É sugerida a utilização de scaffolding24 para agilizar a criação de aplicações”. Para tanto basta utilizar o comando “ruby script/generate scaffold <nome_da_tabela>”. Dessa forma, após a execução do comando supracidato, o desenvolvedor já desfrutará das operações básicas (inserção, deleção, edição, visualização) para sua tabela (JUNQUEIRA, 2007, p. 102-103).
Após seguir os passos citados na Figura 4.4 e descritos no parágrafo anterior, pode-se executar o comando “ruby script/server” para a inicialização do servidor HTTP (por padrão o servidor WebRick é iniciado) que vem embutido nas aplicações Rails. Assim será possível acessar a aplicação através de um browser.
4.9 Discussão
Nesse capítulo percebe-se a enorme capacidade do Rails produzir aplicações com alto nível de produtividade, tornando assim o processo de desenvolvimento um ato ágil.
Pode-se observar também que o framework Rails é bem organizado utilizando vários scripts de geração e manipulação de código, e uma estrutura de pastas para acomodar todo o projeto que está sendo utilizado, isto facilita a manutenção e torna o projeto mais portável visto que toda estrutura pode ser copiada para qualquer computador e utilizada sem nenhum empecilho.
O Ruby on Rails mostra-se um framework completo, autogerando as três camadas do MVC de forma explícita e possibilitando também que o desenvolvedor possa manipular tais camadas, facilitando dessa forma a integração com outras tecnologias que venham a ajudar na criação de aplicações RIA.
Capítulo 5 Adobe Flex – O Framework
CAPÍTULO 5 - ADOBE FLEX – O FRAMEWORK
5.1 Introdução
Segundo a Adobe (2007), o Adobe Flex ou simplesmente Flex, “[...] é um framework multiplataforma dotado de um ambiente para desenvolvimento de aplicações ricas para Internet”, atualmente ele utiliza o Flash Player25 9 ou superior, para “permitir muitas experiências intuitivas e on-line”.
Flex se integra facilmente a diversas tecnologias tais como: PHP, Ruby, ColdFusion, JSP (Java Server Pages), entre outras. (FAIN, 2007, p 05).
Este capítulo pretende apresentar o framework Adobe Flex de forma a apresentar as definições, características, histórico, vantagens e desvantagens de cada um dos elementos envolvidos para o desenvolvimento de aplicações RIA com esse framework.
5.2 Histórico
Em 1996, depois de se juntar a Futurewave – uma antiga empresa de software –, a então empresa Macromedia lança a primeira versão do Macromedia Flash – um programa para criação de animações vetoriais para a Internet – e conseqüentemente o Flash Player que mais tarde tornar-se a base para o Adobe Flex (WIKIPEDIA, 2007).
Depois de várias versões e uma alta aceitação pelos internautas e browsers da época, a Macromedia lança em setembro de 2003 o Flash Palyer 7. Em março de 2004 é lançado a primeira versão do Flex (WIKIPEDIA, 2007).
Um detalhe muito importante é que em sua primeira versão o Flex necessitava de um servidor para poder funcionar nos browsers dos clientes, isso era um grande agravante que comprometia o seu crescimento, pois, um único servidor custava em torno de U$ 15.000,00 (WIKIPEDIA, 2007).
25 Flash Player é um programa distribuído pela Adobe Systems para executar arquivos no formato SWF. Mais
Em agosto de 2005 é lançada a versão 8 do Flash Player, nela foram feitas várias modificações internas que tornaram possível o Flex ser suportando nativamente no Flash Player. Nessa mesma época a Macromedia é comprada pela Adobe. A empresa então passa a se chamar Adobe Systems (WIKIPEDIA, 2007).
Em Junho de 2006 o Adobe Flex 2 é lançado juntamente com Flash Player 9, que foi totalmente reescrito, utilizando agora uma nova estrutura e suportando a mais nova linguagem de programação, o Action Script 3, com novas funcionalidades e facilidades para o desenvolvedor. Juntamente com ele, sua licença passou a ser gratuita e acessível a qualquer pessoa através do Adobe Flex 2 SDK (WIKIPEDIA, 2007).
5.2 Características
Nesta seção aborda-se algumas características do Adobe Flex. A Figura 5.1 demonstra a arquitetura do framework.
Figura 5.1 – Arquitetura de uma aplicação Flex
Fonte: BROWN, 2007
Para que se compreenda melhor, algumas das partes do Framework serão analisadas separadamente.
