UWER: uma extensão de metodologia em Engenharia Web para

UWE­R: uma extensão de metodologia em Engenharia Web para Rich Internet Applications
Leonardo C. Machado1, Orlando B. Filho1, João A. Ribeiro1
1
Faculdade de Engenharia – Universidade do Estado do Rio de Janeiro (UERJ)
Rua São Francisco Xavier, 524, Pavilhão João Lyra Filho, 5º Andar, Bloco D, sala 5028 20550­900 Rio de Janeiro – RJ – Brazil
[email protected], {orlando,araujo}@eng.uerj.br
Abstract. This paper introduces UWE­R, an extension to an existing Web Engineering Methodology (UWE) to model Rich Internet Applications (RIA). Initially it presents the basic concepts behind RIA and UWE, showing the reasons for choosing this methodology among many others. UWE­R proposed extensions are introduced with an instance model for a real web site with RIA features. This work concludes with future directions and issues to be addressed.
Resumo. Este artigo apresenta a UWE­R, uma extensão a uma metodologia de Engenharia Web existente (UWE) para modelar Rich Internet Applications (RIA). Inicialmente caracteriza­se RIA e a própria UWE, apresentando as razões de sua escolha. As extensões constantes na UWE­R são apresentadas com um modelo exemplo de um web site real com características RIA. Ao final encerra­se com as conclusões e direções futuras.
1. Introdução
Assim como a Internet e a Web revolucionaram o modo como os usuários interagiam com as aplicações, as chamadas RIA (Rich Internet Applications) revolucionaram o modo como os usuários interagem com a Web. Aplicações como Google Maps, GMail, Flickr e tantas outras trazem uma experiência muito mais interativa, mas impõem desafios maiores para sua modelagem. E uma aplicação suficientemente complexa imprescinde de uma modelagem que sustente sua implementação. No entanto, propostas de metodologias para modelagem para RIA são ainda um tópico incipiente. O objetivo deste trabalho é colaborar com o preenchimento dessa lacuna. 2. RIA ­ Rich Internet Applications
Há algumas definições de RIA [Klein, Carlson e McEwann 2007] e [Adobe 2007]. Aqui propõe­se a seguinte: são aplicações que se beneficiam da ubiqüidade da Web e ____________________________________________________________________________________
Hífen, Uruguaiana, v. 32 - nº 62 - II Semestre - Ano 2008 - ISSN 1983-6511
205
melhoram seu modelo de interação tradicional adicionando elementos de interface mais ricos juntamente com um mecanismo flexível e assíncrono de interação com o servidor. A experiência que o usuário final tem é similar ao do mundo desktop.
São inúmeras as tecnologias relacionadas com RIA. A maior parte delas envolve, de algum modo, AJAX. AJAX é a sigla para Asynchronous Javascript with Xml. Com AJAX tem­se um conjunto de tecnologias (XML, DOM, XHTML, Javascript e XMLHttpRequest) que permitem a interação assíncrona com o servidor [Zakas, McPeak e Fawcett 2007]. No entanto, RIA não se limita a AJAX. Tecnologias como Flex da Adobe e Java da Sun Microsystems também oferecem mecanismos assíncronos de comunicação com o servidor e a riqueza na interface gráfica. 3. Metodologias de Engenharia Web
A Unified Modeling Language (UML) tornou­se a linguagem padrão para modelar aplicações orientadas a objetos. Tanto no mundo acadêmico quanto no mundo comercial, seus diagramas e definições são utilizadas em modelos de aplicações em geral. No entanto quando se trata de modelar aplicações Web novos desafios se impõem, pois a navegação, interação com o usuário e tipos de conteúdos não encontram suficiente suporte no núcleo da UML. Tanto é assim que [Preciado, Linaje e Sanchéz 2005] citam 15 diferentes metodologias e linguagens para modelar sistemas Web. Algumas baseiam­se em UML e outras não. RIA são uma evolução das aplicações Web tradicionais. De acordo com os mesmos autores nenhuma dessas metodologias e linguagens são adequadas o suficiente para modelar RIA. RIA possuem uma série de características, como continuidade visual da interface, possibilidade de interação assíncrona com o servidor e incorporação de conteúdo multimídia que não são contempladas satisfatoriamente por nenhuma dessas metodologias. Realizou­se estudo detalhado de cada uma das 15 metodologias referidas pelo trabalho acima, notando quais delas poderiam ser estendidas e incorporar os aspectos de RIA. Em http://leo.webhop.info está o resultado completo desse estudo. Serão resumidas aqui apenas as razões que levaram a escolha da UWE: uso de Orientação a Objetos, sua total aderência a UML e repercussão no meio acadêmico (quantidade de artigos e referências encontradas). Uma das poucas metodologias conhecidas até então para modelagem de RIA como a RUX [Preciado, Linaje e Sanchéz 2008], utiliza­se de uma série de outros padrões e linguagens (XICL, UiML, SMIL e XML Events). Se por um lado talvez sejam mais expressivos, implicam numa curva de aprendizado que será mais custosa ao modelador e desenvolvedor. Com o proposto neste trabalho, basta o conhecimento de UML e algumas extensões expressas em mecanismos da própria UML (estereótipos, valores rotulados e restrições). Uma outra vantagem da UWE­R é a possibilidade de usar qualquer ferramenta case UML existente. ____________________________________________________________________________________
Hífen, Uruguaiana, v. 32 - nº 62 - II Semestre - Ano 2008 - ISSN 1983-6511
206
4. Fundamentos da UWE
Para entender as extensões propostas pela UWE­R é preciso conhecimento prévio da UWE [Koch, Knapp, Zhang e Baumeister 2008] e [Kroiβ e Koch 2008]. Resumiremos aqui algumas de suas características.
A UWE é um perfil (profile) de UML ou uma extensão leve (ou seja, baseada apenas em estereótipos, valores rotulados (tagged values) e restrições (constraints)). Pode ser utilizada em qualquer ferramenta CASE que suporte essas características que são padrão da UML. Como extensão à UML, a UWE expressa seus estereótipos e diagramas na forma de um metamodelo. O metamodelo é uma expressão usando a própria UML para demonstrar novos conceitos não cobertos por esta linguagem originalmente. A UWE é uma extensão conservadora (ou profile) da UML 2.0. Por “conservadora” entenda­se que nenhum dos elementos originais da UML (Classe, Associação etc.) são alterados. Todos os elementos do metamodelo da UWE são referenciados como extensões (mecanismo semelhante a herança entre classes) de elementos existentes na UML. Para definir a semântica estática desses novos elementos é utilizada a OCL (Object Constraint Language). Como é compatível com MOF (Meta­
Object Facility), um modelo escrito baseado no metamodelo da UWE pode ser lido em outras ferramentas capazes de tratar o formato XMI (XML Metadata Interchange). Como preconizado no documento de superestrutura da UML [OMG, 2007], no modelo de exemplo, uma metaclasse do metamodelo se transforma num estereótipo, um atributo da metaclasse se transforma num valor rotulado (tagged value) e um papel transforma­
se numa restrição (constraint) expressa com OCL (por exemplo, descrita dentro de um elemento “nota” da UML). No metamodelo da UWE existem dois pacotes de alto nível (Core e Adaptivity). Dentro do pacote Core encontram­se os principais subpacotes da UWE: Requisitos, Conteúdo, Navegação, Apresentação e Processos. A UWE­R apresenta extensões no pacote de Navegação, Apresentação e Processos. 5. UWE­R
A UWE­R não pretende ser uma metodologia completa de modelagem Web no contexto de RIA. Seu foco é nos aspectos de navegação e organização dos elementos de interface gráfica na tela do usuário (apresentação). Isso não só porque esses aspectos são os mais peculiares a RIA, mas também porque os demais aspectos de uma modelagem (como análise de requisitos e modelagem de dados) já se encontram suficientemente cobertos em outras abordagens e na própria UWE. De acordo com o referido documento de superestrutura da UML, para se fazer um perfil (extensão leve) as metaclasses já existentes na UWE não podem ser modificadas. Todas as modificações, portanto, se resumiram em acréscimos de ____________________________________________________________________________________
Hífen, Uruguaiana, v. 32 - nº 62 - II Semestre - Ano 2008 - ISSN 1983-6511
207
metaclasses para incorporar os conceitos de RIA.
5.1. Alterações no pacote de Navegação
A UWE já prevê uma metaclasse para navegação (NavigationClass), mas na sua definição há restrições típicas de aplicações Web tradicionais, uma vez que lá se refere a “estrutura de hipertexto” e há uma relação direta dela para a classe de conteúdo respectiva, pois ela serve de representação daquela no modelo de navegação. No caso de RIA esse cenário pode ser mais complexo. Quando se está num ponto da navegação de um site como o Google Maps, a estrutura não é toda em hipertexto e há várias classes de conteúdo representadas ali. Portanto, é preciso que se crie uma nova metaclasse que represente tal fato. Esta metaclasse tem que herdar de Node, para manter a estrutura da UWE e também terá uma relação de composição com NavigationProperty. Se não fossem as restrições de perfis da UML, poderia ser aproveitada a classe NavigationClass, se seu conceito fosse alterado. Tal nova metaclasse foi chamada de RichNavigationClass. Além disso, é preciso que um novo conceito de Link. NavigationLink é capaz de ligar apenas nós diferentes de processos. No caso de RIA, alguns links podem implicar na execução de processos locais ou remotos, cujos resultados modificam um nó de navegação retornando ao mesmo nó que já era apresentado. Ou seja, existe uma ligação entre um nó (RichNavigationClass), um processo e de volta ao mesmo nó, com alterações de alguns atributos. Além disso há características de assincronia que são importantes de serem modeladas neste novo tipo de link e que fazem com que não se possa aproveitar o já existente ProcessLink. Criou­se então RichNavigationLink. Abaixo à esquerda segue o diagrama das novas metaclasses da UWE­R (em cinza). São apresentadas apenas as metaclasses da UWE (em branco) com que elas se relacionam diretamente. Abaixo à direita, um instância deste metamodelo para o site Google Maps exemplificando o caso de uso de busca de endereço. Figura 1. UWE­R: extensões à Navegação
Uma classe para representar um diálogo (também conhecido como janela de pop­up) foi acrescentada para representar este elemento de navegação que se sobrepõe ____________________________________________________________________________________
Hífen, Uruguaiana, v. 32 - nº 62 - II Semestre - Ano 2008 - ISSN 1983-6511
208
de maneira especial aos nós já existentes.
Um <<richNavigationLink>> poderá ser uma chamada assíncrona para um processo (atributo isAsynchronous da metaclasse) ou denotar que se trata de um callback do processo para a classe de navegação. O atributo result permite que se denote num mesmo diagrama, navegações diferentes dependendo do resultado do processo (vide valores rotulados mapFound e mapNotFound na Figura 1). 5.2. Alterações no pacote de Apresentação
Do ponto de vista da Apresentação algumas extensões são necessárias para representar a riqueza de elementos de interface gráfica de RIA. No entanto não é necessário criar nenhuma metaclasse nova a herdar de PresentationClass. Esta já prevê em sua definição o aninhamento (através das chamadas árvores de inclusão) de vários elementos de apresentação, que são mostrados concomitantemente (permitindo uma continuidade visual).
Assim sendo foram criadas metaclasses que herdam de UIContainer (Canvas, Panel e suas subclasses: AccordeonPanel, TabbedPanel e TreePanel) e de UIElement (Audio, Video e DialogueWindow). Abaixo à esquerda, o diagrama do pacote de Apresentação apenas com as metaclasses novas (em cinza) e as suas relações diretas. Abaixo à direita um exemplo modelando a apresentação do site Google Maps:
Figura 2. UWE­R: extensões à Apresentação
A metaclasse Canvas é a principal do ponto de vista de RIA. Trata­se de uma área livre de desenho onde eventos de mouse são capturados e outros elementos de interface (imagens, outros Canvas etc.) podem ser sobrepostos. Até antes desta extensão, a UWE só oferecia dois tipos de UIContainer: Form e AnchoredCollection. Tais elementos fazem com que a expressão de mapas ou jogos numa aplicação RIA não sejam possíveis de se modelar. Com o Canvas isso se resolve. Um Canvas pode conter uma ou várias imagens (sendo que essas imagens podem ser vetoriais ou raster). Um jogo pode ser modelado como possuindo várias camadas (representadas por Canvas), em que se tem uma camada de fundo e cada elemento móvel da tela seria uma outra camada, todas capturando eventos de mouse. ____________________________________________________________________________________
Hífen, Uruguaiana, v. 32 - nº 62 - II Semestre - Ano 2008 - ISSN 1983-6511
209
A metaclasse abstrata Panel foi criada com o intuito de oferecer um container que não tivesse, necessariamente, uma aparência visual, mas que fosse capaz de sugerir uma ordenação visual dos elementos de interface gráfica na tela. Algumas subclasses de exemplo foram criadas para representar essa organização como um painel com abas, em formato de árvore ou acordeão (painéis que se sobrepõem como pastas com efeito de animação).
Muito da riqueza presente em aplicações RIA vem da possibilidade de se ter vídeo e áudio nas páginas, por isso a criação das metaclasses Audio e Video. DialogueWindow completa as extensões neste pacote.
5.3. Alterações no pacote de Processos
Neste pacote três são as extensões: diferenciação entre processo cliente e processo servidor, uso de diagrama de seqüência com uma mensagem de tipo específico (ControlMessage) e criação de um tipo de ação autônoma (AutonomousAction) para modelar ações que independem do usuário. Abaixo à esquerda, um extrato do diagrama de metaclasses desse pacote. À direita um exemplo de diagrama de seqüência que ilustra o processo de pré­carga de um mapa no Google Maps:
Figura 3. UWE­R: extensões aos Processos
A diferenciação entre processo cliente (que roda no browser através de script ou plugin) e processo servidor (que roda no servidor Web ou servidor de aplicação) é fundamental no contexto de RIA. Como para este tipo de aplicação há uma porção do código que fica no lado do cliente, é muito importante ter mecanismos para indicar isso durante a modelagem do sistema. O pacote de processo da UWE tem três tarefas: 1) integração entre processos de negócio e modelo de navegação, 2) definição de uma interface de usuário para dar suporte ao processo e 3) definição do comportamento. No caso de RIA como existem comunicações assíncronas com o servidor e os dados muitas vezes não são simples parâmetros enviados por HTTP GET ou POST, mas sim em formato XML (usando ou não SOAP), JSON e outros, faz­se necessária a utilização de diagramas de seqüência que explicitem essas comunicações. Além disso, é necessário um tipo de mensagem ____________________________________________________________________________________
Hífen, Uruguaiana, v. 32 - nº 62 - II Semestre - Ano 2008 - ISSN 1983-6511
210
específica que tenha essas informações. Criou­se a ControlMessage que estende o conceito da metaclasse Message (da UML, pacote BasicInteractions). Tem esse nome, por se tratar de uma mensagem entre a camada de controle e de modelo (do padrão de projetos Model­View­Controller ­ MVC). Message já possui um atributo (messageSort) que indica se uma mensagem é assíncrona ou não, portanto não é preciso criar esse atributo. Os novos atributos de ControlMessage são: isCallback (apenas será denotada quando se tratar de um callback do servidor para o cliente), protocolType (tipo do protocolo. Valores reservados: “LOCAL” para chamadas locais no cliente, “HTTP” para simples GET ou POST, “FTP”, “REST” e “SOAP”), dataType (tipo do dado enviado ou recebido. Valores reservados: “JSON”, “XML”,”KML”, “GML” e “STRING”) e dataTypeDefinition (definição do tipo: elemento do Schema ou DTD que define o XML ou referência da EBNF que define o JSON). Um exemplo de sua utilização é dada na Figura 3 (diagrama da direita): nele é feita uma requisição assíncrona de uma classe do cliente para requisitar uma camada do mapa (elemento mapCentroid definido em um Schema), e a resposta (elemento mapResponse definido em um Schema) vem de modo síncrono, do servidor como uma callback. Assim, durante a modelagem do projeto da aplicação tem­se uma noção muita clara de como os dados serão trocados, de que tipo e com que freqüência. Isso é particularmente importante para que a aplicação RIA tenha de fato, não só do ponto de vista de aparência da tela, mas do ponto de vista de interação do usuário a “riqueza” que carrega em seu nome. Isso é dito aqui, pois muitos sites desenvolvidos hoje com tecnologias RIA claramente carregam em seus projetos as mesmas idéias das aplicações Web tradicionais. Muitas delas não se beneficiam das interações assíncronas e a experiência do usuário acaba sendo “pobre” (como no modelo tradicional). Com um diagrama como o acima, fica evidenciado se a aplicação em questão aproveita­se dessas interações ou não já na fase de modelagem.
A última extensão proposta neste pacote é a criação da AutonomousAction. Tal ação diferencia­se da UserAction da UWE, pois esta última implica na interação do usuário. Ora, em RIA, uma determinada ação pode ser executada por um evento do browser (ao carregar uma página, por exemplo), por um temporizador ou pela chegada de uma mensagem de callback. São atributos desta metaclasse: triggerType (o tipo de gatilho para sua execução. Valores reservados: “EVENT” para eventos do browser, “TIMER”, para temporizador e “ONCALLBACK” para recebimento de callbacks), triggerName (nome do evento do browser ou da função de callback. Não é utilizado para temporizador) e triggerParameters (série de parâmetros para os eventos do browser ou da função de callback se for necessário, ou valor do tempo no caso de “TIMER”). Um exemplo também está na Figura 3, à direita: à requisição de mapas no entorno do mapa atual é feita de temporalmente de modo assíncrono. Ao deslocar o mapa, o usuário tem a ilusão de aplicação desktop, pois os mapas vizinhos já estão disponíveis. ____________________________________________________________________________________
Hífen, Uruguaiana, v. 32 - nº 62 - II Semestre - Ano 2008 - ISSN 1983-6511
211
6. Conclusões
A modelagem do Google Maps com a UWE­R é apresentada apenas parcialmente aqui (a modelagem completa encontra­se em http://leo.webhop.info). No entanto já é possível notar a capacidade expressiva da UWE­R. Uma vantagem desta proposta é aproveitar os conceitos e ferramentas já existentes. Sua utilização necessita de uma maior quantidade de testes. Há também espaço para criação de mais elementos, notadamente aqueles que representam a interface gráfica no modelo de Apresentação. Uma formalização do metamodelo da UWE­R é outro dos melhoramentos futuros. Apesar disso, apresenta­se como uma alternativa factível para a modelagem de RIA.
Referências
Adobe (2007). “Rich Internet Applications”, http://www.adobe.com/resources/business/rich_internet_apps/, Março.
Google Maps, (2007), “Google Maps”. http://maps.google.com/, Agosto.
Klein, N., Carlson, M. e McEwann, G., (2007), Laszlo in Action, Manning Publications, 1a. edição, Capítulo1. Koch, N. e Kraus, A., (2002), “The Expressive Power of UML­based Engineering”, Em: Second International Workshop on Web Oriented Software Techonlogy, CYTED, Páginas 105­119.
Koch, N., Knapp, A., Zhang, G. e Baumeister, H., (2008), “UML­Base Web Engineering – An approach based on standards”, capítulo 7 de Web Engineering: Modelling and Implementing Web Applications, Springer Verlag, páginas 143­177, 1a. edição.
Kroiβ, C. e Koch, N., (2008), “The UWE Metamodel and Profile – User Guide and Reference”, Technical Report 0802. http://www.pst.informatik.uni­
muenchen.de/projekte/uwe/download/UWE­Metamodel­Reference.pdf, Agosto.
Preciado, J., Linaje, M. e Sanchéz, F., (2005), “Necessity of methodologies to model Rich Internet Applications”, Em: Proceedings of the 2005 Seventh IEEE International Symposium on Web Site Evolution (WSE’05), Budapeste.
Preciado, J., Linaje, M. e Sanchéz, F., (2008), “Enriching Model­based Web Applications Presentation”, Journal of Web Engineering, Vol. 7, Número 3, páginas 239­256. OMG, (2007), “OMG Unified Modeling Language (OMG UML), Superstructure, V2.1.2”. http://www.omg.org/spec/UML/2.1.2/Superstructure/PDF/, Agosto.
Zakas, N., McPeak, J. e Fawcett, J. (2007), Professional AJAX, Wiley Publishing, Inc., 2a. Edição, páginas. 299­335. ____________________________________________________________________________________
Hífen, Uruguaiana, v. 32 - nº 62 - II Semestre - Ano 2008 - ISSN 1983-6511
212