Integrando Frameworks para Desenvolvimento de Aplicações RIA (Rich Internet Applications) com Ruby On Rails e Adobe Flex Utilizando a Arquitetura MVC

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 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 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 i

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. Paulo Afonso - BA NOV / 2007 ii

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. iii

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. A todos meu sincero agradecimento. iv

"Aprender é a única coisa de que a mente nunca se cansa, nunca tem medo e nunca se arrepende. (Leonardo da Vinci) v

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. Palavras-chaves: RIA, desenvolvimento Web, Adobe Flex, Ruby on Rails. vi

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. Keywords: RIA, Web development, Adobe Flex, Ruby on Rails. vii

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.14 Tela de pesquisa... 58 Figura 6.15 Tela principal e de listagem de documentos... 59 Figura 6.16 Funções HTTPService... 60 viii

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 ix

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 x

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 xi

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 REFERÊNCIAS BIBLIOGRÁFICAS... 68 xii

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 standalone 1. 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 desktop 2 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> 1

Capítulo 1 Introdução 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 frameworks 3 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. 3 Conjunto de programas e rotinas que facilitam o desenvolvimento de uma aplicação. Mais detalhes em: <http://pt.wikipedia.org/wiki/framework> 2

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 HTML 4, 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> 3

Capítulo 1 Introdução 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 exigências do software do que com detalhes tediosos de baixo nível do sistema, deixando-o organizado e de fácil expansão (FRANCO, 2007). 4

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. 5

Capítulo 1 Introduçã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. 6

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. 7

Capítulo 2 A Arquitetura MVC 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). 8

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 Wikipedia 5, 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. 5 Enciclopédia eletrônica disponível em: http://pt.wikipedia.org/wiki/mvc 9

Capítulo 2 A Arquitetura MVC 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). Camada de apresentação ou visualização Camada de lógica de negócios Camada de acesso a dados 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. 10

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. Entradas, ex: Teclado e mouse Controller View Mensagens Mensagens Model Figura 2.2 Modelo MVC Fonte: GIMENES & HUZITA, 2005 11

Capítulo 2 A Arquitetura MVC 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. 12

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 Source 6. 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 parte da 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 13

Capítulo 3 Ruby A Linguagem 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; Controle de acesso: em Ruby há três tipos de acesso aos métodos: público, privado e protegido; 14

Capítulo 3 Ruby A Linguagem Multi-threading 7 : 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 UNICODE 8 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 download 10 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> 10 Significa descarregar. Mais informações em: http://pt.wikipedia.org/wiki/download 15

Capítulo 3 Ruby A Linguagem 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). Figura 3.2 Comando ruby v para verificar a versão instalada do Ruby 16

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. 17

Capítulo 4 Ruby on Rails O Framework 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 RubyOnRails 11 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. 11 Disponível em: <http://www.rubyonrails.com.br>. Acessado em: 10 out. 2007 18

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); 19

Capítulo 4 Ruby on Rails O Framework 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 SQL 12 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 blog 13 que receba as matérias através de e-mail, não precisando que o usuário efetue seu login 14 no site para poder enviar a mensagem (JUNQUEIRA, 2007, p. 95). 12 SQL é uma linguagem de pesquisa declarativa para banco de dados relacional. Mais detalhes em: <http://pt.wikipedia.org/wiki/sql> 13 é uma página da Web cujas atualizações são organizadas cronologicamente de forma inversa. Mais detalhes em: <http://pt.wikipedia.org/wiki/blog> 14 É a ação necessária para acessar um sistema computacional restrito. Mais detalhes em: <http://pt.wikipedia.org/wiki/login> 20

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 template 15 ). 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> 21

Capítulo 4 Ruby on Rails O Framework 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-paraum, 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. 22

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 APIs 16 de Web Service 17 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, cache 18, logs 19, plugins 20 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> 20 Plugin ou Plug-in é um termo que significa "de encaixe". Mais detalhes em: <http://pt.wikipedia.org/wiki/plugin> 23

