Criação de uma framework para desenvolvimento
colaborativo
Luís Filipe Medeiro Costa
Dissertação submetida como requisito parcial para obtenção do grau de
Mestre em Engenharia de Telecomunicações e Informática
Orientador:
Prof. Doutor Carlos Manuel Jorge da Costa,
ISCTE-IUL
RESUMO
Num mundo em que a evolução das aplicações se tornou uma prioridade é essencial para o seu desenvolvimento que as ferramentas correspondentes possam acompanhar este crescimento.
Este artigo baseia-se numa investigação feita como dissertação de mestrado em que o seu grande foco central é a evolução de uma framework para construção de Rich Internet
Applications (RIAs), na sua utilização e resultados obtidos.
O desenvolvimento em equipa, por vezes pode tornar-se bastante complicado quando pensamos em aplicações de grandes dimensões. Neste tipo de aplicações, o mais importante a considerar antes do inicio do desenvolvimento da mesma, para além das tecnologias que irão ser utilizadas, é a sua arquitectura e estruturação, para que o desenvolvimento conjunto da mesma possa ser feito em sincronia e sem entrar em conflitos aquando o código é cometido para repositórios. Como tal a utilização de uma framework que normalize a estruturação do código por ficheiros torna-se essencial, só assim é possível desenvolver uma aplicação de uma forma mais eficiente e coesa.
Como desenvolvedor de RIAs, utilizando o Adobe Flex, decidi estudar mais aprofundadamente a framework Mate. Sendo que esta é uma estrutura baseada nos eventos e mapas de eventos, adaptou-se a mesma utilizando conceitos que eram usados em frameworks da primeira geração.
Para complementar esta investigação, foi criada também uma aplicação que apenas configurando os nomes de mapas, gestores, eventos e respectivas variáveis, cria logo toda a estrutura já com a maior parte do código incluído, gravando também um ficheiro de configurações, para quem em futuras versões da aplicação esta estrutura possa também ser utilizada para outras linguagens.
PALAVRAS CHAVE
Web Applications; Rich Internet Application (RIA); Actionscript; ; Soluções open-source e workflow para desenvolvimento de RIAs; Cairngorm; Mate; framework; Padrões de desenho;
ABSTRACT
In a world where the development of applications has become a priority is essential to its development as the corresponding tools to accompany this growth.
This article is based on a research done as a dissertation of a masters degree in which the big focus is the evolution and development of a framework, for building Rich Internet
Applications (RIAs), in its utilization and the obtained results.
The development in team, sometimes, can be very complicated when we talk about applications of big dimensions. In this kind of applications, the most important to consider before the beginning of the development of the same, beyond the technologies that will be used, it’s his architecture and structure, so that the collaborative development can be made in synchrony and without conflicts when the code is committed to repositories. So, the utilization of a framework that normalizes the structure of the code by logical files it’s essential to make possible to develop an application in a more efficient and correct form.
As a RIA developer, using Adobe Flex, I decided to investigate more depth the Mate framework, as this is a very structure free, being only based on events and their maps, so I have tried to improve it. So, I decided to adapt it using concepts used on other Adobe Flex frameworks from the first generation.
To complete this investigation, I’ve created an application that only configuring the names of maps, managers, events and respective variables, creates all the structure of the framework including all the code in his respective files, also saves a configuration file, so that other users, in future version, could load them and create the structure in other developing languages.
KEYWORDS
Web Application; Rich Internet Application (RIA); Actionscript; ; open-source solutions and workflows for development of RIAs; Cairngorm; Mate; framework; Design Patterns; Usability; SVN.
ÌNDICE Pág. RESUMO ... I PALAVRAS CHAVE ... II ABSTRACT ... III KEYWORDS ... III ÍNDICE ... IV ÍNDICE DE FIGURAS ... VI ACRÓNIMOS E ESTRANGEIRISMOS ... VII AGRADECIMENTOS ... XI 1 – Introdução……… 1 1.1 – Introdução……….. 1 1.2 – Objectivos……….. 1 1.3 – Problema……….… 2 1.4 – Motivação………...……… 3 1.5 – Estrutura do Documento……… 4 2 – Revisão da Literatura……….. 5 2.1 - Conceitos Teóricos………... 5 2.1.1 - Padrões de desenho……….. 7
2.1.1.1 – Exemplo de padrões de desenho……….. 8
2.1.2 - Padrões de desenho em MVC……….………. 10
2.1.3 - Como utilizar um padrão de desenho……….. 12
2.2 – Frameworks……… 12
2.2.1 - A framework Cairngorm……… 14
2.2.2 - O estado corrente das frameworks para Flex………..…. 17
2.2.3- Mate………..………. 18
2.2.3.1 - Como funciona o Mate………. 19
2.3 – Enquadramento tecnológico……….. 21
2.3.1 – Aplicações Desktop vs Aplicações Web……….. 21
3 – Proposta Conceptual………... 28
3.1 - Visão geral das frameworks ……..…………..……….. 28
3.2 – Proposta de framework………...……….. 29
4 – Implementação…..………..………... 36
4.1 - Desenvolvimento de Rich Internet Applications... 36
4.2 - Framework Creator – Facilitando o trabalho de quem desenvolve……... 38
5 –Utilização…………..………... 43
5.1 - Solução Client-side: Adobe Flex………. 43
5.2 - Solução Server-side: .NET + SQL Server Express……….. 44
5.3 - Comunicação entre o cliente e o servidor……… 45
5.4 - Construção da aplicação – Utilização da framework………. 46
5.4.1 - Projecto Gestor de Associados………. 47
5.4.1.1 – Associados……… 48 5.4.1.2 – Actividades………... 49 5.4.1.3 - Gestão de Dados……… 50 5.4.1.4 – Estatísticas………. 52 6 – Conclusões finais……….. 54 6.1 – Passos futuros………. 55 7 - Referências Bibliográficas……… 56
ÌNDICE DE FIGURAS
Pág.
Fig.1 – Utilização do Model (Observer) para colocar os dados nas Views…… 10
Fig.2 – Modelo Model-View-Controller……… 11
Fig. 3 – Processo de comunicação de dados entre cliente e servidor…………. 14
Fig.4 – Esquema das pastas e ficheiros utilizando a framework Cairngorm…. 17 Fig.5 – Aplicação Desktop vs Aplicação Web……….... 22
Fig.6 – Enquandramento das RIAs nas soluções actuais……… 25
Fig.7 – Estrutura dos padrões de desenho na Framework Cairngorm ………… 28
Fig.8 – Estrutura dos padrões de desenho na Framework Mate ………. 29
Fig.9 – Divisão lógica dos gestores de resultados de eventos……… 33
Fig.10 – Estrutura dos padrões de desenho na Framework desenvolvida……… 33
Fig.11 – Escolha do caminho do projecto………... 39
Fig.12 – Criação dos mapas de eventos e dos gestores de resultados………… 40
Fig.13 – Criação dos eventos……….. 41
Fig.14 – Esquema das pastas e ficheiros utilizando a nova framework………. 41
Fig.15 – Ficheiro de configuração do projecto……… 42
Fig.16 – Ecrã de Login da aplicação………. 47
Fig.17 – Área de navegação da aplicação……… 48
Fig.18 – Área da gestão dos associados……….. 49
Fig.19 – Área de gestão de Actividades………. 50
Fig.20 – Plano de Pagamentos……….... 51
Fig.21– Inserção de Associados……… 51
Fig.22 – Inserção de Actividades……… 52
Fig.23 – Gestão de Administradores………... 52
ACRÓNIMOS E ESTRANGEIRISMOS
.NET - Plataforma para desenvolvimento e execução de sistemas e aplicações. Todo e
qualquer código gerado para .NET, pode ser executado em qualquer dispositivo que possua uma framework de tal plataforma
AJAX - Asynchronous Javascript and XML, que representa um conjunto de tecnologias que
quando usadas em conjunto se tornam extremamente poderosas permitindo o desenvolvimento de RIAs.
AMF - Action Message Format . É o formato das mensagens usadas pelo Flash Remoting
Apache - Servidor Web gratuito, compatível com o protocolo HTTP.
API - Application Programming Interface . É um conjunto de rotinas e padrões estabelecidos
por um software para que este possa ser utilizado por programadores no desenvolvimento de outras aplicações.
Cache - Consiste em dotar um computador da capacidade de armazenar temporariamente
parte ou a totalidade de um conjunto de informação armazenada num servidor, para diminuir o número de comunicações.
Callbacks - Código executável ou função que é passado por argumento a outro código.
Combobox - Componente gráfico usado em aplicações informáticas que consiste numa lista
de items que o utilizador pode seleccionar.
CSS - Cascading Style Sheets , é uma linguagem usada para representar a apresentação
gráfica de um documento.
ECMAScript - Linguagem de programação de scripting, sendo a base de Javascript , Jscript ,
Firewall - Aplicação ou dispositivo de hardware que se encarrega de filtrar todos os pacotes
que são trocados entre dois computadores, de forma a evitar penetrações indesejadas nos sistemas.
framework - Estrutura de trabalho, sobre a qual um projecto de software pode ser desenvolvido.
GUI - Graphical User Interface . Nome dado ao interface gráfico com o utilizador.
HTML - Hyper-Text Markup Language . Linguagem de formatação utilizada para definir o
aspecto e conteúdo de uma página Web.
Hosting - Serviço que gere servidores de Internet , e permite a individuos ou organizações
alojar conteúdo Web
HTTP - Hypertext Transfer Protocol, é o protocolo usado na Internet para transportar
informação.
IDE - Integrated Development Environment, é um ambiente de desenvolvimento de software.
Interface - Definição da forma de comunicação entre duas entidades, software ou hardware.
Internet - É uma rede de redes de computadores, que permite a transferência de todo o tipo
de dados.
Javascript - Linguagem de scripting interpretada em run-time normalmente embebida em
HTML .
LAN - Local Area Network. Nome dado a uma rede local de computadores.
Listbox - É um componente gráfico semelhante à combo-box, que permite a selecção de itens
MVC - Model View Controller , padrão de desenho que separa uma aplicação em três
componentes distintos, o modelo de dados, o interface gráfico e o controlo da lógica de negócio e sistema.
MySQL - Servidor de bases de dados popularmente utilizado na Internet. OCAML Objective
Caml , é uma linguagem genérica de programação criada em 1996
Open-Source - Software fornecido aos utilizadores dando-lhe a liberdade de o executar,
estudar, modificar e redistribuir, sem que seja necessária a autorização dos autores Osflash Comunidade open-source de Flash .
Padrões de desenho - É uma solução base para um problema já conhecido, em
desenvolvimento de software. A solução encontra-se na forma de uma descrição ou de um template de resolução do problema.
PHP - Linguagem de scripting open-source. O PHP é usado essencialmente para aplicações
do lado do servidor.
Plugin - Pequena aplicação informática que se pode acoplar numa outra dotando a de novas
possibilidades e capacidades.
Protótipo - É a implementação de uma pequena parte de um sistema, com o objectivo de
demonstrar o seu eventual potencial.
Scripting - Linguagem de programação mais simples e leve, que as tradicionais liguagens de
programação. As linguagens de scripting são interpretadas e não compiladas.
SOA - Service Oriented Architecture. Arquitectura de software utilizada para permitir que
dois sistemas fracamente acoplados possam comunicar, onde o servidor disponibiliza funcionalidades que satisfazem os requisitos funcionais dos clientes, independentemente das tecnologias utilizadas por ambos os lados.
SOAP - Simple Object Access Protocol , é um protocolo que troca mensagens XML numa
Streaming - Tecnologia que permite que o computador cliente possa interpretar e exibir a
informação à medida que esta é recebida durante uma comunicação com o servidor. Este termo é normalmente utilizado no contexto de vídeo ou áudio.
Textbox - Componente gráfico, que permite ao utilizador a introdução de dados através do
GUI de uma aplicação.
Thin Client - É um terminal gráfico ou computador cliente que não processa nenhuma ou
quase nenhuma lógica da aplicação, sendo essa tarefa deixada a cargo do servidor.
URL - Uniform Resource Locator . Nome dado a um endereço Web, normalmente constituído
por um conjunto de caracteres que determinam o caminho para um determinado recurso.
Usabilidade - É o termo usado para definir a facilidade com que uma pessoa pode interagir
com uma aplicação.
Web-browser - Aplicação informática que se encarrega de interpretar HTML para exibir
páginas Web.
WIMP - Window, Icon, Menu, Pointing Device . É um estilo de interacção com uma
aplicação usando os componentes referidos.
Workflow - Automatização de processos de negócio, onde existem um conjunto de regras
pré-definidas, para passar de um processo para outro.
XML - Extensible Markup Language , metodologia usada para estruturar informação em
AGRADECIMENTOS
Gostaria de agradecer a:
Prof. Doutor Carlos Costa pela orientação prestada à dissertação e todo o apoio e atenção prestados ao projecto.
Ao RIAPT pelo apoio nas dúvidas colocadas.
À comunidade Flexcoders pelo apoio nas dúvidas colocadas.
A todos os amigos e família que apoiaram nas inúmeras horas de trabalho e de estudo dedicados a esta dissertação ao longo destes vários meses.
1 - Introdução
1.1 - Introdução
A dissertação de um tema no Mestrado é uma das escolhas mais difíceis no percurso académico de um aluno. É na dissertação que um aluno tem de mostrar todo o conhecimento obtido durante anos de estudo, e para além disso, também as metodologias de trabalho que foi aprendendo assim como a sua vontade de melhorar e a capacidade para solucionar obstáculos que lhe surjam ao longo do seu caminho.
Neste caso, foi decidido optar pela investigação em novas tecnologias e em desenvolver uma nova framework para a criação de Rich Internet Applications (daqui em diante denominadas por RIAs). Neste documento será explicado a importância das RIAs, tecnologias existentes para a sua criação, uma abordagem mais profunda sobre frameworks entre outras investigações feitas ao longo deste ano no âmbito desta dissertação.
1.2 - Objectivos
Para que esta investigação e dissertação pudessem ser completas era necessário cumprir objectivos com diferentes graus de dificuldade, como tal inicialmente deparou-se com objectivos e tarefas mais básicas de modo a aumentar o know-how na área das RIAs e das
frameworks. Para estes era necessário adquirir conhecimentos de várias tecnologias de
desenvolvimento de RIAs e dominar em específico uma tecnologia de desenvolvimento, sendo Adobe Flex a escolhida por motivos mais à frente apresentados, e dominar as
frameworks associadas a esta tecnologia. Para dominar o conceito de framework é importante
conseguir compreender a arquitectura Cliente-Servidor para uma melhor compreensão do funcionamento das mesmas, assim como compreender e dominar os padrões de desenho e de arquitectura tal como o Model-View-Controller (MVC).
Com estes objectivos básicos compreendidos é possível passar aos desafios propostos para o desenvolvimento desta dissertação.
Criar e desenvolver uma framework genérica de desenvolvimento de RIAs mais adaptada para o desenvolvimento colaborativo;
Desenvolver pelo menos uma RIA utilizando a framework proposta.
Criar uma aplicação que crie automaticamente a framework referida nos pontos anteriores.
1.3 – Problema
A construção de uma Rich Internet Application de grande dimensão envolve uma certa complexidade na conjugação das várias linguagens. Como tal para que seja possível fazer uma construção eficiente de uma aplicação escalável tanto em trabalho individual como em trabalho de equipa é necessário recorrer a boas práticas de programação.
É então necessário ter uma framework bem adaptada para que o desenvolvimento possa ser feito da forma mais eficiente e coesa. As frameworks têm se tornado comuns e importantes. Estas são a maneira como sistemas orientado a objectos alcançam uma maior reutilização.
O grande problema que se têm vindo a deparar com a evolução das aplicações, das tecnologias de desenvolvimento e com o surgimento de novas frameworks é o de não existir um equilíbrio nestas frameworks quanto à sua rigidez da estrutura, isto é, certas frameworks são demasiado rígidas, o que para um arquitecto de software quando tenta criar a estrutura base para o desenvolvimento de uma aplicação a maior parte das vezes encontra-se sem opções para que possa variar a estrutura consoante os problemas que lhe forem deparados. Por outro lado, outras frameworks são demasiado livres, fazendo com que as opções de um arquitecto de software por vezes não sejam demasiado limitadoras e criando conflitos de código quando os desenvolvedores dessa aplicação fazem junção de código dos projectos. A grande questão que se coloca é se será possível encontrar um meio termo entre estas
frameworks adaptando as vantagens de cada uma numa framework única que melhore o
trabalho colaborativo, e se será possível que esta possa ser utilizada para mais do que uma linguagem de programação de modo a poder uniformizar o desenvolvimento destas aplicações não interessando qual a linguagem utilizada.
1.4 – Motivação
Um dos grandes desafios é o de ser obrigatório recorrer a boas práticas da Engenharia de Programação, pois sem o recurso a estas o trabalho da equipa pode não ser o desejado. Como tal, ao longo destes últimos meses foi necessário adquirir conhecimentos sobre inúmeros
workflows (RPC; Cairngorm, PureMVC, Mate) pois cada projecto é diferente e cada qual
necessita de um workflow à sua medida.
Por isso o processo utilizado durante a investigação para esta dissertação consistiu em:
Revisão da literatura para perceber os conceitos de padrões de desenho e
frameworks bem como as frameworks em estudo.
Criação de uma proposta de framework através da adaptação de outras frameworks Desenvolvimento de uma aplicação para a prática desta framework
Criação de uma aplicação que consiga criar a framework atrás desenvolvida.
Outro dos factores que permitiu uma grande evolução na aprendizagem das novas tecnologias foi a utilização e investigação de comunidades online onde todo o apoio é sempre garantido, sendo as que mais contribuíram na reposta de dúvidas foram o RIAPT (www.riapt.org) e o Flexcoders (tech.groups.yahoo.com/group/flexcoders).
Ao longo destes meses de dissertação dei uma aula de apresentação de Flex no ISCTE assim como aulas de SIC (Sistemas de Informação e Comunicação) no Curso de Especialização Tecnológica em Desenvolvivmento de Produtos Multimédia e no Curso de Especialização Tecnológica em Fotografia no IADE (Instituto de Artes Visuais, Design e Marketing)
Entretanto também fui construindo outros projectos enquanto estive a trabalhar na empresa Apriva tais como:
http://www.grupo-holon.pt http://www.apriva.pt
http://www.mpsfarmaceutica.pt http://www.saborlisboa.com
1.5 – Estrutura do Documento
Este trabalho de investigação está organizado em sete capítulos.
No primeiro, a introdução, é revisto os objectivos e o problema que motivaram à escolha desta dissertação assim como uma breve abordagem à evolução dos conceitos que levaram ao problema em questão, falando assim no processo utilizado para a investigação.
O segundo capítulo trata-se da revisão de literatura onde é feito explicado o conceito de padrões de desenho, frameworks e são explicadas as frameworks que foram utilizadas para basear a nova Framework assim como o enquadramento tecnológico onde é revisto um estudo sobre as Rich Internet Applications de modo a dar um enquadramento sobre as tecnologias onde é pretendido melhorar
A partir do terceiro capítulo começa o trabalho de investigação, onde neste especificamente, é efectuado a proposta conceptual onde é explicada a nova Framework e as razões que levaram à construção da mesma segundo as configurações finais. No quarto capítulo está a demonstração de uma aplicação criada para implementar a mesma Framework e para terminar o quinto capítulo é onde está demonstrada a utilização desta nova Framework na construção de uma aplicação.
Por último temos o capítulo da conclusão onde se descreve também os passos futuros a serem dados.
2 – Revisão da Literatura
2.1 - Conceitos Teóricos
Para se compreender a explicação da framework, é necessário introduzir alguns conceitos teóricos de padrões de desenho e arquitectura. Para evitar que o relatório seja demasiado extenso estes conceitos serão explicados de uma forma resumida.
Para que houvesse uma evolução dos padrões de desenho e das frameworks foi necessários que várias pessoas investigassem e tentassem progressivamente melhorar os estudos anteriores efectuados.
“Cada padrão descreve um problema que acontece repetidamente no nosso meio, e o núcleo da solução para esse problema de tal forma que é possível utilizar essa solução milhões de vezes sem nunca o fazer da mesma maneira duas vezes.” (Christopher Alexander, 1977)
Padrão de desenho é um conceito que surgiu na década de 70 por Christopher Alexander ao qual este adicionou todas as características e definições que os mesmos devem conter, mas nesta altura, padrões de desenho eram utilizadas para problemas na área da arquitectura. Foi necessário esperar até 1987 os programadores Kent Beck e Ward Cunningham adaptassem este conceito para o desenvolvimento de software.
O próximo quadro é um paralelismo feito sobre aprender a ser um mestre do xadrez com ser um mestre em desenhar software por D.C. Schmidt e J. O. Coplien, em “Pattern Languages of Program Design” para evidenciar a importância da utilização de padrões de desenho na construção de software.
Nível Objectivo Tornar-se um mestre do xadrez Tornar-se um desenhador de software 1 Aprender as regras
Nomes das peças, movimentos das peças, geometria do tabuleiro, etc…
Algoritmos, estruturas de dados, sintaxe da linguagem de programação, etc…
2 Aprender os princípios
Valor relativo de certas peças, valor estratégico dos quadrados centrais, etc…
Modularidade, orientação a objectos, etc…
3 Aprender os padrões
Para ser um mestre do xadrez é preciso estudar os jogos de outros mestres. Estes jogos envolvem padrões que têm de ser compreendidos, memorizados e aplicá-los repetidamente
Para ser um mestre em desenho de software é preciso estudar os padrões nos desenhos de outros mestres
Assim, naturalmente, começaram a ser desenvolvidos padrões de arquitectura baseados na união destes padrões de desenho e por consequente surgiram as frameworks através de conjugação destes padrões de arquitectura.
Para a investigação em questão interessam duas frameworks em pormenor. A Cairngorm, que pertence à primeira geração de frameworks para Adobe Flex, foi desenvolvida pela companhia Intertion::two, adquirida em 2005 pela Macromedia, e logo se tornou a mais utilizada devido às suas qualidades e a ser baseada num modelo de Model-View-Controller (MVC), um dos modelos mais utilizados na área do desenvolvimento de software. Mais recentemente surgiu a Mate, já pertencente à segunda geração de frameworks para Adobe Flex, foi desenvolvida e mantida pela ASFusion desde Julho de 2008 e surgiu com o intuito de facilitar a gestão de eventos, sendo esta uma das mais utilizadas das frameworks de segunda geração.
2.1.1 - Padrões de desenho
Desenhar software orientado a objectos é difícil e desenhar software orientado a objectos reutilizável é ainda mais difícil. O desenho deve ser específico ao problema em mãos mas também ser suficientemente generalista para poder resolver futuros problemas com diferentes requisitos, fazendo com que se evite ou minimize o redesenho do software. Já por inúmeras vezes houve a sensação de que o problema que está a ser resolvido, já tenha sido já resolvido mas sem ser fácil lembrar onde e como? Se fosse possível relembrar os detalhes do problema anterior e como fora resolvido, então seria possível reutilizar essa experiência em vez de a redescobrir. É assim que nasce os padrões de desenho.
O que é um padrão de desenho?
Padrões de desenho, na sua generalidade, são descrições de objectos e classes comunicantes que são customizados para resolver um desenho geral num contexto particular. O padrão de desenho identifica as classes e instâncias participantes, os seus objectivos e colaborações e a distribuição das responsabilidades. Cada padrão de desenho foca-se num problema de orientação a objectos. [17],[19]
Um padrão de desenho tem quatro elementos essenciais [1], [2], [5]:
O nome, que tem por objectivo descrever o problema, a solução e as consequências em uma ou duas palavras aumentando a abstracção na nossa lógica mental.
O problema que descreve onde aplicar o padrão, explicando o problema e o seu contexto. Pode também descrever o problema de desenho específico tal como a representação algorítmica como objectos. Por vezes o problema pode incluir uma lista de condições que têm de ser encontradas antes de fazer sentido aplicar o padrão.
A solução descreve os elementos que constroem o desenho, a sua relação, responsabilidades e colaborações. A solução não descreve um desenho concreto nem a implementação, porque o padrão é como um template que pode ser aplicado em inúmeras situações. Ao contrário, os padrões fornecem uma
descrição abstracta do problema de desenho e como uma estruturação generalista dos elementos o resolve.
As consequências são os resultados da aplicação do padrão. Como a reutilização é muito utilizada em desenho orientado a objectos, as consequências de um padrão inclui o seu impacto na flexibilidade do sistema, escalabilidade ou portabilidade. Perceber as consequências ajuda a entender e avaliar os padrões de desenho.
2.1.1.1 – Exemplo de padrões de desenho
Apesar do tamanho do domínio dos padrões ser provavelmente infinito, a maioria das principais generalizações de padrões para engenharia de software precisas de conhecer já estão identificadas. Os padrões de desenho dividem-se em três tipos principais [17],[18],[19]:
1 - Padrões de Criação
Abstract Factory - Um método Factory é um método que fabrica objectos de um tipo particular; Um objecto Factory é um objecto que encapsula métodos Factory.
Builder - Separa a construção de um objecto complexo da sua representação, de forma que o mesmo processo de construção possa criar diferentes representações.
Factory Method - É uma interface para instanciação de objectos que mantém isoladas as classes concretas usadas da requisição da criação destes objectos.
Prototype - O padrão Prototype fornece uma outra maneira de se construir objectos de tipos arbitrários.
Singleton. - Garante que para uma classe específica só possa existir uma única instância, a qual é acessível de forma global e uniforme.
2- Padrões de Estrutura
Adapter - Permite que dois objectos se comuniquem mesmo que tenham interfaces incompatíveis.
Bridge - Desacopla a interface da implementação; Ocultação de detalhes de implementação dos clientes.
Decorator - Atribui responsabilidade adicionais a um objecto dinamicamente. O Decorator fornece uma alternativa flexível a subclasses para a extensão da funcionalidade.
Facade - Interface unificada para um subsistema; Torna o subsistema mais fácil de usar.
Flyweight - Usa compartilhamento para dar suporte a vários objectos de forma eficiente.
Proxy - Fornece um objecto representante ou procurador de outro objecto para controlar o acesso ao mesmo.
3- Padrões de Comportamento
Chain of Responsability - Evita dependência do remetente (cliente) de uma requisição ao seu destinatário, dando a oportunidade de mais de objecto tratar a requisição.
Command - Associa uma acção a diferentes objectos através de uma interface conhecida.
Interpreter - Usado para ajudar uma aplicação a entender uma declaração de linguagem natural e executar a funcionalidade da declaração.
Iterator - Provê uma forma de percorrermos os elementos de uma colecção sem violar o seu encapsulamento.
Mediator - Cria um objecto que age como um mediador controlando a interacção entre um conjunto de objectos.
Memento - Torna possível salvar o estado de um objecto de modo que o mesmo possa ser restaurado.
Observer - Define uma relação de dependência 1:N de forma que quando um certo objecto (assunto) tem seu estado modificado os demais (observadores) são notificados; Possibilita baixo acoplamento entre os objectos observadores e o assunto.
State – Permite ao objecto alterar seu comportamento quando o estado interno muda. Strategy - Permite que uma família de algoritmos seja utilizada de modo independente
e selectivo.
Template Method -Define o esqueleto de um algoritmo em uma operação adiando a definição de alguns passos para a subclasse.
Visitor - Define operações independentes a serem realizadas sobre elementos de uma estrutura.
Da lista de padrões atrás um dos mais conhecidos é o Observer. Um exemplo actual da utilização deste padrão é quando recebemos no nosso computador actualizações automáticas para alguns dos nossos programas assim que nos ligamos à Internet. O padrão Observer tornou possíveis estas actualizações informando os computadores cada vez que alguma alteração interessante aconteça.
Fig.1 – Utilização do Model (Observer) para colocar os dados nas Views
2.1.2 - Padrões de desenho em MVC
Uma arquitectura é uma forma de representar o desenho de sistemas de software que melhora a estrutura das aplicações especialmente em projectos de grande dimensão [21]. O MVC ou Model-View-Controller [22] é uma arquitectura de software que possui três componentes distintos o Model – componente responsável por agrupar e lidar directamente com os dados – a View - consiste no interface com o utilizador, ou por outras palavras, na representação visual dos dados que estão no model – e o Controller - componente responsável por fazer alterações ao model ou às views, respondendo a eventos, chamando comandos, e definindo o comportamento da aplicação. Antes do MVC, o desenho do interface de utilizador tendia a juntar estes objectos num só. Com o MVC é possível dividi-los para aumentar a flexibilidade e a reutilização.
O MVC divide as views do model estabelecendo protocolos de notificação entre os dois componentes. Uma view tem de garantir que reflecte na sua apresentação o estado do model. Sempre que os dados do
model alterarem, o model notifica as views
que dependem dele. Esta abordagem permite um acoplar de múltiplas views ao model para fornecer diversas apresentações, sendo também possível criar novas views para um
model sem ter de o rescrever. Fig.2 – Modelo Model-View-Controller
O MVC também permite alterar o modo como uma view responde ao input do utilizador sem ter de alterar a sua representação visual. Por isso, o MVC encapsula os mecanismos de resposta no objecto Controller. Esta é uma classe hierárquica de controladores, tornando mais fácil para criar um controlador como uma variação de um já existente.
Uma view utiliza uma instância da subclasse do Controller para implementar uma resposta particular, ao qual para alterar, basta simplesmente substituir a instância por um diferente tipo de controller.
A relação View-Controller é um exemplo de um padrão de desenho chamado Strategy. Strategy é um objecto que representa um algoritmo, e é útil quando se pretende substituir um algoritmo tanto estaticamente ou dinamicamente, quando se tem imensas variáveis no algoritmo, ou quando o algoritmo tem estruturas de dados complexas que queremos encapsular.
2.1.3 - Como utilizar um padrão de desenho
Seguidamente, é apresentada uma pequena descrição de como aplicar um padrão de desenho eficazmente [3],[4],[5]:
1. Ler o padrão de desenho e prestar atenção particular às suas secções da Aplicabilidade e das Consequências para assegurar que o padrão é o correcto para o problema.
2. Voltar a estudar às secções da Estrutura, Participantes e Colaborações para se ter a certeza como as classes e objectos no padrão se relacionam entre elas.
3. Ver a secção do Código Simples para se compreender um exemplo do padrão em código e aprender como o implementar.
4. Escolher nomes para os participantes do padrão que sejam importantes no contexto da aplicação. É importante a escolha dos nomes para tornar o padrão mais explícito na sua implementação.
5. Definir as classes. Declarar os seus interfaces, estabelecer as suas relações, e definir as variáveis que representam os dados e as referências dos objectos. Identificar as classes da aplicação que o padrão irá afectar e modificá-las de acordo com os objectivos. 6. Definir nomes para as operações do padrão com a mesma importância que no ponto 4. 7. Implementar as operações que irão realizar as responsabilidades e colaborações do
padrão.
2.2 - Frameworks
Uma framework é um conjunto de classes cooperativas que utilizam um desenho de reutilização para uma classe específica de software [23]. Por exemplo, um framework pode ser utilizada para ajudar a construir compiladores para diferentes linguagens de programação ou diferentes máquinas, ou também pode ser criada para construir aplicações de gestão financeira. As frameworks podem ser customizadas para uma aplicação em particular criando subclasses específicas a partir das classes abstractas da framework.
A framework dita a arquitectura da aplicação, definindo toda a estrutura, a sua partição das classes e objectos, as responsabilidades ou a colaboração entre os objectos e as classes,
predefine também os parâmetros do desenho para que o programador/desenhador possa concentrar-se nas especificações da sua aplicação, capturando assim as decisões de desenho que são comuns ao domínio da aplicação.
Quando se utiliza uma framework, reutiliza-se o corpo principal e escreve-se o código que este chama, tendo de ser escritas as operações com nomes particulares e pedidos convencionais, mas reduzindo as decisões de desenho necessárias de fazer. Não só torna a construção da aplicação mais rápida mas faz com que todas as aplicações tenham uma estrutura semelhante tornando mais fácil a sua manutenção. Por outro lado, perde-se alguma liberdade criativa tendo em conta que a maior parte das decisões de desenho já terem sido tomadas.
Se uma aplicação é complicada de desenhar, uma framework é ainda mais complicada. Um desenhador de frameworks tem de assegurar que a arquitectura funcionará para qualquer domínio da aplicação. É por isso necessário que o seu desenho a faça o mais flexível e extensível possível. Como as aplicações se tornam tão dependentes de uma framework é necessário que quando um framework evolui que a aplicação evolua também.
Uma framework mais madura normalmente incorpora vários padrões de desenho. Os padrões ajudam a arquitectura da framework a adequar-se às diferentes aplicações sem haver redesenho. Padrões de desenho e frameworks são bastante semelhantes mas eles diferem em 3 maneiras [23]:
Padrões de desenhos são mais abstractos que as frameworks. O positivo das
frameworks é que estas podem ser escritas na programação e não apenas
estudadas, mas executadas e reutilizadas directamente. Em contraste, os padrões de desenho têm de ser implementados cada vez que são reutilizados Padrões de desenho são elementos de arquitectura mais pequenos que as
frameworks. Uma framework tipicamente contêm alguns padrões de desenho,
mas o contrário nunca acontece
Padrões de desenho são menos especializados que as frameworks. As
frameworks têm sempre um domínio particular a serem aplicados. Em
contraste, os padrões de desenho pode ser utilizados em quase todas as aplicações.
A utilização de uma framework para desenvolver uma RIA traz-nos a coesão de uma estrutura que melhora em bastante a organização do código, a escalabilidade e a manutenção de toda a RIA, podendo incluir componentes que ajudem ao desenvolvimento da mesma.
A framework Cairngorm [12],[14] foi inicialmente desenvolvida pela equipa da Adobe Consulting, no intuito de melhorar o desenvolvimento das RIAs na altura do ActionScript 2 e do Flash Remoting com Flash MX 2004. Com o melhoramento das tecnologias para o desenvolvimento das mesmas, também o Cairngorm teve de ser revisto e passado para a versão 2.0 mais adaptado à framework do Flex 2.0.
2.2.1 - A framework Cairngorm
A utilização deste tipo de frameworks, baseados em padrões de desenho, implica também alguns conhecimentos sobre estes e como tal mais à frente irá estar apresentado um resumo sobre os vários componentes utilizados pelo Cairngorm.
De seguida é apresentada uma figura que mostra a fase pela qual a comunicação dos dados entre o cliente e o servidor passam desde que é feito um pedido pela aplicação cliente até o retorno dos seus dados:
Como é possível observar a fase 1 e a fase 3 são aproximadamente iguais tendo apenas uma ordem inversa e enquanto na primeira fase há um envolvimento de eventos e do controller já na terceira fase os dados que foram requisitados são colocados no ModelLocator para a view os poder consumir.
Componentes
Antes de compreender como todos estes componentes funcionam em conjunto é necessário compreender o que é cada um em separado. Seguidamente, serão analisados cada um dos módulos, a saber, ModelLocator, View, Front Controller, Command, Delegate e Service [6]
O ModelLocator guarda toda a informação dos Value Objects da aplicação assim como das variáveis partilhadas num só lugar. É similar a um objecto de sessão do http excepto pelo facto de este estar alojado no lado do cliente.
O View é o interface gráfico que interage com o cliente, constituído pelos componentes do Flex (botões, painéis, etc) e onde os eventos Cairngorm são lançados após as interacções do utilizador (clicks, rollovers, etc)
O Front Controller recebe os eventos lançados pelas views e mapeia-os para os
Commands.
O Command contem a lógica de negócio, faz a chamada do Delegate correspondente e/ou de outros comandos, e actualiza os Value Objects como das variáveis alojadas no
ModelLocator
O Delegate faz a chamada das funções no servidor através do Service e devolve os resultados obtidos para o Command.
O Service define o Remote Procedure Call (http, Web service, etc) para aceder aos dados que estão no servidor.
Juntar os componentes
Para elucidar melhor este ciclo e a integração dos componentes, utilizando a figura 5 como base, é explicado mais pormenorizadamente o ciclo juntando todos os componentes da Framework [6],[7],[8]:
1. Existem as views que interagem com o utilizador.
2. Quando, por exemplo, um utilizador pede para ver os dados de um produto, este na
view insere o número do produto que quer analisar e é lançado um evento (dispatch).
3. O FrontController está sempre atento aos eventos que são lançados e ao receber um pedido procura qual o Command que corresponde ao Event. Assim ele faz o requisito ao Command.
4. Este Command delega o serviço de comunicação de pedido ao seu Business Delegate. Os Business Delegates normalmente estão divididos por gestores, ou seja, neste caso existiria um Business Delegate chamado ProtudosDelegate onde está a comunicação com o servidor para chamar funções de adição, modificação, consulta ou eliminação de produtos.
5. O Business Delegate de seguida comunica com o servidor pedindo os dados que lhe foram comunicados.
6. No servidor é feito a consulta à base de dados e devolve ao Business Delegate que por sua vez envia a resposta ao Command.
7. No Command existem duas hipóteses de resultado. Ou o Command recebe um fault caso o pedido no servidor não tenha sido bem sucedido ou então é devolvido um
result.
8. Caso este result se verifique é aqui que os dados são passados para o ModelLocator que coloca as referências no Value Object correspondente.
9. As views, que por boas práticas da programação devem estar à escuta da alteração dos dados do ModelLocator, apercebem-se das alterações e alteram-nos automaticamente na interface do utilizador.
Fig.4 – Esquema das pastas e ficheiros utilizando a framework Cairngorm
2.2.2 - O estado corrente das frameworks para Flex
No início da expansão do Flex surgiram algumas frameworks adaptadas para Flex sendo que a mais desenvolvida e utilizada era a framework Cairngorm já explicada atrás. Na sua maioria conseguiu resolver todos os problemas de desenvolvimento de aplicações mas também conseguiu criar novos.
Com a evolução do Flex e a sua maior utilização pela comunidade de desenvolvedores de aplicações web começaram a ser criadas frameworks especificas para resolver problemas que antes não tinham sido resolvidos. Foram então criadas várias frameworks sendo que actualmente duas das mais utilizadas e melhor criticadas são a framework Mate e a Swiz. Qual a melhor a ser utilizada é difícil de escolher sendo que as suas diferenças passam pela implementação das mesmas, acaba por ser uma escolha pessoal e de adaptação.
A escolha de framework para utilizar foi a Mate principalmente por ter melhor documentação e assim ser mais fácil compreender a sua lógica de padrões de desenho.
2.2.3- Mate
Mate é uma framework que é totalmente implementada em MXML e é orientada aos eventos, sendo este o seu foco central para tornar mais fácil a definição das respostas aos mesmos [11],[13]. Para implementar Mate é apenas necessário ter um ou mais eventos e ter um mapa de eventos, sendo este um ficheiro MXML incluído no código da aplicação, que define os eventos que queremos escutar e qual a resposta a dar ao seu comportamento. Pode ser utilizado mais do que um mapa de eventos se assim preferirmos para organização do nosso código.
No mapa de eventos é também possível implementar a injecção de dados, através da construção de objectos que injectam os dados recebidos noutros objectos da nossa aplicação de modo a estes não precisarem de ir buscá-los pois estes são logo colocados automaticamente. A injecção de dados traz a vantagem de não ser necessário estes estarem contidos num model mas também a desvantagem de ser necessário fazer várias injecções caso os dados sejam partilhados em vários sítios da aplicação, como tal, é sempre importante perceber onde é realmente necessário criar injectores ou utilizar um ficheiro de dados central.
Um dos possíveis problemas desta framework é não definir uma estrutura para a aplicação, podendo isto favorecer quem desenvolve uma aplicação pois assim pode adaptar o projecto ao seu modo de trabalho, mas obrigando a que uma equipa de trabalho sincronize a sua estrutura de um modo compatível, enquanto que com uma estrutura pré-definida seria mais útil para um projecto onde existam vários desenvolvedores a trabalhar em conjunto.
Como tal, algumas frameworks podem obrigar à utilização de uma certa e determinada metodologia de desenvolvimento por terem uma estrutura já predefinida. Com o Mate a nossa aplicação fica livre de uma estrutura pré-definida pois a comunicação para a base de dados pode ser feita no modo que nos for mais confortável em construir através de eventos.
A documentação com que podemos contar é bastante vasta e útil, com bastantes exemplos e explicações de como funciona e que pode ser encontrada, especialmente para quem está a começar a utilizá-la, em http://mate.asfusion.com
2.2.3.1 - Como funciona o Mate
O mais importante a perceber nesta framework é como os eventos são tratados [11],[13]. Estes são essenciais no desenvolvimento de uma aplicação com Mate, sendo que são simples extensões dos eventos de uma aplicação normal (flash.events.Event). Isto faz com que os módulos construídos numa aplicação com Mate possam ser reutilizados noutra aplicação que não use frameworks de desenvolvimento.
Eventos
Os eventos permitem a um programador saber quando estão a acontecer alterações na aplicação. Estas alterações podem ser causadas pela interacção de um utilizador através do rato ou do teclado, podem ser causadas por ser alguma alteração na aparência dos objectos da aplicação, seja a sua criação ou destruição, ou também por algum resultado proveniente da base de dados.
O resultado destes eventos pode e deve ser utilizado para que a utilização continue a funcionar, e para isso é possível utilizar um controlador/manipulador (handler) de eventos. Estes controladores são funções ou respostas escritas para especificar a resposta ao evento.
Quando os eventos são chamadas a um servidor, podemos considerar a existência de uma estrutura diferente nos eventos. Existe a utilização dos listeners dos eventos, sendo que estes estão à espera que o evento dispare para fazerem a chamada à base de dados, e quando o resultado é retornado o controlador do evento recebe o resultado para completar o ciclo desse evento. Alguns programadores consideram este ciclo como dois eventos, o de chamar a base de dados e o de receber os dados, enquanto outros consideram-no como um único, considerando ter um listener e um controlador.
<mx:Button click="criarPasta()" y="68" label="Criar ficheiros"/>
Sublinhado em cima a amarelo está um evento associado a um botão, o qual é accionado quando um utilizador clica com o rato sobre este botão. Irá lançar uma função que pelo seu nome irá criar uma pasta no seu sistema informático.
var logEvent:LogsSaveEvent = new LogsSaveEvent(LogsSaveEvent.GET); logEvent.descricao = str;
logEvent.id_admin = geralLocator.admin.ID; logEvent.nome_admin = geralLocator.admin.Nome; dispatchEvent(logEvent);
Em cima está um evento de log (guardar em base de dados os passos feitos por um utilizador numa aplicação, para futura identificação), que pode ou não ser lançado por alguma interacção do utilizador. Este irá lançar um evento para fazer uma chamada à base de dados. Neste caso ele não sabe qual é a função que deverá chamar, apenas lança através do dispatchEvent( ), depois existe um listener, ou no caso do Mate um EventMap (que contem o
listener), que irá escutar o evento e lançar a função correspondente ao evento.
EventMaps (Mapa de Eventos)
O EventMap é uma peça fundamental em aplicações que usem a framework Mate. [11],[13] Este é um ficheiro MXML que irá gerir os eventos, lançando as funções correspondentes seja para pedir dados à base de dados como a tratar os resultados provenientes da mesma. Os eventos dentro do EventMap também podem lançar outros eventos. Numa aplicação que use a
framework Mate é obrigatório ter pelo menos 1, mas também podem ser usados mais caso
seja melhor para a estruturação e organização do código.
Dentro de um EventMap encontra-se os EventHandlers e os Injectors (já explicado anteriormente) <EventMap xmlns:mx="http://www.adobe.com/2006/mxml"> <mx:Script> <![CDATA[ import events.AdministradoresReadEvent; ]]> </mx:Script>
<EventHandlers type="{AdministradoresReadEvent.GET}" debug="true">
<RemoteObjectInvoker destination="GestorSociosAdministradores"
method="Administradores_Search"
arguments="{[event.id,event.username,event.password, event.nome]}” debug="true">
<resultHandlers>
<MethodInvoker generator="{LoginManager}"
method="readAdminResult" arguments="{resultObject}"/> </resultHandlers>
method="readAdminFail" arguments="{resultObject}"/>
</faultHandlers>
</RemoteObjectInvoker> </EventHandlers>
</EventMap>
Este exemplo mostra a constituição de um EventHandler num EventMap. A definição de type diz ao EventMap que tipo de evento está a ser escutado pelo EventHandler. Assim, neste caso, quando acontecer um evento igual ao que está definido em
AdministradoresReadEvent.GET, então lançará “Administradores_Search” (definido em
RemoteObjectInvoker) que é uma função do backend programada no GestorSociosAdministradores. Esta é uma chamada à base de dados, e como tal, irá retornar um valor que poderá ser “ligação com sucesso” ou “ligação com falha”. O EventHandler responsabiliza-se por tratar qualquer que seja o seu resultado. Se for positivo então é chamado o método readAdminResult onde os dados irão ser tratados. Por outro lado, se for negativo então será chamado o método readAdminFail que passará alguma informação ao utilizador indicando o insucesso da operação.
É baseado nesta framework que se criou uma aplicação de gestão de associados para os Serviços Sociais do Montepio. O objectivo era utilizar a framework Mate e tentar melhorá-la à medida que era melhor conhecida, através da prática, para assim ser possível alcançar uma conclusão do estudo sobre as frameworks. De seguido encontra-se o estudo com os melhoramentos efectuados à framework.
[11,13]
2.3 - Enquadramento tecnológico
2.3.1 – Aplicações Desktop vs Aplicações Web
Este ponto tem por objectivo fazer uma distinção entre os dois tipos de aplicações, quais as vantagens e desvantagens que cada um apresenta e a razão pelo qual as aplicações web não substituem por completo as aplicações desktop, mas complementam-nas.
As aplicações desktop são um tipo de software que já existe em mercado desde o início dos sistemas operativos. Estas são aplicações que têm de ser instaladas nos computadores dos utilizadores que as necessitem. Como exemplos destas aplicações temos Adobe Photoshop, Microsoft Word, Winamp entre muitos outros milhares de aplicações.
Dando exemplos de casos reais de arquitecturas cliente-servidor, algumas empresas necessitam de instalar programas clientes nos computadores de vários trabalhadores para que estes acedam às bases de dados centrais que estão no seu servidor. Na altura em que este programa passa para uma nova versão, na generalidade é necessário proceder a uma nova instalação deste cliente em todos os computadores, para que todos possam usufruir das novas funcionalidades e que geralmente envolve custos tanto em manutenção como na paragem de produção pelo tempo necessário para proceder às modificações.
Com a utilização de aplicações web esta desvantagem é ultrapassada pelo simples facto que estas se encontram unicamente instaladas no servidor. Os computadores dos utilizadores apenas desempenham o papel de thin clients na medida que estes apenas necessitam de actuar como terminais de interface, sem haver necessidade de nenhuma instalação por parte destes. Com as aplicações web um trabalhador apenas necessita de um web-browser para estabelecer a ligação http com o servidor e trocar tanto os dados necessários ao funcionamento da aplicação, como a estrutura do próprio interface com o utilizador, sendo este interface trocado uma única vez.
A Google é uma das portadoras de maior leque de aplicações Web tendo por exemplo o Google Maps, Google Mail, Google Calendar entre muitas outras ferramentas que eles disponibilizam para utilização. Estas são aplicações muito conhecidas e que demonstram o enorme potencial destas ferramentas. O facto de não ser necessário a instalação das aplicações no computador e ter uma acessibilidade a todas elas em qualquer computador com Internet, são as principais razões da sua popularidade. Todas as suas ferramentas apresentam-se como possíveis substitutas de aplicações que antes eram as únicas possibilidades. Existem outros exemplos como Buzzword, uma ferramenta de processamento de texto com uma qualidade quase equivalente ao Microsoft Word com a vantagem de ser uma aplicação web e disponibilizada gratuitamente.
Como tal, é de interesse enumerar vantagens e desvantagens das aplicações web relativamente às aplicações desktop. [9,15,16]
As vantagens são as seguintes:
Não necessitam de ser instaladas nos computadores dos utilizadores
Acessíveis em qualquer lugar, independentemente do computador e sistema operativo, através de uma ligação à Internet;
Os utilizadores não precisam de se preocupar com upgrades, correcções e actualizações de segurança;
Muito pouco vulneráveis a vírus e spyware;
Devido à própria natureza, são logo à partida aplicações distribuídas;
Redução significativa nos custos de distribuição, manutenção e configuração.
As desvantagens são as seguintes:
Tempos de espera dependentes da velocidade da ligação, que podem ser intoleráveis em determinados tipos de aplicação;
É necessário abordar a segurança de uma forma mais séria, visto o tráfego circular “livremente” pela Internet;
Existe desconfiança por parte dos produtores de software relativamente à construção de aplicações em tecnologias diferentes das habituais, especialmente quando se tratam de aplicações que envolvem responsabilidade acrescida (como software de gestão); Regra geral, as aplicações web possuem um GUI limitado, normalmente baseado em
HTML.
Com o aparecimento do Adobe Flex e outras tecnologias que permitem a criação de RIAs muitas destas falhas conseguem ser resolvidas devido à maior facilidade de criar um interface mais agradável e rico em tudo semelhante aos das aplicações desktop.
2.3.2 - Rich Internet Applications
Definir Rich Internet Application, mesmo quando se trabalha na área, não é fácil. Esta consegue juntar o melhor de todas as áreas das aplicações, mantendo as inúmeras vantagens em termos uma aplicação web com o grande conforto e usabilidade que uma aplicação
desktop pode oferecer. Uma RIA pode oferecer a um utilizador um interface WINP assim
como também pode passar algumas tarefas para o lado do cliente, repartindo assim a carga de processamento pelo cliente e pelo servidor. Outra grande vantagem é que dispensam o refrescamento da página a cada comunicação com o servidor em semelhança ao que acontece com as aplicações desktop.
Fig.6 – Enquandramento das RIAs nas soluções actuais
Quando um cliente pretende alguma informação, executa um pedido http ao servidor, normalmente APACHE, verifica se o pedido deverá ser encaminhado para alguma extensão instalado como o PHP. Estas tratam do pedido encarregando-se de gerar dinamicamente a página HTML que é de seguida entregue ao servidor http. Este então refresca a página do web-browser. As aplicações desktop têm a desvantagem de terem que esperar pela comunicação com o servidor e o respectivo refrescamento da página, e quando estes dados são devolvidos têm de ser acompanhados por toda a página HTML para ser refrescada, tornando assim poucos bytes de dados em muitos kylobytes de informação por um simples pedido.
Nas Rich Internet Applications, este problema é resolvido recorrendo ao AJAX, FLEX, ActiveX, ou Silverlight, permitindo a construção de interfaces em tudo semelhantes aos das aplicações desktop, e reduzindo largamente a quantidade de informação trocada entre o cliente o servidor, na medida em que só são trocados os dados estritamente necessários.
Então qual a necessidade das RIAs ?
As RIAs permitem a criação de aplicações personalizadas e interactivas que melhoram significativamente a experiência do utilizador, revolucionando a maneira como um utilizador interage com a web. Poder criar e fornecer uma experiência eficaz ao utilizador é o que marca a diferença entre um bom produto e outro que não tem sucesso. Por isso, a necessidade de cada vez mais evoluir as aplicações e como tal também as tecnologias para as suas criações.
O aparecimento das RIAs não surge com o objectivo de substituir as aplicações desktop mas sim de as complementar. O aumento da largura de banda e o desenvolvimento de novas tecnologias para construção de aplicações mais sofisticadas trouxe ao nosso mundo informático aplicações como Buzzword (www.buzzword.com) um editor de texto, semelhante ao Microsoft Office Word, Picnik (www.picnik.com) um editor de fotografias e Slide Rocket (www.sliderocket.com), semelhante ao Microsoft Office PowerPoint. Muitas destas novas RIAs chegam a ter funcionalidades e eficiência de resposta melhor que algumas aplicações
desktop com o complemento de ter também outras vantagens maioritariamente em termos de
trabalho colaborativo.
O futuro mais provável é que cada aplicação seja escolhida consoante a solução necessária ao problema a resolver de acordo com as vantagens e desvantagens de ambas.
As aplicações web apresentam inúmeras vantagens em relação às aplicações de desktop, mas obviamente também têm as suas desvantagens. Neste documento serão descritas as principais vantagens, num foco mais pormenorizado, como é o exemplo das aplicações web reduzirem os custos de distribuição, de instalação e manutenção pelo facto de ser apenas necessário disponibilizar a aplicação num servidor http para que os seus clientes através de um
web-browser possam utilizá-la não dependo do local onde estão nem do sistema operativo que
utilizem.
Actualmente o grande problema não está em construir aplicações complexas mas em construi-las de modo a serem de fácil manutenção, escaláveis e que permitam um fácil trabalho de equipa. Como tal, com este projecto pretendesse evoluir e conhecer as frameworks de desenvolvimento em Flex assim como tentar adaptar uma nova framework adaptando as já
existentes que melhore o trabalho colaborativo para a utilização da mesma em outras linguagens de programação.
[9]
2.4 – Conclusão
É então perceptível que as RIAs são o provável futuro nas aplicações informáticas sendo por isso importante que o seu desenvolvimento seja cada vez mais apropriado a cada caso mas sobretudo que sejam cada vez mais desenvolvidas num ambiente de boa Engenharia de Programação para aumentar a sua estabilidade e escalabilidade. Para isso é necessário que as equipas de desenvolvimento utilizem frameworks para que este desenvolvimento seja coerente a cada passo dos projectos. Conseguir utilizar frameworks implica ter alguns conhecimentos sobre padrões de desenho para que a utilização das frameworks seja perceptível a quem desenvolve. Como cada Framework é desenvolvida para determinados objectivos, nem todas eles se preocupam com o trabalho colaborativo nas equipas de desenvolvimento, daí a necessidade de tentar propor uma nova Framework que possa melhorar todo esse processo.
3 – Proposta Conceptual
3.1 – Visão geral das frameworks
Importa, antes de compreender as alterações que foram efectuadas para o desenvolvimento de uma nova framework, perceber a utilização dos padrões de desenho nas mesmas através da elevação de um nível de abstracção
No caso da Framework Cairngorm torna-se perceptível a rigidez da Framework e como tal também a rigidez com a qual deve ser mantida a utilização da mesma.
Fig. 7 - Estrutura dos padrões de desenho na Framework Cairngorm
Esta estrutura e dinâmica de fluxo já foi explicada em pontos anteriores. Command INTERFACE UTILIZADOR Front Controller Delegate Service Responder Observer (Model) SERVIDOR É lançado o evento Vê o comando correspondente ao evento Delega para o seu gestor Chama o serviço Dados enviados
para o gestor Envia dados para ser tratados pela função correspondente Coloca dados tratados disponíveis Proporciona dados consoante as escolhas do utilizador
No caso da Framework Mate torna-se perceptível a simplicidade da Framework e como tal também a facilidade com que pode existir conflitos no desenvolvimento colaborativo de uma aplicação na utilização desta Framework.
Fig.8 - Estrutura dos padrões de desenho na Framework Mate
Esta estrutura e dinâmica de fluxo já foi explicada em pontos anteriores.
3.2 – Proposta de framework
É preciso então encontrar um meio termo entre estas duas frameworks de forma a poder proporcionar um mecanismo rígido o suficiente para evitar conflitos de programação entre colegas de projecto mas também livre o suficiente para que o arquitecto de sistemas possa tomar opções de configuração da estrutura consoante o projecto em questão. Assim é importante acompanhar um exemplo para se chegar a uma estrutura abstracta que possa ser utilizada também noutras tecnologias.
Este exemplo baseia-se na aplicação que foi construída para a compreensão da Framework Mate e desenvolvimento de uma Framework melhorada. Para começar de uma maneira simples, primeiro foi criado o evento para trazer uma listagem de todos os associados
INTERFACE UTILIZADOR
SERVIDOR Service
Event Handler Injector
Event Map
É lançado o evento
Chama o serviço Retorna os dados entregues pelo servidor Injecta os dados na interface do utilizador
presentes na base de dados. Este é um evento que sucede quando é aberta uma página de associados.
Assim que esta página é mostrada é lançado um evento para a base de dados especificando o que é pedido.
var assocEvent:AssociadosSearchEvent = new
AssociadosSearchEvent(AssociadosSearchEvent.GET); assocEvent.id = -1;
dispatchEvent(assocEvent);
A especificação de assocEvent.id = -1 serve para que a base de dados saiba que são todos os associados, fazendo com que não seja utilizado o filtro de ids criado nas queries em SQL. Assim que se especifica uma ou mais variáveis (havendo a possibilidade de também não ser especificada nenhuma) é então feito o disparo do evento. Um dos problemas do Mate enquanto framework para trabalho colaborativo é não definir como obrigatório a criação de ficheiros de eventos à parte, dando a hipótese de este código ser colocado junto com o disparo do evento ou então dando a hipótese que foi escolhida de criar um ficheiro para cada evento à parte.
Por isso decidiu-se que para a framework que estava a ser ajustada, para um melhor trabalho colaborativo, que esta deveria ter todos os eventos colocados à parte numa única pasta. Cada ficheiro de eventos é então definido do seguinte modo:
“package events{
import flash.events.Event;
public class AssociadosSearchEvent extends Event{
public static const GET: String = "associadosSearch";
public var id:Number = -1;
public var nome:String = "";
public var morada:String = "";
public var telefone:String = "";
public var telemovel:String = "";
public var localidade:String = "";
public var email:String = "";
public var bi:String = "";
public var nib:String = "";
public var sitprof:String = "";
public var nsocio:String = "";
public var ncartaogalp:String = "";
public var nemp:String = "";