Capítulo 4 Ruby on Rails O Framework É 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. Minha_App README Rakefile app/ components/ config/ db/ doc/ lib/ log/ public/ script/ test/ tmp/ vendor/ Informações de instalação e uso Gerador de Scripts Arquivos do Model, View e Controller estão aqui Componentes reusáveis Parâmetros de conexão com o BD e configurações Informação de Shema e migrações Documentação com geração automática Código compartilhado Arquivos de Log gerados por sua aplicação Diretório acessado da Web. Sua aplicação é rodada aqui Scripts utilitários Testes unitários, funcionais e de integração, fixtures e mocks Arquivos temporários em tempo de execução Código importado 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 diretórios envolvidos: 24

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. 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 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). 25

Capítulo 4 Ruby on Rails O Framework 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 roteamento 21, 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/. 21 Ato de rotear/encaminhar encaminhar para determinada rota. Mais detalhes em: <http://pt.wikipedia.org/wiki/roteador> 26

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. 27

Capítulo 4 Ruby on Rails O Framework 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). 28

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 rollbacks 22 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: <http://pt.wikipedia.org/wiki/sql> 29

Capítulo 4 Ruby on Rails O Framework 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 Forge 23 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). 23 Disponível em: http://rubyforge.org/ 30

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. Criação do banco de dados Criação da estrutura padrão Configuração do banco de dados Criação de scaffolding 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. 31

Capítulo 4 Ruby on Rails O Framework Criação de scaffolding: É sugerida a utilização de scaffolding 24 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. 24 O termo scaffolding é usado em programação para indicar que o código a que se refere é apenas um esqueleto usado para tornar a aplicação funciona. Mais detalhes em: <http://pt.wikipedia.org/wiki/scaffolding> 32

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 Player 25 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 detalhes em: <http://en.wikipedia.org/wiki/adobe_flash_player> 33

Capítulo 5 Adobe Flex O Framework 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. 34

Capítulo 5 Adobe Flex O Framework 5.2.1 MXML Segundo Brown (2007, p. 25), MXML Macromedia Extentible Markup Language é uma linguagem baseada em XML que proporciona um fácil caminho para declarar e gerenciar elementos visuais em uma aplicação. O MXML assim como o XML possibilita a estruturação da sua aplicação. Com o MXML é possível adicionar transições entre páginas e também adicionar diversos efeitos visuais a componentes de tela (BROWN, 2007, p. 26). Um outro ponto interessante é que o MXML possibilita o uso de folhas de estilos para melhorar a forma de gerenciar cores e estilos dos componentes envolvidos no projeto (BROWN, 2007, p. 26). Dessa maneira será possível organizar uma página de forma estruturada e sofisticada, permitindo um layout moderno e uma interface visual com efeitos e comportamentos, possibilitando assim novas formas de interação com o usuário (BROWN, 2007, p. 26). 5.2.1 Action Script 3.0 Apenas com o MXML não seria possível desenvolver aplicações dinâmicas, pois o MXML é apenas uma linguagem de marcação como visto no tópico anterior, dessa forma, o Action Script complementa o desenvolvimento de um sistema. Segundo Brown (2007, p. 26), Com Action Script você poderá adicionar interação dinâmica entre componentes. O Action Script possibilita o desenvolvedor trabalhar com loops de programação, variáveis, métodos e diversas outras possibilidades disponíveis nessa linguagem. Pode-se pensar em Action Script como um grupo de objetos que carregam tarefas, respondem a eventos que se comunicam um com os outros (ADOBE, p. 35). Em outras palavras, o MXML ao ser compilado para um arquivo de formato SWF 26 (Small Web File) transformando-se em Action Script para poder ser interpretado pelo compilador. 26 SWF é o formato de arquivo gerado pelo Adobe Flash. Mais detalhes em: <http://pt.wikipedia.org/wiki/swf> 35

Capítulo 5 Adobe Flex O Framework 5.3 Programação Dirigida a Eventos Programação Dirigida a Eventos ou Event Driven Programming é um dos grandes paradigmas que o Flex traz ao desenvolvedor. Assim como o paradigma de desenvolvimento Orientado a Objetos existe a Programação Dirigida a Eventos, que traz em seu método características que diferem do modelo seqüencial adotado em outros modelos de desenvolvimento. Diferentemente de um modelo de programação seqüencial, em que primeiro uma linha é executada, e depois outra, e depois outra, em um modelo Event Driven Programming as execuções são assíncronas. Isso possibilita a execução de várias tarefas ao mesmo tempo, tornando a aplicação mais dinâmica. 5.4 Instalação A instalação do Flex é feita de forma simples, bastando apenas que o usuário efetue o download e faça a instalação conforme procedimentos mostrados a seguir. Ao tentar efetuar o download no site do fabricante (http://flex.org/download/) nota-se que existem duas opções, uma conhecida como Flex SDK (Software Development Kit) e outra conhecida como Flex Builder. O primeiro deles, o Flex SDK, que é gratuito, traz consigo componentes do Flex (como os controles de entrada de dados, de layout, etc) e o compilador, que transforma o código fonte no arquivo SWF final. Apenas com ele já é possível criar aplicações. O segundo disponível é o Flex Builder, que além de já ter o SDK, oferece também uma IDE (Integrated Development Environment), um ambiente de desenvolvimento integrado, com ajudas de contexto durante o desenvolvimento, visão em modo design, depuração e afins. O Flex Builder é pago, mas há uma versão de demonstração disponível. O Flex Builder foi desenvolvido em cima da plataforma Eclipse, o que para muitos facilita o aprendizado, já que outras IDEs se baseiam nele também (BROWN, 2007, p. 7-10). 36

Capítulo 5 Adobe Flex O Framework O Flex Builder é construído como um plugin para o Eclipse, que já é um ambiente de desenvolvimento muito sólido e consagrado principalmente para a linguagem de programação Java. Há diversos plugins para o Eclipse que dão a ele a capacidade de servidor de editor de código para diversas linguagens, bem como ferramentas de produtividade, como acesso a banco de dados, controle de versão e afins (BROWN, 2007). Segundo Brown (2007, p. 7), após efetuar o download do Flex Builder no site do fabricante (http://flex.org/download/) ou inserir o CD comprado, pode-se inicar a instalação seguindo os seguintes passos: Seleciona-se a pasta onde ficarão os arquivos temporários de instalação. A opção padrão é C:\Program Files\Flex 2 conforme Figura 5.2. Figura 5.2 Tela Inicial de Instalação Fonte: BROWN, 2007 Depois de escolher a pasta pressiona-se Next para continuar a instalação. 37

Capítulo 5 Adobe Flex O Framework Na próxima etapa aparece a tela representada pela Figura 5.3 onde será possível optar por duas escolhas. A opção Flex Builder and Flex SDK deve ser selecionada se o usuário não possuir o Eclipse instalado no seu computador. Já a opção Flex Builder Plug-in and Flex SDK deve ser selecionada apenas se o usuário já tiver a plataforma Eclipse instalado em seu computador. Geralmente utiliza-se a primeira opção. Figura 5.3 Escolhendo a opção de Instalação Fonte: BROWN, 2007 Na próxima tela será mostrado um termo de licença de uso para ser aceito pelo o usuário. O próximo passo é escolher a pasta onde será instalado o Flex Builder, como mostrado na Figura 5.4. Pressiona-se Next para continuar. 38

Capítulo 5 Adobe Flex O Framework Figura 5.4 Selecionando o local de instalação Fonte: BROWN, 2007 Na próxima tela, mostrada Figura 5.5, pode-se selecionar em quais navegadores de Internet o Flash Player 9 será instalado. O Flex funciona apenas com a versão 9 ou superior do Flash Player. 39

Capítulo 5 Adobe Flex O Framework Figura 5.5 Instalando o Flash Player para cada browser Fonte: BROWN, 2007 Pressiona-se Next e será mostrado (Figura 5.6) um resumo das ações que o instalador irá tomar. 40

Capítulo 5 Adobe Flex O Framework Figura 5.6 Tela de confirmação antes da instalação Fonte: BROWN, 2007 Clica-se no botão Install e a instalação será feita com tudo que é necessário para desenvolver aplicações RIA no Flex. 5.5 Aspectos práticos Após efetuar a instalação do Flex Builder, como mostrado na Seção 5.4, pode-se então criar uma aplicação. Para iniciar uma aplicação Flex, deve-se antes criar um projeto Flex, assim o Flex se encarregará de criar a estrutura mínima (com pastas e arquivos) para o funcionamento do projeto (BROWN, 2007, p. 29). Segundo Brown (2007, p. 29-31), segue-se os seguintes passos para a criação de um novo projeto: 41

Capítulo 5 Adobe Flex O Framework Após abrir o Flex clique a seqüência no menu: File > New > Flex Project. Será mostrada a caixa de diálogo (Figura 5.7) onde é possível selecionar a tecnologia utilizada para o projeto, nesse caso selecione um projeto Basic e pressione Next. Figura 5.7 Caixa de diálogo de um novo projeto Flex Fonte: BROWN, 2007 O próximo passo (Figura 5.8) é digitar o nome do projeto, nesse caso foi digitado ProjetoTeste. Deve-se atentar para não utilizar um nome de projeto já utilizado anteriormente, nem utilizar nome de projetos com espaços em branco no final. É possível clicar Next para adicionar mais informações, mas, por hora, pressiona-se Finish para finalizar a criação do projeto. 42

Capítulo 5 Adobe Flex O Framework Figura 5.8 Obtendo o nome do projeto Fonte: BROWN, 2007 Nesse momento o projeto será criado e o Flex estará pronto para ser utilizado com um novo projeto. Essa seção não demonstrará detalhes de desenvolvimento, a mesma será descrita no Capítulo 6. 5.6 Discussão O Adobe Flex mostra-se uma ferramenta de alto nível para o desenvolvimento de aplicações, pois o mesmo traz em sua plataforma um poderoso IDE que ajuda bastante o desenvolvedor a criar e manter o software concebido através dele. A IDE também possibilita desenvolver interfaces amigáveis ao usuário de forma rápida e eficiente, facilitando o desenvolvimento de aplicações RIA. 43

Capítulo 5 Adobe Flex O Framework Pode-se notar nesse capítulo que o Adobe Flex é um framework novo no mercado, mas que já possui uma história trilhada junto aos seus fabricantes. O Flex gera um arquivo SWF, que é multiplataforma, e pode ser rodado em qualquer Sistema Operacional, tornando-o uma plataforma de fácil integração em qualquer ambiente corporativo devido ao seu alto grau de adaptação em sistemas operacionais variados. 44

Capítulo 6 Estudo de Caso CAPÍTULO 6 - ESTUDO DE CASO 6.1 Introdução Este capítulo pretende mostrar como proceder à integração dos dois frameworks apresentados nas Seções anteriores, utilizando para isso o desenvolvimento de uma aplicação RIA como estudo de caso. A aplicação desenvolvida utilizará recursos dos dois frameworks apresentados nos capítulos anteriores. O Ruby on Rails será utilizado como base para o lado servidor, funcionando como o Model e o Controller na arquitetura MVC e o Adobe Flex será utilizado como a camada View desse mesmo modelo de desenvolvimento, servindo como lado cliente. Todo o software desenvolvido nesse capítulo estará disponível para download 27 em: <http://jacksonpires.blogspot.com/2007/11/bddoc-banco-de-dadosde-documentos.html>, para que seja possível a observação de todo o código fonte gerado, pois as Seções que se seguem abordam apenas os principais pontos do sistema no que diz respeito à integração dos frameworks abordados. 6.2 Estrutura Básica da Aplicação Piloto A aplicação piloto terá como base uma aplicação rica para Internet RIA onde será desenvolvido um sistema de cadastro de documentos. Esse cadastro é caracterizado pela possibilidade do usuário poder cadastrar, categorizar, pesquisar e efetuar o download de todo tipo de documento que a Faculdade Sete de Setembro (FASETE) possua em forma digital. O sistema denominado de Banco de Dados de Documentos BDDOC possuirá um módulo de cadastro de documentos, onde será possível cadastrar o documento, bem como, enviar o mesmo no formato digital para ser disponibilizado posteriormente aos usuários do sistema. No BDDOC, será possível pesquisar um determinado documento por tipo, autor ou palavra-chave. Assim, após encontrar o documento pesquisado, o usuário poderá efetuar o download do mesmo. 27 Download é a transferência de dados de um computador remoto para um computador local. Mais detalhes em: < http://pt.wikipedia.org/wiki/download> 45

Capítulo 6 Estudo de Caso A principal idéia do sistema é que ele possa oferecer aos seus usuários uma forma rápida de pesquisa a documentos que já foram publicados pela instituição, facilitando a elaboração de novos trabalhos que venham a ser desenvolvido no mesmo ramo em que o usuário esteja interessado, servindo também como documentos para referência bibliográfica de trabalhos desenvolvidos pelos mesmos. Dessa forma será possível demonstrar a integração dos dois frameworks para o desenvolvimento de uma aplicação RIA, bem como a utilização do padrão de projeto MVC. 6.2.1 Funcionalidades da Aplicação Piloto Conforme a Seção 6.2 pode-se indicar com mais detalhes as funcionalidades da aplicação que será desenvolvida, seguindo: Módulo para cadastro dos documentos: deve armazenar o Nome, Autor, Área do documento (Ex: Marketing, Letras, Direito, etc), Tipo (Ex: Monografia, TCC, Trabalho, Plano de Negócio, etc), Palavras-Chave, Sinopse e Arquivo no formato digital (que deverá ser submetido no cadastro). Módulo para pesquisa de documentos: deverá ser possível pesquisar o documento por Autor, Descrição, Palavra-Chave, Área ou Tipo. Módulo Principal: esse módulo deve mostrar uma listagem dos documentos cadastrados para que seja possível efetuar o download do documento selecionado. Em todos os módulos serão armazenadas a data e hora em que o documento, autor ou tipo foi cadastrado e a data e hora da última atualização efetuada. Para isso existirão os campos Created_at e Updated_at, que são convenções utilizadas pelo Ruby on Rails para esse tipo de ação. 46

Capítulo 6 Estudo de Caso 6.3 Definindo o padrão de comunicação entre os frameworks Visto que na aplicação RIA desenvolvida será utilizado o padrão de projeto MVC, fica definido que a camada Model e a camada Controller serão desenvolvidos com o framework Ruby on Rails, e que a camada View será desenvolvida com o framework Adobe Flex (Figura 6.1). Entradas, ex: Teclado e mouse Controller View Mensagens Mensagens Model Adobe Flex Ruby on Rails Figura 6.1 Separação da aplicação na arquitetura MVC 28 Dessa forma o sistema obedecerá aos padrões de projeto MVC e mensagens serão trocadas entre as três camadas formalizando assim o padrão de projeto utilizado. Segundo a Coenraets (2007), o Adobe Flex possui algumas maneiras de acessar dados externos, conhecidos como lado servidor, server-side ou back-end. São elas: HTTPService: Com esse tipo de conexão é possível enviar requisições HTTP 29 convencionais para o servidor e consumir a resposta. Embora o HTTPService possa consumir diversos tipos de resposta, o mais utilizado é o XML. 28 Essa figura é de minha autoria, necessária para entender o a separação lógica da aplicação. 29 HTTP é a sigla em língua inglesa de HyperText Transfer Protocol (Protocolo de Transferência de Hipertexto). Mais detalhes em: <http://pt.wikipedia.org/wiki/http> 47

Capítulo 6 Estudo de Caso RemoteObject: Com esse tipo de conexão o cliente pode invocar métodos disponíveis na aplicação e consumir os resultados desses métodos. WebService: Com esse tipo de conexão o cliente pode invocar métodos disponíveis através de Web Services na aplicação e consumir o valor de retorno desses métodos. Contudo, embora as três possuam funcionalidades e características distintas, assim como manipulam a conexão de diferentes formas, as conexões com o servidor dos três componentes são feitas sobre o potocolo HTTP ou HTTPS (COENRAETS, 2007). O padrão escolhido para a aplicação piloto foi o HTTPService por se tratar de uma classe que manipula requisições básicas HTTP, que é o protocolo básico de comunicação para a Web, facilitando o processo de desenvolvimento da aplicação. 6.4 Características do HTTPService Segundo a Coenraets (2007), o HTTPService possibilita conexões HTTP, nos mesmos moldes que um navegador convencional, fazendo uma requisição, e recebendo uma resposta. Ou seja, é possível tanto enviar informações (como o preenchimento de um formulário), quanto receber informações (como receber uma lista de funcionários). Pela flexibilidade, facilidade e padronização, é conveniente receber os dados em formato XML, mais fáceis de lidar do que um texto sem formatação. Com o HTTPService é possível enviar requisições à qualquer tipo de server-side, facilitando a comunicação com o Rails por exemplo (COENRAETS, 2007). Segundo a Adobe (2007), a tag 30 <mx:httpservice> pode ser utilizada para receber facilmente dados externos a uma aplicação Flex. Geralmente são utilizados os métodos POST e GET 31 para fazer requisições a dados externos. A Figura 6.2 demonstra um exemplo do ciclo de comunicação utilizando HTTPService que será utilizada durante a aplicação piloto. 30 São estruturas de linguagem de marcação que consistem em breves instruções, tendo uma marca de início e outra de fim. Mais detalhes em: < http://pt.wikipedia.org/wiki/tag> 31 Método determina o que o servidor deve fazer com o URL fornecido no momento da requisição de um recurso. Mais detalhes em: < http://pt.wikipedia.org/wiki/http> 48

Capítulo 6 Estudo de Caso 1 Na camada View (Adobe Flex) o usuário solicita uma pesquisa e clica no botão Pesquisar. 2 Ao clicar no botão Pesquisar é disparada uma função HTTPService do Adobe Flex que envia através de HTTP a requisição para um método do Controller no Ruby on Rails. 3 Depois de processado o método pesquisa o Controller devolve um XML para a View (Adobe Flex.) Figura 6.2 Exemplo do ciclo de comunicação utilizando HTTPService 32 Segundo a Adobe (2007), para utilizar a tag <mx:httpservice>, basta declará-la logo após a tag <Application>, como mostrado no código abaixo: 32 Essa figura é de minha autoria, necessária para entender o ciclo de uma requisição HTTPService da aplicação. 49

Capítulo 6 Estudo de Caso <mx:httpservice id="feedrequest" url="http://www.seusite.com/lista.rhtml"/> A propriedade id refere-se ao identificador da tag, facilitando a identificação do componente para o futuro uso. A propriedade URL refere-se ao endereço da Internet onde está disponível a informação a ser consumida (ADOBE, 2007). Mais detalhes de implementação serão vistos nas próximas Seções, ao decorrer do desenvolvimento da aplicação piloto. 6.5 Desenvolvendo o Server-Side Por tudo que foi exposto nos Capítulos anteriores pode-se entender que, o server-side consiste em toda a parte da aplicação que rodará no lado do servidor, e compreenderá o Model e o Controller quando utilizamos o padrão arquitetural MVC. Como comentado na Seção 6.3, o server-side será desenvolvido utilizando o framework Ruby on Rails. Visto que o escopo do trabalho não envolve conhecimentos em banco de dados, e tomando como base o banco de dados MySQL já configurado, e a base de dados bddoc_development, bem como as tabelas criadas conforme o diagrama Entidade Relacionamento (Figura 6.3), pode-se iniciar a aplicação piloto. É fácil notar no diagrama (Figura 6.3) que os documentos são compostos por áreas e tipos, que são cadastrados separadamente. 50

Capítulo 6 Estudo de Caso Figura 6.3 Diagrama Entidade Relacionamento BDDOC 33 Para iniciar a aplicação piloto utiliza-se o comando rails bddoc para gerar a estrutura básica como visto na Seção 4.8. Esse comando gerará toda a estrutura do server-side (Figura 6.4). Figura 6.4 Estrutura de Pastas da Aplicação Piloto BDDOC 34 33 Essa figura é de minha autoria, necessária para entender o diagrama ER da aplicação. 34 Essa figura é de minha autoria, necessária o leitor visualizar as pastas geradas pela aplicação. 51

Capítulo 6 Estudo de Caso Após a geração da estrutura de pastas do BDDOC, configura-se o acesso ao banco de dados através do arquivo database.yml disponível na pasta config/ (AKITA, 2006). A configuração do arquivo database.yml (Figura 6.5) é baseada na etapa em que a aplicação se encontra, nesse caso o importante é configurar o bloco development, pois o estágio inicial do ambiente é o de desenvolvimento por padrão (AKITA, 2006). Figura 6.5 Edição do arquivo database.yml Fonte: Arquivo database.yml da aplicação BDDOC, 2007 52

Capítulo 6 Estudo de Caso Após a configuração do banco de dados foram rodados os comandos ruby script/generate model documento, ruby script/generate model tipo e ruby script/generate model area, para que fossem gerados os modelos (models) que representam o banco de dados, como visto na Seção 2.4. Logo depois de gerados os modelos, fez-se necessário a configuração dos arquivos: documento.rb (Figura 6.6), area.rb (Figura 6.7) e tipo.rb (Figura 6.8), conforme Seção 4.4.3, para que o framework Ruby on Rails pudesse mapear o banco de dados, disponibilizando assim todos os métodos necessários para a manipulação dos mesmos na aplicação. Os arquivos estão disponíveis na pasta app/models/. Figura 6.6 Configuração do arquivo documentos.rb Fonte: Arquivo documento.rb da aplicação BDDOC, 2007 Figura 6.7 Configuração do arquivo area.rb Fonte: Arquivo area.rb da aplicação BDDOC, 2007 53

Capítulo 6 Estudo de Caso Figura 6.8 Configuração do arquivo tipo.rb Fonte: Arquivo tipo.rb da aplicação BDDOC, 2007 Após a configuração dos arquivos citados no parágrafo anterior, foi rodado o comando ruby script/generate scaffold tipo, ruby script/generate scaffold area e ruby script/generate scaffold documento, para que pudessem ser geradas as estruturas CRUD 35 para as tabelas, sendo possível cadastrar os tipos e as áreas que estarão disponíveis no cadastro de um novo documento. Para verificar o sucesso dos comandos rodados, é possível executar o comando ruby script/server (Seção 4.8) para iniciar o servidor Web e depois acessar os endereços http://localhost:3000/tipos (Figura 6.9), http://localhost:3000/areas (Figura 6.10) e http://localhost:3000/documentos (Figura 6.11), através de um navegador de Internet, comprovando assim a existência do cadastro de tipos, áreas e documentos. 35 CRUD é o acrônimo da expressão em língua Inglesa Create, Retrieve, Update e Destroy, usada para definir quatro operações básicas usadas em bancos de dados relacionais. Mais detalhes em: <http://pt.wikipedia.org/wiki/crud> 54

Capítulo 6 Estudo de Caso Figura 6.9 Listagem de tipos Fonte: Navegador Firefox com a aplicação BDDOC rodando, 2007 Figura 6.10 Listagem de áreas Fonte: Navegador Firefox com a aplicação BDDOC rodando, 2007 55

Capítulo 6 Estudo de Caso Figura 6.11 Listagem dos documentos Fonte: Navegador Firefox com a aplicação BDDOC rodando, 2007 Como é possível notar, a aplicação já funciona em parte, visto que nesse momento a mesma dispõe do cadastro de tipos, áreas e documentos. No entanto, o cadastro de documentos não funciona corretamente, já que o mesmo não obtém os nomes dos tipos e áreas cadastradas automaticamente, nem possibilita o usuário submeter arquivos para que sejam armazenados no servidor. Assim, na próxima seção desenvolve-se toda estrutura para o módulo de cadastro de documentos e pesquisa do lado cliente (client-side), utilizando o Adobe Flex. Além dos passos descritos nessa seção, serão necessários a criação de alguns métodos no controller documentos (documentos_controller.rb), o mesmo está disponível na pasta app/controllers/ e todo o seu conteúdo está disposto no arquivo app/controllers/documentos_controller.rb. 6.6 Desenvolvendo o Client-Side Para iniciar o desenvolvimento do client-side utilizando o Adobe Flex como plataforma de uma aplicação RIA, deve-se analisar a estrutura de diretórios gerada pelo framework rails. Então, conforme Seção 4.5, utiliza-se à pasta public/ para ser a pasta raiz onde estará localizado o projeto do Adobe Flex. 56

Capítulo 6 Estudo de Caso Logo após essa análise pode-se criar o projeto no Adobe Flex conforme Seção 5.5, atentando apenas para o local onde será criado o projeto, o mesmo deve ser a pasta public/ do projeto BDDOC (Figura 6.12). Figura 6.12 Criação do projeto na pasta public Fonte: Adobe Flex Builder, 2007 Após criar o projeto inicial no Adobe Flex, deve-se criar toda estrutura de janelas, correspondente aos módulos citados na Seção 6.2.1. Essa estrutura compreende: Cadastro de documentos (Figura 6.13), Pesquisa de documentos (Figura 6.14) e Tela principal com listagem de documentos (Figura 6.15) 57

Capítulo 6 Estudo de Caso Figura 6.13 Tela de cadastro de documentos Fonte: Adobe Flex Builder, 2007 Figura 6.14 Tela de pesquisa Fonte: Adobe Flex Builder, 2007 58

Capítulo 6 Estudo de Caso Figura 6.15 Tela principal e de listagem de documentos. Fonte: Adobe Flex Builder, 2007 O próximo passo, depois da criação de toda a estrutura visual, é, efetivar de fato, o cadastro de documentos. 6.6.1 Efetivando o cadastro de documentos Depois de criada as telas citadas na Seção 6.6, devem-se adicionar as funcionalidades aos componentes que trarão os nomes dos tipos e áreas para serem cadastrados durante o registro de um documento. Para esse feito, serão utilizadas duas funções: pesquisaarea() e pesquisatipo() (Figura 6.16), que disparam um HTTPService, com o intuito de retornar uma lista de tipos e áreas (no formato XML) para que sejam preenchidos nos componentes de tela (Figura 6.17). 59

Capítulo 6 Estudo de Caso Figura 6.16 Funções HTTPService. Fonte: Arquivo NovoDocumento.as da aplicação BDDOC, 2007 Figura 6.17 Componentes de tela preenchidos com o retorno do HTTPService. Fonte: Tela de cadastro do novo documento na aplicação BDDOC, 2007 60